Day 5 - Week 5 종합: 데이터 변환 2 — 엔진·오케스트레이션·최적화 통합 복습

한눈에 보는 Week 5 지도

이번 주는 "데이터를 어떻게 변환하고, 어떻게 흐름을 조율하며, 어떻게 싸고 빠르게 만드는가"를 다뤘다. Week 4까지의 Glue가 서버리스 ETL의 기본이었다면, Week 5는 그 주변을 둘러싼 더 큰 도구 상자다 — 대규모 처리를 위한 EMR, 경량 이벤트 처리를 위한 Lambda, 흐름을 엮는 오케스트레이션, 그리고 모든 것을 관통하는 성능·비용 최적화다. 오늘은 이 네 축을 하나의 의사결정 지도로 다시 묶는다.

[변환 엔진 선택]          [오케스트레이션]         [최적화 레이어]
 Lambda  : 경량·이벤트      Step Functions: AWS네이티브   포맷: Parquet/ORC
 Glue    : 서버리스 ETL     MWAA(Airflow) : 복잡·멀티     압축: Snappy/Zstd
 EMR     : 대규모·제어      Glue Workflows: Glue전용      파티션: 날짜 등
 EMR S.  : 서버리스 빅데이터                              파일크기: 128MB~1GB

이 세 열은 독립적이지 않다. 실제 파이프라인은 "오케스트레이터가 변환 엔진들을 순서대로 호출하고, 그 결과를 최적화된 포맷·파티션으로 저장"하는 식으로 세 축이 맞물린다.

1) 변환 엔진 선택: 규모와 제어의 저울

Day 1~2의 핵심은 "작업 규모와 운영 부담의 트레이드오프"다.

EMR에서 반드시 기억할 점: Core 노드(저장+연산)는 온디맨드, Task 노드(연산 전용)는 스팟. 영구 데이터는 S3(EMRFS)에 두고 Transient 클러스터로 작업 시에만 띄워 비용을 아낀다. HDFS는 임시 저장소다.

🎯 시나리오: 한 회사의 파이프라인을 설계한다. (1) IoT 기기가 S3에 작은 JSON을 끊임없이 올린다 → Lambda가 도착 즉시 정제. (2) 매일 새벽 누적 데이터를 대규모 집계 → EMR Transient(스팟 Task) 또는 Glue. (3) 결과를 분석용으로 저장 → Parquet + 날짜 파티션. (4) 전체 흐름 조율 → Step Functions. 각 도구가 강점 영역에서만 쓰인다는 점이 핵심이다.

2) 오케스트레이션: 흐름을 엮는 세 도구

Day 3의 결론은 키워드 매칭으로 정리된다.

함정 재확인: "단계가 많다 = MWAA"가 아니다. 전부 AWS 서비스이고 저운영을 원하면 Step Functions가 맞다. MWAA의 단서는 "Airflow 자산", "멀티 환경", "복잡한 Python 로직"이다.

세 도구가 모두 DAG를 쓰는 이유는 비순환 그래프가 위상 정렬 가능해 "의존성 충족 순서"로 실행하고 독립 작업을 병렬화할 수 있기 때문이다. 오케스트레이션은 결국 "DAG를 정의하고 실행 보장(재시도·멱등성·가시성)을 제공하는 일"이며, 세 도구는 그 실행 보장을 각각 서버리스/표준Airflow/Glue내장 방식으로 제공한다.

3) 최적화: 읽을 데이터 최소화

Day 4의 네 무기는 우선순위 순으로 외운다.

1. 포맷: CSV/JSON → Parquet/ORC(컬럼 프루닝 + 통계 스킵)
2. 압축: 분할 가능한 Snappy/Zstd. 거대 단일 Gzip 텍스트 금지(병렬성 죽음)
3. 파티셔닝: 자주 필터하는 저카디널리티 컬럼(날짜·지역). 고카디널리티 금지(작은 파일 폭증)
4. 파일 크기: 128MB~1GB로 컴팩션. 작은 파일 수만 개는 오버헤드 지옥

포맷 구분 한 줄 요약: 분석 쿼리 = Parquet/ORC(열 기반), 스키마 진화·빠른 쓰기 = Avro(행 기반).

⚠️ 함정: 최적화 문제는 보통 여러 처방을 동시에 요구한다. "Athena 비용 급증" 시나리오의 정답은 "Parquet으로 바꾼다" 하나가 아니라 포맷 전환 + 파티셔닝 + 컴팩션의 조합인 경우가 많다. 보기에서 "가장 효과적인 단일 조치"를 물으면 포맷(열 기반) 또는 파티셔닝이 보통 1순위지만, "모두 적용하라"형 문제도 나온다.

