집계 테이블 기반 “실시간 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깨진 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+1 로 60~90초 걸리던 조회를 개선한 경험이 있는데, MyBatis 환경이었다.\nJPA 환경에서 같은 문제를 재현하고 개선 전략을 수치로 비교하고 싶었다.
\n앨범 목록 API(앨범 + 대표 아티스트명 + 트랙 목록)를 만들었다. Album→Artist(ToOne),\nAlbum→Tracks(OneToMany) 모두 LAZY. 리포지토리는 findAll(Pageable) 하나 —\n코드 어디에도 반복 조회가 없다. 그런데:
앨범 30개 조회 = 쿼리 61개 이상 (목록 1 + artist 30 + tracks 30)쿼리는 리포지토리가 아니라 DTO 변환 중(지연 로딩 접근)에 나간다. 이게 N+1 이 늦게\n발견되는 이유다. MyBatis 는 resultMap 의 collection 쿼리가 XML 에 보이는데, JPA 는\ngetMainArtist().getName() 한 줄이 조용히 SELECT 를 만든다. 그리고 응답은 완전히\n정확하다 — N+1 은 틀린 결과가 아니라 느린 결과라서 기능 테스트로는 절대 안 잡힌다.
측정은 Hibernate Statistics(PrepareStatementCount)로 했다. “느린 것 같다”가 아니라\n쿼리 수를 직접 센다.
앨범 200 / 트랙 2,000 / 페이지 50, 3회 중앙값. 지표를 두 개 봤다 —\n쿼리 수와 함께 Album 엔티티 로드 수(EntityLoadCount).
\n| 전략 | \n쿼리 수 | \nAlbum 로드 수 | \n중앙값 | \n
|---|---|---|---|
| NAIVE (LAZY 순회) | \n102 | \n50 | \n110ms | \n
| fetch join | \n2 | \n200 | \n33ms | \n
@EntityGraph | \n2 | \n200 | \n22ms | \n
default_batch_fetch_size=100 | \n4 | \n50 | \n- | \n
쿼리 수만 보면 fetch join 완승(102→2)이다. 그런데 로드 수가 이상하다.\n페이지는 50개를 요청했는데 전체 200개를 로드했다.
\n컬렉션 fetch join 에 페이징을 걸면 Hibernate 는 LIMIT 을 SQL 로 못 내린다 —\n한 앨범이 트랙 수만큼 여러 행으로 뻥튀기된 결과에서 50행을 자르면 앨범 50개가\n아니기 때문이다. 대신 전체를 메모리에 올려놓고 자른다 (로그의 HHH90003004 경고).\n앨범이 200개라 33ms 지, 200만 개면 OOM 이다. @EntityGraph 도 SQL 형태가 같아\n함정을 그대로 공유한다 — 차이는 선언 방식이지 성능이 아니다.
페이징을 DB 에 남기는 컬렉션 해법은 batch fetch 뿐이었다 (쿼리 4개, 로드 50개).
\ndefault_batch_fetch_size 는 SessionFactory 설정이라 쿼리 단위로 켤 수 없다.\n그래서 벤치마크도 별도 테스트 컨텍스트가 필요했는데, 그 클래스에서 실행되는\n서비스 코드는 NAIVE 벤치마크와 한 글자도 다르지 않다. 같은 코드가 설정 한 줄로\n102쿼리 → 4쿼리가 된다. 동작 원리는 LAZY 프록시 초기화 시 영속성 컨텍스트의 같은 타입\n미초기화 프록시를 batch_size 개까지 모아 IN 쿼리 하나로 로딩하는 것.
open-in-view: false 전제라 DTO 변환은 @Transactional(readOnly=true) 안에서.\nOSIV 로 미루면 편하지만 트랜잭션 밖 커넥션 점유를 편의로 포장하는 것이다벤치마크 코드: AlbumFetchStrategyBenchmarkTest
\n