404 V1 limit analysis report outline - 100-hours-a-week/KTB4-3rd-CLOUD GitHub Wiki

404 V1 한계 분석 보고서 — 문서 골격

이 문서는 내용을 쓰기 전에 목차와 각 절이 무엇을 증명해야 하는지를 고정한 것이다. 부하테스트 설계·실행은 403에, V1/V2 흐름도는 KTB4-모여타-v1-v2-lock-flow.drawio에 있다.

0. 작성 규칙

0.1 모든 장은 같은 사슬을 따른다

서비스 특성만 쓰고 끝내면 안 된다. 각 장은 예외 없이 7개 소절을 같은 순서로 가지며, 앞 소절이 뒤 소절의 근거가 된다.

① 서비스 동작 (유저플로우의 어느 구간)
    ↓ 그래서 얼마나 들어오는가
② 예상 트래픽 지표 (숫자)
    ↓ 그래서 어떤 성격의 부하인가
③ 부하 특성 (요청 유형 · 동시성 · 지속시간 · 데이터 크기)
    ↓ 그래서 어떤 자원을 쓰는가
④ 사용하는 인프라 자원 (경로 + 자원 종류 + V1 배정량)
    ↓ 그래서 무엇을 재야 하는가
⑤ 측정 설계 (시나리오 · 부하 단계 · control/treatment)
    ↓ 실제로 무엇이 변했는가
⑥ 측정 결과 (지표 변화 · 최초 포화 자원 · C_knee)
    ↓ 그래서 무엇을 바꾸는가
⑦ 판정과 인프라 구성 변경

⑦을 쓸 수 없는 장은 ⑤가 잘못 설계된 것이다. 반대로 ②의 숫자 없이 ⑥의 결과만 있으면 "이 정도면 충분한가"를 판단할 수 없다.

0.2 각 장의 첫 줄은 한 줄 결론

독자가 사슬을 먼저 보게 한다.

결론. 채팅 연결 N개에서 heap이 X MB/연결로 증가해 -Xmx512m의 Y%를 점유하고, 같은 컨테이너의 REST p95가 Z% 악화된다. → WebSocket을 별도 프로세스로 분리한다.

0.3 숫자에는 출처를 붙인다

종류	표기 방법
트래픽 가정	내부 가정인지 외부 공개값인지 명시, 계산식 노출
부하테스트 실측	`RUN_ID` + 측정창 길이 + 반복 횟수
인프라 지표	지표 이름(PromQL) + Grafana 패널 이름
파생값	계산식 (403 §2.2)

단일 측정(반복 없음)은 그 사실을 표에 남기고, 지연 차이는 30% 이상일 때만 실재로 인정한다. CPU credit 소모 구간의 저하는 용량 한계로 쓰지 않는다.

1. 서비스 개요와 유저플로우

목적: 이후 모든 장의 ①이 참조할 구간 이름을 확정한다.

1.1 서비스 정의 — 판교 출퇴근 매칭·채팅·정산·게시글
1.2 유저플로우 (노션 유저플로우 다이어그램 삽입)
- 각 구간에 이 문서에서 쓸 이름을 붙인다: 탐색·조회 / 팟 상세 / 참여 요청 / 좌석 승인 / 채팅 연결 / 채팅 메시지 / 정산 / 혼잡도 조회
1.3 구간별 기능 요구와 실시간성 요구
- 어느 구간이 동기 응답이어야 하는지, 어느 구간이 지연을 허용하는지. 이 판단이 7장·8장의 "비동기화 가능 여부" 근거가 된다.
1.4 V1 아키텍처 (drawio: AWS 서비스 배치)
- 단일 AZ · Public Subnet · Prod/Dev EC2 2대 · 컨테이너 4개

①에 쓸 문장 형태: "사용자가 채팅 연결 구간에 진입하면 클라이언트가 Nginx를 거쳐 Spring Boot에 WebSocket 핸드셰이크를 보내고, 매칭 성사까지 연결을 유지한다."

2. 예상 트래픽 지표

목적: 이후 모든 장의 ②가 참조할 기준 숫자를 한곳에 둔다.

2.1 V1 규모 가정 — DAU 1,500 / 피크 조회 1.25 RPS / 쓰기 0.27 RPS
2.2 V2 성장 가정 — 수도권 업무지구 6개 거점 / MAU 115만 / DAU 3.6만
2.3 DAU → RPS 환산식과 근거 (402 §2 재사용, 외부 공개값과 내부 가정 분리)
2.4 구간별 트래픽 분해표 ← 각 장의 ②가 이 표의 한 행을 가져간다

