Amazon Kinesis 완전 정리 (DEA-C01 시험 핵심)
들어가며
DEA-C01 시험의 Domain 1: Data Ingestion and Transformation (34%) 영역에서 자주 등장하는 서비스가 바로 Amazon Kinesis입니다.
Kinesis는 하나의 서비스가 아니라 실시간 스트리밍 처리를 위한 여러 서비스 묶음입니다. 시험에서는 특히 각 서비스의 역할 차이와 Kinesis Data Streams(KDS)의 아키텍처가 자주 출제됩니다.
이 글에서는 시험 대비 관점에서 꼭 알아야 할 핵심 내용을 정리해보겠습니다.
---
Kinesis 서비스 4가지 한눈에 보기
Kinesis는 크게 네 가지 서비스로 구성됩니다. 각각의 목적이 분명히 다르기 때문에 시험에서는 시나리오에 맞는 서비스 선택 문제가 자주 나옵니다.
| 서비스 | 역할 | 핵심 키워드 | | ------------------------------ | ------------------------- | -------------- | | Kinesis Data Streams (KDS) | 스트리밍 데이터 캡처 및 실시간 처리 | 샤드, 실시간 처리 | | Kinesis Data Firehose | 스트리밍 데이터를 데이터 스토어로 자동 전달 | 자동 스케일, 데이터 적재 | | Kinesis Data Analytics | 스트림 데이터를 SQL 또는 Flink로 분석 | 실시간 분석 | | Kinesis Video Streams | 비디오 스트림 수집 및 처리 | 영상 분석 |
시험에서 자주 등장하는 포인트는 다음과 같습니다.
직접 스트림 처리 로직을 구현해야 한다 → Kinesis Data Streams 데이터를 S3나 Redshift에 자동으로 적재해야 한다 → Firehose 스트림 데이터를 SQL로 분석해야 한다 → Data Analytics
!Kinesis 서비스 4가지 비교
Kinesis Data Streams 핵심 구조 (Shard)
Kinesis Data Streams의 핵심 개념은 Shard(샤드) 입니다.
모든 처리량과 확장성은 샤드를 기준으로 결정됩니다.
| 항목 | 내용 | | --------- | -------------------- | | 샤드 쓰기 처리량 | 1MB/초 또는 초당 1000 레코드 | | 샤드 읽기 처리량 | 2MB/초 | | 레코드 최대 크기 | 1MB | | 기본 보존 기간 | 24시간 | | 최대 보존 기간 | 7일 | | 순서 보장 | 샤드 내부에서 보장 |
여기서 중요한 시험 포인트는 처리량 계산 방식입니다.
처리량이 부족하면 샤드를 추가하여 확장할 수 있습니다.
---
서비스 모드: Provisioned vs On-Demand
Kinesis Data Streams에는 두 가지 운영 모드가 있습니다.
| 모드 | 특징 | 사용 상황 | | --------------- | ----------- | -------------- | | Provisioned | 샤드 수를 직접 지정 | 예측 가능한 트래픽 | | On-Demand | 자동으로 처리량 확장 | 트래픽 예측이 어려운 경우 |
시험에서는 보통 트래픽 패턴을 기준으로 정답이 결정됩니다.
트래픽이 일정하다 → Provisioned 트래픽이 급격히 변한다 → On-Demand
---
Producers: 데이터를 넣는 방법
스트림에 데이터를 보내는 주체를 Producer라고 합니다.
대표적인 방법은 다음 세 가지입니다.
| 도구 | 특징 | 사용 상황 | | ---------------------------------- | ----------- | ----------- | | AWS SDK | 직접 API 호출 | 기본적인 데이터 전송 | | Kinesis Producer Library (KPL) | 고처리량 전송 | 대규모 스트리밍 | | Kinesis Agent | 로그 파일 자동 전송 | 서버 로그 수집 |
특히 시험에서는 다음 두 가지가 자주 등장합니다.
대규모 스트리밍 데이터 처리 → KPL Linux 서버 로그 자동 수집 → Kinesis Agent
---
Consumers: 데이터를 읽는 방법
스트림 데이터를 읽는 애플리케이션을 Consumer라고 합니다.
기본적으로는 GetRecords API를 사용합니다.
| 항목 | 내용 | | -------- | --------- | | 호출 제한 | 초당 5회 | | 최대 읽기 크기 | 10MB | | 처리량 | 샤드당 2MB/s |
여러 Consumer가 동시에 데이터를 읽을 경우 처리량을 공유하게 됩니다.
이 문제를 해결하기 위해 Enhanced Fan-Out 기능을 사용할 수 있습니다.
Enhanced Fan-Out을 사용하면
Consumer마다 전용 처리량(2MB/s) 이 제공되고 여러 애플리케이션이 동시에 스트림을 읽어도 성능 저하가 발생하지 않습니다.
---
KCL (Kinesis Client Library)
여러 애플리케이션 인스턴스가 스트림을 처리할 때는 KCL을 사용합니다.
KCL의 주요 역할은 다음과 같습니다.
| 기능 | 설명 | | -------- | --------------- | | 샤드 분산 처리 | 여러 워커가 병렬 처리 | | 체크포인트 관리 | 처리 위치 저장 | | 장애 복구 | 마지막 처리 지점부터 재시작 |
체크포인트 정보는 Amazon DynamoDB에 저장됩니다.
여기서 중요한 시험 포인트는 비용과의 관계입니다.
체크포인트를 자주 기록하면 DynamoDB 비용 증가 너무 적게 기록하면 장애 발생 시 재처리 데이터 증가
---
Lambda와 Kinesis 통합
Kinesis는 AWS Lambda와 매우 자주 함께 사용됩니다.
Lambda는 스트림을 자동으로 폴링하고 새로운 데이터를 처리합니다.
| 기능 | 설명 | | ----- | ------------------------- | | 자동 폴링 | Lambda가 스트림에서 데이터 읽음 | | 자동 확장 | 샤드 수에 따라 Lambda 확장 | | 병렬 처리 | Parallelization Factor 사용 |
처리량을 높이는 대표적인 방법은 다음 두 가지입니다.
Parallelization Factor 증가 Enhanced Fan-Out 사용
---
샤드 확장과 축소
트래픽이 증가하거나 감소하면 샤드를 조정할 수 있습니다.
| 작업 | 설명 | | ------------- | ------- | | Splitting | 샤드 수 증가 | | Merging | 샤드 수 감소 |
샤드를 분할한 이후에는 데이터 처리 순서를 주의해야 합니다.