728x90
이 시리즈를 포스트하는 이유도 사실 면접에서 받은 질문으로 부터 시작됐습니다. 제가 스트리밍 플랫폼에 대한 지식도 많지 않을 뿐더러 이번 기회에 카프카를 비롯한 스트리밍 플랫폼 학습을 제대로 하고자 게시를 하게 됐습니다.
카프카의 기본적인 개념이나 확장은 다른 포스트에서 자세히 다뤄보고, 철저히 특징과 장단점위주로 다른 제품군과 비교를 하여 가장 효율적인 스트리밍 파이프라인은 어떤 형태 일지를 구상하며 정리해보도록 하겠습니다.
1편(broker 비교, kafka vs kinesis)
https://spidyweb.tistory.com/599
2편(consumer 비교, flink, spark streaming, kafka streaming, logstash, kinesis firehose)
https://spidyweb.tistory.com/600
3편(이상 데이터 탐지, 백업, 모니터링, 분석, 파이프라인 및 최종)
https://spidyweb.tistory.com/601
1. Kafka(MSK) vs Kinesis data streams(KDS)
1) Kinesis Data Stream의 특징
비교 하기에 앞서 간단하게 Kinesis Data Stream의 특징을 확인해보고 Kafka와 비교해보도록 하겠습니다.
Amazon Kinesis에서 "Shard"는 데이터 스트림의 기본 단위로써 Stream 내에서 데이터의 전송 및 처리의 단위를 제공, 데이터를 효율적으로 관리하고 처리하는 데 필수적인 역할 Kafka의 Partition개념과 상당히 유사합니다.
(2025-05-08 기준 샤드는 최대 계정당 20,000개 까지 설정 가능합니다.)
Kinesis의 Shard는 Kafka Partition과는 다르게 늘린 이후 줄일 수도 있습니다.
- 샤드 수 증가
- "샤드 분할 (Shard Split)" , 한 샤드를 두 개로 나누면 처리량이 증가
- 샤드 수 감소
- "샤드 병합 (Shard Merge)", 두 개의 샤드를 하나로 병합하여 처리량이 감소
- 수동으로 API를 통해 조절하거나, Kinesis Auto Scaling을 구성하여 자동으로 조절가능
참고: 샤드 수를 조정하면 **데이터 분포(Partition Key hash range)**가 바뀌기 때문에, producer/consumer의 파티셔닝 로직도 신경 써야 할 수 있음
Shard는 partition과 유사하지만, 그러면 kafka의 topic은 kinesis data stream 어디에 해당할까?
1 topic = 1 data stream 에 해당한다고 보면 될 것 같습니다.
Kinesis Data Stream의 특징을 살펴보면 아래와 같습니다.
- 독립적인 데이터 처리: 각 샤드는 별개의 데이터 스트림을 유지하여 병렬로 데이터를 처리 가능
- 처리 용량: 각 샤드는 초당 최대 1,000개의 데이터를 쓸 수 있고, 5개의 데이터를 읽을 수 있다. 필요에 따라 샤드를 추가해 처리 능력을 확장가능
- 순서 보장: 같은 샤드에 기록된 데이터는 순서를 유지하지만, 다른 샤드 간에는 순서가 보장되지 않음(카프카 파티션과 동일)
- Shard Iterator: 데이터를 읽기 위해 사용하는 포인터로, 샤드 내에서 특정 데이터에 접근 가능(kafka의 offset 개념)
- 보통 KCL(Kinesis Client Library) + DynamoDB를 사용하여 consumer group처럼 동작하게 만드며, Kafka의 offset과 비슷한 기능을 함(DynamoDB에 offset(checkpoint) 저장)
- Kafka에서 데이터 재처리를 할 때 Offset을 조정하여 재처리를 하듯, Kinesis에서도 Shard Iterator를 통해 마지막으로 읽은 위치를 추적하는데, 이를 수동으로 조정해서 이전 데이터를 다시 읽을 수 있음
- Enhanced Fan-Out
- 보통 1개의 kinesis data stream당 하나의 consumer를 붙이는데, 하나의 샤드당 초당 2번의 GetRecords 호출이 기본적으로 제한되기 때문에, 여러 Consumer가 동일한 스트림에 접근할 경우, 성능 저하나 throttling(속도 제한)이 발생할 수 있으므로, EFO + KCL + DynamoDB를 사용하여 여러 consumer를 붙여 Consumer Group처럼 사용할 수 있음
- 각 Consumer가 자신만의 2MB/s 전용 처리량을 갖고, 다른 Consumer와 독립적으로 데이터를 읽을 수 있음.
- 최대 20개의 EFO consumer까지 등록 가능.
- 실시간 처리에 적합하고, consumer 간 경합이 없음.
- 단점: 추가 비용 발생.
- 데이터 자동 저장: (24시간 ~ 365일 보존 설정 가능) 또한 kafka와 마찬가지로 데이터를 consume해도 retention 기간동안 데이터를 보존하고 있음
2) Kafka vs Kinesis 특징 비교
| 항목 | Apahce Kafka | AWS Kinesis Data Stream |
| 제공 형태 | 오픈소스 (셀프 관리 or MSK) | AWS Fully Managed 서비스(Serverless) |
| 사용 목적 | 로그 수집, 이벤트 스트리밍, 대용량 버퍼링 | 실시간 로그, IoT 데이터, 클릭스트림 처리 |
| 처리량 | 초당 수백 MB~GB까지 가능 (튜닝 여지 높음) | Shard 단위로 확장 (각 Shard: 1MB/s write, 2MB/s read) |
| 내구성 | 디스크 저장 기반, 복제 기능 (Replication) | 데이터 자동 저장 (24시간 ~ 365일 보존 설정 가능) |
| 유연성 | 다양한 설정/플러그인 지원 (커스텀 처리 가능) | AWS 서비스와 통합 최적화 (Lambda, Firehose 등) |
| Consumer Group 기반 병렬 처리 | 매우 유연 (파티션 수에 따라 병렬성 결정) | Shard 수에 따라 병렬성 결정 |
| 지연 시간 | 수 밀리초~수 초 | 수 밀리초~수 초 |
| 처리 제어 | 정확히 한 번(exactly-once) 지원 (설정 필요) | At-least-once 기본, Lambda 사용 시 병렬성 조정 가능 |
| 설치/구성 난이도 | 높음 (ZooKeeper or KRaft, 브로커 구성 등 필요) | 매우 쉬움 (AWS 콘솔 또는 CLI로 설정) |
| 모니터링 | Prometheus, Grafana 등 외부 도구 필요 | CloudWatch로 통합 모니터링 제공 |
| 장애 대응 | 수동 대응 필요 (운영 경험 중요) | AWS가 대부분 관리 (장애 복구 자동) |
| 기본 메시지 크기 | 1MB (message.max.bytes 또는 max.message.bytes) | 기본 1MB |
| 최대 메시지 크기 | 수십 MB ~ 수백 MB까지 가능 (보통 실무에서는 10MB~50MB 사이로 설정) | 최대 1MB( 단일 record(put 또는 get)의 최대 크기는 1MB) 요청당 최대 500records or 5MB(단일 PutRecords API 호출로 보낼 수 있는 전체 데이터의 크기) 최대 10,000 records 또는 10MB (한 번의 GetRecords 요청으로 읽을 수 있는 최대 크기) |
| 복제 | 파티션 단위 복제(replication.factor=3 (브로커 3개 필요)) | AWS가 자동으로 3-way 복제 수행(고정, 수동 설정 불가) |
2-1) 비용 비교
| 항목 | MSK | Kinesis Data Streams |
| 과금 방식 | EC2 + EBS + 네트워크 + MSK 비용 (브로커 수 기준) | Shard 단위 과금 + PUT/GET 요청 수 + Retention 옵션 |
| 비용 예측 가능성 | 상대적으로 예측 가능 (고정 브로커 수 기준) | 비용 예측이 어려움 (요청 수, 레코드 수, 처리량에 따라 유동적) |
| 저비용 처리량 최적화 | 고정 인프라 비용이 있지만, 처리량 늘어나도 비용 변동 작음 | 처리량 늘면 비용 급증 (Shard, PUT/GET 수 등 누적 과금) |
| 보관 기간 비용 | EBS 비용만 증가 (일반적으로 저렴) | 24시간 이상 저장하면 추가 요금 발생 |
| 예시 | 브로커 3개 (m5.large) 기준: 약 $300~500/월 | 10 Shards + 일 1억건 PUT: 수백~수천 달러/월 |
💡 Kinesis는 소규모에서는 저렴하지만, 대규모 처리(수억 건/일 기준) 시 Kafka보다 훨씬 비쌀 수 있음
2-2) consumer 제어 정도 차이
| 기능/특징 | Kafka (고제어 & 유연) | Kinesis (제한적 & 추상화) |
| Offset 관리 | ✅ 직접 제어 가능 (commit, reset, rewind 등) | ❌ 추상화됨 (Checkpointer 필요, 수동 설정 어려움) |
| Partition 직접 제어 | ✅ 특정 파티션만 읽기 가능 | ❌ Shard 기반, 특정 Shard 제어 어려움 |
| Backpressure 제어 | ✅ Flink/Spark에서 자유롭게 설정 가능 | ❌ 제한적, 속도 조절 어려움 |
| Exactly Once (Flink 연동) | ✅ Flink 상태+Checkpoint로 쉽게 구현 | ❌ 복잡한 사용자 로직 필요 |
| 처리 시점 제어 (Processing semantics) | ✅ At-least-once, Exactly-once 등 선택 가능 | ⚠ 기본 At-least-once만, 제어 어려움 |
| Connectors/Integrations | ✅ Confluent Connectors, Logstash 등 풍부 | ⚠ AWS 전용 커넥터 위주, 제한적 |
| Open Source 커뮤니티 | ✅ 매우 활발, 다양한 예제 존재 | ⚠ 제한적 (AWS 공식 문서 의존) |
| 로컬 개발 용이성 | ✅ 도커로 로컬 클러스터 쉽게 구성 가능 | ❌ 로컬 시뮬레이션 어렵고 비용 발생 |
- Kafka:→ startingOffsets, endingOffsets, partition, failOnDataLoss 등 세밀한 옵션 조정 가능
spark.readStream
.format("kafka")
.option("startingOffsets", "earliest")
.option("subscribe", "topic_name")
.load()
→ startingOffsets, endingOffsets, partition, failOnDataLoss 등 세밀한 옵션 조정 가능
- Kinesis:→ 선택 가능한 starting position은 제한적: TRIM_HORIZON, LATEST, AT_TIMESTAMP 정도
spark.readStream
.format("kinesis")
.option("streamName", "my-stream")
.option("startingPosition", "TRIM_HORIZON")
.load()
→ 선택 가능한 starting position은 제한적: TRIM_HORIZON, LATEST, AT_TIMESTAMP 정도
MSK의 경우 설치와 모니터링, 장애 대응 등 인프라 관점에서의 관리 포인트가 줄기 때문에 카프카를 필요로 할 때 더욱 편하게 사용할 수 있는 장점이 있습니다.
3) MSK vs Kafka Cluster(self manage)
| 항목 | MSK가 관리해주는 것(Fully managed 항목) | 설명 |
| 인프라 프로비저닝 | ✅ 자동 | EC2 인스턴스, VPC, EBS, ENI 등 인프라 자동 설정 |
| Kafka 설치 및 패치 | ✅ 자동 | Kafka 버전 설치 및 보안 패치 자동 적용 (선택 가능) |
| Zookeeper 관리 | ✅ 내부 자동 관리 | 사용자는 Zookeeper 직접 구성할 필요 없음 |
| 모니터링 | ✅ CloudWatch, AWS DMS, MSK Connect | 브로커, 파티션, lag, throughput 등 메트릭 자동 수집 |
| 백업 및 장애 복구 | ✅ 자동 재시작 / 자동 AZ failover | 브로커 다운 시 자동 대체, AZ 장애 시 failover 지원 |
| 보안 구성 | ✅ IAM 인증, TLS 암호화, VPC, Private 접속 | Public 노출 없이 안전하게 사용 가능 |
| 확장성 | ✅ 수동 스케일 (무중단) | 브로커 수 늘릴 수 있고 무중단 확장 지원 |
| 통합 서비스 | ✅ AWS 생태계와 통합 | S3, Lambda, Glue, Firehose, DMS 등과 쉽게 연동 가능 |
MSK의 한계점
| 항목 | 제한 사항 및 불리한 점 | 설명 |
| 커스터마이징 제한 | ❌ Kafka 설정 중 일부는 수정 불가 | 서버 설정, JVM 옵션, 특정 broker-level tuning 불가 |
| 버전 제약 | ❌ 최신 버전 반영 지연 가능 | Kafka 신규 기능 사용이 늦게 가능할 수 있음 |
| 자동 스케일링 없음 | ❌ 브로커 수 자동 증설 불가 | 사용자가 수동으로 늘려야 함 |
| 비용 | ❌ 직접 운영보다 다소 높음 | 관리형 서비스이므로 EC2 직접 운영 대비 비용 증가 |
| Zookeeper 직접 제어 불가 | ❌ 내부적으로만 운영 | 일부 복잡한 트러블슈팅에 제약 있음 |
| 스토리지 탄력성 한계 | ❌ 자동 스토리지 확장 없음 (수동 설정 필요) | EBS 용량 자동 증설 기능 없음 (알람 설정 후 조치 필요) |
| 커넥터/플러그인 제한 | ❌ 일부 Kafka 커넥터는 사용 불가하거나 제한적 | self-managed Kafka Connect만큼 자유도 없음 |
결론
- Kinesis Data Stream은 Kafka 브로커 속의 하나의 Topic과 비슷하다고 생각하면 되지만, 기존의 broker와는 다른 streaming + shard위주의 streaming platform이라고 생각 하면 된다.
- 비용적으로 비교했을 시, 매우 높은 처리량이 필요한 대규모 데이터의 경우 Kafka 클러스터를 사용한은 것이 비용 예측 및 확장성 측면에서 유리하며, Kinesis는 소규모 데이터에 있어서 값싸게 빠르게 사용할 수 있음.
- 비용이 클러스터 비용만 나오는지, 요청 당 비용인지 차이가 처리해야 되는 데이터 양이 많아질 수록 크게 벌어짐
- 세세한 커스터마이징을 통한 튜닝을 하기 위해서는 kafka를 사용하는 것이 유리(Spark, Flink 등 Kinesis보다도 정밀한 제어가 가능)
- 동일한 토픽에 대해 여러 컨슈머(컨슈머 그룹)에서 컨슘을 하게 되는 경우 kafka에서 처리하는 것이 비용적인 측면에서도 유리하고 훨씬 유연하게 활용 가능
- 정밀한 메시지 제어(exactly once를 통한 메시지 순서 제어)를 원할 때는 kafka, kinesis는 At-least-once로 데이터를 한 번 이상 전달하므로 중복 가능성 존재
- 자유도와 높은 처리량, 성능을 원하면 kafka, 운영 편의성 및 간편한 소규모 데이터의 경우 kinesis
728x90
댓글