num.standby.replicas — Kafka Streams 상태 저장소의 핫 스탠바이
KIP-848 새 컨슈머 그룹 프로토콜 및 Kafka Streams num.standby.replicas 공식 문서 종합 (웹 리서치, 2026) — KIP-848: The Next Generation of the Consumer Rebalance Protocol + Confluent 공식 문서(streams/sizing, streams/developer-guide/config-streams) Confluent 공식 문서 Plan and Size Capacity for Kafka Streams 및 Configure a Kafka Streams Application
이 모듈을 다 읽으면
- standby replica가 어떻게 state store 복구 시간을 줄이는지 설명할 수 있다
- standby replica 개수를 늘릴 때 필요한 자원 비용을 설명할 수 있다
kafka-learn-37에서 다룬 Kafka Streams의 state store+changelog 토픽 기반 상태 복구를 전제로, 장애 발생 후 복구 시간을 아예 줄여버리는 '핫 스탠바이' 방식인 num.standby.replicas 설정을 정리한다.
기본값 0 — 장애 시 changelog에서 처음부터 복원
num.standby.replicas의 기본값은 0으로, 이 경우 태스크가 다른 인스턴스로 옮겨가면 그 인스턴스는 changelog 토픽 전체를 처음부터 읽어 로컬 state store를 새로 복원해야 한다 — 상태 크기가 클수록 이 복원 시간이 길어져 그동안 해당 파티션의 처리가 멈춘다.
핵심 포인트
- num.standby.replicas 기본값은 0 — 장애 시 옮겨간 인스턴스가 changelog 전체를 처음부터 읽어 state store를 복원해야 함
- 상태 크기가 클수록 복원 시간이 길어져 그동안 해당 파티션 처리가 중단됨
standby replica — 다른 노드에서 미리 따라잡고 있는 그림자 사본
num.standby.replicas를 1 이상으로 설정하면, 지정한 개수만큼 활성 태스크의 state store를 다른 인스턴스에 그림자 사본(standby task)으로 미리 만들어두고, 이 사본들이 changelog 토픽을 지속적으로 구독해 활성 상태와 계속 맞춰나간다. 장애가 나면 Kafka Streams는 이 standby task를 이미 갖고 있던 인스턴스로 태스크를 우선 재배정하려 시도한다 — 이미 대부분 따라잡은 상태이므로 changelog를 처음부터 읽는 복원 과정이 크게 단축돼(또는 거의 없어져) 페일오버 지연시간이 최소화된다.
핵심 포인트
- num.standby.replicas≥1이면 활성 태스크의 state store를 다른 인스턴스에 그림자 사본(standby task)으로 미리 만들어 changelog로 계속 따라잡게 함
- 장애 시 standby task를 가진 인스턴스로 우선 재배정 — 이미 따라잡은 상태라 changelog 복원 과정이 크게 단축돼 페일오버 지연 최소화
대가 — 저장 공간과 인스턴스 수의 배수 증가
standby replica 개수를 늘릴수록 클라이언트(Kafka Streams 인스턴스) 쪽 저장 공간 요구량도 그만큼 늘어난다 — 예를 들어 standby 1개를 설정하면 상태 저장에 필요한 공간이 2배가 된다. 또한 n개의 standby replica를 설정하려면 그 상태를 분산해서 유지할 물리적으로 별도인 인스턴스가 최소 n+1개는 있어야 한다 — 즉 페일오버 속도 개선은 저장 공간과 인스턴스 프로비저닝 비용 증가라는 대가를 치르고 얻는 트레이드오프다.
핵심 포인트
- standby 1개 설정 시 상태 저장 공간 요구량이 2배로 증가
- n개의 standby replica를 두려면 물리적으로 별도인 인스턴스가 최소 n+1개 필요 — 페일오버 속도 개선은 저장공간+인스턴스 비용 증가와의 트레이드오프