V1 부하테스트 실행 문서

1. 목적과 범위

이 문서는 MAU 1,150,000명을 기준으로 V1의 지속 처리량과 병목 지점을 수치화하고, 그 결과로 수직 확장·DB 분리·외부 호출 격리·WebSocket 분리 여부를 결정하기 위한 실행 기준이다.

측정 대상은 로컬에서 실행한 k6가 V1의 공개 진입점으로 보낸 트래픽이다. 즉, 부하 경로에 public DNS/EIP, Internet routing, TLS, Nginx를 포함한다. V1 private IP는 부하 대상이 아니라 Prometheus가 exporter를 수집하는 주소로만 사용한다.

기존 perf/ 부하테스트 코드는 사용하지 않는다. 새 코드는 loadtest-scenarios/에 독립적으로 작성되어 있다.

판정 정의

C_knee = SLO 또는 데이터 정합성이 처음 깨지는 최대 지속 부하
C_safe = C_knee × 0.7

응답시간·오류율·정합성을 1차 판정값으로 사용하고 CPU, GC, HikariCP, MySQL lock, 디스크와 네트워크 지표는 원인 분석용 증거로 사용한다.

2. MAU·DAU·RPS 재산정

2.1 고정값과 벤치마크의 역할

모여타 MAU는 1,150,000명으로 고정한다. BlaBlaCar 수치는 모여타의 MAU를 다시 계산하는 침투율이 아니라, 운영 로그가 없을 때 DAU/MAU 활동률과 세션 빈도를 정하는 참고값으로만 사용한다.

BlaBlaCar 스페인 2025 공식 자료에는 다음 값이 공개되어 있다.

• 월평균 고유 활성 사용자: 300,000~400,000명
• 연간 카풀 승객: 4,000,000명

출처: BlaBlaCar Spain 2025 activity report

연간 승객 수를 일간 활동 프록시로 변환한다.

일 평균 승객 활동 = 4,000,000 ÷ 365 = 10,959명/day

DAU/MAU 하단 = 10,959 ÷ 400,000 = 2.740%
DAU/MAU 중앙 = 10,959 ÷ 350,000 = 3.131%
DAU/MAU 상단 = 10,959 ÷ 300,000 = 3.653%

따라서 고정 MAU에 적용한 DAU 범위는 다음과 같다.

구분	활동률 프록시	계산	추정 DAU
하단	2.740%	1,150,000 × 2.740%	31,507
중앙	3.131%	1,150,000 × 3.131%	36,008
상단	3.653%	1,150,000 × 3.653%	42,009

이 값은 고유 로그인 DAU가 아니다. 하루 복수 승객 활동이 합쳐지거나 운전자·검색만 한 사용자가 빠질 수 있으므로, 실제 로그가 확보되면 고유 DAU·세션 수·세션당 요청 수로 교체한다.

2.2 기준 혼합 RPS

현재 시퀀스의 한 세션을 HTTP 13건으로 정의한다.

목록·검색 4건 + 상세 4건 + 혼잡도 3건 + 쓰기 1건 + 인증·기타 1건
= 세션당 HTTP 13건

피크 4시간에 일간 세션의 70%가 집중되고, 그 안에서 순간 피크 계수 2.0이 적용된다고 가정한다.

피크 세션 시작률
= DAU × (일 세션/DAU) × 70% ÷ (4 × 3,600초) × 2.0

피크 HTTP RPS
= 피크 세션 시작률 × 13건

일 세션/DAU를 1회로 둔 결과는 다음과 같다.

구분	DAU	피크 세션 시작률	계산 HTTP RPS
하단	31,507	3.063/s	39.82
중앙	36,008	3.501/s	45.51
상단	42,009	4.084/s	53.09

따라서 운영 데이터가 없는 첫 기준 부하는 50 RPS로 고정한다. 중앙값 45.51 RPS에서의 작업별 분배는 다음과 같다.

작업	세션 비율	중앙 RPS
목록·검색	4/13	14.00
상세	4/13	14.00
혼잡도	3/13	10.50
쓰기	1/13	3.50
인증·기타	1/13	3.50

