LiveCommerce

라이브 방송 중 한정 수량 판매는 몇 초 안에 주문이 몰리고, 재고, 결제, 배송이 서로 다른 서비스에 있습니다. 플래시 세일에서 품절은 일상이라 결제를 먼저 받으면 품절될 때마다 환불과 PG 수수료가 생기고, 서비스 하나가 멈추면 이벤트 유실이나 이중 결제가 생길 수 있습니다.

api-gateway(Spring Cloud Gateway)가 JWT를 검증하고 신원 헤더를 다시 쓰며 레이트 리밋과 WebSocket 프록시를 맡습니다. order-service의 Saga 오케스트레이터가 재고를 먼저 10분 잡고 결제를 받습니다(AWAITING_STOCK → AWAITING_PAYMENT → PAYMENT_CONFIRMING → CONFIRMING_STOCK → COMPLETED, 결제 창 5분). inventory(선점, 확정, 반환, 만료 정리), payment(Toss 승인과 취소, Idempotency-Key), live(STOMP 채팅, 실시간 재고, 시청자 수), auth(RS256 JWT, JWKS, 리프레시 토큰 교체), delivery(배송, HMAC 택배 웹훅)가 각자의 PostgreSQL을 쓰고, 서로의 데이터는 API나 Kafka 이벤트로만 읽습니다. 이벤트는 각 서비스의 transactional outbox에서 나가며 traceparent를 함께 저장해 Kafka를 거쳐도 Saga 전체가 한 Jaeger 트레이스로 이어집니다.

크게 보기

무엇을 바꿨나

발견한 원인 4개를 고쳤습니다: 품절 뒤에도 FOR UPDATE 대기 → 락 전 스칼라 조회, 토픽당 파티션 1개와 컨슈머 1개(재고 선점 p95 17.8초) → 파티션 6개와 스레드 6개(키 orderId), outbox 릴레이가 500ms마다 하나씩 확인하며 전송 → 100ms 주기 병렬 배치, 시청자 500명에게 입장마다 인원 수 전송(O(n²)) → 바뀔 때만 초당 최대 1회. 결제 요청 p95 0.71 → 0.63초, 재고 선점까지 p95 17.77 → 4.80초, 완료까지 p95 33.55 → 11.04초, 시청자 수 메시지 454,583 → 8,151. '이전' 지연은 k6가 15–20초 뒤 느린 주문을 기다리지 않아 잘린 값이라 실제 차이는 더 큽니다.

증상

2026-10-09 프로덕션에서 lc-hoard-check.sh로 테스트 계정 하나가 미결제 주문을 연달아 만들자 2×201, 재고 15 → 0이 되었습니다. 한 사용자가 10분 hold 동안 방송 상품 전체를 다른 사람에게서 막을 수 있었습니다.

원인

Saga가 POST /api/orders마다 별도의 hold를 열었고, '구매자 한 명에 열린 주문 하나' 규칙이 어디에도 없었습니다.

해결

V5 마이그레이션: 열린 상태(AWAITING_STOCK, AWAITING_PAYMENT, PAYMENT_CONFIRMING, CONFIRMING_STOCK)에 대한 (member_id, product_id) partial unique index. 컨트롤러가 먼저 확인하고, 경합 시에는 DataIntegrityViolationException을 인덱스 이름으로 구분해 409 OPEN_ORDER_EXISTS와 기존 orderId를 돌려주며, 프론트엔드는 그 주문을 이어 갑니다.

재발 방지

로컬 Postgres에서 동시 트랜잭션 두 개 중 두 번째가 1.5초 기다린 뒤 거부되는 것을 확인했고, 프로덕션 재검사에서 1×201 + 409, 재고 5에서 멈췄습니다. 동시 요청 10개 중 정확히 1개만 201인지 확인하는 통합 테스트를 넣었고, k6 flash-sale.js는 VU마다 자기 사용자를 쓰도록 바꿨습니다(USERS ≥ VUS 검사).

테스트 수

46

커버리지

—

CI

—

테스트 도구

JUnit 5 (통합 24, 카오스 3, gateway 단위 14, SigningKeys 5), 실행 중인 전체 스택에 실제 HTTP, k6 3종

배포 환경

