[AWS] Amazon Kinesis

1. Amazon Kinesis는 왜 필요한가

Amazon Kinesis는 AWS가 제공하는 관리형 스트리밍 데이터 플랫폼으로, 대용량의 실시간 데이터를 안정적으로 수집, 처리, 분석할 수 있도록 설계되었다.

 

기존 AWS 서비스인 SQS(Simple Queue Service), SNS(Simple Notification Service), EventBridge와 비교했을 때, Kinesis의 차별화된 특징은 다음과 같다. 

---

1.1 Kinesis 핵심 특징

순서 보장 및 파티셔닝 (Ordering + Partitioning)

Kinesis는 파티션 키(partition key)를 기준으로 데이터를 샤드(shard)에 분산 저장한다.

※ 용어 설명
 - 파티션 키 : 데이터를 특정 샤드로 라우팅하기 위한 식별자 (예: 사용자 ID, 세션 ID)
 - 샤드 : 데이터 스트림 처리 단위로, 각 샤드는 고정된 처리 용량을 가짐

이를 통해 파티션 키를 가진 데이터는 항상 동일한 순서로 처리되며, 대규모 환경에서도 순서를 보장할 수 있다.

(SQS나 SNS, EventBridge는 이러한 '키 기반 순서 보장' 기능을 기본적으로 제공하지 않는다.)

---

재처리 기능 (Replay / Reprocessing)

Kinesis Data Streams는 데이터를 24시간에서 최대 365일까지 보관할 수 있다.

 

이는 다음과 같은 상황에서 매우 유용하다.

• 버그 수정 후 과거 데이터를 재처리해야 할 때
• 새로운 분석 파이프라인을 추가하면서 과거 데이터부터 처리하고 싶을 때
• 장애 발생 후 누락된 데이터를 복구할 때
• 규제 감사를 위한 데이터 검증이 필요할 때

SQS는 메시지가 소비되면 삭제되므로 재처리가 불가능하고, EventBridge는 이벤트 라우팅에 특화되어 있어 데이터 보관 기능이 없다.

---

다중 소비자 (Multiple Independent Consumers)

동일한 데이터를 여러 consumer(소비자)가 독립적으로 읽을 수 있다.

※ 용어 설명
 - Consumer (소비자) : 스트림에서 데이터를 읽어 처리하는 애플리케이션 또는 서비스

 

예를 들어, 같은 클릭스트림 데이터를 아래처럼 여러 용도로 동시에 활용할 수 있다.

• 실시간 대시보드용으로 처리하는 consumer
• 장기 보관용 S3에 저장하는 consumer
• 이상 거래 탐지 ML 모델에 입력하는 consumer

Kinesis는 Enhanced Fan-Out (EFO) 기능을 통해 각 consumer가 독립적인 처리량(throughput)을 확보할 수 있어, consumer 간 경쟁으로 인한 성능 저하를 방지한다.

※ 용어 설명
 - 처리량 (Throughput) : 단위 시간 당 처리할 수 있는 데이터의 양 (예: 초당 1MB)

---

지속적인 대용량 데이터 수집 (Sustained Ingestion)

Kinesis는 초당 수천~수백만 건의 이벤트를 지속적으로 수집할 수 있도록 설계되었다.

 

이는 다음과 같은 사용 사례에 적합하다 :

• IoT 센서 데이터 수집
• 웹/앱 로그 실시간 수집
• 클릭스트림 분석
• 보안 로그 (WAF, CloudTrail) 처리

EventBridge는 이벤트 기반 아키텍처를 위한 라우팅 서비스로, 대용량 스트림 저장소로는 적합하지 않다.

SQS는 안정적인 메시지 큐지만 '재처리 + 다중 소비자 + 순서 보장'이라는 스트림 처리 요구사항을 충족하지 못한다.

---

1.2 주요 사용 시나리오

다음과 같은 요구사항이 있을 때, Kinesis 사용이 적합하다 : 

1. 실시간 처리 + 재처리 필요
   
   • Clickstream / telemetry / WAF logs / app logs 가 지속적으로 유입
   • 실시간 분석이 필요하지만, 나중에 과거 데이터 재처리도 필요한 경우
