퀴즈: 프로듀서와 멱등

문항 6개. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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