Kafka

기술 하나 대 제품 둘 — 근본적으로 다른 카테고리의 비교

"Kafka vs Kinesis vs Pub/Sub"이라는 프레이밍 자체가 다소 오해의 소지가 있다. Kafka는 어디서든(온프레미스, AWS, GCP, Azure 어디든) 직접 실행할 수 있는 오픈소스 분산 스트리밍 플랫폼(기술)인 반면, Kinesis와 Pub/Sub는 각각 AWS와 GCP에 종속된 프로프라이어터리 완전관리형 서비스(제품)다. 즉 이 비교는 기술 하나와 제품 두 개를 나란히 놓고 보는 것이며, 이 구분은 이식성·벤더 종속성·장기 아키텍처 결정을 생각할 때 특히 중요해진다 — Kafka 클라이언트 라이브러리는 클라우드와 무관하게 동일하게 동작해 멀티/하이브리드 클라우드에서도 이식성을 주는 반면, Kinesis는 AWS에, Pub/Sub는 GCP에 각각 완전히 종속된다.

Kafka의 핵심 강점은 처리량이다 — 잘 구성된 클러스터는 초당 수백만 건의 이벤트를 처리할 수 있고, LinkedIn은 자체적으로 하루 7조 건 이상의 메시지를 Kafka로 처리한다고 공개한 바 있다(이는 LinkedIn 자체 규모의 사례이지 일반적인 벤치마크 기준값은 아니다). Kafka Connect(통합), Kafka Streams(스트림 처리), Schema Registry(데이터 계약), ksqlDB(SQL 기반 처리)로 이어지는 생태계의 폭도 다른 두 제품이 따라오지 못하는 지점이다. 그 대가는 운영 복잡도다 — 브로커·ISR·파티션 수·리밸런싱·디스크 용량을 계속 관리해야 하며, 브로커 3대짜리 소규모 클러스터도 이를 이해하는 담당자가 필요하고 20대 규모라면 전담 팀이 필요해진다.

병렬성의 단위 — 파티션, 샤드, 그리고 '단위가 없는' 구독

Kinesis Data Streams는 샤드를 병렬성의 단위로 쓴다 — 각 샤드는 쓰기 1MB/sec(또는 초당 1,000레코드), 읽기 2MB/sec라는 하드 리밋을 가지며, 샤드를 provisioned 모드로 미리 프로비저닝하거나 on-demand 모드로 자동 확장시킬 수 있다(다만 on-demand는 안정적인 트래픽 기준으로 provisioned보다 단가가 대략 25% 더 높다). Kafka의 파티션과 개념적으로 비슷하지만, 샤드 수 확장(resharding)은 시간이 걸리고 그동안 처리량에 일시적 영향을 준다는 점, 그리고 계정·리전당 기본 샤드 수 한도가 있어(정확한 한도는 리전·계정 설정에 따라 다르고 요청으로 상향 조정 가능하다) 대규모에서는 수백 개의 샤드를 관리해야 한다는 점이 Kafka 파티션 운영과 유사한 부담을 만든다.

Google Pub/Sub는 아예 다른 접근을 취한다 — 파티션도 샤드도 없고, 사용자가 프로비저닝해야 할 용량 단위 자체가 없다. 토픽을 만들고 구독(subscription)을 만들어 발행하면 나머지 확장은 전적으로 Google이 내부적으로 처리한다. 이 덕분에 트래픽이 평소의 10배로 급증해도 아무것도 만지지 않고 흡수할 수 있다는 것이 Pub/Sub의 핵심 차별점이다. 다만 이 완전한 추상화는 대가 없이 오지 않는다 — 순서 보장이 기본이 아니라 옵션(ordering key)이고, 컨슈머가 정확히 몇 개의 병렬 처리 단위를 갖는지 개발자가 직접 통제할 수 없다.

숫자로 보는 비교 — 처리량·지연·보존·순서·메시지 크기·컨슈머 확장성

처리량 측면에서 Kafka는 파티션 하나당(하드웨어·설정에 따라) 대략 10~50MB/sec 수준을 내고 브로커 하나의 이론적 상한은 대형 배치 기준 약 600MB/sec 정도로 언급되지만, 이는 하드웨어와 튜닝에 따라 크게 달라지는 근사치로 봐야 한다. Kinesis는 샤드당 쓰기 1MB/sec라는 하드 리밋이 있어 100개 샤드로 100MB/sec를 낸다. Pub/Sub는 토픽당 고정 상한이 없고 프로젝트당 기본 1GB/sec(요청 시 상향 가능)를 제공한다는 점이 차별점이다.

