Kafka

규모에 따라 뒤바뀌는 총비용 — 크로스오버 지점 이해하기

이 자료가 제시하는 월 비용 추정치(1KB 메시지, 7일 보존, Kafka는 복제 팩터 3 기준)는 절대적인 가격표가 아니라 규모에 따라 어떤 옵션이 상대적으로 유리해지는지 감을 잡기 위한 예시다. 초당 1만 건 수준에서는 자체 운영 Kafka(EC2 3대, 월 약 800달러)나 MSK(월 약 1,200달러)가 이 트래픽에 비해 과도한 컴퓨트를 놀리는 셈이 되어, Kinesis(월 약 400달러)나 Pub/Sub(월 약 500달러) 같은 완전관리형 서비스 쪽이 뚜렷하게 저렴하다 — 이 규모에서는 굳이 Kafka 운영 부담을 질 이유가 없다.

초당 10만 건 근처에서는 네 옵션의 월 비용이 서로 비슷한 수준(수천 달러대)으로 수렴하는 크로스오버 구간에 들어간다. 이 지점부터는 순수 인프라 비용보다 팀의 Kafka 운영 역량 보유 여부가 결정 요인이 된다. 초당 100만 건에 이르면 그림이 완전히 달라진다 — 자체 운영 Kafka는 인프라 비용(월 1만 달러 안팎)은 오히려 낮지만 Kafka 내부를 이해하는 엔지니어 2~3명의 인건비(월 3~5만 달러 수준)가 실질적인 비용의 대부분을 차지하게 되고, 반대로 샤드/구독 기반 완전관리형 서비스(Kinesis·Pub/Sub)는 이 규모에서 단위당 비용이 누적되어 월 수만 달러로 치솟는다. 즉 규모가 커질수록 Kafka는 '단위 경제성'에서 이기고, 완전관리형 서비스는 '총비용'보다 '운영 부담 제로'라는 다른 축의 가치를 판다.

견적에서 빠지기 쉬운 숨은 비용

스트리밍 플랫폼 자체의 단가만 비교하면 실제 청구서의 절반만 보는 것이다. 첫째, 데이터 전송 비용 — 컨슈머가 프로듀서와 다른 가용영역·리전에 있으면 크로스AZ/크로스리전 전송료가 붙는데, 이는 Kafka·Kinesis·Pub/Sub 모두에 해당하며 종종 아키텍처에서 가장 크게 숨어 있는 비용이 된다. 둘째, 컨슈머 컴퓨트 비용 — 스트리밍 플랫폼은 청구서의 절반일 뿐이고, 상태를 갖는 Kafka Streams 애플리케이션의 로컬 스토어(빠른 디스크 필요), Kinesis용 Lambda 컨슈머(호출 횟수·실행 시간 과금), Pub/Sub용 Dataflow 워커(VM 과금)처럼 컨슈머 쪽 컴퓨트도 별도로 비용이 발생한다. 셋째, 스키마 레지스트리와 모니터링 — Kafka를 쓴다면 사실상 Schema Registry(Confluent 또는 AWS Glue Schema Registry)와 별도 모니터링 스택(Prometheus/Grafana/Datadog 등)이 필요해 추가 비용이 붙는 반면, Kinesis·Pub/Sub는 각각 CloudWatch·Cloud Monitoring으로 기본 지표를 별도 비용 없이 제공한다는 차이가 있다.

완전 셀프호스팅과 완전 관리형 사이 — Amazon MSK와 Confluent Cloud

Amazon MSK는 AWS 위에서 실제 Kafka 브로커를 그대로 돌리는 관리형 서비스로, 브로커 패치·모니터링·교체를 AWS가 대신 해주는 대신 토픽·설정·컨슈머 관리 같은 Kafka 고유의 운영 책임은 여전히 사용자 몫으로 남는다. MSK가 특히 의미 있는 상황은 (1) Kafka Connect/Streams/Schema Registry 같은 생태계가 필요하지만 EC2·브로커·(과거 기준) ZooKeeper 운영은 피하고 싶을 때, (2) 온프레미스에서 AWS로 마이그레이션하면서 프로듀서/컨슈머 코드를 바꾸지 않고 API 호환성을 유지하고 싶을 때, (3) Kafka의 처리량 특성과 exactly-once가 필요하지만 팀에 깊은 Kafka 운영 노하우가 없을 때다. 반대로 그냥 S3로 이벤트를 흘려보내는 정도의 요구라면 Kinesis Firehose로 충분한데도 "나중에 Kafka 기능이 필요할지 모른다"는 이유로 MSK를 들이면, Kinesis Firehose가 처리할 수 있었던 일을 하면서 3배 비용을 치르는 결과가 될 수 있다. MSK Serverless는 브로커 프로비저닝 없이 클러스터시간+파티션시간+데이터 전송량 기준으로 과금되어 소규모·버스티한 워크로드에 유리하지만, 지속적인 처리량이 일정 수준(대략 20MB/sec)을 넘으면 provisioned MSK보다 비싸지는 경향이 있고, 브로커 단위 세부 설정도 provisioned MSK보다 제한적이다. 또한 MSK는 최신 Kafka 버전 지원이 커뮤니티 릴리스보다 몇 개월 뒤처지는 경향이 있어, 최신 기능이 꼭 필요하면 자체 호스팅이 업그레이드 시점을 더 자유롭게 통제할 수 있다는 점도 감안할 부분이다.

