성능 테스트 보고서 v2.1 · Greenova Checkout API

01

Executive Summary · KPI

핵심 지표 요약

평균 TPS

1,842

목표 1,500 대비 +22.8%

P95 응답시간

182 ms

목표 300ms 대비 39.3% 우수

P99 응답시간 (Peak)

2,410 ms

SLA 1,000ms 초과 (141%↑)

에러율 (Surge)

3.41%

503 Service Unavailable 급증

성능 검증 결과 종합

PASS 2 · FAIL 1 · WARN 1

시나리오	VU	Duration	TPS	P95	P99	Error	판정
정상 트래픽 (Normal)	50	30분	1,842	182ms	412ms	0.08%	PASS
피크 트래픽 (Peak)	500	30분	4,210	687ms	2,410ms	0.94%	WARN · p99 초과
급증 유입 (Surge)	0→2000	5분 ramp + 20분	3,120	1,420ms	5,890ms	3.41%	FAIL · DB pool exhaust
회귀 재수행 (튜닝 후)	500	30분	5,120	240ms	820ms	0.12%	PASS · 개선안 적용 후

기준: p95 ≤ 300ms, p99 ≤ 1,000ms, Error ≤ 1.0%, TPS ≥ 1,500 (SLO 기준)

02

부하 시나리오

Load Scenarios · nGrinder Agent 8대

■ Scenario A · Normal

정상 트래픽 베이스라인

Virtual Users50 VU

Ramp-up60초

Duration30분 (고정 부하)

Think Time1,000~2,000ms

Target TPS1,500 이상

AgentnGrinder × 2대

실측 평시 트래픽 기준으로 서비스가 안정적으로 처리 가능한지 확인하는 베이스라인. 12개 엔드포인트를 가중치 기반 랜덤 호출.

■ Scenario B · Peak

피크 트래픽 — 캠페인 시나리오

Virtual Users500 VU

Ramp-up180초

Duration30분 (고정 부하)

Think Time500~1,000ms

Target TPS4,000 이상

AgentnGrinder × 4대

블랙프라이데이 기준 최대 동접자 트래픽 예상치를 가정하여 SLA 초과 여부 및 병목 구간을 확인.

■ Scenario C · Surge

급격한 유입 증가 (스파이크)

Virtual Users0 → 2,000 VU

Ramp-up300초 (급속)

Duration20분 + 5분 cool-down

Think Time200~500ms

Target TPS최대치 측정

AgentnGrinder × 8대

쿠폰 오픈·타임세일 진입 시 발생하는 스파이크를 가정. 스케일아웃 지연 및 DB pool·캐시 고갈 관찰이 목표.

가중치 기반 요청 분포 (12 endpoints)

Total 287,420,190 requests

POST /orders (주문 생성)32.4% · 93.1M

GET /products/{id} (상품 조회)24.1% · 69.3M

POST /payments (결제 요청)14.8% · 42.5M

GET /cart (장바구니)11.2% · 32.2M

POST /auth/login (로그인)7.3% · 20.9M

POST /coupons/apply (쿠폰 적용)4.9% · 14.1M

기타 6개 엔드포인트5.3% · 15.3M

03

측정 지표

Metrics · Response / Throughput / Error / Resource

엔드포인트별 응답시간 분포 (Peak 시나리오 기준)

단위: ms

Endpoint	Avg	P50	P95	P99	Max	TPS	판정
GET /products/{id}	48	42	98	210	512	1,210	PASS
GET /cart	62	55	124	287	640	620	PASS
POST /auth/login	82	76	168	410	1,210	340	PASS
POST /coupons/apply	210	182	520	1,420	3,280	210	WARN
POST /orders	340	280	920	2,410	5,120	890	FAIL · p99
POST /payments	420	310	1,180	2,980	6,420	410	FAIL · p99

자원 사용률 (Peak 진행 15분 시점)

app ×4 · db ×1 · redis ×1

App 서버 CPU (4대 평균)72%

App 서버 Memory58%

DB CPU (RDS)94%

DB Connection (100 pool)100 / 100 (POOL EXHAUSTED)

Redis Hit Ratio62% (평시 94%)

Network Out (평균)420 Mbps / 1 Gbps

에러율 시계열 (Surge 시나리오)

총 수집 구간 25분 · 30초 단위 aggregate

구간	요청수	2xx	4xx	5xx	Error%	주요 사유
0 ~ 2분	287,410	99.84%	0.12%	0.04%	0.16%	정상
2 ~ 5분 (ramp)	821,290	99.21%	0.18%	0.61%	0.79%	일부 timeout 시작
5 ~ 10분 (피크 진입)	1,420,320	96.12%	0.24%	3.64%	3.88%	503 · DB pool 고갈
10 ~ 20분 (피크 유지)	2,840,110	96.59%	0.21%	3.20%	3.41%	503 · 502 혼재
20 ~ 25분 (cool-down)	1,210,450	99.41%	0.14%	0.45%	0.59%	회복

04

개선 포인트 · 병목 분석

Bottleneck · Tuning Priority

B-001 DB Connection Pool 고갈 — Peak/Surge 시나리오 503 급증의 1차 원인

Critical 담당: BE 개발팀 · DBA

관찰

Peak 15분 시점 pool 100/100 도달, 이후 신규 요청 대기 큐 적재 → HikariCP `getConnectionTimeout` 초과로 503 반환. DB CPU 94% (iowait 38%)