지연(p99) 측면에서는 잘 튜닝된 Kafka가 5~15ms(acks=1·linger.ms=0의 공격적 설정이면 2~5ms, acks=all+RF=3이면 10~20ms), Kinesis는 표준 폴링 기준 약 200ms(Enhanced Fan-Out의 HTTP/2 푸시를 쓰면 약 70ms), Pub/Sub는 스트리밍 풀 기준 50~100ms(푸시 전달은 100~200ms) 수준으로 언급된다 — 다만 트레이딩 시스템이나 밀리초 단위 실시간 사기 탐지처럼 정말 지연에 민감한 경우가 아니라면 5ms와 200ms의 차이는 최종 사용자 입장에서 체감되지 않는 경우가 많다는 점도 함께 고려해야 한다.

보존 기간은 Kafka가 (계층형 스토리지를 쓰면) 사실상 무제한, Kinesis가 기본 24시간(최대 365일까지 확장 가능, 24시간 초과분은 별도 과금), Pub/Sub가 기본 7일(최대 31일)이다. 순서 보장은 Kafka가 파티션 내부에서 항상 보장(아키텍처의 기본 동작), Kinesis가 샤드 내부에서 시퀀스 번호 기준으로 보장(Kafka 파티션과 기능적으로 유사), Pub/Sub가 명시적으로 설정한 ordering key 내부에서만 보장(설정하지 않으면 순서가 보장되지 않음)된다는 차이가 있다. 메시지 최대 크기는 Kafka 기본 1MB(설정으로 10MB+까지 확장 가능하나 커지면 처리량에 부담을 준다), Kinesis 1MB(레코드당 하드 리밋, 설정 불가), Pub/Sub 10MB(셋 중 가장 여유롭다)다. 컨슈머 확장성은 Kafka·Kinesis 모두 파티션/샤드 수에 의해 상한이 걸리는 반면, Pub/Sub는 구독자 수에 내재적 상한이 없어 셋 중 가장 탄력적인 컨슈머 모델을 제공한다.

정확히 한 번 처리 — '정정': Pub/Sub도 이제 네이티브 exactly-once delivery를 지원한다

Kafka는 버전 0.11부터 멱등성 프로듀서 + 트랜잭션 API로 exactly-once semantics(EOS)를 지원하며, Kafka Streams 내부에서는 end-to-end로 완전히 동작한다(다만 외부 싱크로 나갈 때는 여전히 싱크 쪽의 멱등한 쓰기가 필요하다). 이 EOS가 처리량에 실질적인 오버헤드를 더하는 것은 사실이지만, "트랜잭션을 켜면 at-least-once 대비 처리량이 10~20% 낮아진다"는 식의 특정 수치는 배치 크기·복제 팩터·트랜잭션 커밋 주기 같은 설정에 따라 크게 달라지는 값이라 특정 퍼센트를 암기하기보다 "실질적이지만 워크로드 의존적인 오버헤드가 있다" 정도로 이해하는 것이 정확하다. Kinesis는 at-least-once만 제공하며 중복 제거는 전적으로 애플리케이션(KCL 체크포인팅은 도와주지만 중복 자체를 막지는 않는다) 책임이다.

이 자료는 Pub/Sub에 대해 "Dataflow 파이프라인 안에서는 exactly-once, 표준 pull/push 구독자는 at-least-once"라고 설명하는데 — 정정: 이는 Google Cloud Pub/Sub가 Dataflow 없이도 구독(subscription) 단위로 켤 수 있는 네이티브 exactly-once delivery 기능을 정식 출시(GA)하기 이전 시점의 설명이다. 현재는 구독 생성 시 exactly-once delivery 옵션을 활성화하면, 애플리케이션이 올바르게 ack를 처리하는 한 Dataflow를 쓰지 않는 일반 pull 구독자에게도 중복 없는 전달을 보장받을 수 있다(다만 활성화 시 처리량 상한이 다소 낮아지고 지연이 늘어나는 트레이드오프가 있다). 따라서 "Pub/Sub의 exactly-once는 Dataflow 전용"이라는 서술은 더 이상 정확하지 않다.