들어가며매일 쌓이는 대량의 메트릭 데이터를 집계해서 주간/월간 랭킹을 실시간으로 산출하는 과정을 쉽지 않다. 단순히 "데이터를 읽어서 계산한다"는 직관적인 접근으로 시작한다면, 대량의 데이터를 안정적으로 처리할 수 없을 것이다. 이 글에서는 Spring Batch를 사용한 랭킹 배치 시스템 구현 과정과, 메모리를 지키기 위한 리팩토링 경험을 공유하고자 한다. 요구사항과 초기 설계사용자들에게 인기 상품을 추천하기 위해 주간/월간 랭킹 기능을 제공한다. 요구사항은 다음과 같다. 주간 랭킹 : 매주 월요일부터 일요일까지의 기간 동안 Top 100 상ㅍ품월간 랭킹 : 매월 1일부터 말일까지의 기간 동안 Top 100 상품배치 실행 : 매일 새벽 3시에 전날 데이터를 기반으로 주간/월간 랭킹 계산 데이터 구조..

들어가며이커머스 서비스에서 상품 랭킹은 사용자에게 인기 상품을 추천하고, 판매까지 이어질 수 있게 만드는 중요한 기능이다. 하지만 실시간으로 쏟아지는 많은 요청을 매번 RDB에서 대량 집계해서 보여주는 것은 성능상 한계가 있을 수 있다. 이번 글에서는 Redis ZSET을 활용해 일별 랭킹 시스템을 구현한 경험을 공유하고자 한다. 특히 키 설계 전략과 콜드 스타트 문제 해결을 중점으로 글을 쓰려고 한다. 어떤 랭킹 시스템인가구현하고자 하는 랭킹 시스템은 단순히 누적 판매량순 또는 누적 조회수순으로 정렬하는 것이 아닌, 다음과 같은 요구사항을 가진 랭킹 시스템이다. 일별 랭킹 가장 먼저 고려한 것은 "시간의 범위"이다. 전체 기간의 누적 점수만 사용하면 이미 인기가 많은 상품이 계속 상단을 차지하는..

들어가며카프카를 도입해서 서비스 간 결합도를 낮추는 작업을 진행했다. 전송 방식은 데이터 유실 없이 안정적인 전송을 위해 At-Least-Once(적어도 한 번 전송) 방식으로 구현했다. 그래서 중복 전송에 대한 대비가 필요했다. 프로듀서가 메시지를 보내고 브로커로부터 ACK을 받지 못하면, 프로듀서는 메시지가 유실됐다고 판단하고 재전송을 한다. 이때 실제로는 브로커에 저장이 되었지만 ACK만 유실된 경우라면? 컨슈머는 똑같은 메시지를 두 번 받게 된다. 그래서 컨슈머 쪽에 멱등성 처리를 해주어야 한다. 즉, 카프카가 "정확히 한 번 전송"을 보장해주기 어렵다면, 컨슈머가 "여러 번 받아도 한 번만 처리"하도록 만들면 된다. 결과적으로 시스템 전체는 Exactly-Once 효과를 낼 수 있다. 이..