SAABlog
KOEN
통합중급

Amazon Kinesis: 실시간 스트리밍 데이터 처리 완벽 가이드

Kinesis Data Streams vs Firehose 차이점, SQS와 비교, 샤드 용량 계산까지. SAA-C03 시험 출제 포인트 총정리.

PHILOLAMB••-
Kinesis스트리밍실시간 데이터Data StreamsFirehose

관련 시험 도메인

  • Domain 3: Design High-Performing Architectures

핵심 요약

Amazon Kinesis는 실시간 스트리밍 데이터를 수집, 처리, 분석하는 플랫폼입니다. Data Streams는 밀리초 지연의 실시간 처리용, Firehose는 S3/Redshift로 자동 전송하는 준실시간 전달용입니다.

시험 팁

시험 핵심: "실시간 스트리밍 + 여러 컨슈머" → Kinesis Data Streams, "S3/Redshift로 자동 전달" → Firehose, "메시지 큐잉 + 단일 컨슈머" → SQS

Kinesis는 언제 사용해야 할까?

적합한 경우

Kinesis 추천 시나리오:
├── 실시간 로그/이벤트 스트리밍
│   └── 웹 클릭스트림, 애플리케이션 로그
├── IoT 센서 데이터 수집
│   └── 수천~수백만 디바이스에서 데이터 수집
├── 실시간 분석 및 대시보드
│   └── 실시간 리더보드, 사기 탐지
├── 여러 컨슈머가 동일 데이터 처리
│   └── 분석, 저장, 알림을 병렬로 처리
└── 데이터 재처리가 필요한 경우
    └── 최대 365일까지 데이터 보존

부적합한 경우

Kinesis가 적합하지 않은 경우:
├── 단일 메시지 처리 (1:1 통신)
│   → SQS 사용
├── 메시지 팬아웃 (1:N 푸시)
│   → SNS 사용
├── 이벤트 기반 라우팅
│   → EventBridge 사용
└── 낮은 처리량, 간헐적 메시지
    → SQS/SNS 조합이 더 간단하고 저렴

Kinesis 서비스 유형

4가지 서비스 비교

┌─────────────────────────────────────────────────────────────┐
│                    Amazon Kinesis Family                     │
├──────────────────┬──────────────────────────────────────────┤
│                  │                                          │
│  Data Streams    │  실시간 데이터 스트리밍 (밀리초 지연)      │
│  ───────────     │  • 샤드 기반 용량 관리                    │
│                  │  • 24시간~365일 데이터 보존               │
│                  │  • 여러 컨슈머가 동시 소비 가능           │
│                  │                                          │
├──────────────────┼──────────────────────────────────────────┤
│                  │                                          │
│  Firehose        │  데이터 전달 서비스 (준실시간, 1분+ 지연)  │
│  ────────        │  • S3, Redshift, OpenSearch로 자동 전달   │
│                  │  • 자동 스케일링, 관리 불필요             │
│                  │  • Lambda로 데이터 변환 가능              │
│                  │                                          │
├──────────────────┼──────────────────────────────────────────┤
│                  │                                          │
│  Data Analytics  │  스트리밍 데이터에 SQL 쿼리               │
│  ──────────────  │  • 실시간 집계, 필터링                    │
│                  │  • Apache Flink 기반                     │
│                  │                                          │
├──────────────────┼──────────────────────────────────────────┤
│                  │                                          │
│  Video Streams   │  비디오 스트리밍 수집 및 처리             │
│  ─────────────   │  • 카메라, CCTV 영상 분석                 │
│                  │  • ML 모델과 연동                        │
│                  │                                          │
└──────────────────┴──────────────────────────────────────────┘

Kinesis Data Streams 핵심 개념

아키텍처

┌─────────────────────────────────────────────────────────────┐
│                   Kinesis Data Streams                       │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│   [Producers]                                                │
│   (EC2, Mobile, IoT)                                        │
│       │                                                      │
│       ▼                                                      │
│   ┌──────────────────────────────────────────┐              │
│   │              Data Stream                  │              │
│   │  ┌────────┐ ┌────────┐ ┌────────┐       │              │
│   │  │ Shard 1│ │ Shard 2│ │ Shard 3│       │              │
│   │  │ 1MB/s  │ │ 1MB/s  │ │ 1MB/s  │       │              │
│   │  │  쓰기  │ │  쓰기  │ │  쓰기  │       │              │
│   │  └────────┘ └────────┘ └────────┘       │              │
│   └──────────────────────────────────────────┘              │
│       │                                                      │
│       ▼                                                      │
│   [Consumers]                                                │
│   ┌────────┐ ┌────────┐ ┌────────┐                         │
│   │ Lambda │ │  KCL   │ │Firehose│                         │
│   │        │ │  App   │ │  → S3  │                         │
│   └────────┘ └────────┘ └────────┘                         │
│                                                              │
└─────────────────────────────────────────────────────────────┘

