Diskless Kafka: 브로커가 데이터를 소유하지 않으면 무엇이 달라질까?

Diskless Kafka는 Kafka 클라이언트 API를 유지하면서 메시지의 영속 저장을 브로커 로컬 로그에서 공유 객체 스토리지로 옮김. 브로커의 연산 자원을 조정할 때 저장 데이터까지 이동해야 하는 결합을 줄임 객체 스토리지에는 메시지 바이트를 저장하고, 강한 일관성을 갖는 메타데이터가 순서, 오프셋, 커밋 상태를 결정함. 복제와 합의가 없어지는 것이 아니라, 대용량 메시지 대신 작은 메타데이터를 대상으로 수행됨 여러 파티션의 데이터를 하나의 객체로 묶으면 저장 요청 비용을 줄일 수 있지만, 배치 대기와 객체 업로드가 지연 시간을 늘림. 일부 구현은 별도 WAL로 쓰기 확인 경로를 단축함 KIP-1150은 승인됐지만, 2026년 8월 25일 기준 핵심 구현인 KIP-1163과 KIP-1164는 논의 중이며 Apache Kafka의 네이티브 Diskless Topics는 아직 정식 제공 기능이 아님 높은 처리량, 긴 보존 기간, 일정 수준의 지연 허용이 결합된 워크로드에 특히 적합함. 모든 토픽을 대체하기보다는 토픽별로 로컬, 계층형, 디스크리스 저장 방식을 선택하고 쓰기 확인 지연, 복구 동작, 기능 지원, 총비용을 비교하는 접근이 중요함 기존 Kafka에서 브로커와 로그가 결합되는 이유 Kafka는 순차 I/O와 배치 처리를 중심으로 설계됨. 프로듀서는 레코드를 배치로 묶고, 브로커는 순서가 있는 로그 세그먼트에 추가하며, 컨슈머는 연속된 범위를 읽음 운영체제의 페이지 캐시를 활용하고 가능한 경우 sendfile 같은 제로카피 기법을 사용함 작은 작업 다수를 큰 순차 읽기와 쓰기로 바꾸면 저장장치와 운영체제가 효율적으로 처리할 수 있음. Kafka 설계 문서에서 이 원리를 확인할 수 있음 파티션 리더는 레코드를 받아 오프셋을 할당하고 로컬 로그에 기록하며, 팔로워는 리더에서 배치를 가져와 자신의 저장소에 기록함 acks=all이면 필요한 복제가 이루어진 뒤 프로듀서에 성공 응답을 보냄 배치는 네트워크와 시스템 호출 부담을 줄이고, 페이지 캐시는 최근 데이터를 물리 디스크 읽기 없이 제공할 수 있음 브로커는 파티션 처리뿐 아니라 로컬 로그와 복제본 상태도 소유함. 파티션을 다른 브로커로 옮기려면 데이터도 함께 이동해야 하는 경우가 많음 클라우드가 바꾼 저장 비용과 확장 조건 3개 가용 영역에 걸친 클러스터에서는 리더에 저장한 레코드를 다른 영역의 팔로워로 복사함. 복제본 배치와 확인 응답 설정이 적절하면 ...