2. 여러 분석 파이프라인이 동일한 원본 데이터를 요구하는 경우
   • 사기 탐지 (fraud detection)
   • 실시간 지표 계산 (metrics)
   • 규정 준수 아카이빙 (compliance archive)
3. 개체별 순서 보장 필요
   • 사용자 / 세션 / 디바이스 등 특정 개체(entity) 별로 이벤트 순서를 보장해야 하는 경우
   • 파티셔닝을 통해 대규모 환경에서도 순서 보장 가능

---

2. Kinesis family 개요

Amazon Kinesis는 단일 서비스가 아니라 4개의 독립적인 서비스군으로 구성되어 있으며, 각각 서로 다른 목적과 사용 사례를 가지고 있다.

---

출처 : AWS Docs - Amazon Kinesis Data Streams Terminology and concepts

Kinesis Data Streams (KDS)

• 역할 : 실시간 스트리밍 데이터 수집 및 저장의 핵심 서비스
• 특징
  • Producers(데이터 생성자)와 Consumers(데이터 소비자)를 직접 구현하고 운영
  • 스트림 용량을 관리 (Provisioned 또는 On-demand 모드 선택)
  • Consumer 아키텍처 직접 설계
• 주요 시나리오
  • 데이터 재처리(replay) 필요 시
  • 여러 독립적인 consumer가 필요할 때
  • 커스텀 처리 로직이 필요할 때
  • 세밀한 제어(fine-grained control)가 필요할 때

※ 용어 설명
 - Producer (생산자) : 스트림에 데이터를 전송하는 애플리케이션 (예: 웹 서버, IoT 디바이스)
 - Provisioned 모드 : 샤드 개수를 직접 지정하여 용량을 관리하는 방식
 - On-demand 모드 : Kinesis가 자동으로 용량을 조정하는 방식

---

Amazon Data Firehose (관리형 전송 서비스)

• 역할 : 데이터를 목적지로 자동 전송하는 완전 관리형 서비스
• 특징
  • Consumer 애플리케이션을 직접 구현할 필요 없음
  • 자동 버퍼링 및 배치 처리
  • 지원 목적지 : S3, Redshift, OpenSearch, Snowflake, Splunk, HTTP endtpoints 
• 주요 시나리오
  • 데이터를 단순 저장소나 분석 도구로 전송하기만 할 때
  • 최소한의 코드와 운영 부담으로 데이터 파이프라인을 구축하고 싶을 때
  • 데이터 변환이나 압축이 필요할 때 (Lambda 함수 통합 가능)

 

※ KDS vs. Firehose 선택 기준

• 재처리 필요 → KDS
• 단순 저장/전송만 필요 → Firehose
• 여러 consumer 필요 →  KDS
• 하나의 목적지만 필요 → Firehose

---

Kinesis Data Analytics (스트림 분석)

• 역할 : 실시간 스트림 데이터에 대한 SQL 또는 Apache Flink 기반 분석
• 특징
  • SQL 쿼리로 스트림 데이터 분석 가능
  • Apache Flink 애플리케이션 실행 가능
  • KDS 또는 MSK(Managed Streaming for Kafka)를 데이터 소스로 사용
• 주요 시나리오
  • 시계열 윈도우 집계가 필요할 때 (예: 최근 5분 간 평균)
  • 스트림 데이터 조인(join)이 필요할 때
  • 실시간 이상 탐지가 필요할 때
  • 복잡한 스트리밍 엔진을 직접 구축하고 싶지 않을 때

※ 용어 설명
 - Apache Flink : 대규모 스트림 처리를 위한 오픈소스 프레임워크
 - 윈도우 집계 : 특정 시간 범위 내 데이터를 그룹화하여 계산하는 기법

---

Kinesis Video Streams (비디오 전용)

• 역할 : 비디오/오디오 스트림 전용 서비스
• 주의 : Data Streams와 완전히 다른 서비스다. JSON 로그나 일반 이벤트 데이터는 사용하지 않는다.
• 주요 시나리오
  • 보안 카메라 영상 스트리밍
  • IoT 비디오 디바이스 데이터 수집
  • 실시간 비디오 분석 (ML 모델 연동)