세션이 하루 2회·3회라면 RPS는 선형으로 약 91·137 RPS가 된다. 이는 한계값이 아니라 민감도 확인값이다.

2.3 용량 탐색 단계

기준값 재현 후에는 다음 순서로 한 단계씩 올린다.

25 → 50 → 75 → 100 → 150 → 200 → 300 → 400 → 512 RPS

각 단계는 워밍업 5분, 측정 10분, 동일 조건 3회 반복을 기본으로 한다. 최초 SLO 위반 단계의 앞뒤를 10~20% 간격으로 재측정해 C_knee를 좁힌다.

2.4 행사 burst

행사 사용자 수는 DAU의 10%, 이벤트 세션은 사용자당 HTTP 15건, 그중 50%가 WebSocket에 접속하고 접속자당 10분 동안 메시지 6건을 보낸다는 가정이다.

0 → 5분 동안 peak까지 상승 → 5분 동안 0까지 하강
HTTP peak RPS = 2 × 이벤트 사용자 × 15 ÷ 600초

구분	이벤트 사용자	HTTP peak	최종 WS 연결	연결률	inbound 메시지
하단	3,151	157.5 RPS	1,575	5.25/s	31.5/s
중앙	3,601	180.0 RPS	1,800	6.00/s	36.0/s
상단	4,201	210.0 RPS	2,100	7.00/s	42.0/s

예상 burst는 160 → 180 → 210 RPS, 탐색 burst는 250 → 300 → 400 → 512 RPS로 실행한다. WebSocket은 연결 수와 메시지 수를 HTTP와 별도로 증가시킨다.

3. 부하테스트 환경 설정

3.1 실행 토폴로지

로컬 k6 HTTP 프로세스 ─┐
                       ├─ Public DNS/EIP → TLS → Nginx → Spring ─┬─ MySQL
로컬 k6 WS 프로세스 ───┘                                          └─ FastAPI/외부 API

V1 EC2 ── Node Exporter / cAdvisor / Spring metrics / MySQL exporter / Nginx exporter
             │
             └─ private scrape ── 임시 Prometheus + Grafana EC2

• 부하 발생기는 EC2에 만들지 않고 로컬에서 실행한다.
• HTTP와 WebSocket은 로컬에서 별도 프로세스로 실행한다.
• BASE_URL은 https://, WS_URL은 wss:// public 주소만 사용한다.
• target_private_ip는 Prometheus scrape 전용이며 k6 대상에 넣지 않는다.
• 로컬 CPU 60% 미만, swap 0, 업로드 대역폭 70% 미만, dropped iterations 0, 목표 전달률 95% 이상을 유지한다.

3.2 Terraform 스택의 책임

loadtest-infra/는 기존 infra/와 별도 state를 사용한다. 다음만 관리한다.

• 임시 Prometheus/Grafana EC2 및 EIP
• Prometheus 결과 보관용 private S3 bucket
• monitoring security group
• 기존 V1 SG에 exporter port를 임시로 허용하는 ingress rule
• 기존 V1 EC2에 exporter를 설치·제거하는 SSM Command document

이 스택은 애플리케이션 컨테이너를 생성하지 않는다. 대상 애플리케이션은 기존 V1 배포를 사용해야 한다. 현재 V1 이미지 원천은 infra/ecr.tf의 ECR repository이며, 애플리케이션 배포가 완료되어야 테스트를 시작할 수 있다.

서비스	이미지 원천
Nginx	moyeota/nginx (Amazon ECR)
Frontend	moyeota/fe (Amazon ECR)
Backend	moyeota/be (Amazon ECR)
AI/FastAPI	moyeota/ai (Amazon ECR)

docker ps에 loadtest-node-exporter와 loadtest-cadvisor만 보이면 관측 컨테이너만 준비된 것이며, 부하 대상 애플리케이션은 아직 준비되지 않은 상태다. 애플리케이션은 ECR digest, compose.yaml, runtime.env, release.env를 기존 배포 절차(SSM/CI)로 배포한다. loadtest-infra의 Prometheus/Grafana compose가 애플리케이션을 대신 실행하지 않는다.

