목차 열기
부하테스트 (3일차 통합)
2026-04-14 ~ 2026-04-16, 3일간 진행한 백엔드 MSA 전 서비스 부하테스트와 단계별 최적화 전 과정입니다. AS-IS 상태에서 발견된 503 에러의 진짜 원인을 파고들어, DB 인스턴스 업그레이드 없이 코드·인프라 레벨에서 Queue Flow P99를 6,887ms에서 65ms로 개선한 여정입니다.
핵심 한 줄 요약
DB 인스턴스 업그레이드(돈)로 해결할 수도 있었지만, 원인을 파고드니 사양 문제가 아니라 앱이 쿼리를 너무 많이 보내는 문제였다. 그래서 앱단 최적화로 해결했다.
| 구간 | Seat P99 | DB 커넥션 peak | 비용 |
|---|---|---|---|
| AS-IS (Phase 0) | 6,887ms | 270 (한계) | — |
| Phase 1 (Caffeine 도입) | ~2,000ms | 180 | 0원 |
| Phase 1 확대 (Multi-Service) | ~1,200ms | 150 | 0원 |
| Phase 2 (Redis 분산 캐시) | ~900ms | 120 | 0원 |
| Phase 3 (응답 캐시 + 인프라) | ~600ms | 120 | 0원 |
| Phase 4 (OSIV/Lua/Resilience4j) | 65ms | 100 | 0원 |
문서 구성
| # | 문서 | 내용 |
|---|---|---|
| 1 | 부하테스트 개요 | 테스트 환경, 인프라 스펙, 측정 메트릭, k6 Flow 설명 |
| 2 | 테스트 시나리오 Flow | 각 Flow(queue/seat/recommendation/order)가 호출하는 엔드포인트 조합 |
| 3 | 기술 용어 해설 | HikariCP / Caffeine / Redis / OSIV / Resilience4j 등 핵심 개념 |
| 4 | Phase별 최적화 타임라인 | AS-IS → Phase 1~4 → TO-BE 단계별 작업 내용과 결과 |
| 5 | 테스트별 결과 요약 | 01~21번 폴더의 각 테스트 결과 표/수치 정리 |
| 6 | 503 트러블슈팅 핵심 스토리 | "DB가 한가한데 왜 503?" — 커넥션 풀 병목의 진짜 원인 |
| 7 | Before/After 시각화 비교 | 각 Phase별 캡쳐 이미지와 수치 나란히 비교 (최종 증빙) |
최종 측정치 (Phase 4 적용 후)
큐 플로우 — 1,000 VU (booking-options + queue-enter)
| 메트릭 | 값 |
|---|---|
| Avg | 36ms |
| P95 | 47ms |
| P99 | 65ms |
| Error Rate | 0% |
| 503 | 0건 |
추천 ON 플로우 — 1,000 VU (E2E)
| 서비스 | Requests | P95 | P99 |
|---|---|---|---|
| Queue | 52,895 | 95ms | 194ms |
| Seat | 1,982 | 1.03s | 1.23s |
추천 OFF (포도알) 플로우 — 1,000 VU
| 메트릭 | 값 |
|---|---|
| 총 요청 | 60,316 |
| Error Rate | 0.0% |
| 좌석 Hold 성공률 | 83.6% (VU 기준) |
| 이선좌(409) 경합 | 114건 (정상 동시성 제어) |