405 V1 한계 지점 — 부하테스트 실측 분석

위키 [402 V2 트래픽 시나리오 기반 V1 한계 지점 분석]의 세 시나리오에 대해 2026-09-20 실측값으로 답을 채운 문서다. 문서 골격은 404, 측정 설계는 403에 있다.

각 절은 예외 없이 같은 사슬을 따른다. 서비스 동작 → 예상 트래픽 → 부하 특성 → 점유 인프라 자원 → 측정 설계 → 측정 결과 → 인프라 구성 변경.

---

0. 요약

0.1 결론 세 줄

1. V1의 한계는 RPS가 아니다. 단순 조회는 목표 피크(60.4 RPS)의 10배인 641 RPS에서도 p95 19.4 ms, 오류 0%, CPU throttling 0이었다.
2. 한계는 세 개의 공유 자원에 있다. WebSocket 동시 연결 약 1,700개(행사 목표 3,000의 57%), HikariCP 공용 풀 10개, 동일 팟 행의 lock이다.
3. 세 자원은 모두 다른 기능으로 장애를 전파한다. WS 연결 2,100개에서 일반 조회 p99가 27배, 채팅 저장 47 msg/s에서 조회 p95가 13.6배, 인기 팟 동시 승인 50건에서 조회 p99가 48배 악화됐다.

0.2 위키 세 시나리오에 대한 판정

위키 시나리오	요구 수준	실측 결과	판정
(1) 출퇴근 팟 탐색 조회 증가	조회 60.4 RPS	641 RPS까지 p95 19.4 ms, 오류 0%	여유 있음
(1) 혼잡도 DB 쓰기	37.6 row 쓰기/s	유사 규모(47 write/s)에서 풀 10개 포화, 대기 53건	위험 (직접 측정 아님)
(2) 인기 팟 좌석 경쟁	인기 팟 잠금 1.05 RPS	동시 20건에서 풀 고갈, 50건에서 실패율 59.5%	가정 단위를 바꿔야 함
(3) 행사 WS 동시 연결	동시 3,000개	최대 1,734개, 이후 handshake 30초 타임아웃	목표 미달
(3) 행사 신규 연결률	10 conn/s	20 conn/s에서 handshake p95 33.5 ms	여유 있음
(3) 행사 API 피크	140 RPS	641 RPS까지 여유	여유 있음
(3) 채팅 메시지 증가	—	47 msg/s 저장에서 일반 조회 p95 13.6배 악화	위험

0.3 최초 포화 자원 순위

순위	포화 자원	임계값	근거 RUN_ID	목표 대비
1	WebSocket 동시 연결	약 1,700개	a-ramp3000, c3, d1, g	3,000 목표의 57%
2	HikariCP 공용 풀 (10)	동시 쓰기 20건 / 저장 47 msg/s	e-same-c20, d1-save-h50	1.05 RPS 가정은 통과, 동시성은 실패
3	동일 팟 row lock	동시 50건에서 실패율 59.5%	e-same-c50	—
4	Nginx 연결 수립 처리	200 conn/s에서 p95 3.57초	b-rate200	10 conn/s 목표의 20배
5	Spring CPU quota (0.75)	641 RPS에서도 throttling 0	f-light-700	60.4 RPS의 10배 이상

---

1. 측정 개요

1.1 대상과 환경

t3.medium(2 vCPU · 4 GiB) 1대에 컨테이너 4개. 합계가 호스트 CPU를 100% 소진하도록 배분되어 있다.

컨테이너	CPU	메모리	이 문서에서 중요한 설정
Nginx	0.25	128 MB	worker_processes 1, nofile 32768
Next.js(placeholder)	0.50	512 MB	상시 384 MB 점유
Spring Boot	0.75	768 MB	-Xmx512m, Tomcat threads 200 / max-connections 8192
MySQL	0.50	768 MB	buffer pool 384 MB

• HikariCP 최대 10, 커넥션 획득 타임아웃 1,000 ms, innodb_lock_wait_timeout 3초
• REST와 WebSocket이 같은 Spring 컨테이너의 CPU·heap·Tomcat·풀을 공유한다
• 부하는 로컬 k6 → 공개 HTTPS/WSS → Nginx 경유. 관측은 Prometheus 5초 scrape

1.2 실행 목록

31개 실행, 2026-09-20 18:47~21:00. 구간은 results/runs.tsv, 구간별 자원 집계는 results/derived-20260920T210124.csv.