3.3 모니터링 컨테이너 원천

모니터링 EC2의 user data가 Docker와 Compose를 설치하고 다음 이미지를 pull한다.

컨테이너	이미지	역할
Prometheus	prom/prometheus:v3.13.3	5초 scrape, 시계열 저장
Grafana	grafana/grafana:13.2.1	대시보드
Node Exporter	quay.io/prometheus/node-exporter:v1.12.1	V1 호스트 지표
cAdvisor	ghcr.io/google/cadvisor:v0.60.5	컨테이너 지표

Node Exporter와 cAdvisor는 기존 V1 EC2에 SSM 명령으로 설치한다. Node Exporter가 host network로 실행되어 docker ps에 포트가 표시되지 않는 것은 정상이다. cAdvisor는 8081:8080으로 노출된다.

3.4 k6 코드와 입력 파일

파일	용도
smoke.js	다섯 작업의 기능·인증·경로 확인
http-mixed.js	4:4:3:1:1 혼합 HTTP RPS
http-operation.js	하나의 작업 그룹만 고정해 T2·T4·T5·T6·T7 측정
event-burst.js	삼각형 HTTP burst
hot-row.js	동일 행과 분산 행의 병렬 쓰기 경합
ws-connect.js	메시지 없는 동시 WebSocket 연결
ws-message.js	고정 연결 수에서 aggregate 메시지율
lib/	입력 검증, 인증, 태깅, 공통 metric

입력은 test-data.example.json을 복사해 data/test-data.json으로 만든다. 실제 경로·ID·payload·test token을 입력하고, data/test-data.json은 Git에 커밋하지 않는다. 선택한 scenario의 필수 group에 REPLACE_가 남아 있으면 실행 전에 중단된다.

cp loadtest-scenarios/data/test-data.example.json \
   loadtest-scenarios/data/test-data.json
mkdir -p loadtest-scenarios/results

쓰기 요청은 전용 test account와 disposable/idempotent 데이터를 사용한다. 409를 성공으로 둘 경우에는 예상되는 중복·정원 초과 결과인지 별도 정합성 검증을 수행해야 한다.

3.5 시작 명령

먼저 public 경로로 smoke를 실행한다.

k6 run \
  -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e RUN_ID=smoke-01 \
  --summary-export=loadtest-scenarios/results/smoke-01.json \
  loadtest-scenarios/smoke.js

기준 혼합 부하는 다음과 같이 실행한다.

k6 run \
  -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e TARGET_RPS=50 \
  -e WARMUP=5m \
  -e DURATION=10m \
  -e RUN_ID=http-50-01 \
  --summary-export=loadtest-scenarios/results/http-50-01-summary.json \
  --out json=loadtest-scenarios/results/http-50-01-raw.json \
  loadtest-scenarios/http-mixed.js

실행 전후에 RUN_ID, git/image digest, 대상 public URL, 로컬 장비, 시간대, 동시 WS 수, 테스트 data 버전을 기록한다.

4. 관측 구조와 검증값

4.1 수집 경로

계층	수집 방법	핵심 값
k6 로컬	summary + JSON output	실제 RPS, dropped iterations, p50/p95/p99, status, checks, timeout
호스트	Node Exporter	CPU, load, memory available, filesystem, disk I/O, network, FD
컨테이너	cAdvisor	container CPU, working set, throttling, network, filesystem
Spring	Micrometer /actuator/prometheus	HTTP p95, Tomcat busy/max, JVM heap/direct, GC, Hikari active/pending
MySQL	mysqld-exporter	Threads, row lock wait/deadlock, buffer pool, redo, fsync, disk latency
Nginx	exporter 또는 access log	active/reading/writing/waiting, upstream time, 4xx/5xx, accept 실패
WebSocket	k6 custom + 서버 지표	open/close/error, handshake, ESTABLISHED/TIME_WAIT, message delivery

Prometheus 기본 scrape interval은 5초다. Prometheus Targets 페이지 또는 다음 PromQL로 exporter 상태를 먼저 확인한다.