통합 의사결정 플로우

문제를 만났을 때의 사고 순서:

Q1. 처리 규모는? 
    작음/이벤트 → Lambda
    중~대 서버리스 → Glue / EMR Serverless
    매우 큼/생태계 다양/비용 제어 → EMR on EC2

Q2. 흐름을 어떻게 조율?
    AWS 네이티브 서버리스 → Step Functions
    Airflow 자산/멀티 환경 → MWAA
    순수 Glue → Glue Workflows

Q3. 저장은 어떻게 최적화?
    Parquet + Snappy + 날짜 파티션 + 128MB~1GB

한도와 실행 모델 비교: 숫자가 선택을 가르는 지점

엔진 선택 문제의 오답은 대개 한도에 걸려서 탈락한다. 네 엔진을 같은 항목으로 놓고 본다.

• Lambda의 나머지 한도도 같이 묶어 둔다. /tmp 임시 저장소는 512MB~10,240MB, 페이로드는 동기 6MB·비동기 1MB다(비동기 한도는 오랫동안 256KB였으므로 시험 자료에는 256KB로 나올 수 있다). CPU는 메모리에 비례해 배정되므로 CPU가 모자란 함수는 메모리를 올려야 빨라진다.
• EMR Serverless의 사전 초기화 용량은 워커를 미리 데워 두어 작업을 몇 초 안에 시작하게 해 주지만, 그만큼 유휴 비용이 생긴다. "간헐적 배치, 유휴 비용 없음"이 조건이면 켜지 않는다.
• "30분 걸리는 단일 파일 변환"은 데이터가 작아도 Lambda로는 안 된다. 크기가 아니라 시간 한도가 탈락 사유다.

Step Functions Standard와 Express: ETL에서 갈리는 지점

Day 3에서는 실행 시간(1년 대 5분)으로만 구분했다. ETL 오케스트레이션에서는 그보다 중요한 차이가 있다.

• ETL 오케스트레이션의 기본은 Standard다. Glue Job이나 EMR Step은 몇 분에서 몇 시간이 걸리고, glue:startJobRun.sync처럼 끝날 때까지 기다리는 통합 패턴은 Express에서 쓸 수 없다.
• Standard는 멱등하지 않은 작업을 맡겨도 된다. 같은 상태가 두 번 실행되지 않으므로(Retry를 적은 경우 제외) EMR 클러스터 생성 같은 작업에 맞다. Express는 한 번 더 실행될 수 있어 멱등한 작업에만 쓴다.
• 과금 직관이 반대다. Standard는 단계가 많을수록, Express는 오래·자주 돌수록 비싸다. 초당 수백 건의 짧은 이벤트를 Standard로 돌리면 상태 전이 수가 폭증한다.
• 워크플로 유형은 상태 머신을 만든 뒤에는 바꿀 수 없다.

실패는 누가 다시 시도하는가

파이프라인 장애 문제는 "어느 계층이 재시도하고, 실패가 어디에 남는가"를 묻는다.

⚠️ 함정: 재시도를 여러 계층에 겹쳐 두면 곱해진다. Step Functions의 Retry 3회와 Glue Job 자체의 재시도 3회를 함께 걸면, 한 번의 장애에 Job이 최대 16번 실행될 수 있다. 재시도는 한 계층(보통 오케스트레이터)에만 두고, 재실행되어도 결과가 같도록 출력은 덧붙이기가 아니라 파티션 단위 덮어쓰기로 설계한다.

EMR에서 한 번 더 짚을 것

• 스팟 Task 노드가 안전하다는 말의 전제. Task 노드는 HDFS DataNode를 돌리지 않으므로 회수되어도 데이터는 잃지 않는다. 하지만 작업을 지휘하는 YARN 애플리케이션 마스터가 그 노드에 올라가 있었다면 작업 자체가 실패한다. EMR 6.x부터는 애플리케이션 마스터가 Core·Task 어디에나 올라갈 수 있는 것이 기본값이므로, 스팟 비중이 크면 노드 레이블로 Core(또는 온디맨드) 노드에만 두도록 설정한다.
• Primary 노드는 3대로 구성해 고가용성을 확보할 수 있다. 1대 구성에서는 Primary가 단일 장애점이다. 스팟으로 두면 안 되는 이유다.
• Managed Scaling은 최소·최대 용량만 정해 두면 EMR이 지표를 보고 Core·Task 노드를 늘리고 줄인다. YARN 기반 애플리케이션(Spark·Hive·Flink 등)에만 동작하고 Presto·HBase에는 적용되지 않는다. Primary 노드는 조정 대상이 아니다.
• Instance Fleets는 구매 옵션과 인스턴스 타입의 혼합이 기본 기능이라 스팟 용량 확보에 유리하다. Instance Groups는 그룹마다 타입과 구매 옵션이 하나씩이다.