---

3. Deep dive : Kinesis Data Streams (KDS)

Kinesis Data Streams는 Kinesis Family 중 가장 핵심적인 서비스로, 대부분의 실시간 데이터 파이프라인에서 사용된다.

이를 효과적으로 활용하려면 내부 동작 원리를 이해해야 한다.

---

3.1 샤드(Shard) : 처리량 계산과 스케일링

Kinesis 스트림은 샤드(shard)의 집합으로, 각 shard는 다음과 같은 고정된 처리 용량을 가진다 : 

• 쓰기 용량 : 샤드 당 ~1 MB/s 또는 초당 최대 1,000개 레코드 지원
• 읽기 용량
  • Shared throughput (기본 모드) : 샤드 당 ~2 MB/s
  • Enhanced Fan-Out (EFO) : consumer 별로 샤드당 2 MB/S (독립적)

※ 용어 설명
 - Shared throughput : 모든 consumer가 샤드의 읽기 용량을 공유하는 방식
 - Enhanced Fan-Out (EFO) : 각 consumer가 독립적인 읽기 용량을 받는 방식 (낮은 지연시간 보장)

---

처리량 계산 예시

만약 초당 5 MB의 데이터를 쓰려면 : 

• 필요한 샤드 수 = 5 MB/s ÷ 1 MB/s per shard = 최소 5개 샤드

만약 초당 10,000개의 레코드를 쓰려면 : 

• 필요한 샤드 수 = 10,000 records/s ÷ 1,000 records/s per shard = 최소 10개 샤드

실제 운영 환경에서는 트래픽 변동성을 고려하여 여유 용량(headroom)을 20~30% 추가로 확보하는 것이 권장된다.

---

Hot Shard 문제

Hot Shard는 Kinesis 운영에서 가장 흔한 성능 문제다.

이는 특정 샤드에 데이터가 집중되어 해당 샤드의 용량 한계에 도달하는 현상이다.

 

• 발생 원인
  • 파티션 키 설계가 잘못되어 대부분의 데이터가 동일한 키를 사용
  • 파티션 키의 카디널리티(고유 값의 개수)가 낮음
  • 특정 사용자나 디바이스의 활동이 급증
• 예시
  • 잘못된 설계 : 파티션 키로 "country"(국가) 사용 → 특정 국가(예: US)에 트래픽이 집중되면 해당 샤드에만 부하 집중
  • 올바른 설계 : 파티션 키로 "user_id" 사용 → 수백만명의 사용자가 모든 샤드에 고르게 분산됨
• 해결방법
  1. 파티션 키 재설계 : 높은 카디널리티를 가진 키 혹은 복합 키 사용, 상수 키 절대 금지
  2. 샤드 개수 증가 (Resharding) : 더 많은 샤드로 부하 분산 (주의: 파티션 키 설계가 잘못되었다면 근본 해결 안됨)
  3. Enhanced Fan-Out 사용 : Consumer 측 경쟁 해소 (주의: 쓰기 측 Hot Shard는 해결 안됨)

※ 용어 설명
 - 카디널리티 (Cardinality) : 특정 필드가 가질 수 있는 고유한 값의 개수
  예) 국가 코드 = 약 200개 (낮은 카디널리티), 사용자 ID = 수백만 개 (높은 카디널리티)

---

3.2 Producer와 Consumer

Producer (데이터 생성자)

Producers는 PutRecord 또는 PutRecords API를 호출하여 데이터를 Kinesis에 전송한다.

 

파티션 키 선택이 핵심

• Producer는 각 레코드마다 파티션 키를 지정해야 함
• Kinesis는 파티션 키를 해싱하여 샤드를 자동 배정
• 동일한 파티션 키 = 항상 동일한 샤드 = 순서 보장

최적화 Tip!

• 여러 레코드를 배치로 전송 : PutRecords (최대 500개)
• KPL (Kinesis Producer Library) 사용 시 자동 배치 및 재시도 지원

