S3 위에서 직접 동작하는 Kafka 프로토콜 호환 데이터 스트리밍 플랫폼 WarpStream이 Kafka의 클라우드 비용과 운영 부담 문제를 어떻게 해결하는지 설명합니다.
URL: https://www.warpstream.com/blog/kafka-is-dead-long-live-kafka
WarpStream은 S3 위에 직접 구축된 Apache Kafka® 프로토콜 호환 데이터 스트리밍 플랫폼입니다. 단일의 상태 비저장(stateless) Go 바이너리로 제공되므로 관리해야 할 로컬 디스크가 없고, 리밸런싱해야 할 브로커도 없으며, 운영해야 할 ZooKeeper도 없습니다. WarpStream은 데이터를 인터-AZ 네트워킹으로 주고받는 대신 S3로부터/로 직접 스트리밍하기 때문에 클라우드에서 Kafka보다 5~10배 저렴합니다. 규모가 커질수록 Kafka 배포 비용의 80% 이상을 차지할 수 있는 인터 존(Zone) 네트워킹 비용을 피할 수 있습니다.
그냥 직접 만져보고 싶다면, 30초 안에 데모를 시도해 볼 수 있습니다.
bash$ curl https://console.warpstream.com/install.sh | bash $ warpstream demo
그 외에는 계속 읽어보세요!
이 글 제목을 보고 아마 강한 반응이 있었을 겁니다. 우리의 경험상 Kafka는 데이터 영역에서 가장 호불호가 갈리는 기술 중 하나입니다. 어떤 사람은 싫어하고, 어떤 사람은 맹신하지만, 거의 모든 테크 기업이 사용합니다.
Apache Kafka®는 2011년에 처음 오픈소스로 공개되었고, 빠르게 스트리밍 아키텍처를 구축하기 위한 기본 인프라가 되었습니다. Jay Kreps의 이제는 잘 알려진 블로그 글 The Log는 Kafka가 제공하는 분산 로그(distributed log) 추상화가 왜 그렇게 강력한지 설명해 주기 때문에, 여전히 제가 가장 좋아하는 글 중 하나입니다.
하지만 지금은 2011년이 아닙니다. 현대 소프트웨어를 만드는 방식은 많이 변했고, 특히 클라우드 환경으로의 큰 전환이 있었습니다. 그럼에도 Kafka는 거의 그대로 남아 있습니다. 많은 조직이 Kafka를 클라우드로 “리프트 앤 시프트(lift and shift)”하는 데는 성공했지만, 솔직히 결과에 만족하는 곳은 거의 없습니다. Kafka는 비싸고, 까다롭고, 대다수 조직이 운영하기 어렵습니다.
문제는 Kafka _자체_가 아닙니다. Kafka는 2011년의 LinkedIn 데이터센터라는 환경에 잘 맞는 훌륭한 소프트웨어였습니다. 하지만 현대 워크로드에는 유난히 맞지 않는 점이 두 가지 있습니다.
이 글의 나머지 부분에서는 Kafka를 집중적으로 비판하겠지만, 우리가 Kafka에 대해 말하는 내용은 로컬 디스크에 데이터를 저장하는(아주 잠깐이라도) 유사한 시스템이라면, 어떤 언어로 구현되었든 동일하게 적용된다는 점을 기억해 주세요.
아래 다이어그램은 일반적인 3개 가용 영역(availability zone) Kafka 클러스터를 보여줍니다.
.svg)
생산(Produce)되는 모든 GiB의 데이터는 2/3의 경우에 크로스 존으로 기록되어야 합니다(1). 그리고 내구성과 가용성을 위해 파티션 리더가 다른 두 존의 팔로워로 다시 복제합니다. GiB의 데이터가 존 간 이동될 때마다 $0.02의 비용이 듭니다(2). 소스 존에서의 egress $0.01과 목적지 존에서의 ingress $0.01입니다.
최선의 경우 시나리오(3)에서도 Kafka 클러스터를 통해 스트리밍되는 데이터 1GiB당 비용은
입니다.
반면 S3에 1GiB를 한 달 저장하는 비용은 $0.021(4)뿐입니다. 즉, Kafka를 통해 생산자에서 소비자로 데이터를 복사하는 비용과 같은 비용으로, 그 데이터를 S3에 두 달이 넘도록 저장할 수 있습니다. 실제로 처리량이 큰 Kafka 클러스터에서는 하드웨어 비용은 미미하며, 워크로드 비용의 70~90%가 인터존 대역폭 비용일 뿐입니다. Confluent도 이 문제를 잘 정리한 글이 있습니다.
이 인터-AZ 대역폭 문제는 Kafka의 동작 방식에 내재된, 아주 근본적인 문제라는 점을 강조해야 합니다. Kafka는 LinkedIn의 데이터센터에서 동작하도록 설계되었고, 네트워크 엔지니어가 애플리케이션 개발자에게 데이터 이동 비용을 청구하지 않는 환경이었습니다. 하지만 오늘날 대부분의 Kafka 사용자는 퍼블릭 클라우드에서 운영합니다. 클라우드는 완전히 다른 제약과 비용 모델을 가진 환경입니다. 안타깝게도, 연간 수천만~수억 달러 수준의 클라우드 지출을 감당할 수 있는 조직이 아니라면, 이 문제의 ‘물리’를 피할 방법이 없습니다.
처리량만의 문제가 아닙니다. 처리량이 낮더라도 보존(retention)이 길면 저장소 요구량이 커질 수 있습니다. 이 경우 Kafka는 비싼 로컬 SSD에 데이터를 3중 복제하는 접근을 취하기 때문에, 디스크 활용률 100%라는 최선의 시나리오를 가정하더라도 S3 같은 오브젝트 스토리지를 쓰는 것보다 GiB당 비용이 대략 10~20배(5) 더 듭니다.
대부분의 개발자는 실제로 해결하고 싶은 문제가 있어서 Apache Kafka®를 처음 접합니다. 하지만 문제를 풀기 전에 먼저 아래를 배워야 합니다.
Kafka의 “데이터 플레인”(브로커)과 합의(consensus) 기반의 “컨트롤 플레인”(컨트롤러, ZooKeeper 등)은 모두 로컬 SSD 위에서 직접 동작하며, 전문 지식과 주의 깊은 관리가 필요합니다. 실제로 자체 호스팅 Kafka 클러스터는 노드 교체나 클러스터 스케일링 같은 기본 작업조차 안전하고 신뢰성 있게 수행하려면, 전담 전문가 팀과 상당한 커스텀 툴링이 필요합니다. 예를 들어 Apache Kafka의 내장 파티션 재할당 도구는 (언젠가 반드시 겪게 되는) 하드웨어 장애로 인해 브로커를 폐기(decommission)해야 할 때조차 계획을 자동 생성하지 못합니다.
파티션 재할당 도구는 아직 브로커 폐기를 위한 재할당 계획을 자동으로 생성할 수 없습니다. 따라서 관리자는 폐기할 브로커에 호스팅된 모든 파티션의 모든 레플리카를 나머지 브로커로 옮기는 재할당 계획을 직접 만들어야 합니다. 재할당은 폐기 브로커에 있던 레플리카가 다른 한 브로커로만 몰리지 않도록 보장해야 하므로, 이는 비교적 번거로울 수 있습니다.
많은 경우 AWS MSK 같은 호스팅 제공업체로 클러스터 관리를 넘겨도 운영 부담이 해결되지 않습니다. 예를 들어, (아주 일상적인 작업인) 클러스터 리밸런싱 방법을 설명하는 MSK 문서는 Apache Kafka 문서로 연결될 뿐인데, 거기에는 어떤 파티션을 어떤 브로커로 옮길지 JSON을 손으로 편집하라는 내용과 함께 아래처럼 ‘도움이 되는’ 코멘트가 포함돼 있습니다.
파티션 재할당 도구는 Kafka 클러스터의 데이터 분포를 자동으로 분석하여 균등한 부하 분포를 얻도록 파티션을 이동시키는 기능이 없습니다. 따라서 관리자는 어떤 토픽이나 파티션을 이동해야 할지 직접 판단해야 합니다.
cruise-control 같은 오픈소스 솔루션이 이 부담을 줄여주기도 하지만, 또 다른 개념을 학습해야 하고, 서비스도 배포 및 모니터링해야 하며, 새로운 날카로운 모서리(sharp edges)를 마주하게 됩니다. Cruise Control 자체도 Apache Kafka와 ZooKeeper에 의존하는 JVM 애플리케이션입니다. 결코 가벼운 솔루션이 아닙니다.
불행히도 많은 경우 개발자는 비즈니스 문제를 해결하려고 시작했다가, 결국 Kafka SRE가 되어버립니다.
Apache Kafka®를 사용하는 비용(달러와 엔지니어링 시간 모두)이 높다 보니, 오늘날 기업들은 사기 탐지나 CDC 같은 가장 고부가가치 유스케이스에만 Kafka를 쓸 수 있습니다. 그 외 용도에는 진입 비용이 너무 큽니다.
우리가 Datadog에 있을 때, S3 위에서 직접 동작하는 관측(Observability) 데이터용 컬럼너 DB인 Husky를 만들었습니다. 완성하고 나니 (대부분) 상태 비저장이고 자동 스케일링되는 데이터 레이크가 되었고, 비용 효율적이며, 디스크 공간이 부족해질 일이 없고, 운영도 매우 쉬웠습니다. 거의 하룻밤 사이에 기존의 Kafka 클러스터가 비교하면 _고대 유물_처럼 보이기 시작했습니다.
Datadog에서 Kafka의 대역폭은 초당 수십 GiB 단위였고, 브로커 스토리지는 PiB 단위의 NVMe(6)였습니다. 오픈소스 Kafka, 커스텀 툴링, 베어 VM으로 이런 인프라를 유지하는 것은 결코 쉬운 일이 아닙니다. 다행히 Datadog의 담당 엔지니어링 팀은 매우 유능해서 이를 해냈지만, 수년간 투자했음에도 자동화는 S3 같은 시스템에 투입된 수백만 시간의 엔지니어링 노력—즉 극도로 견고하고, 확장 가능하며, 비용 효율적이고, 탄력적인 시스템—과는 경쟁이 되지 않았습니다.
일반적으로 클라우드 환경에서의 대규모 스토리지 워크로드는 오브젝트 스토리지의 경제성, 신뢰성, 확장성, 탄력성과 경쟁할 가능성이 없습니다. 이것이 Snowflake나 Databricks 같은 “빅데이터” 기술이 애초에 경쟁하려 하지 않는 이유입니다. 대신, 범용 오브젝트 스토리지를 중심으로 시스템을 처음부터 설계함으로써 클라우드 경제성에 기대어(lean into) 갑니다.
Uber, Datadog 등 많은 회사가 Kafka의 온갖 결함에도 불구하고 Kafka를 잘 활용해 왔습니다. 그러나 기존 Kafka 구현이 진입 장벽으로 남아 있는 한, 너무 많은 흥미로운 문제들이 끝내 해결되지 못할 것입니다. 우리가 이 분야를 중요하게 생각하는 이유이며, S3만큼 접근 가능한 데이터 스트리밍 인프라를 만들기 위해 무언가를 구축하려고 한 이유입니다.
S3 위에 Kafka 같은 시스템을 직접 만들 수 있다면, Kafka의 두 가지 주요 문제를 한 번에 해결할 수 있습니다. 비용은 대폭 낮아지고, 전통적인 Kafka 운영상의 골칫거리 대부분은 하룻밤 사이에 사라질 것입니다. 주요 클라우드 제공업체는 VM과 오브젝트 스토리지 사이의 네트워킹 비용을 청구하지 않으며, AWS는 S3가 안정적으로 동작하고 무한히 확장되도록 보장하는 일을 전담하는 엔지니어를 문자 그대로 수백 명 두고 있으니까요.
물론 말처럼 쉽지는 않습니다. 아직 아무도 하지 못한 데는 이유가 있습니다. S3 같은 고지연(high latency) 스토리지 매체 위에서, 어떤 로컬 디스크도 도입하지 않으면서, Kafka 프로토콜의 완전한 시맨틱을 제공하면서, 저지연 스트리밍 인프라를 만드는 방법을 찾아내는 것은 매우 까다로운 문제입니다.
그래서 우리는 스스로에게 물었습니다. “오늘날의 클라우드 환경에서, 오브젝트 스토리지 위에 직접 올라가고, 관리할 로컬 디스크가 없으면서도, 기존 Kafka 프로토콜을 지원해야 한다면, Kafka는 처음부터 다시 설계했을 때 어떤 모습일까?”
WarpStream은 그 질문에 대한 우리의 답입니다.
WarpStream은 AWS S3, GCP GCS, Azure Blob Storage 등 어떤 범용 오브젝트 스토어 위에서도 직접 동작하는 Apache Kafka® 프로토콜 호환 데이터 스트리밍 플랫폼입니다. 인터-AZ 대역폭 비용이 0이며, 관리할 로컬 디스크가 없고, VPC 내부에서 완전히 실행할 수 있습니다.
한 번에 받아들이기엔 정보가 많으니, Kafka 아키텍처와 비교하면서 풀어보겠습니다.
Kafka 브로커 대신 WarpStream에는 “에이전트(Agent)”가 있습니다. 에이전트는 Kafka 프로토콜을 말하는 상태 비저장 Go 바이너리(JVM 아님!)입니다. 전통적인 Kafka 브로커와 달리, 어떤 WarpStream 에이전트든 어떤 토픽에 대해서도 “리더”가 될 수 있고, 어떤 컨슈머 그룹에 대해서도 오프셋을 커밋할 수 있으며, 클러스터의 코디네이터 역할도 할 수 있습니다. 특별한 에이전트는 없으므로, CPU 사용량이나 네트워크 대역폭에 따라 오토스케일링하는 것이 매우 쉽습니다.
Apache Kafka는 Apache ZooKeeper(또는 KRaft)와 로컬 SSD, 복제를 가진 상태 저장 브로커를 요구하는데, 우리는 어떻게 이를 가능하게 했을까요?
S3 같은 오브젝트 스토리지로 모든 스토리지를 오프로딩하면, 부하 변화에 따라 WarpStream 에이전트 수를 데이터 리밸런싱 없이 0으로 손쉽게 늘리거나 줄일 수 있습니다. 또한 어떤 요청이든 즉시 다른 에이전트에서 재시도할 수 있어 장애 복구가 더 빨라집니다. 그리고 파티션별 데이터량 불균형 때문에 특정 Kafka 브로커에 부하가 몰리는 핫스팟 문제도 대부분 제거됩니다. 즉, 파티션을 수동으로 리밸런싱하는 일과 Cruise Control 같은 복잡한 솔루션을 배울 필요가 크게 줄어듭니다.
WarpStream 설계의 또 다른 축은, 현대 데이터 레이크처럼 데이터와 메타데이터를 분리하는 것입니다. 우리는 각 WarpStream “가상 클러스터(Virtual Cluster)”의 모든 메타데이터를, 이 문제를 가장 높은 성능과 비용 효율로 풀기 위해 처음부터 작성한 커스텀 메타데이터 DB에 저장합니다. 사실 우리는 메타데이터 스토어의 효율성에 자신이 있기 때문에, WarpStream 가상 클러스터를 여러분을 위해 무료로 호스팅해 드립니다.
WarpStream의 아키텍처는 문서에서 더 읽을 수 있습니다. 요약하자면, WarpStream은 데이터 복제, 내구성, 가용성의 어려운 문제를 오브젝트 스토리지 버킷에 맡겨서 여러분이 신경 쓸 필요가 없게 만들지만, 여러분의 데이터는 여러분의 클라우드 계정 안에 그대로 남습니다. WarpStream에서 여러분의 클라우드 계정 밖으로 나가는 유일한 데이터는 합의에 필요한 워크로드 _메타데이터_뿐입니다. 예를 들어 파티션 내 배치의 순서 같은 정보 말이죠.
오늘날 인프라에 대규모 데이터 스트리밍 파이프라인을 도입하려는 실무자들은 선택지가 많지 않습니다. Kafka 운영만 전담하는 엔지니어 팀을 따로 만들면서 많은 비용을 쓰거나, 호스팅 솔루션을 벤더에 맡기고 더 많은 비용을 내야 합니다. 그 결과 많은 스트리밍 유스케이스는 경제적으로 불가능해집니다.
우리는 WarpStream이 클라우드를 약점이 아니라 강점으로 활용하는 더 나은 선택지가 될 수 있고, 데이터 스트리밍 세계에서 완전히 새로운 가능성을 열 수 있다고 생각합니다.
말만 믿으라는 건 아닙니다. 우리는 증거도 준비했습니다. 아래 이미지는 (훌륭한 vantage.sh로 측정한) 우리 클라우드 계정 전체의 인터존 네트워킹 비용을 보여줍니다. 여기에는 테스트 환경에서 실행 중인 연속 스트리밍 워크로드도 포함되어 있습니다. 이 워크로드는 140MiB/s로 데이터를 지속적으로 생산하고, 3개의 전용 컨슈머가 이를 소비하여 총 560MiB/s의 연속 데이터 전송을 발생시킵니다.
보시다시피 우리는 인터존 네트워킹 비용이 하루 평균 < $15입니다. 반면 동일한 워크로드를 Kafka 클러스터로 실행하면
의 인터존 네트워킹 비용이 오직 네트워킹 비용만으로 발생합니다.
그리고 이런 인터존 네트워킹 비용을 하드웨어나 S3 API 비용으로 대체한 것도 아닙니다. 동일 워크로드에서 S3 API 오퍼레이션 비용은 하루 < $40입니다.
또한 에이전트 하드웨어/VM은 27 vCPU만 필요합니다.
총소유비용(TCO) 관점에서 WarpStream은 대부분의 Kafka 워크로드 비용을 5~10배 줄일 수 있습니다. 예를 들어, 지속 1GiB/s Kafka 워크로드를 운영하는 비용과 WarpStream으로 동등한 워크로드를 운영하는 비용을 비교하면 다음과 같습니다.
자체 호스팅 Kafka 하드웨어 비용은 각주 7, 자체 호스팅 Kafka 네트워크 비용은 각주 8을 참고하세요. 이 표는 컨슈머의 인터존 네트워킹 비용을 줄이기 위해 Kafka 클러스터가 follower fetch 기능을 사용하도록 올바르게 구성된 최선의 시나리오를 가정합니다. 그렇지 않다면 Kafka 비용은 훨씬 더 높아집니다. 또한 자체 호스팅 Kafka 구성에서의 엔지니어링 급여 비용은 제외되어 있습니다.
위 표는 대용량 Kafka 워크로드에서 하드웨어 비용이 미미하다는 점을 명확히 보여줍니다. 워크로드 비용은 인터존 네트워킹 수수료가 지배하며, WarpStream은 그 네트워킹 수수료를 완전히 제거합니다.
물론 모든 것이 장밋빛은 아닙니다. 엔지니어링은 트레이드오프의 예술이며, WarpStream에서는 큰 트레이드오프 하나를 했습니다. 바로 지연시간(latency) 입니다. 현재 구현에서는 Produce 요청의 P99가 약 400ms인데, S3에 내구적으로 저장되고 클라우드 컨트롤 플레인에 커밋되기 전에는 데이터를 절대 ACK하지 않기 때문입니다. 또한 현재 프로듀서에서 컨슈머까지의 종단 간(end-to-end) 데이터 P99 지연은 약 1초입니다.
여러분의 워크로드가 프로듀서-컨슈머 지연 P99 약 1초를 허용할 수 있다면, WarpStream은 GiB당 총 데이터 스트리밍 비용을 5~10배 줄여주며, 운영 오버헤드는 거의 0에 가깝습니다. 또한 우리는 독자적인 인터페이스를 쓰지 않습니다. 그냥 Kafka입니다. 즉 벤더 락인도 없습니다. 마지막으로 WarpStream은 오브젝트 스토어 구현이 있는 어떤 환경에서도 실행되므로, AWS의 S3, GCP의 GCS, Azure의 Blob Storage 등 여러분이 있는 곳에서 그대로 만날 수 있습니다.
여기까지 읽으셨다면, WarpStream이 주로 Kafka의 두 가지 주요 문제—클라우드 경제성과 운영 오버헤드—를 해결한다는 점을 눈치채셨을 겁니다. 우리는 Kafka에 세 번째 주요 문제가 있다고 생각합니다. 바로 개발자 UX입니다. 우리 관점에서 파티션은 비사소한(stream processing) 애플리케이션을 작성하기에는 너무 저수준의 추상화입니다. 그리고 WarpStream의 아키텍처는 개발자가 전통적인 애플리케이션을 작성하던 방식에 더 가까운, 새로운 방식으로 스트림 처리 애플리케이션을 작성할 수 있도록 도와줄 수 있는 독특한 위치에 우리를 놓아줍니다.
이에 대해서는 향후 블로그 글에서 더 이야기하겠습니다. 하지만 우리가 먼저 하고 싶었던 일은 개발자들이 있는 곳으로 찾아가, 이미 익숙한 도구의 개선된 버전을 제공하는 것이었습니다.
그냥 직접 만져보고 싶다면, 30초 안에 데모를 시도해 볼 수 있습니다.
bash$ curl https://console.warpstream.com/install.sh | bash $ warpstream demo