up{job=~"v1-node|v1-cadvisor|v1-spring|v1-mysql|v1-nginx"}

관측 endpoint가 없는 계층은 원인 분석이 아니라 결과 확인만 가능하다. 특히 Spring·MySQL·Nginx exporter는 자격 증명과 서비스 설정이 필요하므로 Terraform state에 비밀번호를 넣지 않고 별도 구성한다.

4.2 공통 중단 조건

다음 중 하나면 해당 단계를 즉시 중단하고 상태를 보존한다.

• 5xx 또는 timeout이 2분 이상 5% 초과
• OOM, container restart, disk full
• 좌석 초과·잔여 좌석 음수·중복 승인·메시지 유실/중복/순서 오류
• k6 목표 전달률 95% 미만 또는 dropped iterations 발생
• DB가 복구 작업을 요구하는 비정상 상태

5. 서비스 병목 구간별 시나리오

모든 시나리오는 한 번에 한 축만 바꾼다. 각 단계는 기본적으로 5분 warm-up → 10분 measure → 3회 반복이며, 측정 중에는 기존 V1 애플리케이션의 이미지·DB snapshot·CPU credit·exporter 상태를 고정한다.

T2. Spring 요청 처리와 JVM

병목 정의

Nginx와 DB가 여유로운데 Spring의 Tomcat thread, JVM CPU/GC, heap/direct memory, JSON serialization 또는 container throttling이 먼저 포화되는 흐름이다.

k6 HTTPS → Nginx → Spring Controller → service/serialization → response

부하 설계

1. DB·외부 API를 사용하지 않는 가벼운 light group으로 Spring 처리 기준선을 측정한다.
2. 같은 조건에서 실제 list, detail, congestion, write, auth를 각각 http-operation.js로 측정한다.
3. 40 → 46 → 53 RPS로 벤치마크 재현 후 25 → 50 → 75 → 100 → 150 → 200 → 300 → 400 → 512 RPS로 용량을 탐색한다.
4. http_req_duration p95/p99와 Tomcat busy/max, JVM CPU·heap·direct, allocation rate, GC pause, process CPU, context switch, cgroup throttling을 같은 시간축에서 기록한다.

예시:

k6 run \
  -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e REQUEST_GROUP=light \
  -e TARGET_RPS=50 \
  -e WARMUP=5m -e DURATION=10m \
  -e RUN_ID=t2-light-50-01 \
  loadtest-scenarios/http-operation.js

판정

DB·외부 호출 지표가 안정적인데 Tomcat busy/max와 CPU가 함께 포화되면 Spring thread/CPU/직렬화 경로가 1차 병목이다. GC pause와 heap만 증가하면 객체 생성·응답 크기·heap sizing을, throttling이 증가하면 컨테이너 quota와 EC2 크기를 먼저 검토한다.

T4. 상세 조회, N+1과 직렬화

병목 정의

상세 조회 한 건이 참여자·정산·채팅 이력을 여러 query로 읽거나 큰 JSON으로 직렬화하면서 DB query 수, response bytes, Spring CPU/GC가 증가하는 흐름이다.

부하 설계

requests.detail에 다음 fixture를 여러 entry로 준비하고 REQUEST_GROUP=detail 로 고정한다.

• 존재하는 팟: 참여자 0명·소수·큰 목록
• 존재하지 않는 팟: 404가 정상인지 명시
• 작은/중간/큰 채팅·정산 이력
• 동일 ID 반복과 여러 ID 분산

각 fixture를 같은 RPS에서 반복하고 captureResponseBody를 필요한 그룹에만 켜서 response_bytes와 JSON assertion을 수집한다.

k6 run \
  -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e REQUEST_GROUP=detail \
  -e TARGET_RPS=50 -e WARMUP=5m -e DURATION=10m \
  -e RUN_ID=t4-detail-large-50-01 \
  loadtest-scenarios/http-operation.js

측정값과 판정

• HTTP p50/p95/p99, status별 오류율, response bytes
• request당 DB query count 및 SQL 합계시간
• Spring serialization 시간, CPU, allocation, GC
• Hikari active/usage/acquire/pending

