반응형
AWS DEA-C01 › Domain 1 · 전체 압축 정리
Domain 1 — 데이터 수집·변환·오케스트레이션
핵심만 압축 정리
Task 1~4 · 시험에 나오는 것만 · 비유 & 비교표 중심
1.1
34%
데이터 수집 (Ingestion)
Task 1 · 어떤 서비스로 데이터를 가져올 것인가
| 서비스 | 한 줄 비유 | 핵심 특징 | 온프렘 대응 |
|---|---|---|---|
| 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)
Firehose = 완전 서버리스, 목적지까지 자동 Push, 최소 60초 버퍼링 (완전 실시간 X)
1.2
SQL vs Spark — 변환 방식 선택 기준
데이터 변환 (Transformation)
Task 2 · SQL? 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 (변환 먼저)
원본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) 활용 필요할 때
MWAA = 기존 Airflow DAG 코드 재사용, Python 생태계(Operator/Hook) 활용 필요할 때
1.4
코드 최적화 — 런타임 단축 8대 전략
프로그래밍 개념 적용
Task 4 · 코드 최적화, IaC/CI/CD, 알고리즘
| # | 전략 | 핵심 포인트 |
|---|---|---|
| 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 |
- ✅메모리 = CPU 비례 — 메모리 늘리면 CPU도 함께 증가 → 처리 빨라져 총비용 절감 가능
- ✅프로비저닝된 동시성 — 콜드 스타트 방지 (지연시간 민감 파이프라인 필수)
- ✅타임아웃 설정 — 예상 실행 시간 기준. 너무 짧으면 조기 종료, 너무 길면 비용 낭비
- ✅비동기 호출 — 즉각 응답 불필요 시 사용 (처리량 향상)
- ⚠️VPC 배치 시 지연 추가 — 동일 VPC에 배치 + ElastiCache 캐시 활용으로 지연 최소화
| 도구 | 방식 | 용도 |
|---|---|---|
| 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 열 이름 = 영숫자 + 밑줄만. 특수문자 불가
반응형
'Stack > AWS' 카테고리의 다른 글
| AWS DEA-C01 Domain 3 핵심 요약 — CloudWatch·Step Functions·CI/CD 정리 (1) | 2026.03.20 |
|---|---|
| AWS DEA-C01 Domain 2 핵심 요약 — S3·Redshift·DynamoDB 언제 쓰나 (0) | 2026.03.20 |
| AWS DEA-C01 시험 범위 한눈에 정리 — AWS 처음인데 합격할 수 있을까? (1) | 2026.03.18 |
| AWS DEA-C01 공식 샘플 문제 — OpenSearch 실전 문제 + 정답 해설 (0) | 2026.03.16 |
| AWS DEA-C01 데이터 엔지니어 기초 — 수명주기·ETL·파이프라인 완전 정리 (0) | 2026.03.15 |
