Redpanda Cloud Topics GA — S3에 직접 쓰는 스트리밍 엔진의 내부 아키텍처

• Redpanda의 Cloud Topics가 26.1 버전에서 GA(일반 출시)됨 — 데이터를 로컬 디스크 대신 S3/GCS 같은 오브젝트 스토리지에 직접 저장하는 새로운 토픽 타입
  • 같은 클러스터 안에서 일반 토픽과 Cloud Topics를 섞어 쓸 수 있음
  • 핵심은 Cross-AZ 네트워킹 비용 회피 — Raft로 복제하지 않고 오브젝트 스토리지에 직접 쓰므로 AZ 간 데이터 전송 비용이 사라짐

쓰기 경로: 비용 최적화

• 프로듀서 데이터가 들어오면 Kafka API 레이어를 거치지만, 로컬 Raft 로그에 전체 페이로드를 쓰지 않음
  • 메모리에서 시간(예: 0.25초) 또는 크기(예: 4MB) 기준으로 배칭
  • 모든 파티션과 토픽의 데이터를 동시에 모아서 하나의 L0 파일로 S3에 업로드 — PUT 요청 수를 대폭 줄임
• L0 파일이 오브젝트 스토리지에 안전하게 저장되면, 각 파티션의 Raft 로그에는 플레이스홀더 배치(파일명 + 오프셋)만 복제
  • 그 후 프로듀서에 ACK 반환
  • 트랜잭션과 멱등성(idempotency) 보장은 이 플레이스홀더가 기존 Raft 경로를 재사용하기 때문에 그대로 유지됨

읽기 경로: L0 → L1 최적화

• 대부분의 스트리밍 워크로드(tailing consumer)는 메모리 캐시에서 직접 읽으므로 지연이 낮음
• 문제는 캐시 미스 시 L0 파일에서 읽어야 하는 경우
  • L0는 여러 파티션 데이터가 뒤섞여 있어서 특정 파티션 히스토리를 읽으려면 scattered read 발생
• Reconciler라는 백그라운드 프로세스가 L0 데이터를 파티션별로 재정렬해서 L1 파일로 재작성
  • L1 파일은 훨씬 크고, 같은 파티션 범위가 물리적으로 함께 있고, 오프셋순 정렬됨
  • 읽기 시 Last Reconciled Offset 기준으로 L0/L1 분기 — 최근 데이터는 L0(또는 캐시), 과거 데이터는 L1에서 고효율 스트리밍

---

기술 맥락

• Kafka 진영에서 Tiered Storage(KIP-405)가 "차가운 데이터를 오브젝트 스토리지로 내리는" 접근이었다면, Redpanda Cloud Topics는 아예 처음부터 오브젝트 스토리지에 쓰는 거예요. 설계 철학이 근본적으로 다르거든요
• Cross-AZ 복제 비용이 왜 중요하냐면, AWS에서 AZ 간 데이터 전송이 GB당 $0.01인데, 대량 스트리밍에서는 이게 엄청 쌓여요. Raft 3-way 복제를 하면 같은 데이터가 AZ를 3번 넘나드는데, S3에 한 번 쓰면 S3 자체가 AZ 간 내구성을 보장하니까 이 비용이 사라지는 거
• L0/L1 구조는 LSM-tree의 compaction과 비슷한 패턴이에요. 쓰기 최적화(L0, 여러 파티션 혼합)와 읽기 최적화(L1, 파티션별 정렬)를 분리하되, 백그라운드 reconciler가 점진적으로 변환하는 방식. 실시간 tailing은 메모리 캐시로 처리하고, 과거 데이터 조회만 L1에서 읽으니 대부분의 워크로드에서 지연 영향이 거의 없음