※ 용어 설명
 - KPL (Kinesis Producer Library) : AWS가 제공하는 고성능 Producer라이브러리. 사용 시 자동 배치 및 재시도 지원

---

Consumer (데이터 소모자)

Consumer는 세 가지 방식으로 구현할 수 있다 : 

• Shared Throughput Polling (GetRecords API)
  • 가장 단순한 방식. Consumer가 주기적으로 GetRecords를 호출하여 데이터를 가져옴
  • 단점 : 모든 consumer가 샤드의 2 MB/s 용량을 공유함 (경쟁 상태!)
  • 적합한 경우 : Consumer가 1~2개이고, 처리량 요구사항이 높지 않을 때
• Enhanced fan-out (Push 모델)
  • Consumer 별로 독립적인 2 MB/s 처리량 보장.
  • Kinesis가 데이터를 consumer에게 푸시 (낮은 지연 시간)
  • 단점 : 비용 증가 (consumer 당 과금)
  • 적합한 경우 : 낮은 지연 시간이 중요하거나 여러 consumer가 동시 시작할 때
• AWS Lambda event source mapping
  • Lambda 함수를 자동으로 호출하여 데이터 처리
  • 자동 배치, 체크포인팅, 재시도 관리
  • 설정 이해 필수
    1. - Batch size : 한 번에 처리할 레코드 개수
    2. - Bisect on error : 에러 시 배치를 절반으로 나눠 재시도
    3. - Parallelization factor : 샤드 당 동시 실행 Lambda 개수
    4. - DLQ (Dead Letter Queue) : 처리 실패 시 메시지 전송

※ 용어 설명
 - 체크포인팅 (Checkpointing) : 어디까지 읽었는지 위치를 기록하는 메커니즘
 - DLQ (Dead Letter Queue) : 처리에 실패한 메시지를 보관하는 별도 큐
 - Parallelization factor : 하나의 샤드를 여러 Lambda가 동시에 처리하는 정도 (1~10)

---

3.3 순서 보장과 재처리 (Ordering & Replay)

순서 보장 (Ordering)

 

샤드 내에서 순서가 보장된다.

동일한 파티션 키를 가진 레코드는 항상 같은 샤드로 라우팅되므로, 파티션 키별 순서도 보장된다.

서로 다른 파티션 키 간에는 순서가 보장되지 않으며, 전역 순서 (global ordering)가 필요하면 샤드를 1개만 사용해야 한다. 

---

재처리 (Replay)

Consumer는 시퀀스 번호(sequence number)를 지정하여 과거 데이터부터 다시 읽을 수 있다.

보존 기간(retention) 내의 모든 데이터에 접근 가능하다.

여러 consumer가 독립적으로 각자 다른 위치에서 읽는 것이 가능하다.

※ 용어 설명
 - 시퀀스 번호 : 각 레코드에 부여되는 고유한 식별자 (샤드 내에서 순차적으로 증가)

---

3.4 데이터 보존 및 복구 (Retention + Recovery)

• 기본값 : 24시간
• 설정 가능 범위 : 24시간 ~ 8,760 시간 (365일)
• 의미 : 이 기간 내의 데이터는 언제든 재처리 가능
• 비용 고려 사항
  • 보존 기간이 길수록 비용 증가
  • 샤드-시간(shard-hour) 단위로 과금
• 운영 전략
  1. 실시간 처리 스트림 : 24~48시간 보존 (비용 최소화)
  2. 중요 데이터 : 7~30일 보존 (일주일 내 재처리 가능)
  3. 규제/감사 데이터 : 최대 365일 보존
  4. 장기 보관 : Firehose로 S3에 저장 후 Athena로 분석 (저렴)

---

4. 운영 시 발생하는 문제

4.1 Scaling 전략

• Provisioned 모드 (수동 관리)
  • 샤드 개수를 직접 지정; 비용 예측 가능 (샤드-시간 단위 고정 비용)
  • 트래픽 증가 시 수동으로 resharding 필요
  • 트래픽 패턴이 예측 가능하고 안정적일 때 적합함. 