블록	목적	RUN_ID
a	연결당 자원 단가	a-ramp3000 (0→3,000 램프 12.5분)
b	연결 시도율	b-rate20, b-rate100, b-rate200
c	메시지 유형 2×2	c1-200c-256b, c2-200c-8000b, c3-1800c-256b, c4-1800c-8000b
d	채팅 저장과 풀 경합	d0-rest-control, d1-save-h50, d2-save-h50-ws, d2-rest-treatment
e	인기 팟 hot-row	e0-rest-control, e-same-c5/20/50/100, e-mix-c50, e-mix-rest, e-dist-c50
f1c	WS가 REST에 주는 간섭	f1c-rest-control, f1c-ws2100, f1c-rest-treatment
f	조회 RPS 계단	f-light-50~700, f-detail-50~300
g	반복 측정	g-c3-repeat

1.3 판정 규칙과 신뢰 범위

• 측정창은 블록당 75~150초, 반복 1회다. g-c3-repeat와 c3의 차이가 8%(CPU 0.0357 vs 0.0388 cores)였으므로, 30% 미만의 지연 차이는 실재로 인정하지 않는다.
• 지연·오류율은 k6 클라이언트 측정값을 쓴다. 서버 측 http_server_requests 히스토그램 분위는 거의 모든 구간에서 0.95 ms로 고정되어 산정 오류가 확인됐다(§8.2).
• 자원 지표(연결당 heap, 요청당 CPU)는 변동이 작아 1차 근거로, 지연은 보조 근거로 쓴다.

---

2. 공통 기준선

이후 모든 절이 이 두 값을 비교 기준으로 쓴다.

2.1 WebSocket 연결 1개의 자원 단가

a-ramp3000의 램프 구간(0→1,734개, 12.5분)을 lab_ws_connections에 대해 최소제곱 회귀한 값이다.

항목	실측	3,000 연결 환산	Spring 배정량 대비
연결당 heap	28.2 KB	84.6 MB	-Xmx512m의 16.5%
연결당 direct buffer	0.2 KB	0.6 MB	무시 가능
1,000 연결당 CPU	0.0092 cores	0.028 cores	0.75 CPU의 3.7%

heap 기준 수용 가능 연결 = (512 MB × 0.7 − 기저 heap 31.9 MB) ÷ 28.2 KB ≈ 11,800개. 즉 메모리도 CPU도 3,000 연결을 감당한다. 그런데 실제 상한은 1,700개였다(§5.1). 이 불일치가 이 문서의 가장 중요한 미해결 항목이다.

2.2 조회 API 1건의 자원 단가

계열	최대 실측 RPS	그때 backend CPU	요청당 CPU	quota 이론 상한
light (DB 미사용)	641.6	0.148 cores	0.231 CPU-ms	약 3,250 RPS
detail (DB 조회)	274.5	0.125 cores	0.455 CPU-ms	약 1,650 RPS

픽스처 endpoint가 실제 API보다 단순하므로 절대 RPS는 상한 보증값이 아니다. 이 표는 "조회 경로가 V1의 1차 병목이 아니다"를 보이는 데만 쓴다.

---

3. 시나리오 (1) — 출퇴근 팟 탐색: 조회 증가와 혼잡도 저장

3.1 서비스 동작

교통 장애 발생 → 주변 혼잡도 확인 → 목적지 방향 팟 검색 → 여러 팟 비교 → 조건 변경 후 재검색. V2에서는 선택지가 늘어 목록·상세 재조회가 반복된다.

3.2 예상 트래픽 (위키 402)

조회 종류	사용자당 일일	피크 평균 RPS
커뮤니티 목록	10건	20.8
게시글·팟 상세	10건	20.8
혼잡도	9건	18.8
합계	29건	60.4
혼잡도 DB 쓰기 (K=1)	—	37.6 row/s

3.3 부하 특성

정상 상태의 처리량 부하다. 요청당 비용이 곧 용량을 정한다. 단 혼잡도는 조회가 곧 쓰기(최신값 upsert + 이력 insert)를 만드는 읽기처럼 보이는 쓰기 부하다.

3.4 점유 인프라 자원

읽기 경로 : Nginx(0.25) → Spring Tomcat 스레드·CPU(0.75) → [detail] Hikari(10) → MySQL(0.5)
쓰기 경로 : 위 + 동일 spot_id row lock + redo/fsync + EBS

혼잡도 쓰기는 채팅 저장·좌석 승인과 같은 풀 10개를 공유한다.

3.5 측정 설계

