V1의 핵심 사용자 여정 기반 부하테스트 시나리오 설계 - 100-hours-a-week/KTB4-3rd-CLOUD GitHub Wiki

4단계-V2 트래픽 성장에 따른 V1 인프라 한계 문서는 V2의 DAU·세션 행동·행사 유입 가정으로 성장 트래픽을 산정하고, 그 부하를 V1 구조에 적용해 한계 지점을 찾도록 제안한다. 이 문서는 그 목적에 맞춰 V2 성장 가정에서 유도한 사용자 여정 부하를 현재 V1 서버 API와 코드 경로에 넣었을 때, 어느 자원과 어느 부하 수준에서 먼저 지연·오류·정합성 문제가 나타나는지 확인하는 설계 부하테스트를 정의한다.
테스트에서 관측한 SLO 위반 시점과 자원 포화 지점은 V1 인프라의 설계 한계를 찾기 위한 근거다. V2 인프라의 목표 성능이나 실제 운영 SLO를 입증하는 결과로 해석하지 않는다.

1. 어떤 API를 호출해 부하를 만들 것인가?
2. 테스트 서버의 어느 지점에서 부하가 발생하는가?
3. 부하가 발생하는 동안 어떤 자원을 확인할 것인가?
4. 성장 가정의 어느 부하 수준에서 사용자 여정이 나빠지고, 먼저 포화되는 자원은 무엇인가?

위 질문에 답하도록 성장 가정 → 부하 모델 → V1 코드 경로 → 사용자 영향 지표와 자원 지표를 연결한다.

성장 모델

 V2의 DAU 3만 6천 명, 한 세션 13건의 HTTP 요청, 출퇴근 피크와 행사 유입, 채팅 접속률·메시지 빈도를 부하 목표의 근거로 삼는다.

측정 대상

 실제 V1 API를 단일 V1 인프라 경로(Nginx → Spring → 공용 HikariCP → MySQL)에 호출한다. 성장에 따라 증가한다고 가정한 조회량, 연결 수, 메시지 저장량, 동시 참여를 기능별로 분리한 뒤 혼합한다.

관측할 지점

 V2 성장 부하 단계에 따라 p95·p99·오류율·CUJ 완료율이 변하는 지점과, 그때 먼저 나타나는 CPU·스레드·세션 메모리·커넥션 대기·쿼리·행 잠금을 찾는다. 결과는 V1 구조에서 어느 자원을 분리·확장하거나 어떤 코드를 개선해야 하는지 판단하는 설계 입력이다.

해석 범위

 DAU와 이벤트 인원은 실측 트래픽이 아니라 성장 가정이다. 이벤트 15건/세션의 상세 요청 구성은 현재 V1 API 믹스로 근사한다. 혼잡도·AI·영수증 처리처럼 V1에 없는 V2 경로는 호출하지 않는다. 현재 코드는 다중 노드·N-1 장애·자동 확장 동작도 시험하지 않는다. 따라서 목표 RPS를 처리해도 V2 서비스 전체나 V2 SLO, 확장 정책을 검증한 것은 아니다.

SLO 적용

 실행 코드의 기본 threshold는 V1 초기 SLO다. V1의 핵심 사용자 여정 별로 SLI SLO 정의의 99.9% 가용성·98.5% CUJ 완료율 등 상향 목표와 구별한다. 성장 부하를 V1 초기 SLO와 대조해 V1의 한계 부하를 찾는다.

부하는 운영과 같은 공개 진입점(Nginx)을 거쳐 들어가도록 발생시킨다. 내부 주소로 백엔드에 직접 요청하면 Nginx의 요청 제한, WebSocket 프록시, 연결 유지 시간 같은 실제 사용자 경로의 제약이 측정에서 빠지기 때문이다.

