[AWS DEA] 문제로 공부하기 12 - IteratorAgeMilliseconds 높은 경우 해결책

AWS DEA-C01 Kinesis Data Streams AWS Lambda 스트리밍 성능 최적화 IteratorAge

Kinesis + Lambda IteratorAgeMilliseconds 높음 — 샤드 증가 · 병렬화 인자 · Enhanced Fan-Out으로 해결

AWS DEA-C01 시험에 자주 나오는 Kinesis + Lambda 스트리밍 성능 문제입니다. IteratorAgeMilliseconds가 피크 시간대에 높아지는 원인을 진단하고, 샤드 수 증가 · 병렬화 인자(Parallelization Factor) 튜닝 · Enhanced Fan-Out 등록으로 해결하는 방법을 예약 동시성·프로비저닝 동시성과 비교하여 도식으로 정리합니다.

📋 문제

회사가 Amazon S3 데이터 레이크를 운영하며 Amazon Kinesis Data Streams로 데이터를 수집하고 AWS Lambda로 스트림 데이터를 읽어 처리한다. 수집 데이터 볼륨이 매우 가변적이어서 예측할 수 없다.

피크 시간대에 IteratorAgeMilliseconds 지표가 높게 나타난다. 데이터 엔지니어는 Lambda로 Kinesis Data Streams를 읽을 때 성능을 높이는 솔루션을 설계해야 한다.

다음 중 요구 사항을 충족하는 솔루션은 무엇인가? (3개 선택)

🔍 핵심 개념 — IteratorAgeMilliseconds란?

📊 IteratorAgeMilliseconds 지표

의미 Lambda가 Kinesis 레코드를 처리할 때, 해당 레코드가 스트림에 기록된 시간과 Lambda가 실제로 읽은 시간의 차이 (밀리초)

높을 때 Lambda가 Kinesis 스트림 데이터를 따라잡지 못하고 처리 지연(Lag)이 발생 중

이상적 값 0에 가까울수록 좋음 — 실시간에 가깝게 처리 중

원인 데이터 볼륨 > Lambda 처리 용량 → 읽기 처리량 병목

🏗️ 현재 아키텍처 — 병목 지점

데이터 생산자
(볼륨 가변적)

→

Kinesis
Data Streams

→

Lambda
폴링 처리
⚠️ 지연 발생

→

S3
데이터 레이크

⚠️ 기본 구성: Lambda는 샤드당 1개의 동시 실행 인스턴스로 폴링합니다. 피크 시 데이터가 몰리면 처리 처리량이 부족해 IteratorAge가 증가합니다. 해결 방향은 처리 병렬성(Parallelism) 증가입니다.

✅ 정답 3가지 — 처리 병렬성 증가 전략

📦

A. 샤드 수 증가

• 샤드 = Lambda 동시 실행 단위
• 샤드 1개 → Lambda 인스턴스 1개
• 샤드 10개 → 최대 10개 병렬
• 쓰기 1MB/s, 읽기 2MB/s per shard
• 비용 증가하나 처리량 직접 확장

📈 처리 병렬성 직접 확장

⚙️

B. 병렬화 인자 튜닝

• 샤드당 Lambda 1~10개 동시 실행
• 기본값: 1 (샤드당 1개)
• 최대: 10 (샤드당 10개 병렬)
• 샤드 추가 없이 처리량 최대 10배↑
• 최적값은 테스트로 확인 필요

⚡ 비용 효율적 처리량 증가

📡

D. Enhanced Fan-Out

• 전용 2MB/s 읽기 처리량 per shard
• 기본 공유 읽기: 2MB/s 전체 공유
• Push 방식 (HTTP/2)
• 폴링 지연 없이 즉시 전달
• 다수 Lambda 소비자에 적합

🚀 전용 읽기 처리량 확보

📊 솔루션별 Lambda 처리 처리량 비교 (샤드 5개 기준)

기본 (샤드 5, PF=1)

5개 Lambda 인스턴스

A. 샤드 10개로 증가

10개 Lambda 인스턴스

B. 병렬화 인자 PF=10

최대 50개 Lambda 인스턴스

D. Enhanced Fan-Out

전용 2MB/s × 5샤드 + Push 방식

📡 기본 폴링 vs Enhanced Fan-Out 비교

기본 폴링 방식

• 공유 읽기 2MB/s (샤드당 전체 공유)
• 소비자가 많을수록 처리량 분산
• Pull 방식: Lambda가 주기적으로 폴링
• IteratorAge 증가 가능성 높음

Enhanced Fan-Out ⭐