• 조회: light(DB 미사용) 50→150→300→500→700 RPS, detail(DB 조회) 50→150→300 RPS, 각 warm-up 15초 + 측정 75초, WS 없음
• 혼잡도 쓰기: 픽스처에 혼잡도 API가 없어 직접 측정하지 않았다. 동일 풀·동일 규모의 쓰기 부하인 채팅 저장(§5.4, 47 write/s)으로 간접 판단한다

3.6 측정 결과

목표 RPS	실제 RPS	p95	p99	오류율	dropped	backend CPU	throttling	호스트 CPU
light 50	45.9	11.5 ms	16.9 ms	0%	0	0.029	0	8.4%
light 150	137.6	11.3 ms	18.2 ms	0%	0	0.066	0	13.5%
light 300	275.0	11.5 ms	21.9 ms	0%	0	0.085	0	17.4%
light 500	458.3	15.0 ms	53.6 ms	0%	0	0.120	0	22.6%
light 700	641.6	19.4 ms	64.1 ms	0%	0	0.148	0	27.8%
detail 50	45.9	13.2 ms	26.4 ms	0%	0	0.047	0	10.5%
detail 150	137.5	12.3 ms	24.8 ms	0%	0	0.086	0	18.0%
detail 300	274.5	16.7 ms	44.1 ms	0%	0	0.125	0	26.0%

• C_knee에 도달하지 못했다. 641 RPS에서도 오류 0%, throttling 0, Tomcat busy 최대 1이다. 목표 60.4 RPS는 측정 최대값의 9.4%다.
• MySQL CPU는 detail 300 RPS에서 0.105 cores(배정 0.5의 21%)로 여유가 있다.
• 700 RPS 목표에서 실제 641 RPS(91.7%)에 그친 것은 dropped iteration 0이므로 서버 포화가 아니라 발생기·네트워크 쪽 상한으로 본다.

3.7 판정과 인프라 구성 변경

• 조회 경로는 V1에서 변경 우선순위가 가장 낮다. 인스턴스 상향·scale-out을 조회 때문에 결정할 근거는 없다.
• 다만 혼잡도 쓰기(37.6 row/s)는 별개다. §5.4에서 47 write/s가 풀 10개를 포화시키고 같은 풀을 쓰는 조회 p95를 13.6배 악화시켰다. 혼잡도 저장이 추가되면 조회 지연은 조회량 때문이 아니라 쓰기 때문에 무너진다.
• 변경안: 혼잡도 최신값은 캐시(TTL) + 단일 비행(single-flight)으로 쓰기 횟수를 줄이고, 이력 저장은 비동기 배치로 분리한다. 읽기·쓰기 풀을 분리한다.
• 재검증: 혼잡도 endpoint를 픽스처에 추가해 K=1과 K=5로 §5.4와 동일한 control/treatment 비교를 수행한다.

---

4. 시나리오 (2) — 인기 팟 좌석 경쟁

4.1 서비스 동작

팟 목록 비교 → 남은 좌석 확인 → 참여 요청 → 승인. 좌석이 마감되면 새로고침과 재검색이 이어진다. 승인은 좌석 행을 SELECT ... FOR UPDATE로 잠근다.

4.2 예상 트래픽 (위키 402)

요청 종류	계산	RPS
팟 참여 요청	30,000 ÷ 14,400	2.1
참여 승인·거절	30,000 ÷ 14,400	2.1
인기 팟 집중(h=50%)	2.1 × 0.5	1.05

4.3 부하 특성

직렬화되는 경합 부하. 변수는 RPS가 아니라 같은 행에 동시에 도착하는 요청 수다. 대기 중에도 커넥션을 점유하므로 부하가 자원을 이중으로 먹는다.

4.4 점유 인프라 자원

승인 요청 → Spring 스레드 → Hikari 커넥션 1개 점유
          → MySQL 동일 row X-lock (보유 시간 = 트랜잭션 시간)
          → 대기 요청은 lock 대기 + 커넥션 점유를 동시에 유지

임계 조건이 둘이고 서로 다르다.

풀 고갈  : 동시 요청 > 10 → 획득 대기 1,000 ms 초과 → 503
lock 초과: 동시 요청 × 트랜잭션 시간 > 3,000 ms → 503

4.5 측정 설계

hot-row.js로 동일 팟에 동시 5·20·50·100건을 3라운드 발행(lock_hold_ms=100). 대조군은 분산 팟(e-dist-c50), 전파 측정은 detail 50 RPS 병행(e-mix-*), control은 e0-rest-control.

4.6 측정 결과

동일 팟 동시성별(클라이언트 측정):

