세상에 벌써 마지막 회고라니..7월 어느 날 시작한 프로젝트가 벌써 10주가 지나 대단원의 막을 내리게 되었다.한여름에 시작할 땐 언제 10주가 지나지 했는데, 이젠 살짝 춥기도 한 가을의 초입이라니 시간이 참 빠르다.루프팩을 마무리하면서 느낀 것들을 정리해보려고 한다. 사실 루프팩을 시작하기 직전 6월, 회사에서 정리해고를 당했다.SNS에서만 보던 일이 나에게 일어날 줄은 몰랐는데..잘 가다가 갑자기 모르는 길 한복판에 내던져진 기분이었다.한동안 방향도 잃고 방황도 조금 했던 것 같다. 그러던 중 친구에게 루퍼스에서 이 과정을 진행한다는 소식을 듣게 되었다.마침 시간도 뜨고 퇴직금도 생겼겠다.. 같이 해보자는 친구의 권유로 시작하게 되었다. 사실 나는 작년에 비슷한 플랫폼에서 비슷한 코스를 진행한 ..

저번에 만든 일간 랭킹 기능에 주간, 월간 랭킹을 추가하게 되었다. 일간 랭킹까지만 있을 때는 Kafka Consumer + Redis ZSET으로 충분했다.실시간 이벤트를 소비하고 점수를 바로 올리는 구조라 빠르고 직관적이었다.하지만 문제는 주간, 월간 랭킹을 일간 랭킹과 동일하게 가져갈 순 없었다는 것이다.Redis에만 데이터를 적재하려니 TTL을 길게 가져가야 해서 그만큼 비용과 관리 부담이 커졌고, 결국 영속성과 안정성이 보장하는 DB에 데이터를 저장하기로 했다. 이미 product_metrics 테이블에 일간 데이터가 쌓이고 있었기 때문에 이를 기반으로 주간/월간 집계를 만들기로 했다.그렇다면 그냥 호출 시마다 SUM / GROUP BY로 계산하면 되지 않을까?하지만 그렇게 하면 매번 대량 데이..

이커머스 프로젝트를 진행하면서 실시간 상품 랭킹을 설계하게 되었다.사실 어지간한 이커머스에는 다 있는 기능이라 쉽게 끝날 거라 생각했지만… 역시나 고민할 부분이 정말 많았다. 왜 실시간 랭킹인가?사용자가 상품을 조회하고, 좋아요를 누르고, 구매한다.이때마다 바로바로 갱신되는 랭킹을 보여주고 싶었다.기존에는 단순히 DB 테이블에 데이터를 쌓고 조회하는 방식이었다.하지만 트래픽이 늘어난다고 생각하면 단순 집계 쿼리는 곧 심각한 병목으로 이어질 것 같았다.따라서 실시간 반영 + 빠른 조회를 만족시킬 수 있는 Redis를 선택했다. Redis ZSETRedis의 Sorted Set (ZSET) 은 score 기반으로 자동 정렬되는 자료구조다.랭킹도 점수를 기반으로 정렬하기 때문에 아주 적합하다고 생각했다..

내부 이벤트의 한계지난주에는 이벤트를 통해 결합도를 줄이는 구조를 만들었다. 주문은 주문만 알도록 하고, 결제나 쿠폰 사용 같은 후속 작업은 이벤트 핸들러가 이어받도록 분리했다.하지만 애플리케이션 내부 이벤트만으로는 해결할 수 없는 문제들이 남아있었다.신뢰성 부족: 예외가 나면 단순히 로그만 남고 이벤트 자체가 유실될 수 있음확장성 제약: 하나의 애플리케이션 안에서만 소비할 수 있어 별도의 서비스가 이벤트를 받을 수 없음결국 서비스 경계를 넘어 전달할 수 있는 이벤트 파이프라인이 필요했다. 외부 이벤트 브로커가 만족해야 하는 요구사항을 정리해 보면 다음과 같았다.At-Least-Once 전달 보장순서 보장재시도와 DLQ소비자 그룹 확장성이 모든 요구사항을 충족해주는 도구가 바로 Kafka였고, 그래서 이..

저번 주차에 장애 대응 시스템을 구축하면서 분리했던 주문과 결제 API를 다시 하나로 합쳤다.PG가 아직 시뮬레이터이기 때문에 별도의 인증/인가 로직이 존재하지 않았고, 실제 유저가 주문을 하는 플로우를 생각해 봤을 때 주문과 결제를 하나의 API로 묶는 게 자연스럽다는 판단이 들었기 때문이다.그런데 막상 합치고 나니 여러 문제가 발생했다. 길어진 트랜잭션합친 구조는 대략 이런 모습이었다.한눈에 봐도 로직이 길어졌고, 주문이 너무 많은 책임을 떠안게 됐다.주문 { 주문 생성 쿠폰 조회 & 사용 재고 조회 & 차감 포인트 조회 & 차감 결제 요청 주문 정보 데이터 플랫폼 전송}결제 요청 { 주문 검증 결제 생성 PG 결제 요청 API 호출 결제 상태 변경 주문 상태 변경}결제 콜백 { 주문 검증 결제 ..