home
SAA-C03

[analytics] Kinesis Data Streams

끊임없이 쏟아지는 실시간 데이터를 놓치지 않고 받아내기. 여러 소비자가 나눠 읽고 되감기까지 되는 스트림.

One-Line Summary

Kinesis Data Streams(KDS)는 대량의 실시간 스트리밍 데이터를 밀리초 단위로 받아, 여러 소비자가 각자 읽고 되감아(replay) 볼 수 있게 보관해주는 실시간 데이터 스트림이다. 시험에서는 실시간(real-time) 수집 / 순서 보장(파티션 키) / 다중 소비자 / 재처리(replay) 가 핵심이며, "실시간 스트리밍인데 SQS로는 부족한 상황"에서 답이 된다.

Why It Exists

클릭 스트림, IoT 센서, 로그처럼 끊임없이 쏟아지는 데이터를 여러 애플리케이션이 동시에, 실시간으로, 순서대로 소비해야 하는 경우가 있다. SQS는 메시지를 한 소비자가 꺼내면 사라지고(1:1 소비), 순서 재생·다중 소비·되감기를 위한 도구가 아니다.

KDS는 데이터를 스트림에 흘려보내고, 일정 기간 보관하며, 여러 소비자가 각자 원하는 위치부터 읽게 한다.

SQS
  Producer -> [큐] -> 한 소비자가 꺼내면 삭제 (1:1, 되감기 없음)

Kinesis Data Streams
  Producer -> [스트림(샤드들)] -> 소비자 A (실시간 대시보드)
                              -> 소비자 B (S3 적재)
                              -> 소비자 C (이상 탐지)
  데이터는 보존 기간 동안 남아 있어 여러 소비자가 각자 읽고 되감기 가능

시험 감각:

"실시간 스트리밍 데이터를 여러 애플리케이션이 동시에 처리 / 데이터를 다시 읽어야 한다(replay)" = Kinesis Data Streams.

Abbreviations

약어풀네임의미
KDSKinesis Data Streams실시간 데이터 스트림 수집·보관 서비스
ShardShard스트림의 처리 단위(용량 단위), 스트림은 샤드들의 집합
Partition KeyPartition Key레코드를 어느 샤드에 넣을지 정하고 샤드 내 순서를 결정하는 키
KPLKinesis Producer Library고성능으로 데이터를 넣는 생산자 라이브러리
KCLKinesis Client Library샤드를 나눠 읽어주는 소비자 라이브러리
EFOEnhanced Fan-Out소비자마다 전용 2MB/s 읽기 대역을 주는 방식

샤드(Shard)와 용량

스트림은 여러 개의 샤드로 이루어지고, 처리량은 샤드 수에 비례한다. 샤드가 곧 용량 단위다.

항목샤드당 한도
쓰기(입력)1 MB/s 또는 1,000 레코드/s
읽기(출력, 공유)2 MB/s (모든 표준 소비자가 나눠 씀)
읽기(Enhanced Fan-Out)소비자마다 2 MB/s 전용
처리량이 부족하면 -> 샤드 수를 늘림(re-sharding)
소비자가 많아 읽기 경합이 심하면 -> Enhanced Fan-Out으로 소비자별 전용 대역

시험 감각:

"처리량이 부족하다 / throughput exceeded" = 샤드 추가. "소비자가 여러 개인데 서로 읽기 대역을 뺏는다 / 각 소비자에 낮은 지연" = Enhanced Fan-Out.

용량 모드 — Provisioned vs On-demand (빈출)

구분ProvisionedOn-demand
샤드 관리사용자가 샤드 수를 직접 지정/조정AWS가 자동으로 확장·축소
언제 쓰나트래픽이 예측 가능, 비용 최적화트래픽이 불규칙/예측 불가, 운영 부담 최소화
과금샤드 시간 단위처리한 데이터량 기준

시험 감각:

"트래픽을 예측할 수 없다 / 샤드 관리를 하고 싶지 않다" = On-demand.

순서(Ordering)와 파티션 키