동시성	p95	p99	실패율	Hikari 대기	획득 p95	좌석 lock p95	서버 5xx/s
5	542 ms	546 ms	0%	0	2.3 ms	425 ms	0
20	1,961 ms	2,033 ms	4.76%	10	934 ms	971 ms	0.05
50	1,872 ms	2,106 ms	59.5%	32	1,061 ms	976 ms	1.14
100	1,627 ms	2,042 ms	79.9%	84	1,067 ms	1,046 ms	5.73

• 동시 20건이 분기점이다. 풀(10개)을 넘는 순간 대기가 생기고 획득 p95가 934 ms로 타임아웃(1,000 ms) 직전까지 올라간다. 예측대로 동시성 > 풀 크기가 첫 임계였다.
• 동시 50건 이상에서는 획득 p95가 1,060 ms로 타임아웃에 붙어 실패율이 59.5%→79.9%로 뛴다. 즉 실패의 주된 원인은 lock 자체가 아니라 lock 대기가 커넥션을 잡고 있어 발생한 풀 고갈이다.
• 분산 팟 대조군(e-dist-c50)은 실패율 43.1%로 동일 팟(59.5%)보다 낮지만 0%가 아니다. 픽스처의 hot run에 팟이 2개뿐이어서 동시 50건이 25건씩 두 행에 나뉘었을 뿐이다. 대조군으로서 약하다(§8.3).

다른 API로의 전파(detail 50 RPS):

구간	p95	p99	실패율
control e0-rest-control (hot-row 없음)	10.7 ms	17.5 ms	0%
treatment e-mix-rest (동시 50건 병행)	26.4 ms	844.5 ms	0.38%
변화	2.5배	48배	—

일반 조회의 p95는 2.5배지만 p99가 48배다. 좌석 경합이 공용 풀을 통해 조회 API의 꼬리 지연을 만든다는 위키의 장애 흐름 가설이 수치로 확인됐다.

4.7 판정과 인프라 구성 변경

• 위키의 가정 단위를 바꿔야 한다. "인기 팟 잠금 1.05 RPS"는 트랜잭션 시간 0.5초를 적용하면 평균 동시성 0.5로, V1이 통과한다. 그러나 실제 위험은 평균이 아니라 좌석 공개·마감 순간의 동시 도착 수다. 위키 (2)의 트래픽 가정을 동시 승인 요청 수 기준으로 재산정할 것을 제안한다.
• 변경안 우선순위
  1. 좌석 차감을 DB row lock 밖으로 옮긴다 — Redis 원자 카운터 + 멱등키. lock 보유 시간이 사라지면 풀 점유도 사라진다.
  2. 쓰기 경로의 풀을 조회와 분리한다. 승인 API가 풀 전체를 잠식하지 못하게 한다.
  3. 풀 크기 증설은 후순위다. 10→20은 임계를 동시 20→40으로 미룰 뿐, MySQL 동시 실행만 늘린다.
• 정합성은 이번 측정에서 위반이 확인되지 않았다(음수 좌석·정원 초과 0건). 단 스키마의 CHECK (remaining >= 0)가 위반을 503으로 바꿔 드러내므로, 503 중 CHECK 위반분을 분리하는 로그 확인이 남아 있다.

---

5. 시나리오 (3) — 행사 종료: WebSocket 집중과 공유 자원 고갈

5.1 동시 연결 수 — 목표 3,000개에 도달하지 못했다

① 서비스 동작 행사 종료 후 유입된 사용자가 채팅방에 입장해 매칭 성사까지 연결을 유지한다.

② 예상 트래픽 위키 (3)의 목표는 동시 연결 3,000개 이상이다.

③ 부하 특성 장시간 유지되는 상태 보유형 부하. 메시지가 없어도 소켓·FD· 세션 메모리를 점유한다.

④ 점유 자원 Nginx(연결당 client+upstream 2 FD, 0.25 CPU, 128 MB) → Spring (heap 세션 객체, direct buffer, Tomcat 커넥션 슬롯 8192, nofile 16384).

⑤ 측정 설계 ws-connect.js로 0→3,000을 12.5분에 선형 증가(4 conn/s). 램프 자체를 독립변수로 써서 연결 수 대비 자원을 회귀했다. REST 부하는 없다.

⑥ 측정 결과

항목	실측
목표 동시 연결	3,000
실제 최대 동시 연결 (lab_ws_connections)	1,734
handshake p95	30,001 ms (30초 타임아웃)
WS 오류율	57.3%
연결당 heap / CPU	28.2 KB / 1,000개당 0.0092 cores
그때 heap 최대 / working set	301 MB / 604 MB (limit 768 MB)