구간	피크 RPS 또는 동시성	산출 근거	관련 장
탐색·조회	14.0 RPS	세션당 4건 × 피크 세션률	9장
팟 상세	14.0 RPS	세션당 4건	9장
혼잡도 조회	10.5 RPS	세션당 3건	(범위 밖)
참여·승인 쓰기	3.5 RPS, 인기팟 동시 N건	세션당 1건 + 인기팟 집중	7장
채팅 연결	동시 1,800 (1,575~2,100)	이벤트 사용자 50% 접속	3·4·8장
채팅 메시지	36 msg/s (inbound)	접속자 10분간 6건	5·6장
행사 종료 burst	180 RPS	삼각형 부하, 10분	(범위 밖)

2.5 이번 측정에서 다루지 않은 구간과 이유 (혼잡도 외부 API, burst)

3. 채팅 연결 유지 — 연결 수가 Spring 자원을 점유하는가

3.1 서비스 동작 — 채팅 연결 구간, 매칭 성사까지 연결 유지, 1시간 무활동 시 종료
3.2 예상 트래픽 — 동시 1,800 연결 (탐색 범위 3,000)
3.3 부하 특성 — 장시간 유지되는 상태 보유형 부하. 요청량이 아니라 세션 수가 자원을 점유한다. 메시지가 없어도 비용이 0이 아니다.

3.4 사용하는 인프라 자원

클라이언트 → Nginx(0.25 CPU/128MB, FD 2개/연결)
          → Spring Boot(0.75 CPU/768MB, -Xmx512m, Tomcat max-connections 8192, FD 16384)
자원: JVM heap(세션 객체) · direct buffer(NIO) · FD · Tomcat 커넥션 슬롯

3.5 측정 설계 — ws-connect.js, 0→3,000 선형 램프. 램프를 독립변수로 써서 lab_ws_connections 대비 자원을 회귀한다. REST 없음(순수 단가). RUN_ID=a-ramp3000

3.6 측정 결과

지표	출처	값
연결당 heap	`collect-window.py` 램프 회귀 `heap_bytes_per_conn`
연결당 direct	동 `direct_bytes_per_conn`
1,000 연결당 CPU	동 `cpu_cores_per_1k_conn`
연결 3,000에서 working set	`backend_ws_mb` (한계 768MB)
수용 가능 연결 상한	(512MB×0.7 − 기저 heap) ÷ 연결당 heap

그래프: JVM heap used, Container working-set memory, Container CPU cores

3.7 판정과 변경 — 상한이 예측 피크 2,100을 밑돌면 연결 수 자체가 V1 한계. 선택지: WS 프로세스 분리 / backend 메모리 증설 / 세션 상태 축소. 재검증 방법도 함께 적는다.

4. 채팅방 진입 폭주 — 연결 시도율이 진입 계층을 포화시키는가

4.1 서비스 동작 — 매칭 성사·행사 종료 직후 다수가 동시에 채팅방 진입
4.2 예상 트래픽 — 6 conn/s (peak 7), 탐색 20·50·100·200 conn/s
4.3 부하 특성 — 짧고 비싼 순간 부하. 연결 수립마다 TLS 핸드셰이크가 발생한다
4.4 인프라 자원 — Nginx 0.25 CPU · worker_processes 1 · accept queue · listen backlog. 이 계층이 Spring보다 먼저 포화될 수 있다
4.5 측정 설계 — 연결 1,000 고정, CONNECT_RATE 20/100/200. 측정창은 ramp 구간. RUN_ID=b-rate20|100|200
4.6 결과 — handshake(ws_connecting) p95/p99, 101 성공률, nginx_cpu_cores, Nginx active/reading/writing/waiting, listen overflow
4.7 판정 — Nginx CPU가 먼저 quota를 채우면 한계는 진입 계층이다. 변경: Nginx CPU·worker 재배분 / TLS 종료 위치 변경 / ALB 도입 검토

5. 채팅 메시지 유형 — 무엇이 CPU와 메모리를 더 먹는가

5.1 서비스 동작 — 채팅 메시지 구간. 긴 안내·정산 내역과 짧은 대화가 섞인다
5.2 예상 트래픽 — 36 msg/s (탐색 120), 4인 팟
5.3 부하 특성 — 두 축이 섞인 부하. 메시지 건수와 payload 바이트가 각각 다른 비용을 만든다. 둘을 분리하지 않으면 원인을 못 찾는다
5.4 인프라 자원 — Spring 스레드·프레임 처리·역직렬화(건수) / 버퍼·직렬화·네트워크(바이트) / heap allocation rate와 GC

5.5 측정 설계 — 2×2 요인 설계, 120 msg/s 고정, echo 경로(저장 없음)

