# Kafka를 처음부터 다시 만들 수 있다면 어떨까?

> Clean Markdown view of GeekNews topic #20538. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20538](https://news.hada.io/topic?id=20538)
- GeekNews Markdown: [https://news.hada.io/topic/20538.md](https://news.hada.io/topic/20538.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-04-26T10:23:32+09:00
- Updated: 2025-04-26T10:23:32+09:00
- Original source: [morling.dev](https://www.morling.dev/blog/what-if-we-could-rebuild-kafka-from-scratch/)
- Points: 13
- Comments: 2

## Summary

최근 **KIP-1150**과 **AutoMQ**의 프로젝트를 통해 클라우드에 최적화된 Kafka에 대한 논의가 활발해지고 있습니다. 기존 **파티션 구조**를 제거하고 **키 중심 접근**을 제안하며, **동시성 제어**와 **브로커 사이드 스키마 지원** 기능이 필요하다고 강조합니다. 또한, **확장성, 스냅샷, 멀티 테넌시** 같은 최신 시스템 특징을 통합할 필요성을 제기합니다. **멀티 테넌시**와 플러그인 구조를 기본 지원해 **클라우드 네이티브 이벤트 로그 시스템**으로의 전환을 상상해보는 글입니다.

## Topic Body

- KIP-1150(디스크 없는 Kafka)과 AutoMQ의 Kafka 포크 프로젝트를 통해 **클라우드 최적화 Kafka** 논의가 활발해짐  
- Kafka를 다시 만든다면 기존 **파티션 구조를 제거**하고 **키 중심 접근**을 제안  
- **동시성 제어**와 **브로커 사이드드 스키마 지원** 기능이 필요한 상황임  
- **확장성, 스냅샷, 멀티 테넌시** 같은 최신 시스템 특징을 통합할 필요성도 강조  
- Kafka를 기반으로, 기존 Kafka의 한계를 넘어서는 **진정한 클라우드 네이티브 이벤트 로그 시스템**에 대한 상상  
  
---  
  
### Kafka를 다시 만든다면?  
  
- 최근 KIP-1150(디스크 없는 Kafka)과 AutoMQ의 Kafka 포크가 발표되었고, 이는 S3와 같은 객체 스토리지와 Kafka를 통합하여 클라우드 환경에서 탄력성 개선과 비용 절감을 목표로 함  
- 기존 Kafka의 한계를 넘어서는 **클라우드 네이티브 이벤트 로그 시스템**을 상상하며 다양한 개선 사항을 제안함  
  
### 파티션 없는 구조 제안  
  
- 클라우드 객체 스토리지가 무한대 스토리지처럼 동작하기 때문에 **토픽 파티션**의 필요성이 감소함  
- 글로벌 메시지 순서 또는 동일 키를 가진 메시지 순서만 중요한 경우가 많음  
- 사용자에게 파티션 개념을 숨기고 단순화된 사용성을 제공할 수 있음  
  
### 키 중심 접근  
  
- 파티션 스캔이 아니라 **특정 키의 모든 메시지**에 빠르게 접근하고 재생할 수 있도록 설계 제안  
- 수백만 개의 엔터티 수준 스트림을 지원해 수요에 따라 소비자 수를 유동적으로 조정할 수 있음  
- 실패가 키 단위로 격리되므로 시스템 전체의 처리 효율성이 증가함  
- **이벤트 소싱**이나 **액터 모델 시스템**에 이상적인 구조임  
  
### 토픽 계층 구조 지원  
  
- Solace와 같은 시스템처럼 메시지 페이로드 일부를 구조화된 경로 형태의 토픽 식별자로 승격시켜 패턴 기반 구독을 가능하게 해야 함  
- 브로커가 전체 메시지를 파싱하지 않고도 효율적으로 구독 필터링을 지원할 수 있음  
  
### 동시성 제어 기능  
  
- 현재 Kafka는 기록 시 동시성 충돌을 방지할 방법이 없음  
- 키별로 낙관적 락(optimistic locking)을 지원하면, 메시지가 최신 상태를 본 후 기록되었는지 검증할 수 있음  
- **업데이트 손실 문제**를 방지할 수 있음  
  
### 브로커 사이드드 스키마 지원  
  
- Kafka는 현재 메시지를 단순 바이트 배열로 취급해 외부 스키마 레지스트리에 의존함  
- **스키마 일관성** 확보를 위해 브로커 차원에서 AsyncAPI 메타데이터 같은 스키마 정보를 기본 지원할 필요성 제안  
- 이를 통해 **Apache Iceberg** 같은 오픈 테이블 포맷에도 쉽게 연동할 수 있음  
  
### 확장성과 플러그인 구조  
  
- Postgres, Kubernetes처럼 **확장성**과 **플러그인 가능성**을 갖춘 구조를 제안  
- 프로토콜 인식 프록시(Kroxylicious 등)가 없이 브로커 단 필터나 변환을 쉽게 구현할 수 있어야 함  
- 속도 제한, 토픽 암호화, Iceberg 테이블 기반 백엔드 지원 등이 플러그인으로 구현 가능해야 함  
  
### 동기적 커밋 콜백  
  
- 현재 Kafka는 **최종 일관성**만 보장함  
- 프로듀서가 메시지를 전송한 후, 해당 파생 데이터가 업데이트되었는지 즉시 확인 가능한 구조 필요성 제안  
- **자기 쓰기 읽기 보장(read-your-own-writes)** 를 지원해 Kafka를 진정한 데이터베이스 로그로 사용할 수 있게 함  
  
### 스냅샷 기능  
  
- Kafka의 현재 압축(compaction)은 마지막 메시지만 남기는데, 이는 전체 상태를 포함하는 경우에만 유효함  
- 변경 사항만 기록하는 경우에는 키별로 이벤트를 모두 재생해야 하므로 시간이 증가함  
- 키 단위로 이벤트를 스냅샷으로 요약하는 **논리적 압축** 기능이 필요함  
  
### 멀티 테넌시 기본 지원  
  
- 모든 현대적 데이터 시스템은 **멀티 테넌시**를 기본으로 고려해야 함  
- 신규 테넌트 환경을 저렴하고 즉시 생성 가능하게 하고, 자원, 보안, 접근 제어를 철저히 분리해야 함  
  
### 기타 참고사항  
  
- 일부 기능은 S2(고카디널리티 스트림), Waltz(낙관적 락), Apache Pulsar(멀티 테넌시) 같은 시스템에서 이미 지원되고 있음  
- 하지만 제안된 모든 기능을 동시에 지원하는 오픈소스 시스템은 존재하지 않음  
- 이 글은 Confluent 소속 저자의 개인적 견해이며 공식 입장은 아님  
- 이론적으로는 **LSM 트리 기반** 아키텍처가 유력한 선택이 될 것이라고 언급함

## Comments



### Comment 37863

- Author: kaydash
- Created: 2025-04-27T00:12:43+09:00
- Points: 4

우린 이미 그걸 레디스라고 부르고 있어요

### Comment 37837

- Author: neo
- Created: 2025-04-26T10:23:33+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43790420) 
- 동의함. 특정 사용 사례에 대해 헤드 오브 라인 문제를 해결할 가치가 있음
  - 그러나 오늘날 모든 스트리밍 시스템(또는 우회 방법)은 메시지 키별 승인에 대해 O(n^2) 비용을 발생시킴
  - Pulsar와 같은 시스템이 이 기능을 위해 자주 사용됨
  - 이러한 복잡성은 매일 나타나지 않을 수 있지만, 나타날 경우 기다려야 함
  - 동료들과 함께 이 문제를 오랫동안 연구한 결과, 확장 가능한 메시지 키별 승인을 지원하기 위해 근본적인 아키텍처 변경이 필요하다는 결론에 도달함
  - 아키텍처는 정렬된 인덱스를 필요로 하며, 이는 n 메시지를 O(n log n)으로 처리함을 의미함
  - 이 주제에 대해 블로그를 쓰고 싶었지만 시간이 없었음
  - 메시지 키별 승인을 의존하려는 경우, 간헐적인 중단이나 지연을 예상해야 함

- NATS.io는 Kafka보다 사용하기 쉬우며, 파티션 제거, 키 기반 스트림 지원, 유연한 주제 계층 구조와 같은 여러 점을 이미 해결함

- Kafka와의 여정은 대부분 비슷함
  - 처음에는 "오, 확장 가능한 append-only 로그, 훌륭하고 간단함"이라고 생각함
  - 그러나 사용해보면 매우 복잡하다는 것을 깨닫게 됨

- 특정 사용 사례에서는, 생성 요청이 승인될 때 파생 데이터 뷰가 업데이트되었음을 보장할 수 있다면 유용할 것임
  - Kafka를 사용하지 말고, 하위 데이터 저장소에 직접 기록해야 함
  - 그러면 데이터가 커밋되었음을 알고, 쿼리할 수 있는 데이터베이스를 가질 수 있음

- 6년 전 이 질문을 했음
  - Rust로 작성하고 WASM을 활용하면 어떨까
  - 지난 6년 동안 이 작업을 진행해 왔음
  - 지난 2년 동안 Rust와 WASM을 사용하여 Flink를 구축해 왔음

- Kafka의 객체 저장소? 이는 지연 시간과 비용을 10배 증가시킬 것임
  - Kafka는 성공의 희생양임
  - 설계가 간단하고 우아하여, 원래 설계되지 않은 다양한 용도로 사용되고 있음
  - 물론 이러한 사용 사례에 완벽하지 않음

- "파티션 제거"와 "키 수준 스트림"에 대해
  - 스토리지 백엔드를 물리적 파티셔닝에 의존할 때, 이는 단순히 파티션을 키로, 키를 이벤트로 이름을 바꾸는 것과 같음

- Northguard를 주목해야 함
  - 이는 LinkedIn의 Kafka 재작성 이름으로, 약 일주일 전 스트림 처리 모임에서 발표됨

- Apache Kafka의 문제 중 얼마나 많은 것이 Apache Pulsar로 전환함으로써 해결되는지 궁금함
  - Kafka 학습을 건너뛰고 바로 Pulsar를 사용했음
  - 우리 사용 사례에 잘 맞음
  - 불만 없음
  - 그러나 왜 그렇게 적은 사람들이 사용하는지 궁금함

- 유용한 사고 실험임
  - Kafka를 새로운 것으로 대체해야 한다는 결론을 제안하는 답변들이 조용함
  - Kafka의 가장 큰 강점은 그 위에 구축된 넓고 유용한 생태계임
  - 이는 또한 약점임
  - 오늘날 처음부터 시작했다면 하지 않았을 디자인 결정을 일부 유지해야 함
  - 아니면 역호환성을 포기하고, 이미 가지고 있는 생태계를 재구성해야 함