과금 구조 한 표

시나리오 연습: 오답을 먼저 걸러내기

다음 주는 데이터를 저장·서빙하는 쪽 — 데이터 웨어하우스와 카탈로그 영역으로 넘어간다. 변환된 데이터가 어디에 어떻게 안착하는지를 다룬다.

📖 용어

• Transient 클러스터 : 작업을 시작할 때 띄우고 끝나면 자동으로 종료하는 일회성 EMR 클러스터.
• EMRFS : EMR이 S3를 파일 시스템처럼 읽고 쓰게 해 주는 계층. 데이터를 클러스터 밖에 영구 보관하게 해 준다.
• Core / Task 노드 : Core는 HDFS 저장과 연산을 함께 하고, Task는 연산만 한다. Task는 사라져도 데이터가 남아 스팟에 적합하다.
• 콜드 스타트 : Lambda가 실행 환경을 새로 만드느라 첫 호출이 느려지는 현상.
• 상태 전이 : Step Functions에서 한 단계가 끝나 다음 단계로 넘어가는 것. Standard 워크플로의 과금 단위다.
• DAG : 작업을 노드로, 의존 관계를 화살표로 그린 순환 없는 그래프. 오케스트레이터가 실행 순서를 정하는 기준이다.
• 컬럼 프루닝 : 열 기반 포맷에서 쿼리에 필요한 컬럼만 골라 읽는 최적화.
• 파티션 프루닝 : 조건에 맞는 파티션 폴더만 읽고 나머지는 열지 않는 최적화.
• 컴팩션 : 작은 파일 여러 개를 적정 크기의 큰 파일로 합치는 작업.
• 멱등성 : 같은 작업을 여러 번 실행해도 결과가 한 번 실행한 것과 같은 성질. 재시도가 안전하려면 필요하다.

📝 연습 문제

선택지를 클릭하면 정답·해설이 펼쳐집니다.

문제 1

다음 요구를 모두 만족하는 변환 엔진은? "수십 TB를 처리, Hive와 HBase를 함께 사용, 스팟 인스턴스로 비용을 극단적으로 제어, 클러스터를 세밀히 튜닝."

• AAmazon EMR on EC2
• BAWS Lambda
• CAWS Glue
• DAmazon Athena

문제 2

"S3 파일 도착 → Glue 변환 → 검증 → 통과 시 Redshift 적재, 실패 시 알림"을 분기·재시도와 함께 서버리스로 조율하려 한다. 가장 적합한 오케스트레이터는?

• AAmazon MWAA
• B단일 Lambda 함수
• CAmazon Kinesis
• DAWS Step Functions

문제 3

EMR 비용 최적화를 위한 설명 중 옳은 것은?

• A영구 데이터를 Core 노드 HDFS에 저장하고 클러스터를 24시간 유지한다
• BTask 노드에 스팟을 적용하고 영구 데이터는 S3(EMRFS)에 두며 Transient 클러스터로 작업 시에만 띄운다
• CPrimary 노드를 스팟으로 구성해 비용을 줄인다
• D모든 노드를 온디맨드로 고정한다

문제 4

Athena 스캔 비용이 급증했다. 데이터는 단일 Gzip CSV로 저장돼 있고 쿼리는 최근 며칠·특정 컬럼만 본다. 다음 중 비용 절감에 도움이 되지 않는 조치는?

• AParquet 같은 열 기반 포맷으로 변환
• Byear/month/day로 파티셔닝
• Cuser_id 같은 고카디널리티 컬럼으로 잘게 파티셔닝하고 파일을 더 쪼갠다
• D작은 파일을 128MB~1GB로 컴팩션하고 분할 가능한 Snappy 압축 사용

문제 5

다음 중 도구와 대표 용도의 연결이 잘못된 것은?

• ALambda — S3에 도착한 작은 파일을 즉시 정제하는 이벤트 기반 경량 변환
• BMWAA — 기존 Airflow DAG를 재사용하며 멀티 클라우드를 조율하는 복잡한 워크플로
• CGlue Workflows — 다양한 비-Glue 서비스를 복잡한 분기와 함께 조율하는 범용 오케스트레이션
• DParquet — 분석 쿼리에서 컬럼 프루닝으로 스캔량을 줄이는 열 기반 포맷