728x90
이번 포스트에는 카프카 혹은 키네시스에 붙이는 consumer들을 장단점을 비교해보고 use case를 정리해보도록 하겠습니다.
각 consumer의 장단점 위주로 정리하고, 자세한 내용은 다른 포스트에서 자세히 다루겠습니다.
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. 각 consumer들 비교
1) 주요 consumer 특징 정리
Flink
| 항목 | 설명 |
| 실시간 처리 | 밀리초 단위의 record-by-record 처리 (진정한 스트리밍) |
| Exactly-once 보장 | 상태(state)를 유지하며 fault-tolerant하게 처리 |
| Event time 처리 | Watermark, Window를 활용한 정교한 시간 기반 처리 |
| Stateful 처리 | 사용자 정의 상태 유지 가능 (ex. 누적 합, 평균, 세션 정보 등) |
| CEP 기능 | 복잡한 이벤트 패턴 탐지 가능 (ex. 이상 탐지, 연속적인 사용자 행동 감지 등) |
| SQL 지원 | Flink SQL 및 Table API를 통한 선언형 스트리밍 데이터 처리 |
| Source/Sink 연동 | Kafka, Kinesis, S3, Elasticsearch, JDBC 등과 유연하게 연동 가능 |
| Best Use Case | 실시간 사기 탐지, 사용자 행동 분석, 상태 기반 집계, 실시간 알림 시스템 등 |
| 장점 | - Sub-second latency - 강력한 상태 처리 및 타임 제어 - 다양한 connector - Exactly-once semantics |
| 단점 | - 복잡한 클러스터 운영 필요 - 높은 학습 곡선 - 자원 소모 큼 (state, checkpoint, backpressure 등) |
Spark Streaming
| 항목 | 설명 |
| 처리 방식 | Micro-batch 기반 스트리밍 처리 (수 초 단위의 소규모 배치) |
| Exactly-once 보장 | 지원 (sink에 따라 달라질 수 있음) |
| Event time 처리 | 지원 (watermark, window 등 사용 가능) |
| Stateful 처리 | 지원 (mapGroupsWithState, flatMapGroupsWithState 등으로 상태 유지) |
| SQL 지원 | Structured Streaming SQL 사용 가능 |
| Source/Sink 연동 | Kafka, Kinesis, File, JDBC, S3 등 다양한 source/sink 연동 가능 |
| Best Use Case | ETL/ELT 처리, 스트리밍 + 배치 융합, 실시간 데이터 파이프라인 구축 |
| 장점 | - 배치/스트리밍 통합된 API - 대규모 처리에 적합 (Spark의 분산 처리 엔진) - 다양한 커넥터와 유연성 |
| 단점 | - True streaming 아님 (지연 발생) - 상태 관리 복잡 - 정확한 event time 제어는 Flink보다 제한적 |
Kinesis Firehose
| 항목 | 설명 |
| 처리 방식 | Near real-time buffer-based 처리 (60초 또는 1MB 기준으로 전송) |
| Exactly-once 보장 | 기본적으로 없음 (at-least-once) |
| Event time 처리 | 불가능 (데이터 전송만 처리, 시간 기준 분석 X) |
| Stateful 처리 | 불가능 (간단한 transformation만 가능 - Lambda 사용 시 제한적으로 가공 가능) |
| SQL 지원 | 없음 |
| Source/Sink 연동 | Kinesis Streams, Direct PUT → S3, Redshift, OpenSearch, Splunk 등으로 전송 가능 |
| Best Use Case | 간단한 실시간 로그 수집 → 저장 (예: CloudTrail, VPC Flow Logs 등 수집 → S3, Elasticsearch 저장) |
| 장점 | - 완전 관리형, 서버리스 - 자동 배포, 스케일링 - 운영 부담 거의 없음 - 간단한 사용법 |
| 단점 | - 낮은 유연성 및 기능 제한 - 복잡한 가공 불가 - 정확한 처리 보장 부족 - event time 및 상태 기반 처리 불가능 |
2) 비교표
| Consumer | 비용 | 가공 처리력 | 실시간성 | 운영 복잡도 | 확장성 | 대표 사용 사례 |
| Kafka Streams | 낮음 (내장 실행) | 중간 (상태 기반 가공 가능) | High | 낮음 | 중간 | Kafka 내부 실시간 처리, 간단한 join/aggregation |
| Apache Flink | 중간~높음 (클러스터 필요) | 매우 높음 (Stateful, CEP) | Very High | 높음 | 매우 높음 | CEP, Event time 분석, 실시간 복잡 로직 |
| Spark Streaming | 중간 (EMR, 클러스터) | 높음 (ML 포함 가능) | 중간~높음 | 중간 | 높음 | 실시간 + 배치 통합, 통계 + ML 연계 |
| Logstash | 낮음~중간 | 낮음 (단순 필터링/포맷) | Low | 매우 낮음 | 낮음 | 로그 수집/가공 후 전송 (ELK) |
| Kinesis Firehose | 낮음 (완전관리형) | 없음 (간단 포맷 정도) | Low | 매우 낮음 | 높음 | 실시간 저장/적재 (S3/Redshift) |
결론
- 비용을 신경 쓰지 않고 성능과 효율만을 위한 consumer를 고르라면 flink가 압도적으로 좋음
- Exactly-once semantics 지원 (복구, checkpoint, 재처리 포함)
- Event-time 처리: 실시간 스트리밍에서 가장 정밀한 시간 기준 분석 가능
- 복잡 로직: CEP, 다양한 조건 처리, 상태 기반 이벤트, 조인 가능
- 확장성: 대규모 클러스터 분산처리 (Kafka/Kinesis 모두 연동 가능)
- 배포 유연성: Flink on K8s, EMR, Yarn 등 다양한 형태로 운영 가능
- 실시간으로 처리가 필요 없으며, Spark를 사용하고 있는 환경이라면 Spark Streaming으로 통합하는게 관리측면에서 좋음
- 비교적 적은 데이터나, 간편한 설정 및 복잡한 로직으로 가공을 할 것이 아니라면, Kafka Streams 혹은 Kinesis Firehose + lambda 혹은 Logstash가 괜찮은 선택지
- 이미 self hosting kafka를 사용하고 있으면 kafka streams나 logstash
- kinesis data streams를 사용하는 경우 kinesis firehose로 간단하게 처리
- msk를 사용한다면, kinesis firehose도 사용이 가능하긴 함
728x90
댓글