DB 시간과 query 수가 함께 증가하면 N+1·인덱스·fetch 전략을 우선 확인한다. DB 시간은 안정적인데 전체 응답과 response_bytes만 증가하면 객체 그래프와 JSON 직렬화·응답 크기가 병목이다. 없는 ID만 느리면 예외 처리나 검증 query를 별도로 확인한다.

T5. 혼잡도 외부 호출

병목 정의

혼잡도 계산 요청이 Spring에서 FastAPI/외부 LLM을 동기 호출하고, 외부 지연이 Tomcat thread·outbound pool·Hikari 또는 transaction 점유로 전파되는 흐름이다.

HTTP → Spring → outbound connection pool → FastAPI/외부 API → Spring response

부하 설계

1. requests.congestion에 동일 spot과 10·100개 spot 분산 fixture를 준비한다.
2. 외부 의존성의 테스트 프로파일을 애플리케이션 설정 또는 별도 stub으로 고정한다. 지연은 50·200·1,000·3,000ms, 오류율은 0·1·5·20%로 분리한다.
3. 각 profile에서 http-operation.js의 REQUEST_GROUP=congestion을 동일 RPS로 실행한다. 지연·오류를 k6가 임의로 주입하는 것이 아니므로, 해당 profile을 통제할 수 없으면 원인 분리 테스트로 간주하지 않는다.
4. retry가 활성화되어 있으면 retry 횟수와 backoff를 고정하고 별도 결과로 기록한다.

측정값과 판정

• Spring HTTP p95/p99, Tomcat busy/max, request queue
• outbound active/pending, timeout, retry, FastAPI worker queue
• Hikari active/pending 및 transaction duration
• 외부 오류율과 사용자 응답 오류율의 전파 비율

외부 지연에 Tomcat·outbound pending이 비례하고 DB도 함께 점유되면 동기 호출 또는 transaction 범위가 넓은 것이다. 외부 오류보다 사용자 오류가 크면 retry storm·fallback·timeout 처리를 별도로 판단한다.

T6. 혼잡도 최신값 upsert와 이력 저장

병목 정의

외부 계산 결과를 최신값 row에 upsert하거나 이력 row로 insert할 때 동일 spot의 row lock, redo/fsync, 인덱스와 Hikari 대기가 증가하는 흐름이다.

부하 설계

외부 결과를 고정한 테스트 profile에서 다음 두 endpoint group을 별도로 만든다.

• congestionWriteLatest: 최신값 upsert만 수행
• congestionWriteHistory: 최신값 upsert + 이력 insert 수행

각 group에 동일 spot, 10개 spot, 100개 spot fixture를 준비하고 http-operation.js를 1 → 5 → 10 → 20 → 40 → 80 writes/s로 실행한다. 최신값과 이력 저장을 동시에 켜지 않고 각각 측정해야 외부 호출 영향을 제거할 수 있다.

측정값과 판정

• Innodb_row_lock_time, current waits, deadlock
• Threads_running, MySQL CPU, buffer pool hit
• redo bytes, fsync, dirty page, EBS queue/await
• Hikari pending, transaction duration, write p95/p99

동일 spot에서만 급격히 나빠지면 hot-row lock, 모든 spot에서 나빠지면 redo·I/O·인덱스 비용으로 분류한다. deadlock·중복 이력·최신값 유실은 latency와 무관하게 실패다.

T7. 참여 요청 저장 기준선

병목 정의

좌석 정원 경합을 제외하고 서로 다른 팟에 참여 요청을 분산했을 때의 순수 insert 처리량을 구하는 단계다.

부하 설계

requests.write에 서로 다른 팟 ID와 사용자·멱등 request ID를 충분히 준비한다. http-operation.js에서 쓰기 group만 고정하고 1 → 5 → 10 → 20 → 40 → 80 writes/s를 실행한다.

k6 run \
  -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e REQUEST_GROUP=write \
  -e TARGET_RPS=20 -e WARMUP=5m -e DURATION=10m \
  -e RUN_ID=t7-write-20-01 \
  loadtest-scenarios/http-operation.js