예상 원인

주문 생성 트랜잭션이 재고 차감·쿠폰 소진·포인트 적립 4개 테이블에 대해 Long Tx 유지. N+1 쿼리 2건 확인

권고

① HikariCP pool 100→300 증설
② 재고·포인트 업데이트를 이벤트 기반 후처리로 분리
③ N+1 제거 (fetch join)

예상 효과

p99 2,410ms → 800ms 이하 (67% ↓) · 에러율 3.41% → 0.3% 이하

B-002 Redis 캐시 Hit Ratio 하락 (94% → 62%) — 상품 상세 조회 응답시간 3배 증가

High 담당: BE · Platform

관찰

Surge 진입 직후 캐시 TTL 만료가 몰리며 Stampede 발생. DB 직접 조회로 폴백되는 비율 증가

예상 원인

일괄 캐시 갱신 정책 (매일 03:00 전체 재빌드) → 동일 TTL 만료가 동시 발생

권고

① TTL ± 랜덤 jitter(±10%) 적용
② 인기 상품 top 500 Pre-warming
③ Cache-aside + Single-flight lock 적용

예상 효과

Hit ratio 62% → 90% 이상 복원 · DB 부하 40% 경감

B-003 상품 상세 이미지 동기 리사이즈 — /products/{id} p99 210ms 기여 요인

Medium 담당: BE · FE

관찰

썸네일 요청 시 서버에서 ImageMagick 동기 호출 발생. p99 응답시간의 28%를 리사이즈가 점유

권고

① 사전 리사이즈된 CDN 자산 사용 (3가지 해상도 pre-generate)
② 서버 응답에서는 원본 URL만 반환, 변환은 CDN에서 on-the-fly 처리

예상 효과

p99 210ms → 140ms (33% ↓) · App 서버 CPU 72% → 55%

기타

CDN(CloudFront) 비용 증가 예상 (월 +$210) vs. App 서버 2대 축소 가능 (월 -$840)

B-004 Auto-Scaling 반응 지연 — Surge 진입 후 인스턴스 추가까지 4분 소요

Low 담당: Platform

관찰

CPU 70% 임계 기준 스케일아웃 트리거 → 부팅·헬스체크 완료까지 실제 4분 경과. 그 사이 기존 4대에 부하 집중

권고

① Target CPU 70% → 60% 하향
② Warm pool 2대 상시 유지
③ 캠페인 일정 기반 스케줄 스케일아웃 병행

예상 효과

Surge 초기 3분간 에러율 3.88% → 1.2% 이하

튜닝 우선순위 · 예상 ROI

P1 즉시 · P2 단기 · P3 중기

01DB Connection Pool 증설 + Long Tx 분리

HikariCP 증설은 설정 1줄 변경. Long Tx 분리는 주문 생성 API 리팩터링 필요 (약 3일)

P1 즉시 예상 공수 3일 ROI ★★★★★

02Redis 캐시 정책 개선 (TTL jitter + Pre-warming)

Stampede 방지. TTL jitter는 1일 내 적용 가능. Pre-warming 배치 추가 필요

P1 즉시 예상 공수 2일 ROI ★★★★★

03Auto-Scaling Warm Pool 도입

인프라 구성 변경. 비용 소폭 증가 ($~80/월) 대비 Surge 대응력 크게 향상

P2 단기 예상 공수 1일 ROI ★★★★

04CDN 기반 이미지 변환 이관

CDN 설정 + FE 썸네일 URL 변경. 단계적 롤아웃 (상품 상세 먼저)

P3 중기 예상 공수 4일 ROI ★★★

05

재현 / 실행 방법

nGrinder Script · Monitoring

nGrinder 실행 커맨드

Agent 8대 기준

./nGrinder-agent start --controller=ngrinder.qalabs.test:16001

./run-scenario.sh scenario=normal vu=50 duration=30m

./run-scenario.sh scenario=peak vu=500 duration=30m

./run-scenario.sh scenario=surge vu=2000 ramp=300s duration=25m

./export-report.sh out=./results/perf_v2_1/ --format=html,csv

결과: results/perf_v2_1/Greenova_Perf_Report_v2_1.xlsx · summary.html · grafana_snapshots/

모니터링 대시보드

Grafana + CloudWatch + APM

Grafana · API Latency	grafana.qalabs.test/d/checkout-latency
Grafana · Resource	grafana.qalabs.test/d/checkout-resource
CloudWatch · RDS	AWS CloudWatch · rds-checkout-prod (CPU / Connections / ReadLatency)
APM · Datadog	app.datadoghq.com/apm/services/checkout-api
nGrinder Report	ngrinder.qalabs.test/perftest/detail_report/2618

06

결론 · Next Action

Summary · Recommendation

검증 결과 요약

평시 TPS는 목표의 +22.8% 초과 달성. 그러나 Peak 시나리오에서 p99 2,410ms로 SLA 초과, Surge 시나리오에서 DB Pool 고갈로 에러율 3.41% 발생.

핵심 권고

① DB pool + Long Tx 분리 (P1)
② Redis TTL jitter + Pre-warming (P1)
③ Warm pool · CDN 이미지 이관 (P2-3)

재검증 목표

P1 2건 적용 후 회귀 재수행. 목표: Peak p99 ≤ 1,000ms, Surge Error ≤ 1.0%.
재검증 예정일: 2026-04-25