깨진 JSON 메시지 하나가 파티션에 들어오면 무슨 일이 벌어지나.
\n무한 재시도 설정이라면 그 메시지가 파티션 전체를 막는다(head-of-line blocking).\n뒤에 쌓인 정상 메시지 수만 건이 한 건 때문에 처리되지 않는다. 이게 poison pill 이다.
\nM1 입수에서 “재시도 가능(DB 장애) vs 불가(검증 실패)“를 갈랐던 원칙을 그대로 재적용했다.
\n| 실패 유형 | \n판단 | \n처리 | \n
|---|---|---|
| 역직렬화 실패 | \n백 번 다시 읽어도 같은 바이트는 같은 실패 | \n재시도 없이 즉시 DLQ | \n
| 처리 실패 (DB 등) | \n일시적일 수 있다 | \n지수 backoff(0.5s→1s→2s) 3회 → DLQ | \n
ErrorHandlingDeserializer 가 역직렬화 실패를 예외가 아니라 “값”(null + 원인 헤더)으로\n바꿔준다 — 리스너까지 도달해야 우리가 제어권을 갖는다.DLQ 발행에 기존 JsonSerializer 템플릿을 재사용했더니, 깨진 원본 byte[] 가\nbase64 문자열로 이중 인코딩되어 실렸다. 원본 보존이 DLQ 의 존재 이유인데 증거를\n훼손한 셈. DeadLetterPublishingRecoverer 에 Map<Class<?>, KafkaOperations> 로\nbyte[] 전용 템플릿(ByteArraySerializer)을 따로 매핑해야 한다.
1번을 고치며 DLQ 템플릿의 key 직렬화까지 ByteArray 로 바꿨더니 이번엔 키에서 터졌다.\n역직렬화가 실패한 것은 value 뿐이고 key 는 여전히 String 이다. 이 실패가 연쇄를\n일으켰다 — DLQ 발행 실패 → 에러 핸들러 실패 → 배치 전체 재시도. DLQ 경로 자체가\npoison pill 이 될 수 있다는 것을 몸으로 배웠다.
\n배치 리스너에서 예외를 그냥 던지면 배치 전체가 실패 처리된다.\nBatchListenerFailedException 으로 실패 인덱스를 지정하지 않으면, 깨진 메시지\n앞의 정상 메시지까지 도매금으로 묶인다. “깨진 메시지가 섞인 배치에서 정상 메시지는\n살아남는다”를 테스트로 고정해 두었다.
KafkaHeaders.DLT_* 로 바꿔 단다. 검증할 때 이걸 몰라서 또 한 번 헤맸다상세: ADR-0004
\n재생 이벤트(초당 수백 건)를 소비해 곡별 재생수를 집계한다. 재생수는 카운터다 —\n두 번 더하면 그냥 틀리고, 틀렸다는 사실조차 알기 어렵다.
\n그리고 Kafka 는 at-least-once 다. 리밸런싱, 오프셋 커밋 전 종료, 운영자의 오프셋 리셋,\nmax.poll.interval.ms 초과 — 컨슈머는 정상 동작 중에도 같은 메시지를 다시 받는다.\n중복 소비는 장애가 아니라 전제 조건이다.
”enable.idempotence=true 켰으니 안전하다”는 말이 자주 나온다. 아니다.
| 설정 | \n막는 것 | \n못 막는 것 | \n
|---|---|---|
| 프로듀서 멱등성 | \n프로듀서 재시도로 인한 브로커 측 중복 저장 | \n컨슈머 재소비 | \n
| Kafka 트랜잭션(EOS) | \nKafka→Kafka 경로의 중복 | \n외부 DB 쓰기 | \n
컨슈머가 DB 에 쓰는 순간, Kafka 가 주는 보장은 끝난다. 멱등성은 우리 몫이다.
\n| 대안 | \n판단 | \n
|---|---|
| A. eventId UNIQUE + 신규분만 집계 | \n✅ 채택 | \n
| B. 오프셋을 DB 에 저장, 집계와 한 트랜잭션 | \n이론상 가장 정확하지만 기각 | \n
| C. Kafka EOS | \n외부 DB 라 적용 불가 (오해 방지용으로 문서에 남김) | \n
| D. 중복 허용 + 주기 재집계 | \n규모가 커지면 A 와 조합 재검토 | \n
B 를 기각한 결정타는 성능이 아니라 검증 가능성이었다. A 는 중복을 일부러\n만들어(오프셋 되감기) 테스트로 증명할 수 있다. B 는 리밸런싱 시나리오 재현이 훨씬\n어려워 “아마 맞을 것”에 기대게 된다. 덤으로 B 는 kafka-consumer-groups.sh 로\nlag 을 보는 표준 운영 도구를 포기해야 한다.
1. 배치 내부 중복 제거 (LinkedHashMap)\n2. 기처리 eventId 선조회 SELECT ... WHERE event_id IN (...)\n3. 신규분만 원본 적재 INSERT IGNORE batch\n4. 트랙별 델타 합산 후 UPSERT play_count = play_count + VALUES(...)rewriteBatchedStatements\n때문에 affected rows 가 -2 로 뭉개질 수 있다. 집계 정확성이 드라이버 설정에\n의존하는 것은 수용 불가. 선조회가 SELECT 한 번 비싸지만 결정적이다.원본 이벤트는 초당 500건이면 하루 4,300만 행이라 TTL 로 지워야 한다.\n그런데 원본 행이 곧 멱등성 판정 근거다 — 지운 뒤 도착한 중복은 신규로 집계된다.
\nTTL(play_event) > retention.ms(play-events)브로커가 이미 지운 메시지는 재소비될 수 없으므로, 이 부등식이 성립하면 중복이 도착할 수\n있는 기간 동안 판정 근거가 반드시 남아 있다. 처음엔 문서에 “두 값을 같이 움직여야 한다”고\n적었는데, 사람이 기억해야 하는 제약은 언젠가 깨진다. 그래서 기동 시점에 검증해\n어기면 애플리케이션이 뜨지 않게 만들었다(fail fast).
\nAdminClient.alterConsumerGroupOffsets 로 오프셋을 0으로 되감아 120건을 전량\n재소비시키고 카운터 불변을 단언했다. 핵심은 duplicate 메트릭을 함께 단언한 것 —\n이게 없으면 “재소비가 안 일어나서 그대로”인 경우와 구분되지 않는다.\n테스트가 실제로 문제를 만들었는지부터 확인해야 다음 단언이 의미를 갖는다.
덤으로 얻은 교훈: @BeforeEach 에서 DB 를 비워도 토픽의 메시지는 남는다.\n오프셋을 되감으면 다른 테스트가 발행한 이벤트까지 살아난다. 이벤트 기반 시스템에서\n“DB 정리 = 깨끗한 상태”는 성립하지 않는다 — 운영에서도 똑같다.
상세: ADR-0003
\n집계 테이블 기반 “실시간 TOP 100 차트” API. 모든 사용자가 같은 것을 본다 —\n전형적인 읽기 편중 + 핫키 하나 워크로드다. 결정이 세 겹이었다.
\n“Redis 차트면 ZINCRBY + ZREVRANGE 지” 싶었는데, 기각했다. 결정타는 멱등성이다.
\n컨슈머가 같은 배치를 재처리하면 DB 는 event_id UNIQUE 로 걸러내지만\nZINCRBY 는 그대로 두 번 더해진다. 04편에서 세운 멱등성 체계 밖에 비원자\n이중 쓰기 경로를 만드는 구조다. Redis 에도 중복 판정을 만들면 되지만, 그건 같은\n체계를 두 번 구현하는 것이다. DB 집계(TOP 100 쿼리) + 캐시로 갔다.\n설계 결정은 독립적이지 않다 — 앞의 결정이 뒤의 선택지를 제약한다.
Write-through 는 기각: 쓰기 주체(컨슈머, 초당 수백 건)와 읽기 주체(차트 API)가 달라서,\n아무도 안 읽는 사이에도 집계마다 TOP 100 재계산을 강요하는 꼴이다.\n차트는 엔티티 캐시가 아니라 쿼리 결과 캐시라 읽기 쪽에서 채우는 게 자연스럽다.
\n물리 TTL 하나만 쓰면 만료 순간 동시 요청 전부가 DB 로 몰린다.\n캐시가 가장 필요한 순간에 캐시가 없다.
\nsoft TTL 30s : 논리 만료. 지나면 stale — 즉시 응답하고 갱신은 백그라운드 1개 스레드만\nhard TTL 120s : 물리 만료. Redis 가 실제로 지운다\n완전 미스 : ReentrantLock 단일 비행 — 1개 요청만 DB, 나머지는 대기 후 재확인\nRedis 장애 : DB 직접 조회 폴백 — 캐시는 성능 장치지 가용성 의존점이 아니다soft >= hard 설정은 기동 실패로 막았다 — stale 서빙 창이 없으면 이 구조가 무의미해진다.\n04편의 TTL 부등식과 같은 패턴: 설정값을 안전성 조건으로 다룬다.| 검증 대상 | \n방법 | \n
|---|---|
| 캐시 히트 | \nDB 를 바꾼 뒤 응답이 안 바뀌는 것으로 증명 (호출 횟수 카운팅보다 견고) | \n
| stale 동작 | \n30초 대기 대신 generatedAt 을 과거로 조작한 캐시를 주입 | \n
| 단일 비행 | \n빈 캐시에 10 스레드 동시 진입 → DB 호출 정확히 1회 단언 | \n
| Redis 장애 | \n컨테이너를 멈추지 않는다 — 빈 포트를 바라보는 커넥션 팩토리를 조립. 장애는 기다리는 게 아니라 만드는 것 | \n
k6 로 캐시 ON/OFF 를 비교했다 (별도 글 예정인 M4 부하 테스트의 일부).
\n| 시나리오 | \n처리량 | \np95 | \n
|---|---|---|
| 50 VU, 캐시 ON | \n479 rps | \n4.2ms | \n
| 50 VU, 캐시 OFF | \n478 rps | \n5.0ms | \n
| 200 VU 풀부하, 캐시 ON | \n4,167 rps | \n55.7ms | \n
| 200 VU 풀부하, 캐시 OFF | \n3,562 rps | \n99.3ms | \n
| Redis 정지 (캐시 ON) | \n81 rps | \n523ms · 실패율 0% | \n
저부하에서는 캐시가 무의미했다. 인덱스 타고 버퍼 풀에 올라간 DB 도 p95 5ms 다.\n“DB 가 느려서 캐시를 얹는다”는 전제가 이 규모에선 측정으로 기각된 것.\n캐시의 진짜 역할은 고부하에서 드러났다 — 응답을 빠르게 하는 게 아니라\nDB 를 병목에서 제거한다 (p95 43% 감소, 남은 지연은 웹 계층으로 병목 이동).
\nRedis 를 정지시킨 상태에서도 1,650 요청 실패율 0% — 다만 전 요청이 타임아웃\n500ms 를 태우고 폴백했다. “다음 개선은 서킷 브레이커”라는 결론까지가 측정의 산출물이다.
\n상세: ADR-0005
\n