Kafka를 처음부터 다시 만들 수 있다면 어떨까?
(morling.dev)- 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 트리 기반 아키텍처가 유력한 선택이 될 것이라고 언급함
Hacker News 의견
-
동의함. 특정 사용 사례에 대해 헤드 오브 라인 문제를 해결할 가치가 있음
- 그러나 오늘날 모든 스트리밍 시스템(또는 우회 방법)은 메시지 키별 승인에 대해 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의 가장 큰 강점은 그 위에 구축된 넓고 유용한 생태계임
- 이는 또한 약점임
- 오늘날 처음부터 시작했다면 하지 않았을 디자인 결정을 일부 유지해야 함
- 아니면 역호환성을 포기하고, 이미 가지고 있는 생태계를 재구성해야 함