• 전용 2MB/s per shard per consumer
• 소비자 수 증가해도 처리량 유지
• Push 방식: HTTP/2로 즉시 전달
• 지연 최소화 (IteratorAge↓)

❌ 오답 — Lambda 동시성 설정이 IteratorAge를 해결 못하는 이유

🔑 핵심 구분: IteratorAge는 Kinesis 읽기 처리량 병목 문제입니다. Lambda 동시성 설정(E, F)은 Lambda 실행 환경을 제어하지만, Kinesis 스트림에서 데이터를 읽는 속도 자체를 늘리지는 못합니다.

E. 예약 동시성 (Reserved Concurrency)

목적: Lambda 함수에 최대 동시 실행 수를 예약·제한하는 기능
문제: IteratorAge는 읽기 처리량 부족이 원인인데, 예약 동시성은 다른 함수가 이 동시성을 사용하지 못하게 막는 것일 뿐 Kinesis 읽기 속도를 높이지 못함
오히려: 동시성을 제한하면 성능이 악화될 수도 있음

F. 프로비저닝 동시성 (Provisioned Concurrency)

목적: Lambda 인스턴스를 미리 워밍업하여 콜드 스타트 지연 제거
문제: IteratorAge는 콜드 스타트가 원인이 아니라 Kinesis 스트림 읽기 처리량 부족이 원인
결론: 콜드 스타트 없애도 처리 병렬성 자체가 늘지 않아 IteratorAge 미해결

📝 선택지 해설

✅ 복수 정답 (3개 선택)

A

✅ Kinesis 데이터 스트림의 샤드 수를 늘린다

샤드 = Lambda 병렬 실행 단위 — 샤드 증가 → Lambda 동시 처리 수 증가

💡 정답. Kinesis Data Streams에서 Lambda는 샤드당 하나의 동시 실행 인스턴스로 데이터를 처리합니다. 샤드 수를 늘리면 Lambda 동시 실행 수가 함께 늘어나 처리 처리량이 증가합니다. 샤드 1개당 쓰기 1MB/s, 읽기 2MB/s를 제공하므로 피크 볼륨에 맞게 샤드를 스케일 아웃하면 IteratorAge를 낮출 수 있습니다. 다만 비용이 증가하는 점을 고려해야 합니다.

B

✅ 최적의 성능을 찾고자 다양한 병렬화 인자 설정을 테스트한다

병렬화 인자(PF): 샤드당 Lambda 1~10개 동시 실행 — 샤드 추가 없이 처리량 최대 10배 증가

💡 정답. Lambda의 병렬화 인자(Parallelization Factor)를 사용하면 하나의 샤드에서 최대 10개의 Lambda 함수를 동시에 실행할 수 있습니다. 기본값은 1이며, 최대 10까지 설정 가능합니다. 샤드가 5개이고 PF=10이면 최대 50개의 Lambda가 병렬로 실행됩니다. 단, 최적값은 메시지 크기·처리 시간·오류율 등에 따라 달라지므로 다양한 값을 테스트하여 최적 설정을 찾는 것이 올바른 접근입니다.

C

❌ 프로비저닝된 용량 모드로 Kinesis 데이터 스트림을 구성한다

On-Demand → Provisioned 전환 — 용량 모드 변경은 IteratorAge 직접 해결 아님

💡 Kinesis Data Streams는 On-Demand 모드와 Provisioned(프로비저닝) 모드를 지원합니다. Provisioned 모드로 전환한다고 해서 Lambda 처리 처리량이 자동으로 늘어나지는 않습니다. 이미 On-Demand 모드라면 자동으로 스케일 업되므로 Provisioned 전환의 이점이 없고, 오히려 수동 샤드 관리 부담이 생깁니다. IteratorAge 문제 해결에는 병렬성 증가가 핵심이며, 용량 모드 변경은 이를 직접 해결하지 못합니다.

D

✅ 향상된 팬아웃(Enhanced Fan-Out)으로 Lambda 함수를 소비자로 등록한다

샤드당 전용 2MB/s 읽기 처리량 + HTTP/2 Push 방식 — 공유 읽기 처리량 병목 완전 해소

💡 정답. Enhanced Fan-Out을 사용하면 Lambda 함수가 샤드당 전용 2MB/s 읽기 처리량을 할당받습니다. 기본 폴링 방식에서는 해당 스트림의 모든 소비자가 2MB/s를 공유하지만, Enhanced Fan-Out 등록 소비자는 각자 전용 2MB/s를 갖습니다. 또한 Pull 방식이 아닌 HTTP/2 Push 방식으로 레코드가 즉시 전달되어 폴링 지연이 사라지고 IteratorAge가 크게 낮아집니다. 데이터 볼륨이 가변적인 이 시나리오에 매우 적합합니다.

