KIP-441 — 새 인스턴스를 워밍업시켜 스케일아웃 다운타임을 없앤다
Kafka Streams Foreign-Key Join(KIP-213) 및 KIP-441(Smooth Scaling Out) 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Apache Kafka KIP-213(Support non-key joining in KTable), KIP-441(Smooth Scaling Out for Kafka Streams), Confluent 공식 블로그 Apache Kafka KIP-441: Smooth Scaling Out for Kafka Streams
이 모듈을 다 읽으면
- 새 인스턴스에 곧바로 active task를 배정하는 방식이 왜 몇 시간짜리 다운타임을 만들 수 있는지 설명할 수 있다
- 워밍업(warmup) 태스크와 probing rebalance가 이 문제를 2단계로 어떻게 해결하는지 설명할 수 있다
kafka-learn-60에서 다룬 num.standby.replicas(장애 대비용 상시 스탠바이)를 전제로, KIP-441이 그와 비슷한 스탠바이 메커니즘을 '스케일아웃 순간'에도 임시로 재활용해 다운타임을 없애는 방법을 정리한다.
문제 — 새 인스턴스가 상태 태스크를 받으면 changelog를 처음부터 다 재생해야 한다
Kafka Streams 클러스터에 새 인스턴스가 합류할 때, 상태를 가진(stateful) 태스크를 배정받으면 그 인스턴스는 실제 처리를 시작하기 전에 changelog를 최신 시점까지 따라잡아야 한다. 배정 결정이 이 복구 비용을 고려하지 않으면, 어떤 태스크는 상태 저장소를 처음부터 재구축하느라 몇 시간씩 멈춰 있을 수 있다 — 빠른 리밸런싱과 실제 처리 가능 상태 사이의 트레이드오프를 무시한 결과다.
핵심 포인트
- 새 인스턴스가 stateful 태스크를 배정받으면 처리 시작 전 changelog를 최신까지 따라잡아야 함
- 배정 결정이 이 복구 비용을 무시하면 어떤 태스크는 상태 저장소 재구축에 몇 시간씩 걸려 멈춰 있을 수 있음
2단계 해법 — 워밍업(standby로 우선 배정) 후 probing rebalance로 승격
KIP-441은 임시 스탠바이 사본을 이용한 2단계 접근을 쓴다. 1단계(워밍업)에서는 새 인스턴스가 앞으로 맡게 될 태스크를 곧바로 active로 받는 게 아니라, 먼저 standby task로 배정받아 백그라운드에서 상태를 따라잡는다 — 즉 태스크 이동이 '목적지 인스턴스에 standby로 배정 → 따라잡을 때까지 대기 → 다 따라잡으면 리밸런싱'의 순서로 이뤄진다. 이 동안 원래 active를 갖고 있던 인스턴스는 계속 active 배정을 유지해 서비스가 끊기지 않는다. 2단계에서는 새 인스턴스가 acceptable_recovery_lag(허용 가능한 지연) 설정 안으로 따라잡히면, probing rebalance(설정된 주기로 토폴로지 변경과 무관하게 실행되는 리밸런싱)가 이를 감지해 워밍업 태스크를 active로 승격시킨다.
핵심 포인트
- 1단계(워밍업): 새 인스턴스가 곧바로 active가 아니라 standby로 태스크를 받아 백그라운드에서 changelog를 따라잡음 — 그동안 기존 active 소유자는 계속 처리 유지
- 2단계: acceptable_recovery_lag 안으로 따라잡히면 probing rebalance(주기적 리밸런싱)가 이를 감지해 워밍업 태스크를 active로 승격