[AWS DEA] 개념정리 - Domain1 데이터 수집·변환·오케스트레이션

AWS DEA-C01 › Domain 1 · 전체 압축 정리

Domain 1 — 데이터 수집·변환·오케스트레이션
핵심만 압축 정리

Task 1~4 · 시험에 나오는 것만 · 비유 & 비교표 중심

34%Domain 1

26%Domain 2

22%Domain 3

18%Domain 4

1.1

데이터 수집 (Ingestion)

Task 1 · 어떤 서비스로 데이터를 가져올 것인가

34%

서비스	한 줄 비유	핵심 특징	온프렘 대응
Kinesis Data Streams	실시간 컨베이어 벨트	직접 Pull. 샤드 단위 처리량. 기본 24시간 보존	Apache Kafka
Kinesis Data Firehose	자동 배달 트럭	완전 서버리스. S3/Redshift/OpenSearch 자동 전달. 변환·압축 내장	—
Amazon MSK	대형 우체국	완전관리형 Kafka. 기존 Kafka 코드 그대로. 오프셋 보존	Kafka 그대로
AWS IoT Core	스마트홈 허브	수십억 IoT 디바이스. MQTT. 규칙 엔진 → Kinesis/Lambda	—
AWS DMS	무중단 이사 업체	이기종 DB 마이그레이션. CDC 실시간 복제	온프렘 Oracle → RDS
Amazon AppFlow	SaaS 자동 동기화	코드 없이 Salesforce·Slack → S3/Redshift	—
AWS DataSync	창고 간 동기화 트럭	온프렘 NAS ↔ S3/EFS. 암호화·검증 포함	NFS/SMB → S3
AWS Transfer Family	구식 우편배달부	FTP/SFTP/FTPS 수신 → S3 저장	—
Amazon SQS	대기표 번호 기계	메시지 큐. FIFO(순서 보장) vs Standard. 시스템 디커플링	—
Amazon SNS	방송 스피커	Pub/Sub. 1:N 발송. 이메일·Lambda·SQS 동시 전달	—

⚠️ Kinesis Streams vs Firehose 시험 구분 포인트 Streams = 소비자가 직접 Pull, 샤드 관리 필요, 실시간 처리 가능 (Lambda/KCL로 소비)
Firehose = 완전 서버리스, 목적지까지 자동 Push, 최소 60초 버퍼링 (완전 실시간 X)

---

1.2

데이터 변환 (Transformation)

Task 2 · SQL? Spark? 어디서 변환할 것인가

SQL vs Spark — 변환 방식 선택 기준

🗄️ SQL 선택

• 팀이 SQL에 익숙한 환경
• 대상이 Redshift (ELT)
• 단순 집계·조인 위주
• Athena, Redshift, Glue Studio

⚡ Spark 선택

• 복잡한 커스텀 변환 로직
• 지연시간·처리량 요구 엄격
• ML 파이프라인(Spark ML) 포함
• AWS Glue(서버리스) / EMR(클러스터)

서비스	방식	관리	핵심 특징	온프렘
AWS Glue ETL	PySpark	서버리스	Glue Studio(GUI), DataBrew(노코드). 스키마 진화 지원	Spark ETL
AWS Glue Crawler	자동 스캔	서버리스	S3/RDS 스캔 → 스키마 자동 추론 → Data Catalog 등록	—
Amazon EMR	Spark/Hive/Flink	EC2 클러스터	최고 제어권. Spot Instance 비용절감. 대규모 복잡 처리	Spark 클러스터
Kinesis Data Analytics	SQL / Flink	서버리스	Streams/MSK 위에서 실시간 스트림 분석. 윈도우 집계	Apache Flink
AWS Lambda	코드(Python 등)	서버리스	이벤트 기반. 최대 15분. 간단한 변환·라우팅	—

ETL vs ELT 흐름 비교

🔧 ETL (변환 먼저)

원본S3/DB

→

변환Glue/EMR

→

S3 Staging

→

Redshift

Redshift 부하 ↓, 복잡한 변환 가능, 중간 스토리지 비용 발생

🔁 ELT (적재 먼저)

원본S3/DB

→

Redshift(Raw)

→

SQL 변환내부 처리

파이프라인 단순, SQL 기반, Redshift 부하 증가

⚠️ Athena 열 이름 규칙 — 시험 출제 Athena는 영숫자 + 밑줄(_)만 허용. /var/log → var_log 으로 변환 필요. 슬래시·공백·마침표 불가.

---

1.3

파이프라인 오케스트레이션

Task 3 · 어떤 순서로, 어떻게 자동으로 실행할 것인가

