ISR 축소/확장 — replica.lag.time.max.ms가 판정하는 두 가지 조건
Kafka Streams Punctuate 및 ISR 축소/확장 메커니즘 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka 공식 Javadoc(PunctuationType) + KIP-501 + Confluent 기술 문서 KIP-501 및 replica.lag.time.max.ms 관련 커뮤니티 기술 문서
이 모듈을 다 읽으면
- 팔로워가 ISR에서 제외되는 두 가지 조건을 구체적으로 설명할 수 있다
- replica.lag.time.max.ms 값을 너무 짧게/길게 잡았을 때의 트레이드오프를 설명할 수 있다
kafka-learn-09/33에서 다룬 ISR(동기화된 레플리카 집합) 개념을 전제로, 실제로 어떤 팔로워가 ISR에서 빠지고(축소) 다시 들어오는지(확장)를 판정하는 구체적인 시간 기준 replica.lag.time.max.ms의 동작을 정리한다.
ISR 축소 — 두 가지 조건 중 하나라도 만족하면 제외
팔로워가 리더의 ISR에 남아있으려면 두 조건을 모두 만족해야 한다 — (1) replica.lag.time.max.ms(기본값 30000ms=30초) 이내에 리더에게 fetch 요청을 보냈어야 하고, (2) 그 시간 이내에 리더가 그 시점 기준으로 갖고 있던 메시지까지 전부 따라잡았어야 한다. 이 중 하나라도 어기면(fetch 요청 자체를 이 기간 안에 안 보냈거나, 요청은 보냈지만 계속 따라잡지 못하고 있거나) 그 팔로워는 '뒤처졌다'고 판단돼 ISR에서 제외된다.
핵심 포인트
- ISR 유지 조건 2가지: (1) replica.lag.time.max.ms(기본 30초) 이내 fetch 요청 전송, (2) 그 시간 이내 리더의 최신 데이터까지 따라잡기 — 둘 중 하나라도 어기면 ISR에서 제외
- fetch 요청 자체를 안 보내는 경우(네트워크 단절 등)와, 요청은 보내지만 계속 못 따라잡는 경우(느린 디스크 등) 둘 다 축소를 유발할 수 있음
ISR 확장 — 다시 따라잡으면 자동으로 복귀
장애나 지연으로 ISR에서 빠졌던 팔로워도, 다시 온라인이 되어 리더로부터 밀린 메시지를 계속 복제해나가다가 replica.lag.time.max.ms 이내로 따라잡는 상태에 도달하면 자동으로 ISR에 다시 편입된다 — 사람이 수동으로 개입할 필요 없이 정상적인 fetch/복제 과정 자체가 ISR 재편입의 메커니즘이다.
핵심 포인트
- ISR에서 빠졌던 팔로워도 정상적으로 fetch를 재개해 따라잡으면 자동으로 ISR에 재편입 — 수동 개입 불필요
값을 너무 짧게/길게 잡았을 때의 트레이드오프
replica.lag.time.max.ms를 너무 짧게 잡으면, 일시적인 네트워크 지연이나 순간적인 GC 정지처럼 실제로는 문제없는 팔로워까지 자주 ISR에서 빠졌다 들어왔다를 반복하게 돼(잦은 ISR 축소/확장), acks=all을 쓰는 프로듀서의 쓰기 지연이 불안정해지고 불필요한 컨트롤러 메타데이터 갱신 부하도 늘어난다. 반대로 너무 길게 잡으면, 실제로 뒤처진 팔로워를 너무 오래 ISR에 남겨둬 그 팔로워가 리더가 될 경우(unclean leader election이 아니더라도) 실제로는 최신이 아닌 상태로 승격될 위험이 커진다 — 두 극단 사이에서 클러스터의 네트워크 안정성과 내구성 요구사항에 맞게 균형을 잡아야 하는 설정이다.
핵심 포인트
- 너무 짧으면 일시적 지연에도 잦은 ISR 축소/확장이 발생 — acks=all 쓰기 지연 불안정, 컨트롤러 메타데이터 갱신 부하 증가
- 너무 길면 실제로 뒤처진 팔로워를 오래 ISR에 남겨둬, 그 팔로워가 리더로 승격될 때 최신이 아닌 상태로 승격될 위험 증가