같은 상한이 다른 블록에서도 반복됐다. 목표 1,800 연결을 지시한 네 블록의 실측 최대는 c3 1,708 / c4 1,633 / d1 1,628 / g 1,692개다. 반면 1,000 연결을 지시한 b-rate* 세 블록은 오류 0%로 1,000개를 모두 수립했다. 따라서 상한은 1,000과 1,800 사이에 있다.

원인은 단정할 수 없다. §2.1대로 heap(11,800개 여유)도 CPU(3.7% 사용)도 설명하지 못한다. 후보는 Nginx 128 MB 메모리 한도 안의 연결별 프록시 버퍼, Nginx 단일 worker의 연결 처리, 로컬 발생기·Docker VM의 소켓 한도다. 이번 측정의 컨테이너별 CPU 집계에 오류가 있어(§8.2) Nginx를 근거로 지목할 수 없다.

⑦ 판정과 변경

• 행사 시나리오의 핵심 요구(동시 3,000)를 V1은 충족하지 못한다. 달성률 57%이며, 초과분은 거부가 아니라 30초 대기 후 실패로 나타나 사용자에게는 "채팅방이 열리지 않는 상태"로 보인다.
• 원인 규명 전에는 인스턴스 상향과 WS 분리 중 어느 것이 해법인지 확정할 수 없다. 다음 창의 1순위 작업을 §8.4에 적었다.
• 연결당 단가(28.2 KB, 0.0092 cores/1k)는 확보했으므로, WS 전용 프로세스를 분리할 때의 메모리·CPU 산정은 이 값으로 가능하다.

5.2 연결 시도율 — 목표 10 conn/s는 여유, 200 conn/s에서 붕괴

② 위키 (3)의 신규 연결률은 평균 5 conn/s, 피크 10 conn/s다.

③ 짧고 비싼 순간 부하. 연결 수립마다 TLS handshake가 발생한다.

④ Nginx 0.25 CPU · worker_processes 1 · accept queue · listen backlog.

⑤ 연결 1,000개 고정, CONNECT_RATE 20 / 100 / 200 conn/s. 측정창은 ramp 구간.

⑥

연결 시도율	handshake p95	WS 오류율	달성 연결
20 conn/s	33.5 ms	0%	1,000
100 conn/s	156.6 ms	0%	1,000
200 conn/s	3,568.8 ms	0%	1,000

시도율이 10배(20→200)가 되면 handshake 지연은 107배가 된다. 선형이 아니다. 다만 오류는 0%이므로 이 구간은 "실패"가 아니라 "대기"다.

⑦ 목표 10 conn/s는 목표의 2배인 20 conn/s에서도 33.5 ms이므로 문제가 아니다. 단 3,000명이 더 빠르게 유입되는 시나리오(예: 100 conn/s 이상)를 가정하면 진입 계층이 먼저 느려진다. 변경이 필요해지면 Spring이 아니라 Nginx CPU·worker 재배분 또는 TLS 종료 위치 변경이 먼저다.

5.3 메시지 유형 — 건수가 바이트보다 3배 이상 비싸다

①② 채팅 메시지. 긴 안내·정산 내역과 짧은 대화가 섞인다.

③ 두 축이 섞인 부하. 메시지 건수와 payload 바이트가 각각 다른 비용을 만든다.

④ 건수 → Tomcat 스레드·프레임 처리·역직렬화 / 바이트 → 버퍼·직렬화· 네트워크 / 양쪽 모두 heap allocation과 GC.

⑤ 2×2 요인 설계(연결 200·1,800 × payload 256 B·8,000 B), 저장 없는 echo 경로, 목표 120 msg/s 고정.

⑥ 연결 200개 두 셀은 메시지 건수가 16,684건으로 정확히 같아 바이트 비용만 분리된다.

셀	연결	payload	메시지	실제 msg/s	backend CPU
c1	200	256 B	16,684	97.5	0.0378
c2	200	8,000 B	16,684	94.8	0.0511
c3	1,708	256 B	10,628	44.9	0.0388
c4	1,633	8,000 B	9,928	42.4	0.0494

메시지 1건 기본 비용 = 0.0378 cores ÷ 97.5 msg/s ≈ 0.39 CPU-ms/건
payload 바이트 비용  = (0.0511 − 0.0378) ÷ (7.56 KB × 94.8/s) ≈ 0.02 CPU-ms/KB
8,000 B 메시지 1건   = 0.39 + 0.15 ≈ 0.54 CPU-ms  → 건수 비용이 72%

