코딩 해파리

기존 시스템 REST API - 30분 동안 5000명의 동시 가상 사용자(VUs)를 목표로 부하 테스트를 진행상품 서비스 파드 2개, 주문 서비스 2개 (각 0.5vCPU, 1GB 메모리) 결과 :  부하 테스트 결과, 약 175 req/s에서 HTTP 요청의 99퍼센타일 응답 시간(http_req_duration_q0.99)이 1400ms까지 상승했습니다.이 시점부터 서버 병목이 두드러졌으며, Product 서비스 Pod(CPU 할당 0.5코어) 2개는 실제로 0.411코어, 0.423코어(약 82% 이상 사용)를 보였는데, 이는 Order 서비스 Pod와 유사한 자원 사용 패턴이었습니다.이를 통해, 주문(Order)으로 인한 상품(Product) 서비스 부하가 상당하다는 사실을 확인할 수 있었습니다..

들어가며현재 프로젝트 목표 중에 높은 트래픽 상황을 견디며 처리하는 성능이 좋은 서버를 구축하는 부분이 있었습니다. 하지만, 기존에는 주문 생성 이벤트가 들어올 때마다 매번 DB에 쓰기 작업을 수행하도록 설계되어 있었기 때문에, 주문이 발생하였을 때 상품 재고 감소 처리 로직(재고 차감 로직)에서 심각한 성능 저하가 발생했습니다. 이렇게 많은 이벤트를 단건 단위로 처리하다 보니, 트래픽이 폭주할 때 자원 사용량 증가로 시스템 전반에 병목 현상이 생겼습니다.이 글에서는 이벤트 배치 처리 방식을 도입하여 성능을 최적화한 과정을 공유합니다. 기존 문제점N건의 이벤트에 대해 N번의 DB 쓰기주문 생성 이벤트가 1건 들어올 때마다 상품 서비스에서 재고 차감 로직을 실행 → DB에 직접 쓰기.이벤트가 폭발적으로 증..