백엔드
신규 서비스 배포 전에 실험과 개선을 반복한 이야기
두줄요약
VSMS 배포 전 성능 테스트에서 재고 갱신 순서로 인한 DB 데드락과 I/O 병목을 발견했습니다.\n상품 정렬과 로그 MongoDB 분리로 목표 1,200 TPS를 넘어 1,500 TPS 이상을 유지했습니다.
문제 상황
- 재고 조회·증감·배치 작업을 제공하는 VSMS의 신규 서비스 배포 전 목표 성능 1,200 TPS 설정
- 첫 공식 성능 테스트에서 DB 데드락과 commit I/O로 120 TPS 수준의 처리량 확인
원인 분석
- 여러 상품의 재고를 하나의 트랜잭션에서 서로 다른 순서로 갱신하며 순환 대기 발생
- 수량 변경 처리와 로그 적재의 DB I/O, RDB 커넥션 점유가 주요 병목
해결 방법
- 트랜잭션별 차감 대상 상품 정렬로 잠금 획득 순서를 통일해 데드락 제거
- commit을 모아 처리하는 실험과 리팩토링 전후 성능 비교 수행
- 수량 변경 로그를 메인 RDB에서 MongoDB로 분리해 커넥션 사용량 축소
성능/운영 포인트
- 운영 RPS 샘플을 기반으로 물류 증가와 성장률을 반영한 목표 TPS 산정
- 장시간 성능 테스트에서 약 6,161만 건 처리와 1,500 TPS 이상 유지 확인
- 가독성을 희생한 코드와 리팩토링 코드의 성능 차이가 근소함을 검증 후 리팩토링 채택