Amazon Kinesis
전체 구조 (파이프라인)
데이터 소스 처리 저장/분석
(IoT, 앱 로그, 클릭)
│
▼
┌─────────────┐ ┌──────────────────┐ ┌─────────────┐
│ Kinesis │───►│ Managed Service │───►│ Firehose │───► S3/Redshift
│ Data Streams│ │ for Apache Flink│ │ (전달) │ OpenSearch
│ (수집·저장) │ │ (실시간 분석·변환) │ └─────────────┘
└─────────────┘ └──────────────────┘
Plain Text
복사
Kinesis Data Streams (KDS)
데이터를 실시간으로 받아서 여러 소비자가 각자 처리할 수 있도록 일정 기간 보관해두는 스트리밍 파이프
•
핵심 특징
◦
실시간 스트리밍 (밀리초 지연)
◦
데이터 보존: 기본 24시간 ~ 최대 365일
◦
여러 소비자가 동일 스트림 동시 읽기 가능
◦
데이터 재처리(Replay) 가능
◦
샤드(Shard) 기반 처리량 관리
•
샤드 처리량
◦
쓰기: 샤드당 1MB/초 또는 1,000 레코드/초
◦
읽기: 샤드당 2MB/초
•
용량 모드
◦
Provisioned: 샤드 수 수동 지정
◦
On-Demand: 자동 스케일링 (샤드 관리 불필요)
•
소비자 (Consumer)
◦
Lambda, KCL, Kinesis Data Analytics (Apache Flink), Kinesis Firehose
Kinesis Data Firehose (Amazon Data Firehose)
데이터를 받아 목적지로 자동 배달해주는 완전 관리형 배송 서비스
•
핵심 특징
◦
완전 관리형 데이터 전달 서비스
◦
Near-Real-Time (최소 60초 버퍼링, Zero Buffer 옵션 ~5초)
◦
데이터 보존 없음 (전달 후 끝)
◦
재처리(Replay) 불가
◦
스케일링 자동
•
지원 목적지 (Destination)
◦
S3, Redshift, OpenSearch, Splunk
◦
Datadag, MongoDB, HTTP Endpoint
•
변환 기능:
◦
Lambda로 데이터 변환 후 전달
◦
형식 변환: JSON → Parquet/ORC (S3 저장 최적화)
KDS vs Firehose 핵심 비교
항목 | Kinesis Data Streams | Kinesis Firehose |
지연 시간 | 밀리초 (실시간) | 최소 60초 (Near-Real-Time) |
데이터 보존 | 1일~365일 | 없음 |
재처리(Replay) |  | |
다중 소비자 | | (단일 목적지) |
스케일링 | 수동(샤드) 또는 On-Demand | 자동 |
관리 복잡도 | 높음 | 낮음 (완전 관리형) |
주요 용도 | 실시간 처리, 커스텀 앱 | S3/Redshift 전달, 로그 수집 |
실시간 처리 + 여러 소비자 + 재처리 필요 → KDS
S3/Redshift로 자동 전달 + 관리 최소화 → Firehose
두 서비스 함께: KDS → 실시간 처리 + Firehose → S3 저장
Amazon Managed Service for Apache Flink
이전 이름: Kinesis Data Analytics
현재: Amazon Managed Service for Apache Flink
•
역할:
◦
스트리밍 데이터를 실시간으로 SQL 또는 Apache Flink로 분석
◦
KDS 또는 Firehose를 소스로 사용
◦
이상 탐지, 실시간 집계, 필터링
•
예시
◦
IoT 센서 데이터 → KDS → Apache Flink → 이상값 탐지 → Firehose → S3 저장
AWS Glue + Athena + Redshift
데이터 분석 파이프라인
원시 데이터 (S3)
│
▼
AWS Glue (ETL + 카탈로그)
├── Crawler: S3 데이터 스캔 → 스키마 자동 감지
├── Data Catalog: 메타데이터 중앙 저장소
└── ETL Job: 데이터 변환 (JSON→Parquet, 정제)
│
▼
변환된 데이터 (S3 — Parquet/ORC)
│
├──► Amazon Athena (서버리스 SQL, 임시 분석)
└──► Amazon Redshift (대규모 DW, 정기 분석)
Plain Text
복사
AWS Glue
•
Glue Crawler
◦
S3, RDS, DynamoDB 등 데이터 소스 자동 스캔
→ 스키마 추론 → Glue Data Catalog에 테이블 등록
•
Glue Data Catalog
◦
Athena, Redshift Spectrum, EMR이 공유하는 중앙 메타데이터 저장소
•
Glue ETL
◦
PySpark/Python 기반 데이터 변환
◦
서버리스 (인프라 관리 불필요)
◦
JSON → Parquet 변환 (Athena 쿼리 비용 절감)
AWS Athena
•
개념
◦
서버리스 SQL 쿼리 서비스
◦
S3에 있는 데이터를 직접 쿼리 (별도 데이터 이동 없음)
◦
표준 SQL 사용
•
과금 방식
◦
스캔한 데이터양 기준 ($5/TB)
→ Parquet/ORC 컬럼형 포맷 + 파티셔닝으로 비용 절감
•
사용 사례
◦
CloudTrail 로그 분석
◦
ALB/CloudFront 액세스 로그 분석
◦
Cost & Usage Report 분석
◦
임시(Ad-hoc) 쿼리
Amazon Redshift
•
개념
◦
완전 관리형 페타바이트급 데이터 웨어하우스
◦
컬럼형 스토리지 → 집계 쿼리 최적화
◦
대규모 정기 분석에 적합
•
Redshift Spectrum
◦
Redshift에서 S3 데이터 직접 쿼리
◦
데이터를 Redshift로 복사하지 않고도 분석 가능
→ Athena와 유사하지만 Redshift 클러스터 필요
•
Redshift Serverless:
◦
클러스터 관리 없이 Redshift 사용
◦
간헐적 쿼리 워크로드에 비용 효율적
Athena vs Redshift 선택 기준
항목 | Athena | Redshift |
인프라 | 완전 서버리스 | 클러스터 (Serverless 옵션 있음) |
데이터 위치 | S3에서 직접 쿼리 | Redshift 내 또는 S3(Spectrum) |
적합한 쿼리 | 임시(Ad-hoc), 비정기 | 정기적, 복잡한 BI 쿼리 |
비용 모델 | 스캔 데이터양 | 클러스터 시간당 |
쿼리 성능 | 중간 | 매우 빠름 (클러스터 최적화) |
S3 로그를 가끔 분석 + 서버리스 → Athena
매일 대규모 BI 리포트 → Redshift
S3 데이터를 Redshift로 복사 없이 분석 → Redshift Spectrum
JSON → Parquet 변환 + 카탈로그 관리 → Glue
DynamoDB 심화
GSI vs LSI — 시험 단골 비교
GSI(Global Secondary Index)는 기본 테이블과 다른, 파티션 키와 정렬 키를 가질 수 있는 인덱스로, 테이블의 모든 파티션에 걸쳐 쿼리할 수 있어 “글로벌”이라 불린다. GSI는 별도의 프로비저닝된 처리량 설정을 가진다. LSI(Local Secondary Index)는 기본 테이블과 동일한 파티션 키를 가지되 다른 정렬 키를 가지는 인덱스다. LSI는 인덱싱하는 테이블과 읽기/쓰기 처리량 설정을 공유한다.
GSI | LSI | |
파티션 키 | 다른 파티션 키 가능 | 기본 테이블과 동일 |
정렬 키 | 다른 정렬 키 가능 | 다른 정렬 키만 변경 가능 |
생성 시점 | 테이블 생성 후에도 추가 가능 | 테이블 생성 시에만 정의 |
처리량 | 별도 RCU/WCU 프로비저닝 | 기본 테이블과 공유 |
일관성 | 최종 일관성만 지원 | 강력 일관성 지원 |
파티션 크기 제한 | 없음 | 파티션 키당 10GB 제한 |
개수 제한 | 테이블당 최대 20개 | 테이블당 최대 5개 |
기존 테이블에 새 쿼리 패턴 추가 → GSI (나중에 추가 가능)
테이블 생성 시 추가 정렬 기준 필요 → LSI (생성 시에만)
강력 일관성 읽기 필요 → LSI
완전히 다른 파티션 키로 쿼리 → GSI
DynamoDB DAX
•
DAX (DynamoDB Accelerator)
◦
DynamoDB 전용 인메모리 캐시
◦
마이크로초 응답 시간
◦
애플리케이션 코드 변경 최소화
(DynamoDB API 호환 — 엔드포인트만 DAX로 변경)
•
DAX vs ElastiCache 선택
◦
DAX → DynamoDB 전용, 코드 변경 취소
◦
ElastiCache → 여러 DB 캐싱 가능, 더 유연한 데이터 구조
•
Write-Through 캐싱 방식
◦
쓰기 시 DAX와 DynamoDB 동시 업데이트
◦
Lazy Loading 미지원
DynamoDB Streams
테이블 변경(Insert/Update/Delete) 이벤트 캡처
24시간 보존
•
활용 패턴:
◦
DynamoDB Streams → Lambda
→ 변경 시 실시간 알림
→ 다른 테이블로 복제
→ ElastiCache 자동 갱신
→ 크로스 리전 복제 (Global Tables 이전 방식)
•
Global Tables:
◦
DynamoDB Streams 기반으로 자동 멀티 리전 복제
→ 직접 Streams + Lambda 구성보다 권장
DynamoDB 읽기 일관성 모델
•
Eventually Consistent Read (기본)
◦
최신 데이터가 아닐 수 있음
◦
비용: RCU(Read Capacity Unit)의 절반 소비
•
Strongly Consistent Read
◦
항상 최신 데이터 반환
◦
비용: RCU 1개 소비
◦
GSI에서는 지원 안 됨
•
Transactional Read
◦
ACID 트랜잭션
◦
비용: RCU의 2배 소비
AWS Lake Formation
데이터 레이크 구축 및 보안 관리 서비스
•
핵심 기능:
◦
데이터 레이크 중앙 보안 관리
→ Glue Data Catalog 기반
→ 테이블/컬럼 레벨 세밀한 접근 제어
◦
Cross-Account 데이터 공유
→ 다른 계정에 특정 테이블/컬럼만 접근 허용
◦
데이터 수집 자동화
→ S3, RDS, 온프레미스에서 자동 수집
•
사용 사례
◦
여러 팀이 S3 데이터 레이크를 공유하지만 각 팀은 자신의 데이터만 접근해야 함
→ Lake Formation 컬럼 레벨 권한 제어
EMR vs Glue 선택 기준
AWS Glue | Amazon EMR | |
유형 | 서버리스 ETL | 관리형 Hadoop 클러스터 |
코드 | PySpark/Python | Spark, Hive, HBase, Presto |
인프라 관리 | 없음 | EC2 클러스터 직접 관리 |
커스터마이징 | 제한적 | 높음 (다양한 오픈소스 도구) |
시작 시간 | 빠름 | 클러스터 시작 시간 필요 |
비용 | 실행 시간 기반 | EC2 인스턴스 비용 |
적합한 경우 | ETL, 데이터 변환 | 대규모 ML, 복잡한 분석 |
서버리스 ETL, 관리 최소화 → Glue
Spark/Hive 커스텀 클러스터, 대규모 ML → EMR
Apache HBase, Presto 사용 → EMR
Summary
개념 | 한 줄 요약 |
KDS | 실시간, 다중 소비자, Replay 가능, 샤드 기반 |
Firehose | Near-Real-Time, S3/Redshift 전달, 관리 불필요 |
Apache Flink | 스트리밍 실시간 SQL/Flink 분석 |
Glue Crawler | S3 스캔 → 스키마 자동 감지 → Data Catalog 등록 |
Glue Data Catalog | Athena/Redshift/EMR 공유 메타데이터 저장소 |
Athena | 서버리스 SQL, S3 직접 쿼리, 스캔 데이터 과금 |
Redshift | 페타바이트 DW, 대규모 BI, 컬럼형 스토리지 |
Redshift Spectrum | Redshift에서 S3 직접 쿼리 |
GSI | 다른 파티션 키 가능, 나중에 추가 가능, 최종 일관성만 |
LSI | 같은 파티션 키, 생성 시에만 정의, 강력 일관성 지원 |
DAX | DynamoDB 전용 인메모리 캐시, 마이크로초 응답 |
DynamoDB Streams | 변경 이벤트 캡처, 24시간 보존, Lambda 트리거 |
Global Tables | Streams 기반 멀티 리전 자동 복제 |
Lake Formation | 데이터 레이크 컬럼 레벨 보안, 크로스 계정 공유 |
EMR | 관리형 Hadoop 클러스터, 대규모 커스텀 분석 |