셀	연결	payload	RUN_ID
기준	200	256 B	`c1-200c-256b`
큰 컨텍스트·적은 연결	200	8,000 B	`c2-200c-8000b`
짧은 메시지·많은 연결	1,800	256 B	`c3-1800c-256b`
교차	1,800	8,000 B	`c4-1800c-8000b`

5.6 결과 — 회귀 CPU ≈ a + b·R + c·(R×S)로 메시지당 CPU-ms와 KB당 CPU-ms를 분리. GC pause·allocation rate 비교. 반복은 g-c3-repeat
5.7 판정 — b 지배 → 배칭·ACK 경량화 / c 지배 → payload 상한·압축·본문 분리

6. 채팅 메시지 영속화 — 비동기·캐시가 필요한가

6.1 서비스 동작 — 메시지 저장 후 전달(현재는 커밋 후 ACK)
6.2 예상 트래픽 — 36 msg/s (탐색 120)
6.3 부하 특성 — 응답 경로가 DB 트랜잭션에 묶인 부하. 커넥션 점유시간이 곧 처리량 상한을 만든다
6.4 인프라 자원 — HikariCP 10개(연결 획득 타임아웃 1s) · MySQL 0.5 CPU · redo·fsync · EBS. 이 풀을 REST 조회·승인과 공유한다
6.5 측정 설계 — 저장 없음(5장 c3) → 저장(d1-save-h50) → 저장+REST(d2-*, control d0-rest-control). chat_hold_ms로 점유시간 조절
6.6 결과 — chat_commit_p95_ms, hikari_pending_max, hikari_acquire_p95_ms, chat_errors, 병행 REST p95·5xx. 예측(10 ÷ 점유시간)과 실측 비교표
6.7 판정 — 풀 대기 지배 → 저장 비동기화(큐+배치 insert) / MySQL I/O 지배 → 배치 커밋·DB 분리 / 조회 악화 → 캐시·읽기 풀 분리

7. 인기 팟 좌석 승인 경합 — 사용자 증가가 다른 API를 무너뜨리는가

drawio의 "V2 트래픽 시나리오 — 인기팟 좌석 Lock 경합" 경로를 그대로 검증하는 장.

7.1 서비스 동작 — 좌석 승인 구간. 동일 pod_id에 요청이 집중된다
7.2 예상 트래픽 — 쓰기 3.5 RPS이지만 인기팟은 같은 행에 동시 N건
7.3 부하 특성 — 직렬화되는 경합 부하. RPS가 아니라 동시 도착 수가 변수. 대기 중에도 커넥션을 점유한다
7.4 인프라 자원 — SELECT ... FOR UPDATE row lock · innodb_lock_wait_timeout 3s · 공용 Hikari 10 · Spring 스레드
7.5 측정 설계 — hot-row.js 동일 팟 동시성 5/20/50/100(e-same-c*), 분산 팟 대조군(e-dist-c50), REST 병행(e-mix-*), control e0-rest-control

7.6 결과 — 두 실패 모드를 분리해서 제시

풀 timeout : 동시성 > 10 → 획득 1s 초과 → 503
             증거 hikari_pending_max, hikari_acquire_p95_ms ≈ 1000ms
lock wait  : 동시성 × lock_hold > 3s → 503
             증거 innodb_row_lock_current_waits, seat_lock_p95_ms ≈ 3000ms

정합성: approved + remaining == capacity, 음수 좌석·중복 승인 0건

7.7 판정 — 동일 팟만 악화되고 분산은 평탄 → hot-row 구조 변경 (Redis 원자 카운터·멱등키·대기열). 병행 REST까지 악화 → 풀 분리·타임아웃 조정

8. 실시간 연결이 일반 API에 주는 간섭 — REST와 WS를 분리해야 하는가

V2 설계의 핵심 결정이 걸린 장.

8.1 서비스 동작 — 채팅 연결을 유지한 사용자가 동시에 조회·상세를 호출
8.2 예상 트래픽 — WS 1,800~2,100 유지 + REST 50 RPS
8.3 부하 특성 — 자원 공유형 간섭. 두 부하가 같은 컨테이너에 있다
8.4 인프라 자원 — 같은 0.75 CPU · 같은 512MB heap · 같은 Tomcat 스레드 · 같은 Hikari 10. frontend·mysql은 별도 quota이므로 함께 악화되면 원인이 다르다
8.5 측정 설계 — control(f1c-rest-control) → WS 2,100 유지 + 동일 REST(f1c-rest-treatment). 두 실행을 연속 배치해 credit 조건을 맞춤

8.6 결과