샤드 (Shard) 용량

작업용량 제한
쓰기 (Ingestion)샤드당 1MB/초 또는 1,000 레코드/초
읽기 (Consumption)샤드당 2MB/초
읽기 트랜잭션샤드당 5 GetRecords/초

시험 팁

샤드 계산 예시: 초당 5MB 쓰기가 필요하면 최소 5개 샤드 필요. 시험에서 "처리량 부족" 문제 → 샤드 수 증가!

파티션 키 (Partition Key)

파티션 키 역할:
├── 데이터를 어느 샤드로 보낼지 결정
├── MD5 해시 함수로 샤드 매핑
├── 최대 256자 유니코드 문자열
└── 같은 키 → 같은 샤드 → 순서 보장

좋은 파티션 키 예시:
├── user_id (사용자별 순서 보장)
├── device_id (디바이스별 순서 보장)
└── session_id (세션 내 순서 보장)

나쁜 파티션 키:
└── 고정값 (예: "default") → 핫 샤드 발생!

데이터 보존 기간

보존 기간비용사용 사례
24시간 (기본)추가 비용 없음일반 실시간 처리
7일 (확장)GB-월 추가 요금재처리 필요
365일 (장기)더 낮은 GB-월 요금규정 준수, 감사

용량 모드

모드특징선택 기준
On-Demand자동 스케일링, 사용량 기반 과금트래픽 예측 어려움
Provisioned샤드 수 직접 지정, 시간당 과금트래픽 예측 가능, 비용 최적화

Kinesis Data Firehose

특징

Firehose 핵심 특징:
├── 완전 관리형 (서버리스)
│   └── 샤드 관리 불필요, 자동 스케일링
├── 준실시간 전달 (Near Real-Time)
│   └── 최소 버퍼 시간 1분
├── 데이터 변환 지원
│   └── Lambda 함수로 변환
│   └── Parquet/ORC 형식 변환
├── 자동 압축
│   └── GZIP, Snappy, ZIP
└── 저장하지 않음
    └── 목적지로 바로 전달

지원 목적지

Firehose 목적지:
├── AWS 서비스
│   ├── Amazon S3
│   ├── Amazon Redshift (S3 경유)
│   ├── Amazon OpenSearch Service
│   └── Apache Iceberg Tables
├── 서드파티
│   ├── Splunk
│   ├── Snowflake
│   ├── Datadog
│   └── MongoDB
└── 커스텀
    └── HTTP 엔드포인트

Data Streams vs Firehose: 어떤 걸 선택해야 할까?

비교 표

비교 항목Data StreamsFirehose
지연 시간밀리초 (실시간)최소 1분 (준실시간)
데이터 저장24시간~365일 보존저장 없음 (바로 전달)
스케일링수동 (샤드 관리)자동
컨슈머여러 컨슈머 지원지정된 목적지만
데이터 변환컨슈머에서 처리내장 Lambda 변환
비용샤드 + 데이터량데이터량만
복잡도높음 (샤드 설계 필요)낮음

선택 기준 흐름도

실시간 스트리밍 데이터 처리가 필요하다
        │
        ▼
밀리초 수준 실시간 처리가 필요한가?
        │
       Yes → 여러 컨슈머가 동시에 데이터를 처리해야 하나?
        │           │
        │          Yes → [Kinesis Data Streams]
        │           │
        │          No → 데이터 재처리가 필요한가?
        │                   │
        │                  Yes → [Kinesis Data Streams]
        │                   │
        │                  No → [Firehose가 더 간단]
        │
       No
        │
        ▼
S3/Redshift/OpenSearch로 자동 전달이 목적인가?
        │
       Yes → [Kinesis Data Firehose]
        │
       No → [다른 서비스 고려 (SQS, EventBridge)]

시험 팁

시험 키워드 매핑:

  • "실시간 분석", "여러 애플리케이션이 동시 소비" → Data Streams
  • "S3에 자동 저장", "최소 운영 오버헤드" → Firehose
  • "데이터 재생(Replay)" → Data Streams (보존 기간 내 가능)

Kinesis vs SQS vs SNS: 어떤 걸 선택해야 할까?

비교 표

비교 항목Kinesis Data StreamsSQSSNS
모델Pull 기반 스트리밍Pull 기반 큐Push 기반 Pub/Sub
컨슈머 수여러 컨슈머 (동일 데이터)단일 컨슈머/메시지여러 구독자
데이터 보존24시간~365일최대 14일보존 없음
순서 보장파티션 키 기준FIFO 큐만없음
처리량초당 수백만 레코드초당 수천 메시지높음
재처리가능불가능불가능
비용높음낮음낮음

선택 기준

메시징/스트리밍 서비스 선택:
        │
        ▼