Confluent Cloud는 MSK보다 더 넓은 기능(완전관리형 Schema Registry, ksqlDB, 200개 이상의 사전 구축 커넥터, 멀티리전 복제를 위한 클러스터 링킹)을 AWS·GCP·Azure 어디서든 제공하는 또 다른 완전관리형 Kafka 옵션이다. 대가는 더 높은 비용과 별도의 벤더 관계를 관리해야 한다는 점이며, Kafka를 스트리밍 백본으로 진지하게 채택한 조직에는 이 프리미엄이 MSK 대비 그만한 값을 하는 경우가 많다.

흔한 실수 — 선택과 구현에서 반복되는 함정

가장 흔한 실수는 Kinesis Firehose로 충분한 "단순 S3 적재" 요구에 굳이 Kafka 클러스터와 커스텀 컨슈머를 만드는 것이다 — 실시간 처리가 필요 없는 배치성 요구에는 스트리밍 자체가 과한 선택일 수 있다. 두 번째는 Pub/Sub를 쓰면서 순서 보장을 당연하게 여기는 것이다 — ordering key를 명시적으로 설정하지 않으면 순서는 보장되지 않으며, 이를 모르고 상태 머신을 설계하면 몇 주 뒤에야 불가능한 상태 전이가 발생하는 것을 발견하게 된다.

세 번째는 "비용을 아끼려고" Kafka를 자체 호스팅하는 것이다 — 초당 1만 건 규모에서 자체 호스팅이 MSK 대비 아끼는 돈은 월 400달러 정도인데, 브로커가 새벽 2시에 디스크가 가득 차거나 리밸런싱이 컨슈머를 20분간 멈추게 하거나 Kafka 2.8에서 3.6으로 업그레이드해야 하는 순간 그 절감분은 순식간에 사라진다 — 자체 호스팅의 손익분기점은 대부분의 팀이 생각하는 것보다 높다. 네 번째는 데이터 중력을 무시하는 것이다 — 데이터 웨어하우스가 BigQuery이고 ML 학습이 Vertex AI에서 돌고 마이크로서비스가 GKE에서 도는데 "Kafka가 더 낫다"는 이유만으로 AWS에 Kafka를 두면, 스트리밍 플랫폼 자체보다 비싼 크로스클라우드 데이터 전송 문제를 만들게 된다.

다섯 번째는 피크 처리량 기준으로 과잉 프로비저닝하는 것이다 — 평균 트래픽이 피크의 20%에 불과한데 24시간 내내 피크 용량을 유지하며 비용을 치르는 대신, Pub/Sub의 서버리스 모델이나 Kinesis on-demand 모드처럼 단가는 다소 높아도 실사용량 기준으로 과금되는 옵션이 총비용에서 더 유리할 수 있다. 여섯 번째는 프로덕션 이전에 장애 모드를 테스트하지 않는 것이다 — Kafka는 브로커 장애와 컨슈머 리밸런싱으로, Kinesis는 샤드 한도 초과 시 스로틀링으로, Pub/Sub는 ack 데드라인 만료로 인한 중복 전달로 각각 다르게 실패하므로, 컨슈머 크래시·브로커 다운·처리량 한계 초과 같은 시나리오를 프로덕션 이전에 반드시 검증해야 한다. 일곱 번째는 Kinesis Data Streams(스트리밍 플랫폼, Kafka 토픽에 대응)와 Kinesis Firehose(전달 서비스, S3로 쓰는 Kafka 컨슈머에 대응)를 혼동하는 것이다 — 서로 다른 문제를 푸는 서비스인데도 Firehose로 충분한 일에 Data Streams용 커스텀 컨슈머를 만들거나, 반대로 실시간 처리가 필요한데 Firehose로 억지로 해결하려는 경우가 잦다. 여덟 번째는 스키마 진화를 미리 계획하지 않는 것이다 — 이벤트 스키마는 반드시 바뀌므로, Kafka의 Schema Registry 같은 호환성 강제 장치 없이 시작하면 새 메시지 포맷에 컨슈머가 크래시하거나 조용히 잘못된 결과를 내는 사고로 이어진다. 마지막으로, 스트리밍 플랫폼 선택을 되돌릴 수 없는 결정처럼 취급하는 것도 실수다 — 프로듀서/컨슈머를 얇은 추상화 계층 뒤에 감춰 두면 플랫폼 이전은 몇 달이 아니라 몇 주 안에 끝나는 작업인 경우가 많으며, 분석 마비의 비용이 나중에 이전하는 비용보다 더 클 수 있다.