서비스	한 줄 비유	핵심 특징	선택 시나리오
AWS Step Functions	요리 레시피 관리자	상태 머신(ASL). Lambda·Glue·EMR 연결. 재시도·에러처리 내장. 시각적 편집	서버리스 워크플로, 단계별 에러 제어
Amazon MWAA	공사 현장 일정 관리자	완전관리형 Airflow. DAG Python 코드 → S3 저장. 의존성 기반 스케줄	기존 Airflow 코드 그대로 클라우드 이전
Amazon EventBridge	자동 반응 알람 시스템	이벤트 버스. AWS 이벤트 + cron 스케줄 → Lambda/Step Functions 트리거	이벤트 기반 자동 트리거
AWS Batch	야간 대량 생산 라인	EC2/Spot/Fargate 위 컨테이너 배치. 작업 큐·의존성 관리. 수시간 이상 처리	Lambda 15분 초과하는 대규모 배치

💡 Step Functions vs MWAA 선택 기준 Step Functions = 서버리스·간결한 워크플로·AWS 서비스 직접 연동 우선일 때
MWAA = 기존 Airflow DAG 코드 재사용, Python 생태계(Operator/Hook) 활용 필요할 때

---

1.4

프로그래밍 개념 적용

Task 4 · 코드 최적화, IaC/CI/CD, 알고리즘

코드 최적화 — 런타임 단축 8대 전략

#	전략	핵심 포인트
01	병렬 처리	Glue/EMR → Spark 파티션별 병렬 실행
02	배치 처리	오버헤드 감소. Glue·EMR 배치 처리 내장
03	컬럼 기반 포맷	Parquet / ORC → 압축률 우수, 스캔 범위 최소화. Athena 비용 대폭 절감
04	조기 필터링	WHERE 조건을 소스 레벨에서 처리 (Predicate Pushdown)
05	파티셔닝	날짜/리전 기준 분할. S3 경로: year=2024/month=03/
06	데이터 압축	Gzip·Snappy. 스토리지 비용↓ + 전송 속도↑
07	메모리·리소스 최적화	Spark executor 메모리·코어 수 조정. 병목 방지
08	증분 처리 (Incremental)	마지막 실행 이후 델타만 처리. 전체 재처리 X

Lambda 최적화 체크리스트

• ✅메모리 = CPU 비례 — 메모리 늘리면 CPU도 함께 증가 → 처리 빨라져 총비용 절감 가능
• ✅프로비저닝된 동시성 — 콜드 스타트 방지 (지연시간 민감 파이프라인 필수)
• ✅타임아웃 설정 — 예상 실행 시간 기준. 너무 짧으면 조기 종료, 너무 길면 비용 낭비
• ✅비동기 호출 — 즉각 응답 불필요 시 사용 (처리량 향상)
• ⚠️VPC 배치 시 지연 추가 — 동일 VPC에 배치 + ElastiCache 캐시 활용으로 지연 최소화

IaC / CI/CD 도구 구분

도구	방식	용도
CloudFormation	YAML/JSON 템플릿	인프라 전체 정의·배포. 스택 단위 관리
AWS CDK	Python·TypeScript 등 실제 언어	코드로 인프라 정의. 재사용 가능한 Construct 패턴
AWS SAM	CloudFormation 확장	Lambda·Step Functions·DynamoDB 서버리스 파이프라인 전용 배포
CodeCommit/GitHub	소스 코드 저장소	템플릿·스크립트 버전 관리 → 커밋 시 CI/CD 자동 트리거

📝 시험 시나리오 — 데이터 손실 복구

Kinesis → Java 앱 → OpenSearch 파이프라인에서 데이터 손실 발생. 코드로 복구할 수 있나?

멱등성 처리(Idempotent Processing) 적용 + 샤드 반복기(Shard Iterator)가 오류 발생 전 샤드 위치를 가리키도록 수정. 같은 메시지를 여러 번 처리해도 결과가 동일하므로 재처리 시 중복 없음.

---

🎯 Domain 1 시험 핵심 — 이것만 기억

• ①Kinesis Streams vs Firehose — Streams=Pull(직접 소비), Firehose=Push(자동 전달·서버리스)
• ②MSK vs Kinesis — MSK=기존 Kafka 코드 그대로, Kinesis=AWS 네이티브·샤드 관리
• ③Glue vs EMR — Glue=서버리스 Spark, EMR=클러스터 직접 관리(Spot 비용절감)
• ④ETL vs ELT — ETL=Redshift 부하↓(Spark 선처리), ELT=Redshift 내부 SQL 변환(단순)
• ⑤Step Functions vs MWAA — Step=서버리스 AWS 연동, MWAA=기존 Airflow 코드 이전
• ⑥최적화 3대 포인트 — Parquet/ORC 포맷 + 파티셔닝 + 증분 처리
• ⑦Lambda 콜드스타트 → 프로비저닝된 동시성으로 해결
• ⑧서버리스 IaC = AWS SAM, 전체 인프라 = CloudFormation/CDK
• ⑨멱등성 + 샤드 반복기 = Kinesis 데이터 손실 복구 방법
• ⑩Athena 열 이름 = 영숫자 + 밑줄만. 특수문자 불가

AWS DEA-C01 Domain 1 압축 정리 · hyeonlee.net

Domain 2 정리도 확인해보세요 😊