측정값과 판정

성공·중복·제약조건 오류를 status와 business result로 분리하고 insert p95/p99, Hikari pending, MySQL CPU/lock/I/O, commit·redo를 기록한다. 분산 insert가 안정적인데 동일 팟 승인만 악화되면 일반 쓰기 처리량과 좌석 hot-row 경합을 혼동하지 않는다.

T8. 인기 팟 승인 hot-row

병목 정의

동일 팟의 정원/승인 row를 여러 요청이 동시에 갱신하면서 DB row lock, deadlock, Hikari 대기와 정합성 위반이 발생하는 흐름이다.

부하 설계

hot-row.js가 한 round마다 http.batch로 동일 시점에 요청을 발행하고, round 뒤 hotRowVerify를 호출한다.

• 동일 팟: REQUEST_GROUP=hotRowSame
• 대조군: REQUEST_GROUP=hotRowDistributed
• 동시성: CONCURRENCY=2,5,10,20,50,100
• 기본 round: 3회, round 간격 10초
• 예상 status는 실제 비즈니스 결과만 허용하고, 409를 허용하면 중복/정원 초과 결과임을 별도 기록

k6 run \
  -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e REQUEST_GROUP=hotRowSame \
  -e VERIFY_GROUP=hotRowVerify \
  -e CONCURRENCY=20 -e ROUNDS=3 -e ROUND_PAUSE=10s \
  -e RUN_ID=t8-same-20-01 \
  loadtest-scenarios/hot-row.js

hotRowVerify.assertions의 JSON path와 정원 값은 실제 API 응답에 맞게 수정한다. 잔여 좌석 음수, 승인 수 초과, 중복 승인, deadlock은 단 한 건이어도 실패다. 동일 행과 분산 행의 latency 차이가 row lock의 증거가 된다.

T9. WebSocket 연결 자체

병목 정의

메시지를 보내지 않고 WebSocket handshake, Nginx proxy, Spring session, file descriptor, heap/direct memory가 동시 연결 수에 따라 포화되는 흐름이다.

부하 설계

ws-connect.js를 local process에서 실행한다.

• 수요 재현: 1,575 → 1,800 → 2,100 connections
• 용량 탐색: 500 → 1,000 → 1,500 → 3,000 → 5,000 connections
• 연결률: 5.25 → 6 → 7 → 10 → 20 → 50 connections/s
• 각 단계 idle hold 30분, ramp-down 1분

k6 run \
  -e WS_URL=wss://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e TARGET_CONNECTIONS=1800 \
  -e CONNECT_RATE=6 \
  -e HOLD_DURATION=30m \
  -e RUN_ID=t9-ws-1800-01 \
  loadtest-scenarios/ws-connect.js

측정값과 판정

handshake p95/p99·성공률, k6의 open/close/error, Nginx active/reading/writing/ waiting, Spring FD·ESTABLISHED/TIME_WAIT, heap/direct memory·GC·heartbeat, host/container CPU를 기록한다. 로컬 file descriptor·CPU·네트워크가 먼저 포화되면 서버 한계로 판정하지 말고 generator headroom 실패로 표시한다.

T10. WebSocket 메시지·fan-out·저장

병목 정의

고정된 WebSocket 연결에서 inbound message가 Spring fan-out, outbound delivery, DB commit과 결합되어 REST와 공유 자원을 압박하는 흐름이다.

부하 설계

ws-message.js에서 연결 수를 고정하고 aggregate MESSAGE_RATE를 변경한다.

• 예상 inbound: 31.5 → 36 → 42 msg/s
• 용량 탐색: 10 → 20 → 50 → 100 → 300 msg/s
• 연결 수: 1,575·1,800·2,100 및 필요 시 3,000
• 방 분포: 한 방 집중, 여러 방 분산
• message profile: 저장 없는 heartbeat, DB 저장 chat message
• fan-out: 평균 수신자 1·3·9명

k6 run \
  -e WS_URL=wss://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e TARGET_CONNECTIONS=1800 \
  -e MESSAGE_RATE=36 \
  -e CONNECTION_RAMP=5m -e DURATION=10m \
  -e RUN_ID=t10-message-36-01 \
  loadtest-scenarios/ws-message.js

