pile·
DB / 데이터·마켓컬리마켓컬리 Hello World·

신규 서비스 배포 전에 실험과 개선을 반복한 이야기

컬리 가상 재고 관리 시스템(VSMS)을 정식 배포하기 전, 성능 테스트에서 나온 데드락과 DB 병목을 반복 실험으로 개선한 이야기다. 목표 1200 TPS를 잡고 첫 테스트에서 120 TPS와 데드락을 만난 뒤, 트랜잭션 정렬·DB 스펙 상향·커넥션 절약으로 1500 TPS 이상까지 끌어올렸다.

핵심 포인트
  • 예상 피크 300 TPS의 4배인 1200 TPS를 목표로 성능 테스트를 설계
  • 첫 공식 테스트에서 DB 데드락으로 120 TPS라는 저조한 결과
  • 트랜잭션이 아이템을 다른 순서로 잠가 생긴 순환 대기를 대상 정렬 3줄 변경으로 제거
  • 최대 병목은 DB IO로, DB 스펙을 2코어에서 8코어로 올려 320에서 924 TPS로 개선
  • 수량 변경 로그를 RDS에서 MongoDB로 옮겨 RDB 커넥션을 확보, 최종 1500 TPS 이상 유지
상세 정리
  • 시스템: VSMS는 기획·개발·DevOps가 약 8개월간 준비해 2020년 8월 30일 정식 배포했고, 상품코드·재고 수량 관리 admin API, 재고 조회·조정 customer API, 배치 잡으로 구성된다.
  • 목표 설정: 2020년 6~7월 2주간 RPS 데이터에 물류센터 추가·성장 전망을 반영해 예상 피크 300 TPS의 4배인 1200 TPS를 성능 목표로 잡았다.
  • 첫 테스트: 2020년 7월 2일 6개 에이전트와 가상 유저 300으로 돌린 첫 공식 테스트에서 DB 데드락이 발생해 120 TPS에 그쳤다.
  • 데드락 원인: 트랜잭션들이 아이템을 서로 다른 순서로 잠가(Tx1은 A에서 B, Tx2는 B에서 A) 순환 대기가 생기며 상호 차단됐다.
  • 데드락 해결: 트랜잭션 대상을 정렬해 순환 의존을 없애는 3줄짜리 코드 변경 PR로 데드락을 제거했다.
  • 병목 진단: 가장 큰 병목은 데이터베이스 IO였다.
  • DB 스펙 실험: 2코어·2GB DB에 인스턴스당 커넥션 20으로 320 TPS였는데, 8코어·60GB로 올리자 924 TPS까지 나왔다.
  • 리팩토링 판단: 커밋을 단일 연산으로 합치는 등 리팩토링본과 비리팩토링본을 단일 API로 통제 비교한 결과 성능 차이는 근소해, 유지보수를 위해 7월 23일 리팩토링본을 머지했다.
  • 커넥션 절약: 7월 22일부터 8월 4일까지 수량 변경 로그를 RDS에서 MongoDB로 옮겨, 중요한 작업이 쓸 RDB 커넥션을 확보했다.
  • 최종 결과: 7시간 테스트로 3,685만 건을 처리해 1,462 TPS, 이어 4시간 45분 테스트로 2,476만 건에 1,445 TPS를 냈고, 합산 11시간 45분 약 6,161만 건 처리에 1500 TPS 이상을 유지해 목표를 넘겼다.
  • 배포: VSMS는 8월 12일 백그라운드 배포 후 8월 30일 정식 오픈했다.
왜 읽나신규 서비스 배포 전 부하 테스트로 DB 데드락·IO·커넥션 병목을 잡아야 하는 백엔드·DBA에게 트랜잭션 정렬·스펙 상향·RDS에서 MongoDB 분리의 실측 사례.
마켓컬리
마켓컬리 Hello World 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. DB / 데이터·spotify-engSpotify Engineering·

    데이터 레이크 온라인 포인트 쿼리 인덱싱 — RAP

    Spotify 엔지니어링이 페타바이트 규모 데이터 레이크(GCS)에 저장된 Parquet 파일에서 한 자릿수 밀리초 레이턴시로 포인트 쿼리를 수행하는 RAP(Random Access Parquet) 방식을 공개했다. Trino·BigQuery 같은 분산 SQL 엔진은 단일 행 조회도 스케줄링·플래닝 비용으로 수 초가 걸리지만, RAP는 외부 인덱스로 키→(파일, 행 번호)를 직접 매핑해 의존적 read chain을 병렬화함으로써 이 문제를 해결했다. 기존 KV 스토어(Bigtable)와 달리 GB당 비용이 클라우드 스토리지 read 수준에 불과해 장기 이력 데이터나 롱테일 피처도 인터랙티브 조회 대상이 된다.

    #data-engineering#indexing#data-lake+2
  2. DB / 데이터·여기어때 (GC컴퍼니)여기어때 (GC컴퍼니)·

    데이터 통합— MongoDB 원칙으로 document를 통합하고 동기화를 재설계하다 (3/3)

    여기어때 전시개발팀은 ES 단일 대문서 → MongoDB v1 RDB 1:1 파편화 → v2 도메인 단위 통합이라는 세 차례 구조 전환을 거쳐 전체 동기화 시간을 약 1시간에서 10분으로 단축했다. 이 글은 3부작의 마지막으로, v2 통합 문서 구조에 맞춰 "$set/$unset 필드 단위 부분 갱신 + 이벤트 발행" 기반 동기화를 어떻게 재설계했는지 구체적인 MongoDB 패턴과 함께 설명한다.

    #denormalization#data-sync#mongodb+2
  3. DB / 데이터·pinterest-engPinterest Engineering·

    Pinterest 차세대 DB 수집 프레임워크의 자동화된 스키마 진화

    Pinterest의 CDC 기반 DB 수집 파이프라인은 MySQL에서 Kafka, Flink, Spark, Iceberg를 거치는 다층 구조다. 스키마 변경이 생기면 모든 계층을 동시에 업데이트해야 해 드리프트, 배포 실패, 데이터 불일치가 반복됐다. Pinterest 엔지니어링 팀은 이를 해결하기 위해 가산적 변경만 자동화하는 스키마 진화 프레임워크를 구축하고, PR 기반 롤아웃과 SLA 기반 일관성 모델을 도입했다.

    #data-pipeline#apache-flink#cdc+2