クイズ：プロデューサーと冪等性

프로듀서가 네트워크 오류로 응답을 못 받았을 때 설계 문서가 말하는 근본 문제는?

• 브로커가 이미 그 메시지를 버렸으므로 반드시 다시 보내야 한다
• 오류가 메시지 커밋 전에 난 것인지 후에 난 것인지 프로듀서가 알 수 없다
• 재시도하면 순번이 어긋나 브로커가 이후 메시지를 전부 거부한다
• 컨슈머가 그 메시지를 이미 읽었을 수 있어 되감아야 한다

acks=0 에 대한 프로듀서 설정 문서의 설명으로 맞는 것은?

• 리더가 로그에 쓰면 즉시 답하므로 팔로워 복제 전 리더 장애에 취약하다
• ISR 전체의 확인을 기다려 가장 강한 보장을 준다
• 서버 확인을 전혀 기다리지 않아 받았다는 보장이 없고 retries 도 효과가 없다
• 리더와 팔로워 하나의 확인을 기다리는 절충안이다

acks=1 을 명시하고 enable.idempotence 는 건드리지 않았다. 문서가 정한 결과는?

• 멱등이 조용히 꺼진다 — 충돌하는 설정이 있고 멱등을 명시적으로 켜지 않았기 때문
• ConfigException 으로 프로듀서가 뜨지 않는다
• 멱등이 유지되고 acks 만 all 로 강제된다
• 멱등은 유지되지만 재시도가 0 으로 바뀐다

request.timeout.ms 를 브로커의 replica.lag.time.max.ms 보다 크게 두라는 문서의 이유는?

• 작으면 컨슈머 그룹 리밸런스가 잦아진다
• 작으면 불필요한 프로듀서 재시도로 메시지가 중복될 가능성이 커진다
• 작으면 브로커가 ISR 에서 리더를 제외해 쓰기가 멈춘다
• 작으면 delivery.timeout.ms 가 자동으로 줄어든다

멱등 프로듀서로 보냈는데도 같은 결제가 두 벌 있고, 덤프에서 두 배치의 producerId 가 서로 다르다. 가장 그럴듯한 원인은?

• 브로커가 재시도를 걸러 내지 못하는 버그다
• max.in.flight.requests.per.connection 이 5 를 넘어 순번이 섞였다
• 애플리케이션이 실패를 보고받고 새 프로듀서(새 세션)로 다시 보냈다 — 멱등은 세션 안에서만 유효하다
• acks=all 이라 리더와 팔로워가 각각 한 벌씩 썼다

delivery.timeout.ms 와 request.timeout.ms·linger.ms 사이에 문서가 요구하는 관계는?

• delivery.timeout.ms 는 request.timeout.ms 와 linger.ms 의 합 이상이어야 한다
• delivery.timeout.ms 는 request.timeout.ms 보다 작아야 재시도가 빨리 끝난다
• 세 값은 서로 독립이라 아무 관계가 없다
• linger.ms 는 delivery.timeout.ms 의 절반 이하여야 한다