- 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 트리 기반 아키텍처가 유력한 선택이 될 것이라고 언급함