E

❌ Lambda 함수에 예약 동시성을 늘린다

다른 함수로부터 동시성 예약·보호 — Kinesis 읽기 처리량과 무관

💡 예약 동시성(Reserved Concurrency)은 Lambda 함수가 사용할 수 있는 동시 실행 수를 계정 전체 한도에서 예약(독점)하는 기능입니다. 다른 함수가 이 동시성을 사용하지 못하도록 보호하는 목적입니다. IteratorAge는 Kinesis 스트림에서 Lambda가 데이터를 읽는 속도의 문제이며, 예약 동시성을 설정해도 샤드당 Lambda 실행 수는 늘어나지 않습니다. 오히려 동시성을 낮게 예약하면 성능이 저하될 수 있습니다.

F

❌ Lambda 함수에 프로비저닝된 동시성을 사용한다

콜드 스타트 제거 목적 — IteratorAge 원인인 처리 처리량 병목과 무관

💡 프로비저닝 동시성(Provisioned Concurrency)은 Lambda 인스턴스를 미리 초기화하여 콜드 스타트(Cold Start) 지연을 제거하는 기능입니다. 그러나 IteratorAgeMilliseconds가 높은 원인은 콜드 스타트가 아니라 피크 시 데이터 볼륨이 Lambda 처리 처리량을 초과하는 병목입니다. 프로비저닝 동시성으로 초기화 지연을 없애도 Kinesis 읽기 병렬성 자체가 늘어나지 않아 IteratorAge 문제가 해결되지 않습니다.

정답 및 핵심 정리 (클릭)

정답: A + B + D

IteratorAge가 높다 = Kinesis 읽기 처리량 병목이 핵심 진단입니다. 해결 방향은 처리 병렬성 증가입니다. A는 샤드 자체를 늘려 Lambda 인스턴스를 추가하고, B는 샤드당 Lambda를 10배까지 늘리며, D는 전용 읽기 처리량을 확보하고 Push로 지연을 제거합니다. E·F(동시성 설정)는 Lambda 실행 환경 최적화이지 Kinesis 읽기 처리량과 무관합니다.

# IteratorAgeMilliseconds 높음 → 처리 병렬성 증가로 해결 문제 원인: 데이터 볼륨 > Lambda 처리 처리량 (Kinesis 읽기 병목) 해결책 A. 샤드 수 증가 - 샤드 1개 = Lambda 동시 실행 1개 - 샤드 10개 = Lambda 동시 실행 10개 - 처리량: 샤드당 읽기 2MB/s 해결책 B. 병렬화 인자(Parallelization Factor) 튜닝 - 기본값: 1 (샤드당 Lambda 1개) - 최대값: 10 (샤드당 Lambda 10개) - 샤드 5개 + PF=10 → 최대 50개 Lambda 병렬 해결책 D. Enhanced Fan-Out 등록 - 전용 2MB/s per shard (공유 아님) - HTTP/2 Push → 폴링 지연 없음 - 소비자 늘어도 처리량 보장 오답 E. 예약 동시성 → Kinesis 읽기 속도와 무관 오답 F. 프로비저닝 동시성 → 콜드 스타트 제거 목적, IteratorAge 해결 불가

📊 선택지 비교 요약

선택지	조치	처리 병렬성 증가	IteratorAge 해결	결론
A ⭐	샤드 수 증가	✅ 샤드당 Lambda 1개씩 추가	✅ 직접 해결	정답
B ⭐	병렬화 인자 튜닝	✅ 샤드당 최대 10개	✅ 직접 해결	정답
C	프로비저닝 용량 모드	❌ 처리량 변화 없음	❌ 미해결	탈락
D ⭐	Enhanced Fan-Out	✅ 전용 2MB/s + Push	✅ 직접 해결	정답
E	예약 동시성	❌ 읽기 속도 무관	❌ 미해결	탈락
F	프로비저닝 동시성	❌ 콜드 스타트만 해결	❌ 미해결	탈락

#AWS_DEA-C01 #KinesisDataStreams #AWSLambda #IteratorAgeMilliseconds #EnhancedFanOut #병렬화인자 #ParallelizationFactor #샤드수증가 #Lambda동시성 #스트리밍성능최적화 #데이터레이크 #AWS자격증 #AWS데이터엔지니어