연결 1,800 셀(c3)은 메시지가 44.9 msg/s로 절반인데 CPU는 c1과 같다. 즉 연결 1,508개 추가가 메시지 52.6건/s와 맞먹는 비용이다.

주의. c3·c4는 목표 120 msg/s에 대해 42~45 msg/s만 달성했다(발생기 한계, §8.3). 따라서 연결 축과 메시지 축이 완전히 분리되지 않았고, 위 회귀는 연결 200개 셀의 비교가 1차 근거다.

⑦ 긴 컨텍스트보다 짧은 메시지가 많은 쪽이 더 위험하다. 변경 우선순위는 payload 압축·상한이 아니라 건당 처리 비용 절감(ACK 경량화, 메시지 배칭, 저장 비동기화)이다. payload 상한은 8 KB 수준에서는 부차적이다.

5.4 메시지 저장 — 공용 풀을 포화시켜 일반 조회를 무너뜨린다

① 메시지를 저장한 뒤 전달한다(현재 구조는 커밋 후 ACK).

② 위키 (3)의 "채팅 메시지 증가 → DB 커넥션 대기 → 참여 API 지연" 가설.

③ 응답 경로가 DB 트랜잭션에 묶인 부하. 커넥션 점유시간이 처리량 상한을 만든다.

④ HikariCP 10개(획득 타임아웃 1초)를 조회·승인·혼잡도 저장과 공유한다.

⑤ 저장 없음(c3, §5.3) → 저장만(d1-save-h50) → 저장 + detail 50 RPS (d2-*), control은 d0-rest-control. 트랜잭션 점유시간은 chat_hold_ms=50.

⑥

항목	c3 저장 없음	d1 저장만	d2 저장 + 조회
실제 msg/s	44.9	47.4	37.6
커밋 p95	—	494 ms	109~466 ms
Hikari active (최대 10)	0	10 / 10	7
Hikari 대기	0	53	0
획득 p95	0.97 ms	445 ms	47~214 ms
채팅 저장 오류/s	0	1.02	3.03
backend CPU	0.0388	0.0896	0.0734

같은 시간대 일반 조회(detail 50 RPS, 클라이언트 측정):

구간	p95	p99	실패율
control d0-rest-control	12.1 ms	28.5 ms	0%
treatment d2-rest-treatment	164.8 ms	663.6 ms	1.53%
변화	13.6배	23배	—

⑦ 판정과 변경

증거	결론
저장만으로 풀 active 10/10, 대기 53, 획득 p95 445 ms	커넥션 점유시간이 병목 → 저장 비동기화(큐 + 배치 insert)
MySQL CPU 0.072 cores(배정 0.5의 14%)로 여유	DB 처리 능력이 아니라 풀이 한계 → 풀 증설보다 점유시간 단축
병행 조회 p95 13.6배·실패 1.53%	공용 풀이 장애 전파 경로 → 읽기·쓰기 풀 분리
저장 없음(c3)에서는 풀 지표 전부 0	실시간 경로와 영속 경로 분리가 V2 필수 항목

47 msg/s가 풀을 포화시켰다는 것은 혼잡도 쓰기 37.6 row/s(§3)도 같은 임계 구간임을 뜻한다. 두 쓰기가 동시에 존재하는 V2에서는 이 항목이 조회 지연의 실제 원인이 된다.

5.5 WebSocket 연결이 REST API에 주는 간섭

⑤ control(f1c-rest-control, WS 0) → WS 2,100 유지 상태에서 동일 REST 반복(f1c-rest-treatment). 두 실행을 연속 배치해 조건을 맞췄다.

⑥

항목	control	treatment (WS 1,642개 유지)	변화
REST p95	11.0 ms	167.2 ms	15배
REST p99	33.4 ms	914.8 ms	27배
REST 실패율	0%	4.54%	—
dropped iterations	0	24	—
backend CPU	0.032	0.061	1.9배
heap 최대	123 MB	277 MB	2.3배
GC pause p95	3.1 ms	257 ms	82배
working set	601 MB	632 MB (limit 768)	+5%
Hikari 대기	0	0	변화 없음
MySQL CPU	0.017	0.018	변화 없음
Next.js CPU	변화 없음	변화 없음	—

⑦ 판정