iwinv VPS의 docker-compose.prod.yml: 컨테이너 16개(Spring 서비스 7, Next.js, PostgreSQL 5, Kafka KRaft, Jaeger, Caddy edge). 어떤 컨테이너도 포트를 publish하지 않고 edge만 외부 proxy 네트워크에 연결되며 /api/*와 /ws/*는 gateway, 나머지는 frontend로 보냅니다. JVM은 USER app(비 root), 서비스마다 메모리 제한(Spring 512MB, PostgreSQL 256MB, Kafka 768MB). PAYMENTS_FAKE_ENABLED=false. deploy.sh: 충돌 표시 검사 → git pull --ff-only → SHA 태그 이미지 8개 빌드 → up -d → 모든 서비스의 /actuator/health와 frontend를 edge 안에서 60 × 3초 확인 → 성공 시 APP_TAG와 .deploy-history 기록. 2026-10-10 측정: 배포 2분 38초(빌드 116초), 중단 약 27초.

백업

서버 공통 cron 백업(매일 03:00, 7일 보관)이 livecommerce PostgreSQL 5개를 덤프하는 것이 백업 로그에 남아 있습니다. 복원 시험은 아직 하지 않았습니다.

롤백

rollback.sh <sha>: 이미지 8개가 모두 있는지 확인한 뒤 빌드 없이 up -d --no-deps --force-recreate. 마이그레이션은 Flyway로 앞으로만 가며(V5는 인덱스만 추가해 이전 코드도 동작), 프로덕션 훈련에서 rollback 48초(중단 약 36초), 재전진 39초(약 26초)였습니다.

모니터링

lc-diagnose.sh 한 번으로 컨테이너 상태, restart/OOM, 메모리, 24시간 ERROR 수, 공개 엔드포인트 지연, 상태별 주문, 15분 넘게 멈춘 주문, outbox PENDING, 재고, DB 크기, Kafka lag를 확인합니다. 2026-10-09: 9일 연속 가동, restart 0, OOM 0, ERROR 0, Kafka lag 0, PENDING 0. Jaeger(OpenTelemetry, 샘플링 20%)로 Saga 전체 트레이스.

• order-service/…/saga/OrderSagaOrchestrator.kt

  Saga 상태 머신: hold → 결제 → 확정, 보상, OPEN_ORDER_EXISTS

• order-service/…/saga/SagaRecoveryScheduler.kt

  20초 넘게 멈춘 단계와 결제 기한이 지난 주문을 5초마다 복구

• order-service/…/outbox/OutboxRelay.kt

  병렬 전송, 확인된 연속 앞부분만 PUBLISHED, 첫 실패에서 중단

• inventory-service/…/service/InventoryService.kt

  reserve / confirm / release / expire, 락 없는 품절 거절 뒤 FOR UPDATE

• payment-service/…/gateway/TossPaymentGateway.kt

  Toss 승인/취소: timeout, Idempotency-Key, 거절 응답 매핑

• api-gateway/…/filter/IdentityRelayFilter.kt

  클라이언트가 보낸 신원 헤더를 지우고 JWT에서 다시 씀

• api-gateway/…/ratelimit/RateLimitFilter.kt, ClientAddress.kt

  레이트 리밋과 XFF 체인에서 신뢰할 수 있는 IP

• auth-service/…/config/SigningKeys.kt

  env에서 키 로드, thumbprint kid

• delivery-service/…/webhook/WebhookSignature.kt

  HMAC 서명, timestamp 신선도, event_id 한 번 적용

• order-service/…/V5__one_open_order_per_member_product.sql

  열린 주문 하나 partial unique index

• load-test/k6/flash-sale.js

  200 VU 플래시 세일과 불변식 5개

재고 100개에 구매 시도 1,000건(200 VU)을 3회 실행해 매번 초과 판매 0건, 결제와 판매 수량 불일치 0건, HTTP 오류 0건이었고, 매 실행 끝에 불변식 5개를 admin API로 확인했습니다. 측정으로 병목을 찾아 판매 완료 시간을 1분 27초에서 약 23초로 줄였고, 커넥션 풀 가설은 측정으로 기각했습니다. 프로덕션에서는 계정 하나가 미결제 주문 2건으로 재고 전체(15 → 0)를 잡을 수 있던 문제를 partial unique index로 막았고(15 → 5), auth 재시작 뒤 같은 토큰에 서비스마다 다른 응답(401/200)이 나던 JWT 키 문제(0eeaf2c)와 로그인·주문에 제한이 없던 문제(085ded0)를 고쳤습니다. 그 밖에 브로커가 없을 때 outbox 트랜잭션이 몇 분씩 락을 잡던 문제(881afda), 파티션 증설 뒤 컨슈머가 새 파티션을 못 보던 문제, 이전 실행의 hold가 만료돼 판매가 101로 보이던 k6 불변식 오류, 다른 프로젝트 컨테이너가 8080 포트를 잡아 통합 테스트 14개가 실패한 일도 원인을 찾아 정리했습니다.