목차 열기
좌석 추천 ON / OFF 실측 비교
k6 부하 테스트 1,000 VU 시나리오로 좌석 경합 상황에서 추천 ON(서버 자동 배정) vs 추천 OFF(포도알 직접 선택)의 실측 지표를 비교한 문서입니다.
측정 환경: Staging · 2026-04-17 · k6 LOCAL · 1,000 VU · matchId 로테이션
핵심 한 줄 요약
추천 OFF(직접 선택)는 seat-holds에서 경합(409) 1,236건 · 시도 성공률 38.2%. 추천 ON(서버 자동 배정)은 동일 부하에서 경합 0건 · 성공률 100%로 재시도 자체를 구조적으로 제거했습니다.
| 지표 | 추천 OFF | 추천 ON | 효과 |
|---|---|---|---|
| 이선좌 (409) 경합 | 1,236건 | 0건 | 경합 완전 제거 |
| Seat 서비스 성공률 | 84.5% | 100% | +15.5%p |
| seat-holds 시도 성공률 | 38.2% | 100% | +61.8%p |
| 전체 요청 수 | 10,000 | 10,000 | 동일 부하 |
테스트 조건
| 항목 | 값 |
|---|---|
| 환경 | Staging · https://api.staging.playball.one |
| 측정일 | 2026-04-17 |
| 가상 유저 (VU) | 1,000 |
| Duration | VU당 1 iteration |
| 로그인 | loadtest-login (1,000개 계정 순환) |
| Token Batch | 100개씩 병렬 획득 |
| 재시도 정책 | 이선좌(409) 발생 시 다른 블럭/좌석으로 재시도 |
| 실행 모드 | LOCAL (Docker · k6 binary) |
테스트 대상 엔드포인트
| # | 추천 OFF Flow | 추천 ON Flow |
|---|---|---|
| 1 | POST /seat/matches/{matchId}/booking-options (OFF) | POST /seat/matches/{matchId}/booking-options (ON) |
| 2 | POST /queue/matches/{matchId}/enter | POST /queue/matches/{matchId}/enter |
| 3 | GET /queue/matches/{matchId}/status | GET /queue/matches/{matchId}/status |
| 4 | GET /seat/matches/{matchId}/sections/{id}/seat-groups (포도알) | POST /seat/matches/{matchId}/recommendations/seat-entry |
| 5 | GET /seat/matches/{matchId}/sections/{id}/blocks (섹션블럭) | GET /seat/matches/{matchId}/recommendations/blocks |
| 6 | POST /seat/matches/{matchId}/seat-holds (좌석선점) | POST /seat/matches/{matchId}/recommendations/blocks/{blockId}/assign (자동 배정) |
1. 추천 OFF — 포도알 직접 선택
1-1. 요약 카드 (상태 코드 분포)
- 총 요청 11,236 · P95 2,403ms · P99 3,344ms · 5XX 0건
- 200 OK 8,764 (78.0%) · 409 충돌 2,472 (22.0%)
- 재시도 누적치 — VU가 이선좌를 만나면 다른 블럭으로 재시도

1-2. 전체 대시보드 (재시도 포함 누적)

1-3. 서비스별 상세 통계 (단일 Iteration)
VU당 1 iteration 기준 Queue 2,000건 + Seat 8,000건 = 총 10,000건. 이 중 seat-holds phase에서만 409 1,236건 발생 (다른 phase는 100%).

1-4. 엔드포인트별 수치
| Endpoint | req | 성공률 | P50 | P95 | P99 |
|---|---|---|---|---|---|
| booking-options-off | 2,000 | 100% | 689ms | 1,961ms | 2,152ms |
| queue-enter | 2,000 | 100% | 644ms | 1,137ms | 1,204ms |
| seat-groups | 2,000 | 100% | 838ms | 1,301ms | 1,907ms |
| section-blocks | 2,000 | 100% | 1,593ms | 3,316ms | 3,831ms |
| seat-holds | 2,000 | 38.2% | 822ms | 2,284ms | 2,909ms |
1-5. Grafana · 백엔드 지표




