[AWS DEA] 문제로 공부하기 6 - Firehose + Lambda

AWS DEA-C01 데이터 엔지니어 스트리밍 · Firehose Parquet 변환 최소 운영 오버헤드

실시간 로그 수집 → Parquet 변환 → S3 — Firehose + Lambda가 정답인 이유

AWS DEA-C01 시험에 자주 나오는 스트리밍 ETL 문제입니다. 여러 애플리케이션의 로그를 중앙 집중식으로 수집하면서 Apache Parquet으로 변환해 S3에 거의 실시간 전달해야 할 때, Firehose / Kinesis Data Streams / Glue ETL / EMR Hive 중 최소 운영 오버헤드로 요구사항을 충족하는 솔루션을 도식과 함께 비교 정리합니다.

📋 문제

전자 상거래 회사가 AWS에서 여러 애플리케이션을 실행한다. 이 회사는 중앙 집중식 스트리밍 로그 수집 솔루션을 설계하려고 한다. 솔루션은 로그 데이터를 Apache Parquet 형식으로 변환한 다음 Amazon S3에 로그 파일을 저장할 수 있어야 한다. 생성되는 로그 파일의 수는 하루 중에 계속 달라지며, 데이터 엔지니어는 로그 파일을 거의 실시간으로 전달하도록 지원하는 솔루션을 구성해야 한다.

다음 중 최소한의 운영 오버헤드로 이러한 요구 사항을 충족하는 솔루션은 무엇인가?

✅ 핵심 요구사항 체크

• 🔄
  중앙 집중식 스트리밍 로그 수집
  여러 앱에서 발생하는 로그를 하나의 파이프라인으로 통합 → 스트리밍 수집 서비스 필요
• 📦
  Apache Parquet 형식으로 변환
  원본 로그(JSON·텍스트)를 열 기반 Parquet으로 변환 → 데이터 레이크 분석 최적화
• ⚡
  거의 실시간 전달 (Near Real-time)
  로그 순환 주기에 의존하지 않고 수집 즉시 처리 · 전달 → 배치가 아닌 스트리밍 방식
• 🪶
  최소 운영 오버헤드
  서버 프로비저닝·관리 없이 자동 스케일링 → 완전관리형(Fully Managed) 서비스 선호

📐 아키텍처 비교

✅ 정답 — Firehose + Lambda

🖥️

애플리케이션들

로그 스트림 전송

→

🚒

Data Firehose

수집 · 버퍼링
자동 스케일링

→

λ

Lambda

Parquet 변환
(인라인 처리)

→

🪣

Amazon S3

Parquet 저장

❌ 오답 A — S3 → EventBridge → Glue ETL

🖥️

애플리케이션

로그 파일 저장

→

🪣

입력 S3 버킷

로그 순환 의존

→

📅

EventBridge

이벤트 트리거

→

⚙️

Glue ETL

배치 처리
실시간 ❌

❌ 오답 C — Kinesis Data Streams + EC2 KCL

🖥️

애플리케이션

스트림 전송

→

🌊

Kinesis
Data Streams

수집 스트림

→

💻

EC2 + KCL

직접 관리
오버헤드 ↑

→

🪣

Amazon S3

Parquet 저장

🪶 솔루션별 운영 오버헤드 (낮을수록 좋음)

Firehose + Lambda ⭐

최저

완전관리형

S3 + Glue ETL

보통

실시간 ❌

Kinesis + EC2

높음

서버 관리

EMR + Hive

매우 높음

클러스터 관리

📝 선택지 해설

각 항목을 클릭하면 해설이 펼쳐집니다.

A

❌ 입력 S3 버킷 → EventBridge → AWS Glue ETL → 출력 S3 버킷

배치 기반 ETL — 로그 순환 주기에 의존