같은 파티션 키를 가진 레코드는 같은 샤드로 가고, 그 샤드 안에서는 넣은 순서가 보장된다. 전체 스트림 차원의 전역 순서는 보장하지 않는다.

같은 device-id -> 같은 샤드 -> 그 기기 이벤트는 순서대로
서로 다른 device-id -> 다른 샤드 가능 -> 기기 간 순서는 보장 안 함

시험 감각:

"같은 사용자/기기의 이벤트를 순서대로 처리" = 해당 엔티티를 파티션 키로 지정.

보존과 되감기(Retention & Replay)

데이터는 스트림에 일정 기간 보관되므로, 소비자가 원하는 시점부터 다시 읽을 수 있다. 이것이 SQS와의 큰 차이다.

항목값
기본 보존 기간24시간(1일)
최대 보존 기간365일
Replay보존 기간 내라면 과거 데이터를 다시 읽기 가능

시험 감각:

"동일 데이터를 여러 번/나중에 다시 처리해야 한다" = KDS의 replay(SQS로는 불가).

생산자·소비자 (누가 넣고 누가 읽나)

역할대표 수단
생산자(Producer)SDK, KPL, Kinesis Agent, IoT 등
소비자(Consumer)KCL, Lambda, Data Firehose, Managed Service for Apache Flink
전형적 파이프라인
  [소스] -> Kinesis Data Streams -> Flink(실시간 집계) -> Firehose -> S3/Redshift
                                 -> Lambda(실시간 처리)

KDS vs SQS (핵심 비교, 빈출)

구분Kinesis Data StreamsSQS
목적실시간 스트리밍 데이터 분석·처리컴포넌트 분리(decoupling), 작업 큐
소비다중 소비자가 각자 읽음, 되감기 가능한 소비자가 꺼내면 삭제(1:1)
순서파티션 키 기준 샤드 내 순서FIFO 큐에서만 순서 보장
데이터 보존최대 365일, replay 가능처리 후 삭제(최대 14일 보관)
확장 단위샤드관리 불필요(자동)

시험 감각:

"여러 앱이 같은 스트림을 실시간 분석 / 되감기" = KDS. "그냥 작업을 분리하고 버퍼링" = SQS.

Common Wrong Directions

오답 방향왜 부족한가
실시간 다중 소비·replay가 필요한데 SQS 선택SQS는 1:1 소비·삭제형 → 다중 소비/되감기는 KDS
서버 없이 S3/Redshift로 그냥 적재만 하면 되는데 KDS+직접 소비자 구성적재·변환만이면 Data Firehose가 관리 부담 적음
처리량 초과를 인스턴스 늘려서 해결KDS 처리량은 샤드 수로 결정 → 샤드 추가/On-demand
전역 순서가 보장된다고 가정순서는 샤드(파티션 키) 단위만 보장
소비자 읽기 지연을 무시소비자가 많으면 공유 2MB/s 경합 → Enhanced Fan-Out

Exam Triggers

문제에서 이런 표현이 나오면떠올릴 것
"real-time streaming data", "ingest clickstream/IoT/logs"Kinesis Data Streams
"multiple consumers process the same stream"KDS (필요 시 Enhanced Fan-Out)
"replay / reprocess data", "read data again later"KDS (보존 기간 내 replay)
"process records in order per user/device"Partition Key 지정
"throughput exceeded / ProvisionedThroughputExceeded"샤드 추가 또는 On-demand
"unpredictable traffic, don't manage shards"On-demand 용량 모드
"just load streaming data into S3/Redshift"Data Firehose(KDS 아님)

Memory Sentence

Kinesis Data Streams는 실시간 스트리밍 데이터를 샤드에 받아 보존하고, 여러 소비자가 각자 읽고 되감을 수 있게 한다. 순서는 파티션 키(샤드) 단위, 처리량은 샤드 수로 결정, 트래픽 예측 불가면 On-demand. 다중 소비/replay가 필요하면 SQS가 아니라 KDS, 단순 적재만이면 Firehose.

References

댓글

아직 댓글이 없습니다.