• REST p95가 control 대비 15배, p99 27배 악화되고 오류가 4.54% 발생했다. 403의 판정 기준(20% 악화)을 크게 넘는다.
• 악화의 동반 지표는 **GC pause(3.1 → 257 ms)와 heap(123 → 277 MB)**이다. Hikari와 MySQL은 변화가 없으므로 원인은 DB가 아니라 같은 JVM의 메모리·GC다.
• Next.js·MySQL 컨테이너는 영향이 없었다. 즉 호스트 자원 경합이 아니라 Spring 컨테이너 내부의 공유 자원 경합이다. 컨테이너 quota 격리는 작동했다.
• 결론: REST와 WebSocket의 프로세스 분리가 V2 설계의 1순위다. 같은 JVM에 두는 한, 채팅 연결이 늘 때마다 일반 API의 꼬리 지연과 오류율이 함께 올라간다.

---

6. V1 한계 종합

6.1 장애 전파 지도 (실측값 부착)

[행사 유입]                          [인기 팟 마감]              [조회 증가]
 WS 연결 1,700개에서 포화             동시 승인 20건 초과          641 RPS까지 여유
   │ handshake 30초 타임아웃            │ 풀 10개 고갈              │ throttling 0
   │ (목표 3,000의 57%)                 │ 획득 p95 1,060ms          │
   ↓                                    ↓                           ↓
 같은 JVM heap·GC 압박                공용 HikariCP 10             (병목 아님)
 GC pause 3.1 → 257ms                  │
   │                                    ├─ 좌석 승인 실패 59.5%
   ↓                                    ├─ 일반 조회 p99 48배
 일반 REST p99 27배 · 오류 4.5%         └─ 채팅 저장 오류 1~3/s
                                            │
 [채팅 메시지 저장 47 msg/s] ───────────────┘
   풀 active 10/10 · 대기 53 → 일반 조회 p95 13.6배 · 실패 1.53%

세 시나리오가 서로 다른 입구로 들어와 같은 두 자원(Spring JVM, Hikari 풀 10개) 에서 만난다. 이것이 V1 구조의 핵심 한계다.

6.2 V1이 감당 가능한 규모

축	V1 실측 한계	V2 요구	충족
조회 RPS	641 RPS 이상 (knee 미도달)	60.4 RPS	✅ 10배 여유
행사 API 피크	641 RPS 이상	140 RPS	✅
WS 신규 연결률	20 conn/s에서 33 ms	10 conn/s	✅
WS 동시 연결	약 1,700개	3,000개	❌ 57%
동시 좌석 승인	20건 미만	재산정 필요	❌
채팅 저장 처리량	47 msg/s에서 풀 포화	미산정	❌
혼잡도 쓰기	미측정 (47 write/s 간접)	37.6 row/s	⚠

---

7. V2 인프라 구성 변경 결정

우선순위	변경	근거 (절·지표)	기대효과	재검증
1	REST와 WebSocket 프로세스 분리	§5.5 REST p99 27배·오류 4.54%, GC pause 82배 / §5.1 연결 상한 1,700	채팅 연결 증가가 일반 API 지연·오류로 번지지 않음	분리 후 §5.5 control/treatment 재실행, p95 악화 20% 미만 확인
2	채팅 저장 비동기화 (큐 + 배치 insert)	§5.4 풀 active 10/10·대기 53·획득 p95 445 ms, 병행 조회 p95 13.6배	WS 응답 경로에서 DB 트랜잭션 제거, 풀 점유시간 단축	동일 47 msg/s에서 풀 대기 0·조회 p95 변화 20% 미만
3	읽기·쓰기 커넥션 풀 분리	§4.6 동시 20건에서 풀 고갈 / §5.4 / §3.7 혼잡도 쓰기	쓰기 경합이 조회 API를 잠식하지 못하게 격리	e-mix·d2를 동일 조건으로 재실행
4	좌석 차감을 DB row lock 밖으로 (Redis 원자 카운터 + 멱등키)	§4.6 lock p95 1,046 ms, 실패율 59.5~79.9%	lock 보유 시간 제거 → 풀 점유 동반 제거	동시 50·100건에서 실패율 0%·정합성 유지
5	혼잡도 최신값 캐시 + 이력 비동기 저장	§3.7 (간접 근거)	조회당 쓰기 2건 → 캐시 미스 시에만	혼잡도 endpoint 추가 후 K=1·5 측정
6	연결 상한 1,700 원인 규명 후 결정 (인스턴스 상향 / Nginx 조정 / WS 게이트웨이)	§5.1 heap·CPU로 설명 불가	3,000 연결 목표 달성	§8.4 절차
—	조회 때문의 scale-out·인스턴스 상향	§3.6 641 RPS에서 throttling 0	—	근거 없음, 보류

적용 순서는 위 순번대로 한 번에 하나만 적용하고, 같은 시나리오·같은 RUN_ID 규칙으로 재측정한다.