2. 추천 ON — 서버 자동 배정
2-1. 요약 카드 (상태 코드 분포)
- 총 요청 10,000 · P95 3,411ms · P99 4,345ms · 5XX 0건
- 200 OK 10,000 (100.0%) · 409 충돌 0건
- 서버가 블럭 단위 분산 락으로 1명씩 순차 진입 → 경합 자체가 발생하지 않음

2-2. 전체 대시보드

2-3. 서비스별 상세 통계
VU당 1 iteration 기준 Queue 2,000건 + Seat 8,000건 = 총 10,000건.모든 phase 100% 성공 — 재시도 불필요.

2-4. 엔드포인트별 수치
| Endpoint | req | 성공률 | P50 | P95 | P99 |
|---|---|---|---|---|---|
| booking-options-on | 2,000 | 100% | 465ms | 701ms | 765ms |
| queue-enter | 2,000 | 100% | 637ms | 801ms | 898ms |
| rec-seat-entry | 2,000 | 100% | 860ms | 2,537ms | 3,164ms |
| rec-blocks | 2,000 | 100% | 1,497ms | 2,670ms | 3,565ms |
| rec-seat-hold (자동 배정) | 2,000 | 100% | 2,248ms | 4,345ms | 4,749ms |
2-5. Grafana · 백엔드 지표


3. 정량 비교표
3-1. 엔드포인트(좌석 확정) 기준
| 지표 | OFF · seat-holds | ON · rec-seat-hold | 효과 |
|---|---|---|---|
| 총 시도 | 2,000 | 2,000 | 동일 |
| 200 (성공) | 764 | 2,000 | +1,236건 |
| 409 (경합) | 1,236 | 0 | 경합 완전 제거 |
| 시도 성공률 | 38.2% | 100% | +61.8%p |
| TPS | 17.8 | 47.6 | +167% |
3-2. 응답 속도 (좌석 확정 phase)
| Percentile | OFF · seat-holds | ON · rec-seat-hold |
|---|---|---|
| Avg | 824ms | 2,248ms |
| P50 | 822ms | 2,248ms |
| P95 | 2,284ms | 4,345ms |
| P99 | 2,909ms | 4,749ms |
응답 속도 자체는 ON이 느림 — 서버가 빈 연석을 실시간으로 계산해 배정하기 때문. 반면 OFF는 빠르지만 38.2%만 성공해서 실질 체감은 ON이 더 좋음 (재시도 · 이선좌 · 네트워크 왕복 제거).
4. 해석
왜 OFF는 38.2%만 성공하는가
- 1,000명이 같은 좌석맵을 보고 클릭하면 인기 좌석에 트래픽이 집중
- 먼저 클릭한 사람이 분산락을 선점 → 나머지 요청은 409 반환
- 네트워크가 빠른 VU에 유리 → 구조적 불공정
- 실제 서비스에서는 재시도 로직으로 최종 성공률을 끌어올리지만, 매 재시도마다 RTT와 DB 부하가 누적
왜 ON은 0건 경합인가
- 블럭 단위 분산 락으로 블럭에 1명씩 순차 진입
- 서버가 블럭 내 빈 연석(연속석)을 실시간 계산해 자동 배정
- 두 유저가 같은 좌석을 받을 수 없는 구조 → 경합 자체가 발생하지 않음
- 네트워크 속도와 무관하게 공정한 분배
5. 결론
추천 ON은 응답 속도는 OFF보다 느리지만, 좌석 확정 성공률 38.2% → 100%, 경합 1,236건 → 0건으로 티켓팅 경합 문제를 구조적으로 해결했습니다.
사용자는 한 번의 요청으로 좌석을 확정받고, 서버는 재시도 트래픽 없이 안정적인 처리량을 확보합니다.