항목	control	treatment	변화율
REST p95 / p99 / 오류율
backend CPU · throttling
heap · GC pause · Tomcat busy
frontend · mysql CPU (격리 확인)
CPU credit balance (편향 확인)

8.7 판정 — p95 20% 이상 악화 + backend 자원 상관 → WS 분리. frontend·mysql 동반 악화 → 호스트 CPU·credit 문제로 재해석

9. 일반 조회 트래픽 증가 — t3.medium 컨테이너는 어디서 꺾이는가

9.1 서비스 동작 — 탐색·조회, 팟 상세
9.2 예상 트래픽 — 조회 14 RPS + 상세 14 RPS, 혼합 피크 45.5 RPS
9.3 부하 특성 — 정상 상태의 처리량 부하. 요청당 비용이 곧 용량을 정한다
9.4 인프라 자원 — DB 미사용 경로(Spring CPU·Tomcat) vs DB 사용 경로(+Hikari·MySQL)
9.5 측정 설계 — light 50→700, detail 50→300, 각 90초 단계, WS 없음. RUN_ID=f-light-*, f-detail-*
9.6 결과 — RPS–p95 곡선, 요청당 CPU-ms, quota 이론 상한 = 750 ÷ 요청당 CPU-ms, throttling 시작 RPS, C_knee/C_safe, credit balance 추이
9.7 판정 — 목표 피크 대비 여유율. light만 평탄하고 detail이 꺾이면 한계는 DB 경로. 변경: 인스턴스 상향 / quota 재배분 / 쿼리·인덱스·캐시

10. V1 한계 종합

10.1 최초 포화 자원 순위표 — 어느 부하가 어느 자원을 가장 먼저 포화시켰는가 | 순위 | 부하 특성 | 최초 포화 자원 | C_knee | 목표 피크 대비 여유 | 근거 RUN_ID |
10.2 장애 전파 지도 — drawio 경로에 실측값을 얹은 그림 (어느 지표가 몇에서 다른 기능을 무너뜨렸는가)
10.3 V1이 감당 가능한 규모 재산정 — DAU·동시 연결·RPS 기준으로

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

11.1 결정표 — 증거 → 변경 → 기대효과 → 검증 방법 | 관측 증거(장·지표) | 구성 변경 | 기대효과 | 재검증 시나리오 |
11.2 변경안 상세 — 각 항목마다 대안과 탈락 이유까지 (REST·WS 분리 / 메시지 브로커 / 저장 비동기화 / hot-row 구조 / DB 분리·RDS / scale-out·LB / 인스턴스 타입)
11.3 적용 순서와 기준 — 한 번에 하나만 적용하고 동일 시나리오로 재측정
11.4 V2 목표 SLO와 수용 기준

12. 측정의 한계

결론의 신뢰 범위를 스스로 밝히는 장. 이걸 빼면 위의 숫자가 과대평가된다.

12.1 픽스처와 실제 서비스의 차이 — fan-out·방 개념 없음, 인증 없음, 쿼리 복잡도 차이, 합성 지연(chat_hold_ms·lock_hold_ms)
12.2 측정창과 반복 — 단일 측정, 90~150초 창, 30분 idle hold 없음, soak 없음
12.3 CPU credit — 측정 구간별 credit 상태와 보정 방법
12.4 부하 발생기 한계 — 로컬 1대, 목표 전달률·dropped iterations
12.5 다음 창에서 측정할 항목 — 풀 크기 대조(10↔20), WS_PER_CONNECTION_BYTES, 혼잡도 외부 API, 행사 burst, 장애·복구(RTO/RPO)

부록

A. 실행 명령과 RUN_ID 목록 (403 §13.3)
B. 지표 정의와 PromQL (403 §2.1)
C. 파생값 계산식 (403 §2.2)
D. 원시 결과 위치 — loadtest-scenarios/results/, runs.tsv, derived-*.csv, Grafana 구간 링크, TSDB 보관 위치
E. 테스트 환경 고정값 — target.env, 이미지 digest, 컨테이너 자원 예산, 픽스처 run 설정

이 골격을 채우는 순서

1·2장을 먼저 확정한다. 여기서 정한 구간 이름과 숫자를 3~9장이 계속 참조한다.
3~9장은 ⑤⑥을 먼저 채운다(측정 데이터가 이미 있으므로). 그다음 ①②③④를 역방향으로 검산하면 "측정하지 않은 자원을 근거로 쓴 장"이 드러난다.
⑦은 10·11장을 쓰면서 확정한다. 장별 ⑦이 서로 충돌하면 11.3의 적용 순서로 해소한다.
12장을 마지막이 아니라 3~9장을 쓰는 도중에 함께 채운다. 그 장에서 못 본 것을 그때 적어야 빠지지 않는다.