메시지 payload에는 runId, VU, iteration, timestamp를 포함해 수신 유실·중복· 순서 오류를 식별한다. end-to-end delivery p95/p99, sent/received/lost/duplicate, outbound deliveries/s, Spring CPU, network, DB commit, Hikari pending을 함께 기록한다. 메시지 저장 시에만 REST p95가 악화되면 저장 경로 비동기화 또는 DB write path 분리를 우선 검토한다.

T11. REST·WebSocket 공유 자원 간섭

병목 정의

WebSocket connection/session/fan-out이 REST와 같은 Spring process, heap, thread, Hikari, host network를 사용해 HTTP p95 또는 오류율을 악화시키는 흐름이다.

부하 설계

1. WebSocket 없이 http-mixed.js를 TARGET_RPS=50으로 실행해 control을 만든다.
2. 별도 로컬 process에서 ws-connect.js를 시작하고 hold 단계에 진입시킨다.
3. WS 연결을 1,575·1,800·2,100·3,000·5,000으로 고정한 상태에서 동일한 HTTP 혼합 부하를 반복한다.
4. 필요하면 T10의 36 msg/s를 추가해 연결만의 간섭과 메시지 fan-out 간섭을 분리한다.

# 터미널 1: WS hold
k6 run -e WS_URL=wss://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e TARGET_CONNECTIONS=1800 -e CONNECT_RATE=6 -e HOLD_DURATION=30m \
  -e RUN_ID=t11-ws-1800-01 loadtest-scenarios/ws-connect.js

# 터미널 2: 같은 시간대 REST
k6 run -e BASE_URL=https://PUBLIC_DOMAIN \
  -e DATA_FILE=./data/test-data.json \
  -e TARGET_RPS=50 -e WARMUP=5m -e DURATION=10m \
  -e RUN_ID=t11-http-with-ws-1800-01 loadtest-scenarios/http-mixed.js

판정

WS가 없는 control 대비 REST p95가 20% 이상 악화되고 Spring CPU/heap/GC, Tomcat busy, Hikari 또는 network 상관관계가 확인되면 공유 process/resource 분리가 우선이다. 로컬 generator 지표가 먼저 포화된 경우에는 결과를 서버 한계로 사용하지 않는다.

6. 결과물과 확장 방향 결정

각 실행은 다음을 남긴다.

• scenario, RUN_ID, 목표/실제 RPS 또는 WS 연결·메시지율
• p50/p95/p99, status별 오류율, checks, timeout, dropped iterations
• 최초 SLO 위반 시각과 C_knee, C_safe
• 호스트·컨테이너·Spring·MySQL·Nginx 지표의 동일 시간 범위
• 좌석·메시지 정합성 결과
• 로컬 generator CPU/memory/FD/network headroom
• k6 summary/raw JSON, Grafana screenshot, image digest와 DB snapshot 정보

판정 예시는 다음과 같다.

관측 증거	우선 검토할 확장 방향
Host CPU·container throttling이 먼저 포화, DB 여유	EC2 크기와 container quota 재배분
MySQL CPU·lock·I/O와 Hikari pending이 함께 증가	query/transaction 개선 후 DB 분리 또는 RDS
외부 API 지연에 Tomcat·outbound pending이 비례	timeout, cache, single-flight, bulkhead, 비동기화
WebSocket 연결만으로 heap·FD가 포화	WebSocket gateway 또는 process 분리
메시지 저장 시에만 REST가 악화	채팅 저장 비동기화 또는 DB write path 분리
동일 row에서만 지연 급증·deadlock	Redis 원자 카운터/멱등키 등 hot-row 구조 변경
C_safe < 계획 피크 × 운영 여유율	최적화 또는 수직/수평 확장 후 동일 조건 재시험

최종 보고서는 시나리오별 3회 반복의 중앙값과 변동폭을 함께 제시하고, 부하 발생기 한계로 인해 목표를 달성하지 못한 실행은 서버 용량 계산에서 제외한다.