‘카프카’가 죽었지만, ‘카프카’는 영원히 살아있다

 (warpstream.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • Kafka는 데이터센터 시대의 분산 로그로 성공했지만, 퍼블릭 클라우드에서는 AZ 간 네트워크 비용과 로컬 디스크 운영 부담이 커짐
  • WarpStream은 Apache Kafka 프로토콜과 호환되는 디스크리스 스트리밍 플랫폼으로, S3 같은 객체 스토리지 위에서 로컬 디스크와 브로커 리밸런싱 없이 동작함
  • 3개 가용 영역 Kafka 클러스터는 1GiB 스트리밍마다 최선의 경우에도 약 $0.053의 AZ 간 전송 비용이 들며, 이는 S3 1GiB 한 달 저장 비용 $0.021보다 높음
  • WarpStream은 상태 없는 Go 바이너리인 Agent와 별도 메타데이터 저장소로 스토리지·컴퓨트, 데이터·메타데이터를 분리하고 데이터는 사용자 클라우드 계정의 객체 스토리지에 남김
  • 비용은 대부분 Kafka 워크로드에서 5~10배 절감될 수 있지만, 현재 구현은 Produce 요청 P99 약 400ms, 생산자-소비자 종단 간 P99 약 1초의 지연 시간을 감수해야 함

클라우드에서 비싸진 Kafka의 기본 구조

  • Apache Kafka는 2011년 오픈소스로 공개된 뒤 스트리밍 아키텍처의 기본 인프라로 자리 잡음
  • 문제는 Kafka 자체보다, 2011년 LinkedIn 데이터센터에 맞춰진 설계가 현대 클라우드 워크로드와 잘 맞지 않는다는 점임
  • 비용과 운영 부담이 특히 크게 드러남
    • 클라우드 경제성: Kafka 복제 방식은 AZ 간 대역폭 비용을 크게 만들 수 있음
    • 운영 부담: 자체 Kafka 클러스터 운영에는 전담 팀과 맞춤형 도구가 필요함
  • 로컬 디스크에 데이터를 저장하는 유사 시스템도 같은 비용·운영 문제를 겪을 수 있음

Kafka-nomics: AZ 간 전송 비용

  • 일반적인 3개 가용 영역 Kafka 클러스터에서는 생산된 데이터가 파티션 리더 위치 때문에 2/3 확률로 영역을 넘어 쓰이고, 이후 리더가 다른 두 영역의 팔로워로 데이터를 복제함
  • 1GiB가 영역 간 전송될 때 비용은 $0.022로 계산됨
    • 출발 영역 egress $0.01
    • 도착 영역 ingress $0.01
  • 최선의 경우에도 1GiB 스트리밍 비용은 0.02 * 2/3 + 0.02 * 2 = $0.053 수준임
  • S3에 1GiB를 한 달 저장하는 비용은 $0.021이며, Kafka로 생산자에서 소비자까지 데이터를 복사하는 비용이면 같은 데이터를 S3에 두 달 넘게 저장할 수 있음
  • 처리량이 큰 Kafka 클러스터에서는 하드웨어보다 AZ 간 대역폭 요금이 비용을 지배하며, 워크로드 비용의 70~90%까지 차지할 수 있음
  • 처리량이 낮아도 보존 기간이 길면 저장 용량이 커지고, 로컬 SSD에 3중 복제하는 방식은 100% 디스크 사용률을 가정해도 S3 같은 객체 스토리지보다 GiB당 약 10~20배 비쌀 수 있음

개발자가 떠안는 클러스터 운영

  • 개발자는 비즈니스 문제를 해결하려고 Kafka를 도입하지만, 먼저 Kafka와 ZooKeeper 또는 KRaft, 리더 선출, 파티션, 컨슈머 그룹, 리밸런싱, 브로커 튜닝, 클라이언트 튜닝을 익혀야 함
  • Kafka의 데이터 플레인인 브로커와 합의 기반 컨트롤 플레인인 컨트롤러·ZooKeeper 등은 모두 로컬 SSD 위에서 직접 운영됨
  • 자체 호스팅 Kafka 클러스터는 노드 교체나 클러스터 확장 같은 기본 작업도 안전하게 수행하려면 전문 팀과 커스텀 도구가 필요함
  • Apache Kafka 내장 파티션 재할당 도구는 브로커 폐기 시 자동 재할당 계획을 만들 수 없고, 관리자가 파티션 복제본 이동 계획을 직접 작성해야 함
  • AWS MSK 같은 호스팅 서비스도 운영 부담을 완전히 없애지는 못함
    • MSK의 클러스터 리밸런싱 문서는 Apache Kafka 문서로 연결됨
    • 해당 절차에는 어떤 파티션을 어떤 브로커로 옮길지 JSON을 수동 편집하는 과정이 포함됨
  • Cruise Control은 부담을 줄일 수 있지만, 별도 개념 학습, 서비스 배포·모니터링, 운용상 날카로운 지점이 추가됨
    • Cruise Control 자체도 Apache Kafka와 ZooKeeper에 의존하는 JVM 애플리케이션임

객체 스토리지 위에 스트리밍을 올리는 접근

  • Datadog에서 만든 Husky는 S3 위에서 직접 실행되는 관측 데이터용 컬럼형 데이터베이스였고, 대부분 상태 없는 자동 확장 데이터 레이크로 동작함
  • Husky 구축 이후 Kafka 클러스터는 비교 대상에서 오래된 구조처럼 보이게 됨
  • Datadog의 Kafka 대역폭은 두 자릿수 GiB/s, 브로커 저장소는 PiB 단위 NVMe로 측정될 정도였음
  • 대규모 저장 워크로드는 클라우드 환경에서 객체 스토리지의 경제성·신뢰성·확장성·탄력성과 경쟁하기 어려움
  • Snowflake와 Databricks 같은 빅데이터 기술도 범용 객체 스토리지를 중심으로 시스템을 설계함
  • Kafka와 비슷한 시스템을 S3 위에 직접 만들면 두 가지 부담을 동시에 줄일 수 있음
    • 비용 감소
    • 전통적인 Kafka 운영 문제 감소
  • 핵심 난점은 S3 같은 고지연 저장 매체 위에서 로컬 디스크 없이 Kafka 프로토콜의 의미를 유지하면서 저지연 스트리밍 인프라를 만드는 것임

WarpStream 아키텍처

  • WarpStream은 AWS S3, GCP GCS, Azure Blob Storage 같은 범용 객체 스토어 위에서 직접 실행되는 Apache Kafka 프로토콜 호환 스트리밍 플랫폼임
  • AZ 간 대역폭 비용이 없고, 관리할 로컬 디스크가 없으며, 사용자의 VPC 안에서 실행될 수 있음
  • Kafka 브로커 대신 Agent를 사용함
    • Agent는 상태 없는 Go 바이너리임
    • JVM을 사용하지 않음
    • Kafka 프로토콜을 말함
    • 어떤 Agent든 토픽 리더, 컨슈머 그룹 오프셋 커밋, 클러스터 코디네이터 역할을 할 수 있음
  • WarpStream은 두 가지 분리로 Kafka의 상태ful 구조를 대체함
    • 스토리지와 컴퓨트를 분리하고 데이터를 S3로 오프로딩함
    • 데이터와 메타데이터를 분리하고 메타데이터를 맞춤형 메타데이터 저장소로 오프로딩함
  • 객체 스토리지로 모든 저장을 넘기면 부하 변화에 맞춰 Agent 수를 늘리거나 줄일 때 데이터 리밸런싱이 필요 없음
  • 장애가 나도 요청을 다른 Agent에서 즉시 재시도할 수 있어 복구가 빨라짐
  • 파티션별 데이터 불균형 때문에 일부 Kafka 브로커 부하가 높아지는 핫스팟 문제도 대부분 줄어듦
  • WarpStream Virtual Cluster의 메타데이터는 맞춤형 메타데이터 데이터베이스에 저장됨
  • 데이터 복제, 내구성, 가용성은 객체 스토리지 버킷이 맡고, 사용자의 데이터는 클라우드 계정 안에 남음
  • 클라우드 계정 밖으로 나가는 것은 파티션 내 배치 순서 같은 합의에 필요한 워크로드 메타데이터뿐임
  • 자세한 구조는 WarpStream 아키텍처 문서에 정리돼 있음

비용 예시와 지연 시간 트레이드오프

  • 테스트 환경의 지속 스트리밍 워크로드는 140MiB/s 데이터를 계속 생산하고, 전용 소비자 3개가 이를 소비해 총 560MiB/s의 연속 데이터 전송을 만듦
  • 전체 클라우드 계정의 AZ 간 네트워크 비용은 하루 평균 $15 미만으로 측정됨
  • 같은 워크로드를 Kafka 클러스터에서 실행하면 AZ 간 네트워크 비용만 하루 $641로 계산됨
    • 계산식은 0.14GiB * $0.053/GiB * 60 * 60 * 24
  • 같은 워크로드의 S3 API 작업 비용은 하루 $40 미만임
  • Agent 하드웨어는 27 vCPU 규모의 VM만 필요함
  • 대부분 Kafka 워크로드의 총소유비용은 WarpStream에서 5~10배 낮아질 수 있음
  • 가장 큰 단점은 지연 시간임
    • Produce 요청 P99는 현재 약 400ms임
    • 데이터가 S3에 내구적으로 저장되고 클라우드 컨트롤 플레인에 커밋되기 전까지 확인 응답하지 않기 때문임
    • 생산자에서 소비자까지의 종단 간 P99 지연 시간은 약 1초임
  • 워크로드가 P99 약 1초 생산자-소비자 지연을 허용하면, GiB당 스트리밍 비용을 5~10배 줄이고 운영 부담을 거의 없앨 수 있음
  • 인터페이스는 독자 프로토콜이 아니라 Kafka이며, AWS S3, GCP GCS, Azure Blob Storage를 사용하는 환경에서 실행될 수 있음

개발자 경험과 사용 방법

  • WarpStream은 Kafka의 주요 문제 중 클라우드 경제성과 운영 부담을 먼저 다룸
  • Kafka에는 개발자 경험 문제도 있으며, 파티션은 복잡한 스트림 처리 애플리케이션을 작성하기에 너무 낮은 수준의 추상화로 간주됨
  • 향후 스트림 처리 애플리케이션을 전통적인 애플리케이션 작성 방식에 더 가깝게 만들 수 있는 방법을 다룰 계획임
  • 데모는 30초 이내에 실행할 수 있음
$ curl https://console.warpstream.com/install.sh | bash
$ warpstream demo
  • WarpStream은 Apache Kafka 위에 객체 스토리지 기반 대체품을 판매하는 회사의 제품 소개이며, 본문 수치와 비교는 그 맥락에서 읽어야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “거의 모든 기술 회사가 Kafka를 쓴다”는 말은 틀린 것 같음
    근거를 서로 제시한 건 아니지만, 최근 일한 6개 회사 중 Kafka를 쓴 곳은 0곳이었고, 그 전 회사에서는 도입을 주도했지만 나중에 버렸음
    LinkedIn은 99%에게 없는 초대규모 문제를 풀려고 Kafka를 만들었고, 기술자들이 필요 없는 기술을 쓰는 평판이 있긴 해도 대부분은 Kafka 사용을 피하는 데 성공하고 있다고 봄

    • Kafka를 어떻게 싫어할 수 있는지 잘 모르겠음. Kafka는 말 그대로 게시/구독 의미론으로 데이터를 A에서 B로 옮겨줌
      필요한 게 전부라면 보존 기간 없는 단순 메시지 브로커처럼 쓰기 쉽고, 지속성을 활용한 특이한 작업이 필요하면 그쪽으로 가면 됨
      기본 형태로도 견고하고 널리 쓰이는 오픈소스 도구에 부정적 감정을 갖는다면 대개 일부 특수 기능이나 사용 사례 때문일 것 같음
      오히려 이런 표현은 이 벤더에게 좋지 않게 보임. 기술적 장단점으로 Kafka를 비판하거나 경쟁할 수는 있지만, 시장에서의 위치를 왜곡하는 건 별로임
    • Kafka는 메시지 큐라기보다 지속성 있는 WAL에 가까움. 작업에 WAL이 필요 없으면 거의 확실히 과하고 싫어하게 될 것이고, WAL이 필요하면 최고의 도구가 됨
    • 계약직이라 여러 회사를 옮겨 다니는데, Kafka를 도입하려는 회사들을 몇 번 봤고 매번 문제를 찾는 해법처럼 보였음
      좋은 사용 사례가 있다는 건 의심하지 않지만, 지금까지는 어떤 상황에도 억지로 끼워 넣는 열성 사용자들만 봐서 뒷맛이 안 좋게 남았고 그래서 “싫어하는 쪽”에 속함
    • 동의하지 않음. 사람들이 필요 없는 곳에 Kafka를 끼워 맞추려 할 수는 있지만, 이벤트 스트리밍이 있는 애플리케이션에서는 여전히 Kafka가 1순위임. 분석, 메시징, 센서 등이 그렇다
      “Accidental SRE” 부분에는 동의하지만 Kafka는 탄탄한 기술이고, 그래서 Redpanda 같은 “Kafka보다 나은 Kafka” 도구도 넘쳐남
      마지막에는 논점에서 벗어난 듯함. 널리 쓰이지 않는다고 해도 그게 양극화된 기술인지와는 별개임. 언급한 1%의 확장 문제를 푸는 사람들에게는 여전히 좋아하거나 싫어하는 대상이 될 수 있음
      “람보르기니는 호불호가 갈린다”는 말이 대부분의 사람이 람보르기니를 갖고 있지 않아서 틀렸다고 하는 것과 비슷함. 글쓴이도 명시적으로 “데이터 분야에서”라고 해서 범위를 제한했음
    • 그 표현이 내 개인 네트워크와 업무 경험에 꽤 크게 물든 건 맞는 것 같음

  • 몇 가지 질문이 있음

    1. 각 메시지를 S3에 바로 넣으면 S3 API 호출 비용이 엄청나지 않나? 로컬 저장소 없이 메시지를 어떻게 내구성 있게 버퍼링/큐잉/병합하나?
    2. 각 가용 영역마다 Kafka 클러스터를 하나씩 돌리고, ETL 시점까지 가용 영역 간 복제를 하지 않는 방식은 뭐가 문제인가? AZ1 클라이언트는 AZ1 클러스터로, AZ2 클라이언트는 AZ2 클러스터로 보내는 식임
    3. Kafka 파티션 안에서 작업 순서는 어떻게 보존하나?
    • WarpStream Agent는 최근 약 100ms 동안 요청을 받은 모든 토픽-파티션의 데이터를 한 파일로 묶어 S3에 플러시함
      그래서 S3 PUT 비용은 토픽-파티션 수가 아니라 실행 중인 Agent 수와 플러시 간격에 비례함. 데이터가 S3와 클라우드 제어 평면에 내구성 있게 저장되기 전에는 Produce 요청을 승인하지 않음
      신뢰성과 비용 중 하나를 골라야 해서는 안 된다고 봄. WarpStream은 3개 가용 영역에서 돌리는 수준의 신뢰성과 가용성을 한 가용 영역 비용으로 제공함
      순서는 클라우드 제어 평면에서 실행되는 커스텀 메타데이터 데이터베이스가 처리함
    • Kafka 동작 방식상 메시지는 브로커에 도달하기 전부터 자연스럽게 버퍼링되고 병합되므로, 당연히 메시지는 병합되고 있음
      각 가용 영역에 Kafka 클러스터를 두고 나중에 합칠 때까지만 복제하는 방식 자체에는 문제가 없음. 다만 분산 시스템과 가용 영역이 주어지면 엔지니어들, 그리고 비즈니스 요구사항은 대체로 다중 가용 영역 구성을 선택하게 됨. 리전도 마찬가지임
      그래서 대부분의 Kafka 클러스터는 다중 가용 영역이지만 사실 그러지 않아도 되는 경우가 많고, 그 비용 청구서가 Kafka 탓으로 돌아감
      Kafka 프로토콜은 Kafka 파티션 내 작업 순서를 실제로 보존하지 않음. 프로듀서-파티션 쌍 안의 작업 순서를 보존하며, 그것도 특정 방식으로 설정했을 때만 가능함
      표준 구현은 프로듀서로부터 브로커가 메시지를 받은 순서를 보존하는 방식이지만, 외부 시스템 관점에서는 올바르게 설정했을 때 특정 키와 특정 프로듀서의 메시지가 수신 순서대로 보존된다는 의미에 가깝다
    • 3번이 특히 궁금함. 아키텍처 개요를 보면 모든 Agent가 활발히 쓰고 압축하는 것처럼 들리는데, 어떤 토픽-파티션을 압축할지 어떻게 조율하나?
      Cloud Metadata Store가 사실상 오프셋을 나눠주는 역할을 하나?
    • 1번에 대해서는, Kafka가 AWS 안에 호스팅되어 있다면 Amazon은 AWS 내부 데이터 전송에 과금하지 않는 것으로 알고 있음

  • WarpStream 공동창업자이자 CTO인 Ryan Worl임. S3 위에 직접 구축한 Kafka 프로토콜 호환 스트리밍 시스템의 개발자 프리뷰를 발표하게 되어 매우 기쁨
    실행할 상태 저장 디스크/노드가 없고, 데이터 리밸런싱도 없고, ZooKeeper도 없으며, 가용 영역 간 대역폭 비용이 없어 5~10배 저렴함
    WarpStream에 대해 질문이 있으면 공동창업자 richieartoul과 함께 답하겠음

    • 축하함. 내 사이드 프로젝트 목록에 있던 “Kafka의 SQLite” 항목을 지울 수 있어서 기쁨
      만들지 않았던 이유 중 하나는 규모가 중요하지 않다면 사용자가 축소판 Kafka를 원하기보다 SQLite를 직접 쓰면 되는 것 아닌가 하는 역설이 느껴졌기 때문임
      하지만 사람들이 Kafka 프로토콜의 의미론을 좋아하거나, 이미 Kafka를 쓰다가 생각했던 규모가 아니어서 복잡성을 감당할 필요가 없다는 걸 알게 된 경우가 있을 수 있음. 행운을 빔
    • S3 호환 서비스, 특히 Cloudflare R2를 지원하나? S3 호환 제공자마다 API 동작과 일관성 모델이 조금씩 달라서 별도 처리가 필요할 수 있다고 들었음
      Cloudflare R2를 지원한다면 멀티 클라우드에도 좋을 것 같음
    • 블로그 글에서 파티션은 프로그램이 직접 다루기엔 너무 저수준 추상화라고 했는데, 그렇다면 WarpStream은 파티션을 쓰지 않는다는 뜻인가?
      Kafka가 파티션 수준에서 제공하는 것 같은 순서 보장도 제공하나?
    • 프로듀서가 이제 S3 쓰기를 기다려야 하니 지연 시간이 훨씬 커지는 것 아닌가?
      “5~10배 저렴”하다는 게 대부분 가용 영역 간 비용 절감 때문이라면, AWS MSK도 그걸 제공하지 않나?
    • ZooKeeper는 어떻게 대체하나?

  • 한 가지는 확실함. 클라우드 제공자 위의 개별 VM에서 Kafka를 “정석대로” 돌리면 터무니없이 비쌈
    Kafka와 Hadoop에 대해 여러 고객과 아주 단순한 얘기를 한 기억이 있음. 디스크가 이미 완전한 중복 시스템으로 제공되는데 왜 VM/디스크 수준에서 데이터를 다시 복제하느냐는 것임
    여기서는 Azure Storage였고, 로컬 중복, 가용 영역 중복, 전역 중복 저장소를 제공하며 그중 상당수는 관리 디스크 실행에 사용할 수 있었음
    그래서 제대로 설계된 Hadoop/Kafka 클라우드 관리형 서비스는 공급자의 내장 중복성을 활용하기 위해 저장소 어댑터를 씀. 일부 클라우드 제공자에 Kafka 호환 이벤트 브로커가 있는 이유도 같음
    WarpStream의 나머지 부분은 금상첨화에 가깝지만, 내부 구조와 가용 영역 간 비용을 어떻게 피하는지는 궁금함
    참고로 Microsoft에서 일하지만, 거의 10년 전 입사 전에는 Hadoop/Spark/Kafka 클러스터를 구축했음

    • 예전에는 진짜 프로세스보다 훨씬 적은 리소스만 쓰는 타이브레이커 프로세스로 중복 시스템을 구현하곤 했음
      일부 Raft 구현은 투표권은 있지만 쿼럼 리더가 될 수 없는 노드를 허용함. 예를 들어 모든 트래픽이 비대칭 VPN 터널을 통과하는 지사는 리더로 선출되면 안 되지만, 어떤 후보를 볼 수 있는지는 알고 있음
      그래서 클러스터 운영의 기본 비용은 하드웨어 3배가 아니라 2.2배에 가까웠고, 작은 솔루션이나 개발자 샌드박스에서는 큰 차이였음. 샤드 3개로는 부하가 애매하게 부족하지만 5개는 너무 많은 경우, 또는 6개와 7개의 차이에서도 중요함
      문제는 지리적 복제에서는 이 글의 핵심 논지인 두 문제를 해결하지 못한다는 점임. 클라우드 경제성 측면에서 Kafka의 복제 전략은 설계상 막대한 가용 영역 간 대역폭 비용을 만들고, 운영 부담 측면에서 자체 Kafka 클러스터 운영에는 전담 팀과 정교한 커스텀 도구가 사실상 필요함
      그래도 클라우드에서 이 기능을 되찾을 필요가 있음. 특히 과거에도 늘 그랬듯 추가 다시 자가 호스팅으로 흔들리기 시작할 때 더 그렇다
    • 아니면 의도된 대로 브로커에 임시 데이터 저장소를 쓰면 됨
    • “디스크가 이미 완전한 중복 시스템으로 제공되는데 왜 VM/디스크 수준에서 데이터를 복제하느냐”에 대한 답은 쉬움
      EBS와 비슷한 솔루션은 비용이 따라옴. 특히 많은 IOPS가 필요할 때 매우 비쌈. 가용 영역 간 트래픽 비용은 아낄 수 있어도 저장소에 말도 안 되는 돈을 내게 됨
      복제를 직접 하면 훨씬 저렴한 연결 스토리지를 쓸 수 있음
    • Azure 디스크 복제는 데이터의 내구성을 위한 것이지, Kafka 관점에서 데이터 가용성을 위한 것이 아님

  • richieartoul에게, 블로그 글은 약간 양념이 과함
    Kafka는 아주 큰 클러스터를 운영하기 전까지는 본질적으로 전문가 전담 팀과 수백만 달러를 요구하지 않음
    다만 3개 가용 영역에 걸친 클러스터가 가용 영역 간 전송 비용으로 돈을 빨아먹는다는 데는 완전히 동의함. AWS가 MSK를 파는 방식도 그거임. 가용 영역 간 전송이 “무료”라고 하지만, 사실 이미 가격에 포함되어 있음

  • 흥미로워 보이지만 “Accidental SRE”를 읽고 두 가지 질문이 생김
    베어메탈은 오래전부터 있었는데, 자체 베어메탈 관리가 딱히 훨씬 쉬워진 것 같지는 않음. 정말 쉬웠다면 이런 것들을 최종 사용자가 더 많이 직접 관리했을 것임
    그렇다면 이 서비스를 어떻게 관리하나? 클라우드 제공자인가, 베어메탈인가?
    두 사람 모두 보통 직접 관리하는 FoundationDB 경험이 많음. 그래서 메타데이터 저장소도 다시 FoundationDB를 선택했나? 선택했거나 선택하지 않았다면 이유가 궁금함

    • WarpStream의 현재 제공 방식은 하이브리드 BYOC 접근임. 고객이 자기 클라우드 계정에서 Agent를 실행하고, 우리는 메타데이터 저장소를 원격으로 관리함
      이렇게 하면 모든 고객 데이터가 고객의 클라우드 계정과 S3 버킷 안에 남아 우리가 보거나 건드릴 수 없음. 고객이 WarpStream Agent를 직접 실행해야 하긴 하지만, 관리하기 쉬운 상태 없는 컨테이너일 뿐임
      메타데이터 저장소로 FoundationDB를 검토했지만 결국 쓰지 않았음. 무료 티어를 비용 효율적으로 만들려면 이 특정 사용 사례에 맞게 메타데이터 저장소를 최대한 효율적으로 만들어야 했고, 그러려면 좀 더 커스텀한 것이 필요했음
      그래도 FoundationDB는 훌륭한 기술임. 내가 써본 여러 분산 데이터베이스 중 최고임

  • “파티션을 몇 개나 써야 하나? 불명확하지만 한 번 정하면 절대 바꿀 수 없으니 제대로 골라야 한다”는 말은 그냥 틀렸음. 파티션 수는 바꿀 수 있음
    그리고 반복해서 말하는 “Kafka 운영에는 엔지니어 팀 전체가 필요하다”는 주장도 잘 이해되지 않음. 경험상 사실이 아님. 운영 비용이 비싼 건 맞지만, 우리 팀에서는 엔지니어링 시간이 많이 필요하지 않음

  • 아주 흥미로움. 나도 비슷한 걸 설계했고 Zig로 구현하려고 했음 https://github.com/fremantle-industries/transit
    Kafka의 힘 상당 부분은 API에서 나오고, 결국 클러스터 관리 복잡성은 여러 구현체를 통해 추상화될 것이라는 비슷한 결론에 도달했음
    S3 키 공간 위에 Kafka 지속성을 구현할 수 있다면 WarpStream처럼 S3에 직접 지속화하는 방식으로 시작하고, 이후 더 빠른 핫 디스크와 메모리 계층화 메커니즘을 얹어 종단 간 지연 시간을 낮출 수 있다고 봤음
    방향이 마음에 듦. 더 깊게 이야기하고 싶으면 Twitter로 연락해도 좋음 https://twitter.com/rupurt

  • 예전 직장에서 이 제품과 아마 매우 비슷한 것을 만들었음. 일 단위 두 자릿수 TB의 머신러닝 트래픽이 있었고 실시간 지연 시간이 필요하지 않아 전부 S3로 옮겼더니 약 90% 비용 절감이 나왔음
    JVM 위에 만들었고 메타데이터 유지를 위해 여전히 6개 브로커 Kafka 클러스터를 썼음. 원래 전부 Kafka에 있었을 때는 아마 300개 브로커였을 것임
    Kafka의 컴퓨팅/저장 모델은 지연 시간을 감수할 수 있는 극단적 사용 사례에서는 잘 확장되지 않고, Apache Pulsar 모델이 더 잘 맞는 편이었음. 다만 당시 Pulsar는 프로덕션에서 쓰기엔 충분히 안정적이지 않았음
    비용 효율의 핵심 중 하나는 데이터 크기가 충분히 커서 경제적인 파일 크기에 도달할 때까지 오래 기다릴 필요가 없었다는 점임. 초당 10MB 미만 파이프라인이 이 방식으로 효율적으로 동작할지는 상상하기 어려움

    • 이 영역에서 자체 솔루션을 만든 사람들을 꽤 많이 만났음. “전통적인 Kafka를 통해 S3 포인터를 푸시하는” 접근은 매우 실용적임
      이게 Pinterest의 memq였나, 아니면 다른 것이었나?

  • 글 제목은 “Kafka is dead. Long live WarpStream.”이어야 했음. “long live” 부분은 후계자를 가리킴

답변달기