acks (min.insync.replicas)

프로듀서가 "이 메시지는 확실히 저장됐다"고 인정받는 조건을 정하는 설정. 처리량과 내구성 사이의 손잡이다.

세 가지 값

acks=0 — 브로커 응답을 아예 안 기다린다
- 가장 빠르지만 브로커가 못 받아도 프로듀서는 모른다 → 유실
acks=1 — 리더 복제본이 자기 로그에 쓰면 인정
- 리더가 쓰고 나서 팔로워에 복제되기 전에 죽으면 → 유실
acks=all — ISR(리더를 따라잡은 복제본 집합) 전부가 받아야 인정
(=-1) — 가장 안전. 대신 왕복이 더 필요해 지연이 는다

`acks=all` 하나로는 부족하다 — 함정

acks=all은 "ISR 전부가 받아야 한다"인데, ISR이 몇 개인지는 말하지 않는다. 장애로 팔로워가 전부 뒤처져 ISR에 리더 하나만 남으면, acks=all이 사실상 acks=1이 된다. 그 상태에서 리더가 죽으면 데이터가 사라진다.

그래서 짝이 되는 설정이 min.insync.replicas 다.

acks=all + min.insync.replicas=2
ISR이 2개 미만이면 브로커가 쓰기 자체를 거부한다
- (NotEnoughReplicasException)
조용히 유실되는 대신 명시적으로 실패한다

"조용한 유실보다 명시적 실패가 낫다" 는 것이 이 조합의 사고방식이다. 복제 3 + min.insync.replicas=2 + acks=all이 흔한 표준 구성이다 — 브로커 한 대가 죽어도 쓰기가 계속되고, 두 대가 죽으면 멈춘다.

왜 3-2 조합인가

복제 3, min.insync=2
  정상        ISR 3개 → 쓰기 OK
  1대 장애    ISR 2개 → 쓰기 OK (가용성 유지)
  2대 장애    ISR 1개 → 쓰기 거부 (일관성 우선)

복제 3에 min.insync=3으로 잡으면 한 대만 죽어도 쓰기가 멈춘다 — 가용성이 너무 낮다. 반대로 min.insync=1이면 보호 효과가 없다.

함께 보는 설정

enable.idempotence=true — 프로듀서가 시퀀스 번호를 붙여, 네트워크 재전송으로 인한 중복 쓰기를 브로커가 걸러 준다. 최신 클라이언트에서는 기본이다.
retries — 일시 오류 재시도 횟수. 멱등 프로듀서가 아니면 재시도가 곧 중복이 된다.

면접 함정

❌ "acks=all이면 유실이 없다" → min.insync.replicas가 없으면 ISR이 1로 줄었을 때 무방비다.
❌ "acks=all이면 정확히 한 번이다" → 내구성 설정이지 중복 방지가 아니다. 중복은 멱등 프로듀서·멱등 컨슈머의 몫이다.

프로듀서 설정 묶음

acks=all                      # ISR 전부가 받아야 인정
min.insync.replicas=2         # (토픽 설정) ISR이 2 미만이면 쓰기 거부
enable.idempotence=true       # 재전송으로 인한 중복 쓰기를 브로커가 제거
retries=2147483647            # 멱등 프로듀서와 함께면 재시도가 안전해진다
max.in.flight.requests.per.connection=5   # 멱등 모드에서 순서가 보장되는 상한

enable.idempotence=true를 켜면 뒤의 세 값이 자동으로 안전한 조합으로 맞춰진다. 최신 클라이언트에서는 이게 기본값이다.

거부되면 무엇이 보이나

org.apache.kafka.common.errors.NotEnoughReplicasException:

Messages are rejected since there are fewer in-sync replicas than required

이 예외는 장애가 아니라 설계대로 동작한 것이다. 조용히 유실되는 대신 명시적으로 실패했다는 신호이므로, 여기서 재시도·백프레셔로 받아 내는 것이 애플리케이션의 몫이다.