Payment Load Test

🔥 Payment 부하테스트

Mock PG로 결제 confirm까지 부하테스트하다가 찾은 HikariCP 커넥션 풀 자기잠식 데드락 기록

---

목차

1. 배경
2. Mock PG
3. 1차 — 30 threads, HikariCP 풀 부족 확인
4. 2차 — 풀을 20으로 늘렸더니 오히려 악화 → 진짜 원인
5. 권장 해결 방향
6. 재현 방법

---

배경

POST /payment/payments/confirm은 외부 PG(Toss)를 실제로 호출하기 때문에 그동안 부하테스트 대상에서 제외되어 있었다. 이번에 Mock PG를 만들어 confirm까지 포함한 전체 흐름을 부하테스트했고, 그 과정에서 풀 크기로는 해결되지 않는 실제 동시성 결함을 찾았다. 도메인 구조와 API 전체는 Payment 참고.

---

Mock PG

PaymentTossClientAdapter가 호출하는 baseUrl은 설정으로 완전히 외부 주입되므로, 앱 코드를 건드리지 않고 이 값만 로컬 서버로 돌리면 confirm 전체(락 해제 시점, 트랜잭션 분리, 지갑 충전까지)를 부하테스트할 수 있다. 별도 의존성 없이 JDK 내장 HttpServer만으로 MockTossServer.java를 작성했고, 기존 단위테스트(TossPaymentAdapterTest.kt)가 WireMock으로 이미 검증해 둔 실제 요청/응답 포맷을 그대로 따랐다.

JMeter 시나리오는 스레드마다 매 반복 prepare로 새 결제를 만들고, 그 응답을 그대로 confirm에 흘려보내는 체이닝 구조로 만들었다 (confirm은 READY 상태에 대해 단 한 번만 성공하므로).

---

1차 — 30 threads, HikariCP 풀 부족 확인

30 threads로 부하를 걸자 confirm 성공률이 58%(80/138)로 떨어졌다. Prometheus로 확인한 5분 구간 지표:

지표	값
hikaricp_connections_active 최대	10 (기본 풀 크기)
hikaricp_connections_pending 최대	30
confirm 평균 응답시간 (일부 구간)	30~60초

confirm 1건이 prepare 1회 + confirm 내부 트랜잭션 2회, 총 DB 왕복 3번을 필요로 하는데 30명이 think-time 없이 몰아치자 기본 풀(10)이 그대로 바닥났다 — 여기까지는 합리적인 "용량 부족" 결론이었다.

---

2차 — 풀을 20으로 늘렸더니 오히려 악화 → 진짜 원인

maximum-pool-size: 20으로 늘리고 재검증하니 예상과 반대로 confirm 성공률이 1.5%(1/66)로 더 나빠졌다. 게다가 DB엔 신규 APPROVED가 9건인데 confirm 200 응답은 1건뿐이었다 — 8건은 서버에서 실제로 처리(지갑 충전까지)됐지만 클라이언트가 60초 넘게 기다리다 먼저 타임아웃으로 포기한 뒤 응답이 도착한 것이다.

부하 구간의 HikariCP 추이:

active:  0, 17, 20, 20, 20, 20, 20, 20, 20, 20, 20, 0, ...   ← 최댓값에 고정, 전혀 안 풀림
pending: 0,  0, 30, 30, 30, 30, 30, 30, 30, 30, 30, 0, ...   ← 대기열도 고정, 전혀 안 줄어듦

풀이 부족해서 줄을 서는 상황이라면 완료되는 요청이 생길 때마다 값이 오르내려야 한다. 100초 가까이 완전히 평평했다는 건 그 시간 동안 단 하나도 끝나지 못했다는 뜻이다 (부하가 끝나면 곧바로 active=0, idle=20으로 회복되므로 누수는 아니었다).

그림 1 — pool=10일 때 대기가 30까지 튀는 첫 번째 부하 구간

Note

위 스크린샷 — active가 풀 최댓값(20)에, pending이 30에 못 박힌 채 부하가 끝날 때까지 단 한 칸도 움직이지 않는다. 정상적인 "풀 부족"이라면 완료되는 요청이 생길 때마다 두 값이 오르내려야 하므로, 이 완전한 수평선 자체가 데드락의 증거다.

근본 원인 — 커넥션 풀 자기잠식 데드락: confirm의 두 번째 트랜잭션은 DB 트랜잭션을 연 채로 그 안에서 지갑 서비스를 gRPC로 블로킹 호출한다. 이 앱은 모놀리스라 지갑 gRPC 서버가 같은 JVM, 같은 HikariCP 풀을 쓰는데, 그 핸들러도 자기 쿼리를 실행하려면 같은 풀에서 커넥션을 하나 더 받아야 한다.

sequenceDiagram
    participant C as confirm 스레드 (x N)
    participant Pool as HikariCP 풀 (size=20)
    participant W as Wallet gRPC 핸들러

    C->>Pool: ① 커넥션 획득 (Payment Tx2 오픈)
    Note over C,Pool: 풀의 커넥션이 전부 ①에서 소진될 때까지 반복
    C->>W: ② getWallet/chargePoints (블로킹, 커넥션 쥔 채로 대기)
    W->>Pool: ③ 자기 쿼리용 커넥션 요청
    Pool--xW: 풀 전부가 이미 ①에 점유돼 있어 배분 불가
    Note over C,W: 아무도 끝나지 못함 — 순환 대기

Loading

동시 confirm 수가 풀 크기에 근접하면 모든 커넥션이 "①에서 대기 중인 스레드"에게 점유된 채 ③에 필요한 커넥션이 하나도 남지 않는다 — 고전적인 중첩 자원 획득 데드락이다.

Important

풀을 20으로 늘렸을 때 더 나빠진 것도 이걸로 설명된다: 풀이 클수록 더 많은 스레드가 동시에 ①까지 도달해 같은 함정이 더 완전하게 발동한다. 이 문제는 풀 크기로 해결되지 않는다.

흥미로운 점은, 바로 위 Toss PG 호출은 정확히 반대로 짜여 있다는 것이다 — 코드 주석에도 "트랜잭션 종료 시 락이 해제되므로 외부 PG 호출 중 DB 락이 유지되지 않는다"고 명시돼 있다. 개발자는 외부 호출을 트랜잭션 밖에서 해야 한다는 원칙을 이미 알고 Toss 호출엔 적용했지만, 같은 트랜잭션 안의 지갑 gRPC 호출에는 적용하지 못한 것으로 보인다.

---

권장 해결 방향

Tip

지갑 gRPC 호출을 Tx2 밖으로 분리한다: (a) 결제 상태를 APPROVED로 먼저 커밋 → (b) 트랜잭션 밖에서 지갑 gRPC 호출. Toss 호출과 동일한 패턴이다.

---

재현 방법

cd payment/mock-pg && ./start-mock-pg.sh          # Mock PG 기동
# 앱을 local,loadtest 프로파일로 기동 (application-loadtest.yml)
cd payment && ./confirm.sh 30 10 60               # 30명 / ramp 10초 / 유지 60초

Grafana RAIO Main - Application Metrics 대시보드의 "DB 커넥션 풀 (HikariCP)" 패널로 active/pending 추이를 실시간으로 볼 수 있다.