[WIL] Redis Hot Key 를 공부하면서 배운 것들

1. Redis Hot Key

Hot Key는 “키가 하나냐 여러 개냐”의 문제가 아니라, 특정 key에 요청이 과도하게 집중되는가의 문제다.

즉, 현재 구조처럼 ranking:all:yyyyMMdd 하나의 ZSET에 하루치 모든 상품 이벤트가 몰리면, 그 key를 처리하는 Redis 노드가 병목이 된다.

핵심은 이거다.

• key 수가 적다고 hot key가 없는 것이 아님
• 오히려 모든 트래픽이 단일 key로 집중되면 구조적으로 hot key
• Redis는 단일 스레드 기반으로 명령을 처리하므로, 특정 key에 write가 몰리면 지연이 누적될 수 있음

---

2. ZINCRBY와 write 집중

현재 구조는 이벤트 1건마다 ZINCRBY를 호출한다.

예를 들어 조회 이벤트가 매우 많이 발생하는 인기 상품이 있으면:

• Kafka 메시지 1건 처리
• 점수 계산 1회
• Redis ZINCRBY 1회

이 흐름이 반복된다.

문제는 Batch Listener를 쓰고 있어도 실제 Redis write는 배치 처리처럼 동작하지 않고 이벤트 단위로 발생한다는 점이다.

즉, 배치 소비의 장점은 Kafka 쪽에만 있고, Redis 입장에서는 여전히 write 폭주다.

---

3. Batch Consumer와 Batch Processing은 다르다

이 부분은 자주 헷갈린다.

• Batch Consumer: Kafka에서 메시지를 묶어서 가져오는 것
• Batch Processing: 가져온 메시지를 내부에서도 묶어서 집계 후 처리하는 것

현재 코드는 Batch Consumer이긴 하지만, 내부 로직은 메시지마다 바로 incrementScore()를 호출하므로 실질적으로는 단건 처리의 반복이다.

즉,

• Kafka pull 횟수는 줄였지만
• Redis write 횟수는 줄이지 못한 상태

라고 볼 수 있다.

---

4. Throughput과 Latency의 트레이드오프

배치 내 집계를 하면 Redis write 횟수는 줄어든다. 대신 이벤트가 바로 반영되지 않고, 조금 모아서 반영하게 된다.

그래서 항상 두 축을 같이 봐야 한다.

• Throughput: 초당 얼마나 많은 이벤트를 안정적으로 처리할 수 있는가
• Latency: 이벤트가 발생한 후 랭킹에 반영되기까지 얼마나 늦어지는가

실시간성이 아주 중요한 서비스라면 지나치게 긴 집계 주기는 위험하고,
반대로 처리량이 중요하다면 짧은 실시간성보다 write 감소가 더 중요할 수 있다.

---

5. 운영상 신호와 설계 전환

설계 변경은 “이론상 더 좋아 보여서”가 아니라 운영 신호를 보고 판단해야 한다. 이 구조에서 봐야 할 신호는 대체로 이런 것들이다.

• Redis CPU 사용률 상승
• 특정 시간대 Redis command 처리 지연 증가
• ZINCRBY 호출량 급증
• Kafka consumer lag 증가
• batch size는 충분한데 처리 시간이 계속 늘어남
• Redis 네트워크 RTT 증가
• 인기 상품 이벤트 급증 시 처리량 급격히 흔들림

즉, 단순히 “hot key가 걱정된다”가 아니라 실제 병목이 Redis write 집중으로 드러나는가를 봐야 한다.

---

설계 관점 요약

현재 구조의 핵심 문제는 Kafka는 배치로 읽고 있지만 Redis는 이벤트마다 즉시 쓰고 있다는 점이다.

그래서 구조적으로 다음 문제가 생긴다.

• ranking:all:yyyyMMdd라는 단일 key에 모든 write가 집중됨
• Batch Listener를 사용해도 Redis write 수는 줄지 않음
• 인기 상품/피크 시간대에 Redis가 병목이 될 가능성이 높음
• write 수 자체가 많아 네트워크 round-trip 비용도 커짐

이걸 개선하려면 배치 내부에서:

1. 이벤트를 순회하며 상품별 delta를 메모리에 집계하고
2. 상품별 최종 점수 변화량만 Redis에 반영해야 한다

즉, 설계 포인트는
“이벤트 단위 처리”에서 “배치 단위 집계 후 반영”으로 책임을 옮기는 것이다.