406. SLI/SLO 정의에 따른 부하테스트 코드·시나리오 수정

근거: 위키 「V1의 핵심 사용자 여정 별로 SLI/SLO 정의」, 「4단계 V2 트래픽 성장에 따른 V1 인프라 한계」, KTB4-3rd-BE(v1.0.0) 코드, deploy/nginx/nginx.conf, deploy/compose.yaml 산출물: loadtest-scenarios/real/ (신규), loadtest-scenarios/lib/config.js·cuj-journey.js·ws-connect.js·ws-message.js (임계값 수정)

1. 기존 코드에서 바뀌어야 했던 것

1-1. 대상 API: 픽스처 → 실제 서버

기존 (data/test-data.json)	실제 서버	반영
/api/lab/posts, /api/lab/posts/{n}	GET /api/map-pins, GET /api/nearby-posts(커서), GET /api/companion-posts/{id}, GET /api/community-posts/{id}·/comments	lib/api.js, lib/read-mix.js
/api/lab/runs/*/parties/*/approve (좌석 승인)	V1에는 승인 단계가 없음. 경합 지점은 POST /api/companion-posts/{id}/participants의 조건부 UPDATE와 POST /api/taxi-pots의 FOR UPDATE	hot-row.js, lib/contention.js
/api/lab/runs/*/stats (혼잡도)	V1에 혼잡도 API 없음 → 지도 이동(/api/map-pins)으로 대체	lib/read-mix.js 가중치 표
/ws?runId= raw WS echo	/api/wss STOMP: CONNECT(Authorization) → SUBSCRIBE /sub/chat/{room} → SEND /pub/chat/{room}	lib/stomp.js
토큰 수동 입력	Kakao OAuth뿐 → 테스트 서버 JWT_SECRET으로 HS256(iss=moyeota, sub=userId) 발급	tools/make-users.py
ID 하드코딩	공개 API로 시드 후 fixture.json, 실행 시 map-pins로 재수집	seed.js, discoverTargets()

1-2. 성공·실패 판정: 상태코드 → SLI good/bad/제외

기존에는 expectedStatuses 목록에 들어가면 성공, 아니면 실패였다. SLI 문서 6장 기준으로 바꿨다 (lib/slo.js classify, lib/api.js RULES).

분류	예	가용성 분모
good	2xx, 의도된 빈 상태(current-taxi-pot 200 + null)	포함
bad	5xx, timeout·reset(status 0), 409 MATCH_BUSY, nginx 429	포함
도메인 거절	ALREADY_PARTICIPATING, COMPANION_NOT_JOINABLE, BANK_ACCOUNT_REQUIRED, MATCH_ALREADY_IN_PROGRESS, COMPANION_POST_CANCELED(410) 등	제외 (business_rejections로 별도 집계)
입력 오류	400 MALFORMED_REQUEST, 422 VALIDATION_ERROR 등	제외
테스트 데이터 오류	401·403·404(규칙에 없는 것)	제외, test_data_errors==0 임계값으로 실행 무효 처리

MATCH_BUSY와 도메인 거절이 같은 409라서 상태코드만으로는 구분이 안 된다. 그래서 응답 본문의 error.code를 읽는다(본문을 버리지 않도록 discardResponseBodies:false).

1-3. 임계값: 이전 V2 초안값 → V1 초기 SLO

항목	이전 기본값	SLO 문서	수정 위치
가용성 / 오류율	99.95% / 0.05%	99.9% / 0.1%	lib/config.js v2SloThresholds, real/lib/slo.js
조회 지연	p95 750ms, p99 2s	p95 1s, p99 2.5s	동일
쓰기·매칭 지연	p95 1.2s, p99 2.5s	p95 1.5s, p99 3s	동일
WS 연결 성공률	99.95%	99.9%, 3초 안에 CONNECTED	ws-connect.js, ws-message.js, cuj-journey.js, lib/stomp.js
메시지 전달	성공 99.99%, p99 1.5s	99.9%, p99 2s	동일
CUJ 완료율	98.5%	97% (의도 확정 후 기준)	cuj-journey.js, real/cuj.js
정합성	없음	100%	hot_row_consistency, taxi_state_fresh

지연 SLO는 http_req_duration이 아니라 **유효 이벤트만 담는 api_duration**으로 판정한다. 도메인 거절(빠른 409)이 섞이면 p95가 실제보다 좋게 나오기 때문이다.

1-4. 실제 서버 계약 때문에 바뀐 클라이언트 동작

1. 메시지 전달 확인은 content로 매칭한다. 브로드캐스트되는 MessageItem에는 client_message_id가 없다(id, type, sender, content, created_at). SLI 문서 P6의 "같은 client_message_id의 MESSAGE"는 현재 구현으로는 측정할 수 없다. 그래서 UUID를 넣은 고유 content로 echo를 매칭한다. BE에서 client_message_id를 내려주도록 바꾸는 것을 권장한다.
2. SEND 본문은 client_message_id(snake_case)로 보낸다. 컬럼이 NOT NULL이라 null이면 저장이 실패하고, 클라이언트에는 아무 응답 없이 끝난다. STOMP 컨버터에 네이밍 전략이 적용되는지 확인되지 않아 clientMessageId도 같이 보낸다.
3. SUBSCRIBE 직후 200ms 기다린 뒤 SEND한다. inbound 채널이 순서를 보장하지 않아(setPreserveReceiveOrder 미설정) SEND가 구독 등록보다 먼저 처리되면 자기 echo를 못 받는다.
4. 구독자는 반드시 실제 참여자여야 한다. 비참여자의 SUBSCRIBE는 에러 없이 버려지므로, seed.js가 방을 만들고 멤버를 참여시킨 매핑만 쓴다.
5. 모집자는 등록 직후 방 ID를 알 수 없다. POST /api/companion-posts 응답에 chat_room_id가 없어서 GET /api/chat-rooms에서 companion_id로 찾는다(H5 측정 구간에 요청 1건이 추가됨).
6. 택시팟은 좌표 6자리와 분 단위 출발시각이 완전히 일치해야 매칭된다. @Digits(fraction=6) 때문에 좌표는 소수 6자리로 반올림한다. CUJ는 10분 슬롯을 써서 기존 팟 합류도 일어나게 했고, taxi_match_total{match_result}로 합류율을 본다.
7. URL 정규화. 실제 ID를 name 태그에서 빼고 /api/companion-posts/{companion_id} 형태로 기록한다(SLI 문서 5-1의 카디널리티 원칙).

2. 실제 서버 코드 기준 부하 지점

시나리오	호출 API	서버 내부 경로	확인할 자원
S1 조회 증가	nearby 28 / 상세 28 / map-pins 21 / 쓰기 7 / 기타 7 (합 91 = 91 RPS 기준)	HomeService 두 테이블 MBRContains + ST_Distance_Sphere 정렬, 병합	Spring CPU, HikariCP, MySQL 공간 인덱스
S2 연결 증가	/api/wss CONNECT·SUBSCRIBE, 1,800연결·6/s	JWT 디코딩, SUBSCRIBE마다 참여자 조회 쿼리	세션 heap·GC, 소켓, 구독 시점 DB
S3 메시지 저장	SEND 36 msg/s	참여자 조회 → 방·사용자 조회 → INSERT → last_message_id UPDATE (메시지 1건 = 쿼리 4~5개, 커넥션 1개)	HikariCP 점유·대기, MySQL commit
S4-a 동행 좌석 경합	같은 글에 동시 참여 20/50/100	UPDATE companions SET current_count+1 WHERE current_count<capacity 같은 행 X-lock (정원 최대 10 → 나머지는 COMPANION_NOT_JOINABLE)	row lock 대기, 커넥션 점유
S4-b 택시팟 경합	같은 좌표·분으로 동시 매칭	users FOR UPDATE → companions FOR UPDATE(없으면 gap lock) → 실패 시 3회 재시도 → MATCH_BUSY	lock wait(기본 50s), 데드락, 팟 쪼개짐(taxi_pot_fragmentation)
S5 혼합	조회 + ws/chat/hotrow	같은 JVM·HikariCP 10개	control 대비 treatment의 조회 p95·p99
CUJ	참여자·모집자·택시팟 E2E	위 경로 전부 + STOMP 첫 메시지	cuj_reliability 97%

주의할 코드 특성:

• GET /api/map-pins는 서버에서 뷰포트 크기를 검증하지 않고, 쿼리에 LIMIT도 없다. 500개 초과 여부는 전부 읽은 뒤에 판단한다. 넓은 뷰포트 하나로도 테이블 전체를 스캔할 수 있으므로, 시나리오는 모바일 한 화면(0.02°×0.025°)으로 제한했다. 반대로 이 API 자체는 별도 개선 대상이다.
• 택시팟 경합은 innodb_lock_wait_timeout(기본 50초)까지 커넥션을 붙잡을 수 있어서 요청 타임아웃을 60초로 따로 뒀다.

3. 테스트 전에 서버에서 확인·변경해야 할 것 (코드만으로 해결 안 됨)

#	항목	현재 (repo 기준)	영향	조치
1	nginx limit_req	IP당 20r/s, burst 40	발생기 한 대에서 20 RPS를 넘으면 429 → 91 RPS 측정 불가	테스트 기간에 발생기 IP를 geo로 제외. 스크립트는 nginx_rate_limited==0으로 감지
2	/api/wss 프록시	location /api/에 걸려 있고 Upgrade/Connection 헤더 미전달, proxy_read_timeout 60s	업그레이드 실패 또는 유휴 연결이 60초 뒤 끊김	location /api/wss를 분리해 헤더·3600s 적용. ws_unexpected_close로 감지
3	STOMP heartbeat	Simple Broker에 TaskScheduler가 없어 서버 heartbeat 0	유휴 연결 유지는 nginx 타임아웃에 달려 있음	위 2번과 함께 처리
4	지표 노출	Actuator만 있고 Prometheus registry·endpoint 노출 설정 없음	HikariCP active/pending, Tomcat, JVM GC를 볼 수 없음	micrometer-registry-prometheus + management.endpoints.web.exposure.include (테스트 서버 한정)
5	공간 인덱스	스키마가 repo에 없음(ddl-auto: validate)	origin_location·location에 SPATIAL INDEX가 없으면 S1 결과가 달라짐	SHOW INDEX 확인 후 문서에 기록
6	테스트 사용자	users 테이블 직접 INSERT	엔티티 외 NOT NULL 컬럼이 있으면 실패	seed-users.sql 적용 전 SHOW CREATE TABLE users 확인
7	발생기 위치	로컬 PC 1대	지난 측정의 1,734연결 상한 원인이 확정되지 않음	연결 테스트는 발생기 2대 분산과 비교

4. 남은 SLI 계측 (부하테스트 밖)

SLI 문서의 서버 측 지표(companion_join_total, taxi_match_retry_total, taxi_match_lock_wait_seconds, after-commit 메트릭, Nginx access log의 $request_time)는 아직 BE·인프라에 없다. 지금 k6 결과는 클라이언트 관점의 SLI다. 서버 지표가 들어오면 같은 X-Load-Test-Run-Id 헤더로 구간을 맞춰 비교한다.