Apache Kafka에 도입될 Diskless Topics(KIP-1150)은 오브젝트 스토리지를 복제 엔진으로 사용해, 클라우드 환경에서 최대 80%의 비용 절감과 폭발적 유연성을 제공합니다. 기존 토픽과 완벽히 호환되며, 혁신과 경제성을 동시에 달성할 Kafka의 새로운 진화입니다.
KIP-1150는 Apache Kafka에서 오브젝트 스토리지에 복제를 위임하는 새로운 타입의 토픽을 제안합니다. 디스크가 핫 패스에서 제외되면서, 클러스터 리밸런싱, 핫 파티션, IOPS 한도와 같은 기존의 문제점들이 사라집니다. 그리고 영역 간 네트워크 비용과 비싼 로컬 디스크 비용이 최대 80%까지 절감됩니다. 이제 데이터는 로컬 디스크와 오브젝트 스토리지 모두에 존재하기 때문에 사용자는 토픽별로 지연 시간을 조절하고, 브로커를 몇 초 내에 추가 또는 제거할 수 있으며, 재해 복구를 위한 저렴한 지오 리플리케이션도 수월하게 사용할 수 있습니다.
이 모든 것은 Kafka 코드베이스의 단 1.7% (약 23,000줄)만 수정하면 가능하며, 클라이언트 API 변경도 없습니다. 짧은 지연 시간이 필수적인 sub-100ms 토픽과, 초저가 디스크리스 스트림(로그, 텔레메트리, 배치 데이터 등)을 같은 클러스터에서 모두 사용 가능하죠. 유연한 복제 덕분에 Kafka는 어떤 클라우드 가격 모델이 와도 미래에도 안전합니다.
디스크리스 토픽 시작은 한 줄이면 됩니다:
kafka-topics.sh --create --topic my-topic --config topic.type=diskless
자세한 설계를 바로 보고 싶다면 공개 KIP를 참고하세요.
Kafka가 왜 성공했을까요? 오랫동안, Kafka는 스트리밍 기술 중 가장 범용적인 엔진으로, 이벤트 주도형 아키텍처, 로그, 메트릭, 새로운 미들웨어 케이스까지 거의 모든 데이터 파이프라인을 지원할 정도로 다재다능했습니다.
Kafka의 성공 비결은 단지 다재다능함이 아닙니다. 바로 디스크를 썼기 때문입니다. 메모리 기반 시스템과 달리, Kafka는 높은 처리량과 짧은 지연 시간, 그리고 신뢰성을 모두 갖췄죠. 프로듀서와 컨슈머를 분리한 덕분에 컨슈머가 느려도 디스크에 안전하게 데이터를 저장할 수 있어, 전체 파이프라인이 멈추지 않았습니다. 많은 경쟁 시스템들은 메시지를 메모리에 보관하다 컨슈머가 밀리면 크래시나 전체 장애로 이어졌죠.
아이러니하게도, 초기 성공을 이끈 디스크가 이제는 클라우드 환경에서 Kafka의 약점이 되었습니다. 최신 디스크리스 아키텍처가 등장해, 디스크를 제거함으로써 큰 비용절감과 운영 단순화를 이뤄냈기 때문입니다.
Diskless Topics는 완전히 디스크를 없애기보다는, 디스크를 추상화하여 오브젝트 스토리지(S3 등)를 활용, 비용과 유연성을 모두 챙깁니다. Kafka는 이제 자신만의 강점을 클라우드의 경제성과 민첩성과 결합하여 새로운 장을 엽니다.
시장에서는 이미 디스크리스 구조로 혁신이 일어나고 있고, 최초 발표 후 2년이 지난 지금 더 빠른 변화가 이어지고 있습니다.
Apache Kafka에 새롭게 도입되는 개념이지만, Diskless Topics는 비용 효율성과 고지연 Kafka를 위한 첫 솔루션은 아닙니다. 이미 유사한 여러 제품이 있고, Kafka가 이 방식을 받아들여야 오픈소스 커뮤니티도 직접적으로 이득을 볼 수 있습니다.
우리는 바퀴를 다시 발명할 이유가 없습니다. 이 KIP 이전에 많은 스타트업들이 길을 닦아 주었고, 앞으로 실현해야 할 과제도 미리 풀어 줬습니다. Diskless를 통해 검증된 효율성을 Kafka에, 그리고 모두가 쉽게 쓸 수 있도록 하자는 의미가 큽니다.
혁신 속도: Diskless는 커뮤니티 주도의 대형 프로젝트도 점진적 업데이트 대신 대담한 설계 도약을 할 수 있음을 증명할 것입니다.
클라우드 가격 모델: 복제 핫 패스에서 디스크를 제거해, 클라우드에서 Kafka 사용시 발생하는 가장 비싼 컴포넌트(디스크 기반 복제 비용)를 크게 낮춥니다.
생각해보세요: 클라우드에서 Kafka의 총 소유 비용(TCO)의 **80%**가 네트워크 오버헤드와 관련 있습니다(Warpstream 블로그 참고). Gartner 등 주요 분석 기관에 따르면 글로벌 스트리밍 지출이 500억 달러를 넘습니다. 만약 Diskless Topics가 기본 배포 모델이 된다면, 커뮤니티는 네트워크와 스토리지 비용에서 수십억 달러를 아낄 수 있습니다. 이 정도 즉각적인 ROI는 무시할 수 없습니다.
그래서 우리는 질문했습니다. 오픈 소스 최대 프로젝트가 스타트업처럼 혁신할 수 있을까? Kafka가 클라우드 네이티브처럼 저렴하게, 자유롭게 오토스케일이 가능할까요? 우리는 커뮤니티에 수십억 달러의 비용을 절약할 수 있을까요?
커피 한잔 하며, 거인을 어떻게 깨우고 있는지 살펴봅시다.
Apache Kafka는 세계에서 가장 영향력 있는 오픈소스 프로젝트 중 하나이지만, 오픈 커뮤니티라는 점에서 지속적인 비판의 대상이기도 합니다. 아마 이런 말 많이 들어보셨을 겁니다:
이 주장들은 잘 만들어졌지만, 현실의 입체감을 담지 못하는 2차원적 메시지에 불과합니다. 현실은 더 깊고 섬세하죠. 하지만 마케팅의 세계니까 이해합니다. 저희의 시각은 다음과 같습니다:
그러나 결정적인 사실 한 가지 - Kafka에는 마케팅팀이 없지만, 100,000개 이상의 회사가 매일 Kafka 오픈소스 버전을 쓰고 있습니다. 스트리밍 시장에 연간 500억 달러가 투입되고, 그 대다수가 Kafka를 쓴다면, Kafka는 말보다 실제가 큽니다. 다만 생태계가 성장함과 동시에, 디스크 기반 복제의 _클라우드 비용_도 비례해 커지는 게 문제죠. 보수적인 거버넌스 덕에 게임 체인저인 기능들은 출시까지 몇 년씩 걸립니다.
대부분 오픈소스 사용자는 선택의 기로에 섭니다. 1) 비싼 클라우드 비용을 감수하든, 2) 내부적으로 독자 솔루션을 만들든(인력이 충분하다면), 3) Kafka 호환 유료 서비스에 종속되든 셋 중 하나죠. 그 어떤 길도 썩 내키진 않습니다. 이런 흔한 내러티브, 즉 Kafka는 너무 비싸고, 고집스럽고, 과거에 갇힌 기술이라는 인식이 자연스레 커집니다. 더 많은 회사가 대안으로 떠나거나 자체 해킹을 하게 되면, Kafka의 범용 스트리밍 엔진 지위도 위태로워집니다.
Diskless는 Aiven에도 큰 이득입니다. 우리는 클라우드에서 3,700개가 넘는 전용 Kafka 클러스터와 초당 46GiB 이상을 서비스하고 있습니다. Diskless를 도입하면 Kafka 클러스터 업그레이드만으로도 네트워크/디스크 비용을 수백만 달러 절약할 수 있습니다.
그런데 왜 오픈소스 커뮤니티를 도울까요? Aiven 입장에서는 오픈소스 Kafka를 사용하는 게 아니라, 우리는 곧 오픈소스 Kafka입니다. Kafka가 잘되면 Aiven도 잘되기 때문이죠. 관리형 Kafka 서비스가 믿을 만하고 비용경쟁력이 있다면 더 많은 기업이 Kafka 운영을 맡기려 할 것입니다. 우리는 관리 수수료를 얹지만, 고객은 자체 Kafka 전문인력 필요가 없어 결과적으로 이득입니다. 인프라 비용이 낮아질수록 고객도 함께 저렴해집니다! 즉, KIP-1150은 Aiven과 커뮤니티 모두에게 윈윈입니다.
하지만 KIP가 가진 의미는 더 큽니다. 상업적 벤더들이 Kafka의 사실상 비공식 R&D팀 역할을 하며 신기술을 테스트해보고 많은 시행착오 비용을 나눌 수 있습니다. 검증된 개념은 다시 오픈소스 Kafka 핵심 기능으로 들어오죠. (티어드 스토리지가 대표적 예)
Diskless Topics는 이제 _불가피한 진화_입니다. 시장에서 검증된 기능을 먼저 받아들여, Apache Kafka가 경쟁력을 유지하고 네트워크 효과도 유지할 수 있습니다.
우리는 KIP가 엔지니어들이 협력할 공유의 '운동장'이 되길 진심으로 원합니다. 제안서도 여러 작은 KIP으로 나눠 피드백 과정을 가속화하고 마찰을 줄였습니다. 완벽함이 좋은 해결책의 적이 되지 않기를 바랍니다.
충분히 빠르면, 큰 거인도 난다고 믿기에.
집중합시다: 클라우드에서 Kafka 운영은 저렴하지 않습니다. 가장 큰 뱀파이어는 AZ간 복제입니다. 이미 훌륭한 분석글들이 많으니(Stan’s 블로그 등 정독 추천), 여기선 또다른 비용 분석은 생략합니다.
1 GiB/s, Tiered Storage, 3배 팬아웃 Kafka 클러스터를 AWS에서 돌리면 연간 340만 달러!
왜 클라우드에서 Kafka가 비싼가? 근본 원인을 따지면, 복제 모델 탓은 아닌 것 같습니다. 복제 모델은 이미 10년 넘게 시장을 지배해온 훌륭한 구조입니다. 문제는 클라우드 가격 모델 그 자체. 오늘날에는 영역간 트래픽에 큰 과금을 하지만, 내일은 또 달라질 수 있습니다. 기존 토픽을 남겨두어 가격 구조 변화에도 Kafka가 살아남을 수 있게 하자는 겁니다.
아이러니하게도, S3 같은 오브젝트 스토리지는 "스토리지"일 뿐 아니라 로드 밸런서이자 영구 복제 시스템 역할도 합니다. Diskless는 객체 저장소를 Kafka의 복제 엔진으로 써서, 가장 비싼 클라우드 오버헤드(영역간 블록 복제)를 잘라냅니다. Diskless 벤치마크 결과, 배치 사이즈가 비용-지연 트레이드오프를 결정짓는 핵심 요소였습니다. 예를 들어 100KB 블록은 응답이 빠르지만 PUT 비용이 비싸고, 10MB 대형 블록은 비용이 저렴하지만 지연은 증가합니다. 일반적인 워크로드에는 1MB 블록이 최적이었고, 200~400ms 지연에, 고전적 복제 대비 약 80% 비용 절감 효과를 냈습니다. 다양한 실험을 거쳐 최적의 기본값을 Apache Kafka에 반영할 예정입니다. 실측 계산은 따로 튜닝 계산기로 해보세요.
시뮬레이션 주요 결과: Diskless는 작업 완료 후 데이터 저장이 최소화되는 워크로드에서 가장 큰 비용 절감 효과를 냅니다. '일시성' 데이터에는 90% 가까운 비용 절감까지 측정됐습니다. Diskless Kafka의 비용 분석만으로도 별도 포스트가 필요할 정도입니다.
물론 저렴한 비용도 좋지만, 복제의 유연성 덕에 Kafka 자체의 민첩성이 비약적으로 높아집니다. 예시로:
이 모든 게, 기존 Kafka 클러스터와 완전히 호환됩니다.
Diskless는 Kafka를 분해하는 게 아니라, 기존 구조를 확장하여 새로운 토픽 타입(diskless)을 전통적 토픽과 나란히 추가하는 방식입니다. 즉, 기존 툴·워크플로우와 완벽히 호환되면서 Diskless/Kafka 토픽을 동시에 운영할 수 있습니다.
KIP의 핵심은 S3, DynamoDB, Spanner 등과 같은 클라우드 네이티브 기술의 확장성과 신뢰성을 적극 활용한다는 점입니다. 비용은 낮추고, 운영 부담은 줄이고, 강력한 엔터프라이즈 서비스를 바로 쓸 수 있으니 마다할 이유가 없죠. 이를 위해 다음 6가지 원칙을 따릅니다:
Diskless는 Kafka 내장 기능: 토픽별로 단순 설정만 바꾸면 오브젝트 스토리지로 자동 쓰기가 됩니다. Kafka에 통합되므로 어떤 벤더든 사용 가능.
업그레이드만, 마이그레이션 불필요: Kafka 자체 기능이므로 클러스터 업그레이드 후 새 토픽만 생성하면 됩니다. 비용이나 이전 부담 없음.
별도 브랜치 없음(포크 방지): Diskless는 메인 저장소와 충돌을 최소화하는 업스트림 통합을 목표로 설계됐습니다. Tiered Storage처럼 모두의 협업 효과 기대.
Diskless 토픽은 Kafka 토픽: 사용 경험, 클라이언트 버전, 앱 코드 변화 등 없이 바로 전환, 일관성 문제도 없음.
Diskless는 오브젝트 스토리지로 복제: 브로커 디스크가 아닌, 순수 오브젝트 스토리지에 저장됨.
리더 없는 구조: 모든 브로커가 모든 Diskless 토픽을 처리할 수 있고, 파티션 리더 브로커가 필요 없으므로 핫스팟/계층간 트래픽이 사라짐.
지금까지 핵심 개념·기술 요약·미래 비전 등을 다뤘습니다(기술 세부 내용은 곧 별도 공개 예정). 만약 Diskless(KIP-1150)가 커뮤니티 승인을 받는다면, 스트리밍 설계 지형이 완전히 재편될 것입니다. 비용이 크게 낮아지면, Kafka의 적용 범위 자체가 넓어지고 최신 데이터 아키텍처 트렌드에도 적합한 솔루션이 됩니다. 예를 들어 Diskless와 Tiered Storage 간 파일 포맷을 통합하거나, 모두 오브젝트 스토리지에서 즉시 검색 가능하게 만들 수도 있습니다. Iceberg 네이티브 토픽도 함께 활용해, 저렴한 분석 파이프라인 등 새로운 가능성이 열립니다. 향후 클라우드 가격이 변한다 해도, 원하는 시점에 자유롭게 디스크리스/디스크드 토픽 전환, 저장소 클래스 변경이 가능합니다.
아마 1~2년 후 "Diskless Topics" 도입이 전환점이었음을 느끼게 될 겁니다. KIP-1150이 클라우드 비효율과 제약 문제를 해결해, 표준 Kafka 클라우드 배포 정의를 새로 쓸 수 있게 되겠죠. 회의적이어도 괜찮습니다. 댓글·반박·경험담을 환영합니다. 이런 과정이 변화의 동력이 됩니다.
하지만 혹시라도 설레신다면(그래야 합니다!), 지금이 바로 직접 KIP 원문을 읽고, 피드백을 남기고, Kafka 복제 모델의 미래를 같이 그려볼 순간입니다.