대용량 실시간 스트리밍 데이터인가? (로그, IoT, 클릭스트림)
        │
       Yes → 데이터 재처리가 필요하거나 여러 컨슈머가 필요한가?
        │           │
        │          Yes → [Kinesis Data Streams]
        │           │
        │          No → [Firehose + SQS 조합 고려]
        │
       No
        │
        ▼
여러 구독자에게 동시에 메시지를 보내야 하나? (팬아웃)
        │
       Yes → [SNS] 또는 [SNS + SQS 조합]
        │
       No
        │
        ▼
비동기 작업 분리/버퍼링이 목적인가?
        │
       Yes → [SQS]
        │
       No → [EventBridge] (이벤트 라우팅)

시험 팁

SQS vs Kinesis 핵심 차이:

  • SQS: 메시지 삭제 후 다른 컨슈머 접근 불가
  • Kinesis: 여러 컨슈머가 동일 데이터 읽기 가능, 보존 기간 내 재처리 가능

비용 구조

Data Streams 가격 (US-East 기준)

On-Demand Standard:

항목가격
데이터 수입$0.08/GB
데이터 출력$0.04/GB
스트림 시간$0.04/시간/스트림

Provisioned:

항목가격
샤드 시간$0.015/샤드/시간
PUT 페이로드$0.014/100만 단위

Firehose 가격

항목가격 (US-East)
첫 500TB$0.029/GB
다음 1.5PB$0.025/GB
5PB 이상$0.020/GB

시험 팁

비용 최적화:

  • 예측 가능한 워크로드 → Provisioned 모드가 저렴
  • 간헐적/예측 불가 → On-Demand 모드
  • 단순 전달만 필요 → Firehose가 Data Streams보다 저렴

SAA-C03 시험 출제 포인트

자주 출제되는 시나리오

  1. ✅ 서비스 선택: "실시간 클릭스트림 분석" → Kinesis Data Streams
  2. ✅ Streams vs Firehose: "S3로 자동 저장, 관리 최소화" → Firehose
  3. ✅ Kinesis vs SQS: "여러 애플리케이션이 동일 데이터 처리" → Kinesis
  4. ✅ 용량 계산: "초당 5MB 처리" → 5개 샤드 필요
  5. ✅ 데이터 보존: "7일간 재처리 필요" → 확장 보존 기간 설정

시험 문제 예시

시험 팁

시험 문제 예시 1: "IoT 센서에서 초당 수백만 개의 이벤트를 수집하여 실시간 대시보드와 S3 아카이브에 동시에 전송해야 합니다. 가장 적합한 아키텍처는?"

→ 정답: Kinesis Data Streams + 2개 컨슈머 (Lambda for 대시보드 + Firehose for S3)

시험 팁

시험 문제 예시 2: "웹 서버 로그를 수집하여 Amazon S3에 Parquet 형식으로 저장해야 합니다. 최소한의 운영 오버헤드로 구현하는 방법은?"

→ 정답: Kinesis Data Firehose (S3 목적지 + Parquet 변환 설정)

시험 팁

시험 문제 예시 3: "주문 처리 시스템에서 각 주문을 한 번만 처리해야 합니다. 주문 급증 시 시스템을 보호하려면?"

→ 정답: SQS (단일 컨슈머, 버퍼링 역할) - Kinesis 아님!

자주 묻는 질문 (FAQ)

Q: Kinesis Data Streams와 Firehose를 함께 사용할 수 있나요?

예. Data Streams를 소스로 Firehose를 연결할 수 있습니다. 실시간 처리(Data Streams 컨슈머)와 S3 아카이브(Firehose)를 동시에 구현할 때 유용합니다.

Q: 샤드 수는 어떻게 결정하나요?

쓰기 기준: 필요한 MB/s ÷ 1MB = 최소 샤드 수 읽기 기준: 필요한 MB/s ÷ 2MB = 최소 샤드 수 둘 중 큰 값을 선택합니다.

Q: Kinesis에서 메시지 순서가 보장되나요?

파티션 키 기준으로 보장됩니다. 같은 파티션 키를 가진 레코드는 같은 샤드로 가고, 샤드 내에서는 순서가 보장됩니다. 전체 스트림 레벨의 순서는 보장되지 않습니다.

Q: Enhanced Fan-Out이란 무엇인가요?

기본적으로 모든 컨슈머가 샤드당 2MB/s를 공유합니다. Enhanced Fan-Out을 사용하면 각 컨슈머가 샤드당 2MB/s를 독립적으로 받습니다. 컨슈머가 많을 때 유용합니다.

Q: Kinesis는 서버리스인가요?

Firehose는 완전 서버리스입니다. Data Streams는 샤드 관리가 필요하지만, On-Demand 모드에서는 자동 스케일링됩니다.

관련 글

참고 자료