k6 부하 발생기 (로컬)
  → 공개 도메인 / Elastic IP
  → Nginx 컨테이너 (limit_req, WebSocket 프록시)
      ├─ /api/*      → Spring Boot backend:8080 (cpus 1.0, mem 768MiB)
      │                  → Spring Security/JWT
      │                  → Controller → Service 트랜잭션
      │                  → HikariCP (기본 10개)
      │                  → MySQL 8.4 (cpus 0.5, mem 768MiB, buffer pool 384MB)
      └─ /api/wss    → Spring WebSocket(STOMP)
                         → StompAuthChannelInterceptor (CONNECT 인증, SUBSCRIBE 참여자 확인)
                         → ChatMessageSendService → MySQL
                         → Spring Simple Broker → 구독자

REST API, WebSocket, 메시지 저장이 모두 같은 Spring 프로세스와 같은 HikariCP 풀을 사용한다. 따라서 시나리오는 기능별 단독 부하로 자원 점유를 먼저 확인하고, 이후 기능을 함께 실행해 공유 자원을 통한 지연 전파를 확인하는 순서로 구성한다.

CUJ는 어떤 사용자 행동과 완료 결과를 측정할지 정하고, V2 성장 가정은 그 행동에서 파생되는 요청·연결·메시지 규모를 정한다. 현재 코드는 이를 두 층으로 실행한다. read.js는 매 도착마다 요청 믹스의 API 하나를 호출하고, ws-chat.js와 hot-row.js는 연결·저장·행 잠금의 자원 비용을 분리해 측정한다. cuj.js는 참여자·모집자·택시팟의 실제 API 순서를 끝까지 실행해 E2E 완료율을 잰다. 그러므로 91/180/226 RPS 구간 전체에서 모든 가상 사용자가 매번 CUJ 전체를 밟는 모델은 아니다. 현재 부하 코드는 V2 규모의 구성 부하로 V1 병목을 찾고, 별도의 CUJ 표본 부하로 여정 완수 여부를 확인하는 방식이다.

시나리오 실행 전에 real/tools/make-users.py로 테스트 사용자와 토큰을 만들고, real/seed.js로 공개 API를 호출해 계좌 등록, 채팅방, 동행·커뮤니티 게시글을 생성한다. 시드 데이터는 V2 성장 가정의 수도권 업무지구 6개 거점(판교, 강남, 여의도, 광화문, 성수, 가산디지털단지)에 분산한다.

테스트 사용자는 용도별로 나눠 한 계정이 여러 시나리오의 상태를 오염시키지 않도록 한다.

기본 풀 합계는 2,600명이다. real/lib/fixture.js의 POOL_CHAT, POOL_HOTROW, POOL_TAXI, POOL_CUJ, POOL_WRITER로 크기를 바꿀 수 있으며, make-users.py --count도 합계 이상으로 맞춰야 한다. seed.js는 택시·CUJ·hotrow 풀에 계좌를 등록하고, chat 풀로 4인 채팅방을 만든다. writer 풀은 조회 콘텐츠 작성과 일반 쓰기 트래픽에 사용한다. 시드 기본 콘텐츠는 동행 600건, 커뮤니티 600건이며 환경변수로 조정한다. 결과 픽스처는 FIXTURE_OUT으로 지정할 수 있다.

여기서 SLO는 성장 부하를 받는 현재 V1 설계의 한계점을 찾기 위한 사용자 영향 경계다. 실행 코드의 threshold는 V1 초기 SLO 기준이며, 이 값을 만족한 최대 부하를 V2 운영 성능 보장으로 보지 않는다. 응답은 SLI 문서 6장의 기준으로 분류하고, threshold가 처음 깨지는 성장 부하와 같은 시점에 포화되는 자원을 기록한다.

MATCH_BUSY와 도메인 거절은 같은 409로 응답하므로 상태코드만으로는 구분할 수 없다. 응답 본문의 error.code를 읽어 분류한다.
지연시간은 유효 이벤트(Good·Bad)만 담은 api_duration으로 판정한다. 빠르게 반환되는 도메인 거절이 섞이면 p95가 실제보다 좋게 나오기 때문이다.

참고 문서가 제시하는 V2 운영 목표는 가용성 99.95%, CUJ 완료율 98.5%, 조회 p95 750ms/p99 2초, 쓰기 p95 1.2초/p99 2.5초 등으로 V1 초기 SLO보다 높다. 현재 real/lib/slo.js는 이 상향값을 적용하지 않는다. 따라서 이 부하테스트는 성장 트래픽이 V1 경로에 주는 비용과 최초 위반 지점을 밝히며, V2 상향 SLO를 합격 조건으로 검사하는 절차는 별도로 추가해야 한다.

테스트 환경이 올바른지 확인하는 보조 지표도 함께 기록한다.

사용자 지표가 SLO를 벗어났을 때 원인을 찾기 위해 같은 구간의 서버 자원 지표를 함께 수집한다. 이 지표들은 SLO의 분자·분모로 사용하지 않는다.

모든 요청에 X-Load-Test-Run-Id 헤더를 붙여, 서버 로그와 k6 결과의 측정 구간을 맞춘다.

사용자는 지도와 주변 목록에서 출발 시간·목적지·검색 반경을 바꾸며 재검색한다. 조회 증가는 일시적인 급증이 아니라 피크 시간 동안 지속되는 처리량 부하다.

4단계 문서의 세션당 요청 비율(목록·검색 14 / 상세 14 / 혼잡도 10.5 / 쓰기 3.5 RPS, 45.5 RPS 기준)을 실제 V1 API로 옮겼다. 가중치 합이 91이므로 기준 91 RPS에서 가중치 1이 1 RPS에 해당한다.

기본 실행은 STEPS=46,91,180,226이며 소수도 지원해 45.5를 지정할 수 있다. k6 도착률은 10초 단위로 설정하므로 45.5 RPS가 가능하다. 첫 측정 전에 기본 2분 warm-up이 있고, 각 측정 단계는 기본 5분, 단계 간 회복 구간은 30초다. WARMUP, STEP_DURATION, STEP_GAP으로 조절한다. 이 짧은 단계는 최초 지연·오류 경계를 찾기 위한 것이다. 성장 가정의 출퇴근 피크 지속시간까지 확인하려면 STEPS=91, STEP_DURATION=4h로 별도의 장시간 실행을 한다. 단계별 dropped_iterations가 0이 아니면 목표 RPS를 발생기가 만들지 못한 것이므로 해당 단계를 서버 용량으로 해석하지 않는다.

map-pins는 넓은 뷰포트 하나로도 테이블 전체를 읽을 수 있으므로, 시나리오에서는 모바일 지도 한 화면(위도 0.02° × 경도 0.025°)으로 뷰포트를 제한하고 매 요청마다 위치를 조금씩 옮긴다.

Nginx       → 요청 처리 시간, upstream 응답 시간
Spring      → CPU, Tomcat busy thread, JSON 직렬화 CPU
HikariCP    → active, pending, 커넥션 획득 시간
MySQL       → CPU, 공간 쿼리 시간, rows examined, buffer pool hit

단계별로 sli_availability{step_rps}와 api_duration{step_rps, sli_class:read}를 판정해 SLO가 처음 깨지는 RPS와 그 시점에 먼저 포화되는 자원을 기록한다.

매칭이 늘면 새로운 채팅방에 입장하는 사용자와 이미 연결된 상태에서 메시지를 주고받는 사용자가 함께 늘어난다. 연결 수와 메시지 수는 서로 다른 자원을 점유하므로 독립된 부하 축으로 측정한다.

브로드캐스트되는 메시지에는 client_message_id가 포함되지 않는다. 그래서 SLI 문서 P6의 "같은 client_message_id의 MESSAGE 수신"은 현재 구현으로 측정할 수 없다. 대신 메시지마다 UUID를 넣은 고유 content를 보내고, 발신자가 같은 content를 수신한 시점을 전달 완료로 판정한다.

연결   → Nginx 소켓·프록시 버퍼 → Spring WebSocket 세션 → JWT 디코딩 (CONNECT)
구독   → StompAuthChannelInterceptor → 참여자 조회 쿼리 (SUBSCRIBE마다 DB 1회)
메시지 → ChatMessageSendService
         → 참여자 조회 → 채팅방 조회 → 발신자 조회
         → messages INSERT → chat_rooms.last_message_id UPDATE   (메시지 1건 = 커넥션 1개, 쿼리 4~5개)
         → Simple Broker → 방 구독자에게 팬아웃

유휴 연결은 DB 커넥션을 점유하지 않지만 세션 객체와 heap을 유지한다. 반대로 메시지 저장은 짧은 요청이어도 HikariCP 커넥션을 점유한다. 또한 연결 시점의 SUBSCRIBE도 DB를 조회하므로, 짧은 시간에 많은 사용자가 입장하면 구독 단계에서도 커넥션 경합이 발생할 수 있다.

좌석 경합은 전체 RPS가 낮아도 특정 행에 요청이 몰리는 hot-row 부하다. 활동 사용자 수가 아니라 같은 대상에 동시에 도착한 요청 수로 측정한다.

hot-row.js 기본값은 LEVELS=20,50,100, ROUNDS=3, DISTRIBUTE=1이다. 각 레벨과 라운드마다 새 대상을 준비하고, http.batch로 요청을 한 번에 보낸 뒤 검증하고 정리한다. DISTRIBUTE=K는 요청을 K개 대상/경로에 나눈다. 택시 경로는 출발지를 달리하고 도착 경도를 미세 조정해 경로를 구분한다.

동행 참여

참여 요청 → 활성 참여 여부 조회 → 사용자 조회
         → UPDATE companions SET current_count = current_count + 1
            WHERE id = ? AND status = 'RECRUITING' AND current_count < capacity   ← 같은 행 X-lock
         → 참여 행 INSERT → 채팅방 조회 → commit

정원이 최대 10명이므로 동시 50명 요청이면 9명만 수락되고 나머지는 COMPANION_NOT_JOINABLE로 거절된다. 거절된 요청도 행 잠금을 기다리는 동안 커넥션을 점유한다.

택시팟 매칭

매칭 요청 → users 행 FOR UPDATE → 진행 중 매칭 확인
         → companions FOR UPDATE (좌표·출발 분 완전 일치, 정원 미달)
            ├─ 있으면 참여 행 INSERT
            └─ 없으면 팟·방장 참여 행·채팅방 생성
         → SYSTEM_JOIN 메시지 저장 → commit
         → 잠금 획득 실패 시 최대 3회 재시도 → 409 MATCH_BUSY

일치하는 팟이 없을 때 동시에 들어온 요청들이 각자 새 팟을 만들면 같은 조건의 팟이 여러 개로 쪼개진다. 이를 taxi_pot_fragmentation으로 기록한다. real/lib/api.js의 요청 timeout 기본값은 60초다. MySQL innodb_lock_wait_timeout은 테스트 대상의 실제 설정을 결과에 기록해야 하며, 여기서 기본값을 가정하지 않는다.

MySQL     → row lock 대기 시간, lock wait 건수, deadlock 건수
HikariCP  → active·pending, 커넥션 획득 시간 (잠금 대기 중 점유)
사용자    → 수락·거절·MATCH_BUSY 비율, 쓰기 p95·p99
정합성    → current_count ≤ capacity, 사용자별 진행 중 택시팟 1개 이하

같은 대상 집중(hot-row)과 분산(대조군)을 같은 동시성으로 비교해, 지연이 동시 요청 수 때문인지 같은 행 잠금 때문인지 구분한다.

각 기능을 단독으로 처리할 수 있어도 같은 시간에 발생하면 같은 JVM과 HikariCP에서 경합한다. 조회 단독 결과와 조회에 다른 부하를 더한 결과를 비교해 지연이 어떤 공유 자원을 통해 전파되는지 확인한다.

한 번의 실행 안에서 시간 창을 나눠 같은 조회 부하를 비교한다.

control (5분)    → 조회만 READ_RPS
ramp             → 간섭 부하가 목표치까지 증가 (판정 제외)
treatment (5분)  → 조회 + 간섭 부하

비교 프로필의 기본은 조회 50 RPS, 제어 5분, 연결 ramp 구간, 처리 5분이다. 기본 간섭 유형은 chat이다. CONTROL, TREATMENT, READ_RPS, WS_CONNECTIONS, CONNECT_RATE, MESSAGE_RATE, HOTROW_CONCURRENCY, HOTROW_INTERVAL로 변경할 수 있다. control 동안 연결은 시작하지 않고, ramp 동안은 조회 측정만 판정에서 제외하며, treatment에서 간섭과 조회를 함께 측정한다.

행사 프로필은 INTERFERE 값과 관계없이 all을 기본으로 잡아 채팅·연결·hot-row를 함께 실행한다. hot-row는 treatment 시작 시점부터 실행된다. CUJ 완료율은 real/cuj.js를 별도 프로세스로 실행해 함께 측정한다. 합산 기준 225.5 RPS를 정수로 표현할 때는 PEAK_RPS=226으로 올려 실행한다.

api_duration{window:control, sli_class:read}와 api_duration{window:treatment, sli_class:read}의 p95·p99를 비교한다. treatment 구간의 가용성, 조회·쓰기 지연, WebSocket 연결, 메시지 전달이 모두 SLO를 만족해야 해당 혼합 부하를 수용한 것으로 판정한다. HTTP RPS만 통과했다고 행사 상황을 수용했다고 판정하지 않는다.

개별 API가 SLO를 만족해도 여러 단계를 연속으로 거치는 여정은 실패할 수 있다. SLI 문서의 세 CUJ를 실제 API 순서대로 실행해 목적 달성 여부를 측정한다.

• 탐색만 하고 참여 가능한 글이 없어 떠난 경우는 신뢰성 분모(cuj_reliability)에서 제외하고 제품 퍼널(cuj_funnel)에만 포함한다.
• 참여 요청이 도메인 거절로 반환되면 다른 글로 최대 3회 다시 시도한다. 현재 코드는 세 후보가 모두 도메인 거절된 경우 intent를 확정하지 않아 cuj_reliability 분모에서 빠진다. 따라서 이 측정값은 참여 버튼을 누른 모든 사용자 기준이 아니라, 탐색 후보가 있고 요청 중 도메인 거절 없이 의도가 확정된 여정 기준이다.
• 모집자의 게시글 등록 응답에는 chat_room_id가 없어 내 채팅방 목록에서 방을 찾는다. 이 때문에 H5 측정 구간에 요청이 1건 추가된다.
• 택시팟은 좌표와 출발 분이 완전히 일치해야 합류하므로 6개 경로 × 10분 슬롯을 사용해 기존 팟 합류도 발생하도록 한다.
• 여정이 끝나면 참여를 정리해 같은 계정으로 반복 측정한다.

기본 JOURNEY=all은 세 여정을 각각 분당 12회 시작하며 기본 실행 시간은 10분이다. 전체 시작률은 분당 36회다. 이 CUJ 시작률은 코드의 기본 측정 부하로, V2 DAU·RPS 산식에서 직접 환산한 값은 아니다. JOURNEY_RATE는 여정별 rate이고, JOURNEY를 하나로 지정하면 해당 여정만 실행한다. CUJ 사용자 풀은 여정별로 나누며 실행률을 올릴 때는 POOL_CUJ도 늘려야 한다. 참여자 여정에서 탐색 후 유효 후보가 없으면 신뢰성 분모에서 제외하지만 퍼널 지표에는 남긴다. 기술 오류는 코드상 신뢰성 분모에 포함되지만, 도메인 거절과 MATCH_ALREADY_IN_PROGRESS는 의도 확정 전에 발생한 경우 제외된다. 단계별 cuj_step_total 및 REST SLI도 함께 해석한다.

현재 택시팟 hot-row 검증은 성공 응답의 팟 ID·current_count로 팟 분산과 응답 기준 정원을 검사한다. 실행 뒤 DB에서 참여자 수를 재조회하지 않으며, taxi_state_fresh는 CUJ에서 매칭 응답과 current-taxi-pot를 비교해 측정한다. 두 검증 범위를 구분해서 결과를 해석한다.

V1의 핵심 사용자 여정 별로 SLI/SLO 정의
V2 서비스 확장 가정 및 성장 지표
Grafana k6 - Scenarios and executors
Grafana k6 - Thresholds
Spring Framework - WebSocket Monitoring
Google SRE Workbook - Implementing SLOs\