• On-demand 모드 (자동 관리)
  • Kinesis가 자동으로 용량을 조정한다.
  • 처리량에 따라 비용 변동 (GB당 과금)
  • 트래픽 변동이 크거나 예측 불가능할 때 적합함.

---

4.2 Backpressure + Throttling (실패가 발생하는 지점)

Kinesis 장애는 대부분 용량 초과로 인한 교착 상태에서 시작된다.

일반적인 장애 시나리오는 다음과 같다 :

1. Producer 트래픽 급등
   • 마케팅 이벤트, 시스템 장애, DDoS 등으로인한 갑작스러운 트래픽 증가
   • 샤드의 쓰기 용량 한계 (1 MB/s) 도달
2. ProvisionedThroughputExceededException 발생
   • Kinesis가 요청 거부
   • Producer 측 에러 로그 증가
3. 재시도 폭증 (Retry Storm)
   • Producer 애플리케이션이 자동 재시도
   • 재시도 트래픽이 원래 트래픽에 추가됨 → 상황 악화
   • 지연시간(latency) 기하급수적 증가
4. Consumer lag 성장
   • Consumer가 처리 속도를 따라가지 못함
   • IteratorAgeMilliseconds 지표 상승
   • Consumer가 처리 속도를 따라가지 못함
   • IteratorAgeMilliseconds 지표 상승
   • 보존 기간이 짧으면 데이터 유실 위험
5. 시스템 전체 장애
   1. 다운스트림 서비스(OpenSearch Redshift 등)까지 지연
   2. 백프레셔가 전체 시스템으로 전파

※ 용어 설명
 - 백프레셔 (Backpressure) : 다운스트림 시스템이 느려져서 업스트림까지 영향을 주는 현상
 - 스로틀링 (Throttling) : 용량 한계 도달 시 요청을 거부하는 메커니즘
 - Consumer Lag : Consumer가 처리해야 할 데이터와 실제 처리한 데이터 사이의 시간 차이
 - IteratorAgeMilliseconds : Consumer가 읽고 있는 데이터의 나이 (밀리초 단위)

---

해결 방법

1. Producer 측 최적화
   • 버퍼링 : 로컬에서 일정 시간/개수만큼 모았다가 배치 전송
   • 지수 백오프 : 재시도 간격을 점진적으로 늘림 (예: 100ms → 200ms → 400ms)
   • KPL 사용 : 자동으로 배치/재시도/집계 처리
2. 충분한 샤드 용량 확보
   • 예상 최대 트래픽의 120~150%로 샤드 프로비저닝
   • 여유 용량(headroom) 반드시 확보
3. Partition key 분배 시험
   • 프로덕션 배포 전 부하 테스트 필수
   • CloudWatch로 샤드별 IncomingBytes 모니터링
   • 특정 샤드에 부하 집중 시 파티션 키 재설계
4. 모니터링 및 알람
   • WriteProvisionedThroughputExceeded 알람 설정
   • IteratorAgeMilliseconds 임계값 설정 (예: 60초)
   • 자동 스케일링 정책 구현

---

4.3 주요 모니터링 지표 (CloudWatch Metrics)

1. Throttling 지표 (문제 감지)
   • WriteProvisionedThroughputExceeded
   • ReadProvisionedThroughputExceeded
2. Consumer Lag (가장 중요)
   • IteratorAgeMilliseconds : Consumer가 읽고 있는 데이터의 나이
3. 처리량 지표 (용량 계획)
   • IncomingBytes / IncomingRecords : 샤드로 들어오는 데이터량 
   • OutgoingBytes / OutgoingRecords : 샤드에서 나가는 데이터량
4. Enhanced Fan-Out 지표 (EFO 사용 시)
   • Consumer 별 처리량 및 지연시간
   • Consumer 간 성능 차이 모니터링

---

참고 출처

 - Amazon Kinesis Data Streams란? - Amazon Kinesis Data Streams

 - Amazon Kinesis Data Streams Terminology and concepts - Amazon Kinesis Data Streams

 - What is Amazon Data Firehose? - Amazon Data Firehose

 - Choose source and destination for your Firehose stream - Amazon Data Firehose

 - https://data-engineer-tech.tistory.com/28