아마존 Kinesis
더 많은 작업
- Amazon Kinesis; Kinesis; 아마존 키네시스
- 실시간으로 계속 들어오는 스트리밍 데이터를 수집·저장·전달·처리하는 AWS 서비스군
아마존 Kinesis는 하나의 서비스가 아니라 스트리밍 데이터를 다루는 서비스 묶음의 이름이다. 클릭 로그, IoT 센서 값, 애플리케이션 로그처럼 끊임없이 발생하는 데이터를 받아서 몇 초 안에 처리하거나 저장소로 넘기는 데 쓴다. 현재 Kinesis 이름이 붙은 서비스는 Kinesis Data Streams와 Kinesis Video Streams이고, 예전 Kinesis Data Firehose는 아마존 Data Firehose로 이름이 바뀌었다. 같은 문제를 아파치 카프카로 풀고 싶다면 아마존 MSK를 쓴다. 일반 개념은 스트리밍 문서를 참고한다.
| 구분 | Kinesis Data Streams | 아마존 Data Firehose | Kinesis Video Streams |
|---|---|---|---|
| 역할 | 스트림을 저장해 두고 여러 소비자가 직접 읽어 처리 | 받은 데이터를 목적지까지 자동 전달 | 카메라 등에서 오는 영상·음성 스트림 수집·저장 |
| 처리 코드 | 소비자 애플리케이션을 직접 작성(Lambda, KCL, Flink 등) | 코드 없이 설정만으로 전달, 필요하면 Lambda로 변환 | SDK로 프레임 단위 접근, 영상 분석 연동 |
| 데이터 보존 | 기본 24시간, 최대 365일, 보존 기간 안에서 재처리 가능 | 보존하지 않음(버퍼링 후 전달) | 설정한 보존 기간 동안 저장 |
| 용량 관리 | 온디맨드 또는 프로비저닝(샤드 수 지정) | 완전 관리형, 자동 확장 | 완전 관리형 |
| 목적지 | 소비자가 결정 | S3, Redshift, OpenSearch Service, Splunk, Apache Iceberg 테이블, HTTP 엔드포인트 등 | 영상 분석 애플리케이션 |
| 대표 시나리오 | 실시간 대시보드, 이상 탐지, 여러 팀이 같은 스트림을 각자 소비 | 로그·이벤트를 S3 데이터 레이크나 Redshift로 적재 | CCTV·드론 영상 수집과 분석 |
생산자(producer)가 레코드를 쓰면 스트림이 보존 기간 동안 저장하고, 소비자(consumer)가 읽어서 처리하는 구조다.
| 항목 | 설명 |
|---|---|
| 샤드(shard) | 스트림의 용량 단위. 샤드 하나는 쓰기 초당 1MB 또는 1,000레코드, 읽기 초당 2MB를 처리한다 |
| 파티션 키 | 레코드가 들어갈 샤드를 정하는 키. 같은 파티션 키의 레코드는 같은 샤드에 들어가므로 파티션 키 단위로 순서가 보장된다 |
| 시퀀스 번호 | 샤드 안에서 레코드마다 부여되는 번호 |
| 보존 기간 | 기본 24시간이고 최대 8,760시간(365일)까지 늘릴 수 있다. 24시간을 넘기면 추가 요금이 붙는다 |
| 용량 모드 | 온디맨드(Standard, Advantage)는 트래픽에 맞춰 자동 확장되고, 프로비저닝 모드는 샤드 수를 직접 늘리고 줄인다 |
| 향상된 팬아웃 | 등록한 소비자마다 샤드당 전용 읽기 처리량을 받는 방식. 소비자가 여러 개일 때 서로 처리량을 나눠 쓰지 않는다 |
| 레코드 크기 | 레코드 하나의 데이터는 base64 인코딩 전 기준 최대 10MiB까지 쓸 수 있다 |
- 한 샤드에 특정 파티션 키가 몰리면(핫 샤드) 그 샤드만 한도를 넘어 쓰기 제한(throttling)이 생긴다. 파티션 키를 고르게 분산해야 한다.
- 데이터가 보존 기간 동안 남아 있으므로, 소비자 오류가 났을 때 과거 시점부터 다시 읽어 재처리할 수 있다. SQS와 크게 다른 점이다.
이전 이름은 Kinesis Data Firehose이다. 스트리밍 데이터를 받아서 목적지까지 넣어 주는 완전 관리형 전달 서비스로, 샤드나 소비자 코드를 관리하지 않는다.
- 버퍼링: 들어온 데이터를 버퍼 크기(MB)나 버퍼 간격(초) 중 먼저 차는 조건에 맞춰 모았다가 한 번에 전달한다. 그래서 완전한 실시간이 아니라 준실시간(near real-time)이다.
- 형식 변환: JSON 입력을 아파치 파케이(Parquet)나 Apache ORC 같은 열 형식으로 바꿔 S3에 저장할 수 있다. 스키마는 AWS Glue 데이터 카탈로그의 테이블 정의를 쓴다. CSV 등 다른 입력은 먼저 Lambda로 JSON으로 바꿔야 한다.
- 변환: Lambda 함수를 호출해 레코드를 가공하거나 걸러낸 뒤 전달할 수 있다.
- Redshift 적재: 먼저 S3에 쓰고 Redshift의 COPY 명령으로 적재한다.
- 원본으로 Kinesis Data Streams를 지정해 스트림을 읽어 오게 할 수도 있다.
스마트폰, 보안 카메라, 차량 카메라, 드론 등 수많은 장치에서 실시간 영상을 받아 저장하고, 실시간 처리나 배치 분석 애플리케이션이 프레임 단위로 꺼내 쓸 수 있게 한다. 저장한 데이터는 자동으로 암호화되고 생산자·수집 타임스탬프로 색인된다. 영상 외에 오디오, 열화상, 레이더 같은 시계열 데이터도 보낼 수 있다.
아마존 Managed Streaming for Apache Kafka(아마존 MSK)는 오픈 소스 아파치 카프카를 관리형으로 운영해 주는 서비스다. 클러스터 생성·삭제, 브로커 장애 감지와 교체 같은 제어 영역 작업을 AWS가 맡고, 토픽 생성과 생산·소비는 카프카 API 그대로 쓴다.
- 브로커를 가용 영역마다 배치한다. 프로비저닝 클러스터(Standard, Express 브로커)와 용량 관리가 필요 없는 MSK Serverless가 있다.
- 기존 카프카 애플리케이션, 도구, 커넥터를 코드 변경 없이 옮길 수 있다는 점이 가장 큰 선택 이유다.
- MSK Connect로 외부 시스템과 데이터를 주고받고, MSK Replicator로 리전 간 복제를 구성한다.
| 구분 | Kinesis Data Streams | 아마존 MSK | 아마존 SQS |
|---|---|---|---|
| 모델 | 스트림(로그) | 스트림(카프카 토픽) | 메시지 큐 |
| 재처리 | 보존 기간 안에서 다시 읽기 가능 | 토픽 보존 설정 안에서 다시 읽기 가능 | 소비 후 삭제, 다시 읽기 불가 |
| 여러 소비자 | 같은 데이터를 여러 소비자가 각각 읽음 | 소비자 그룹별로 각각 읽음 | 메시지 하나는 소비자 하나가 처리 |
| 순서 | 샤드(파티션 키) 단위 | 파티션 단위 | 표준 대기열은 순서 보장 없음, FIFO 대기열은 보장 |
| 선택 기준 | AWS 관리형 스트리밍을 최소 운영으로 | 카프카 호환이 필요할 때 | 작업 분리·완충용 비동기 처리 |
- "스트리밍 데이터를 S3·Redshift·OpenSearch에 코드 없이 적재, 운영 오버헤드 최소"면 아마존 Data Firehose를 고른다. "실시간으로 직접 처리, 여러 애플리케이션이 같은 데이터를 소비, 재처리 필요"면 Kinesis Data Streams다.
- "밀리초~초 단위 실시간"이 요구되면 버퍼링이 있는 Firehose보다 Data Streams가 맞다.
- 순서 보장이 필요하면 같은 엔터티(주문 ID, 장치 ID)를 파티션 키로 쓴다. 특정 샤드만 제한에 걸리면 파티션 키 분산이 해법이다.
- "기존 카프카 애플리케이션을 그대로 이전"이면 아마존 MSK다.
- "수집한 JSON을 Parquet으로 바꿔 Athena 비용을 줄인다"는 Firehose의 레코드 형식 변환으로 해결한다.
- 영상 스트림 수집은 Kinesis Video Streams이며 Data Streams와 혼동하지 않는다.
- Amazon Kinesis Data Streams 용어 및 개념 – AWS
- 스트림 모드 선택 – AWS
- Amazon Data Firehose란 무엇인가요? – AWS
- 입력 데이터 형식 변환 – AWS
- Amazon MSK란 무엇인가요? – AWS