---

8. 측정의 신뢰 범위

8.1 픽스처와 실제 서비스의 차이

측정 대상은 perf/ws-lab/demo 합성 픽스처다. 실제 moyeota/be가 아니다.

• fan-out이 없다. 핸들러가 발신자에게만 ACK/echo를 보낸다. 4인 팟에서 1건이 3명에게 전달되는 비용(§5.3의 3배)은 미측정이다.
• 방(room) 개념이 없어 "한 방 집중 ↔ 여러 방 분산" 축을 측정하지 못했다.
• 인증·권한 검증이 없다(토큰 미사용). 실제 토큰 검증 CPU는 빠져 있다.
• 혼잡도 외부 API(FastAPI·LLM) 호출 경로가 없다.
• chat_hold_ms=50, lock_hold_ms=100은 Thread.sleep 합성 지연이다.
• 조회 endpoint가 실제 쿼리보다 단순하다. §2.2와 §3.6의 절대 RPS는 상한 보증값이 아니다.

8.2 확인된 계측 오류 (결론에 사용하지 않은 값)

값	문제	대응
derived-*.csv의 rest_p95_ms	거의 모든 구간에서 0.95 ms 고정 → 히스토그램 분위 산정 오류	지연은 k6 클라이언트 값만 사용
nginx_cpu_cores	전 구간 0.0004 cores 고정 → 시리즈 매칭 오류 의심	§5.1에서 Nginx를 원인으로 지목하지 않음
chat_errors·seat_errors	15~20초 창에서 increase()가 0 반환	서버 5xx rate로 대체
WS 오류율 53~57%	실패 후 재접속을 반복해 분모가 커짐(ws_connections_opened 39,098)	동시 연결 최대값(lab_ws_connections)을 1차 근거로 사용

URI별 분리가 필요한 구간은 다음 쿼리로 재집계해야 한다.

histogram_quantile(0.95, sum by (le) (rate(http_server_requests_seconds_bucket{uri!~"/actuator.*"}[1m])))

8.3 측정창과 대조군의 약점

• 블록당 75~150초, 반복 1회. g-c3-repeat 대비 변동 8%를 관측했으므로 30% 미만 차이는 판정에 쓰지 않았다.
• 30분 idle hold와 soak이 없어 연결 누수·완만한 heap 증가는 미검출이다. working set이 세션 전반에 576 → 651 MB로 상승했으나(limit 768 MB) 원인을 누수로 단정할 수 없다.
• c3·c4·d1·g가 목표 120 msg/s에 대해 42~47 msg/s만 달성했다. 메시지율 축이 고정되지 않았다.
• 분산 팟 대조군(e-dist-c50)은 팟이 2개뿐이어서 대조가 약하다.
• CPU credit 잔량을 기록하지 못했다. 세션 후반 블록(f, g)이 credit 영향을 받았는지 확인할 수 없다.
• 서버 설정 축(풀 10↔20, WS_PER_CONNECTION_BYTES, -Xmx)은 재배포가 필요해 이 창에서 다루지 않았다.

8.4 다음 측정 창의 1순위 — 연결 상한 1,700의 원인 규명

§5.1의 불일치를 해소하지 못하면 §7의 6번 결정을 내릴 수 없다. 순서대로 수행한다.

1. 연결을 1,500 → 1,600 → 1,700 → 1,800으로 100개 단위로 올리며 Nginx 컨테이너의 working set과 CPU를 함께 본다 (128 MB 한도 가설 검증).
2. 같은 구간에서 Nginx error log와 node_netstat_TcpExt_ListenOverflows, 호스트 소켓 수·FD를 확인한다.
3. Nginx를 우회해 Spring에 직접(내부 경로) 연결을 올려 동일 상한이 재현되는지 본다. 재현되면 Spring, 재현되지 않으면 Nginx다.
4. 로컬 발생기를 2대로 나눠 같은 상한이 나오는지 확인한다(발생기 배제).
5. 원인이 Nginx 메모리면 proxy_buffering off·버퍼 축소 또는 Nginx 자원 증설로, Spring이면 WS 게이트웨이 분리로 간다.

8.5 그 외 남은 항목

• fan-out 비용(수신자 1·3·9명) — 핸들러에 방·세션 레지스트리 추가 후 측정
• 혼잡도 API 부하 (K=1·5)
• 행사 burst 삼각형 부하 140 RPS
• 장애·복구 RTO/RPO
• 풀 크기 대조(10↔20)와 -Xmx 조정 실험