💡 Parquet 변환 자체는 가능하지만, S3에 파일이 업로드되어야 EventBridge가 트리거됩니다. 이는 애플리케이션의 로그 순환 예약(ex. 1시간 단위 파일 생성)에 완전히 종속됩니다. 로그가 파일로 묶여야 처리가 시작되므로 거의 실시간 전달을 보장할 수 없습니다. 스트리밍이 아닌 배치 방식입니다.

B

✅ Amazon Data Firehose → Lambda(Parquet 변환) → 출력 S3 버킷

완전관리형 스트리밍 전달 + Lambda 인라인 변환

💡 정답. Firehose는 완전관리형 스트리밍 전달 서비스로 자동 스케일링을 지원합니다. 로그 트래픽이 하루 중 변동하더라도 별도 설정 없이 자동 대응합니다. Lambda 변환 함수를 Firehose에 연결하면 수집된 레코드를 S3에 저장하기 전 인라인으로 Parquet 변환합니다. 서버 관리 없이 거의 실시간 전달과 포맷 변환을 동시에 달성합니다.

C

❌ Amazon Kinesis Data Streams → EC2 + KCL → Amazon S3

사용자 정의 소비자 + EC2 인스턴스 그룹 직접 관리

💡 실시간 스트리밍과 Parquet 변환은 가능하지만, KCL 소비자 애플리케이션을 직접 개발해야 하고 EC2 인스턴스 그룹의 프로비저닝·패치·스케일링을 직접 관리해야 합니다. 로그 트래픽 변동에 따라 수동 혹은 Auto Scaling 설정도 필요합니다. 최소 운영 오버헤드 조건에 맞지 않습니다.

D

❌ Amazon EMR(Hive) → 정규식 테이블 생성 → HiveQL UNLOAD → S3 외부 테이블

EMR 클러스터 + 사용자 정의 HiveQL 스크립트

💡 기술적으로 변환·저장은 가능하지만 EMR 클러스터 자체를 구성·관리해야 하고, HiveQL 스크립트를 직접 개발·유지보수해야 합니다. 선택지 중 운영 오버헤드가 가장 높으며, HiveQL UNLOAD를 예약하는 방식은 실시간이 아닌 배치에 가깝습니다.

정답 및 핵심 정리 (클릭)

정답: B — Amazon Data Firehose + Lambda

Firehose는 완전관리형 스트리밍 파이프라인으로, 수집 → 변환 → 전달을 서버 없이 처리합니다. Lambda 변환 함수를 연결하면 Parquet 변환까지 인라인으로 처리되어 별도 ETL 인프라가 필요 없습니다. 트래픽 변동도 자동 스케일링으로 대응합니다.

# 정답 흐름 요약 여러 애플리케이션 (로그 스트리밍) └─ Amazon Data Firehose ├─ 자동 스케일링 (트래픽 변동 대응) ├─ Lambda 함수 호출 (인라인 변환) │ └─ 원본 로그 (JSON) → Apache Parquet 변환 └─ 출력 S3 버킷 저장 (거의 실시간) ✅ 운영 오버헤드: 서버 없음 / 자동 스케일링 / 코드만 관리

📊 선택지 비교 요약

선택지	수집 방식	Parquet 변환	실시간 전달	운영 오버헤드
A. S3 + Glue ETL	파일 업로드	✅ 가능	❌ 로그 순환 의존	보통
B. Firehose + Lambda ⭐	스트리밍	✅ Lambda 인라인	✅ 거의 실시간	최저 (완전관리형)
C. Kinesis + EC2	스트리밍	✅ KCL 앱 개발	✅ 실시간	높음 (EC2 관리)
D. EMR + Hive	배치	✅ HiveQL 개발	❌ 예약 배치	가장 높음 (클러스터)

#AWS_DEA-C01 #AWS데이터엔지니어 #AmazonFirehose #DataFirehose #Parquet변환 #스트리밍ETL #LambdaETL #KinesisDataStreams #AWSGlue #EMRHive #실시간로그수집 #S3데이터레이크 #최소운영오버헤드 #AWS자격증