402 V1 한계 지점 측정을 위한 부하테스트 설계 V2

1. 목적과 판정 원칙

이 테스트의 목적은 V1이 단순히 몇 RPS를 처리하는지 확인하는 것이 아니다. 사용자 증가 시 최초로 포화되는 자원과 장애 전파 경로를 수치로 확인하고 다음 확장 방향을 결정하는 것이다.

• 단일 EC2의 수직 확장 또는 컨테이너 자원 재배분으로 충분한가
• MySQL을 별도 호스트나 RDS로 분리해야 하는가
• REST와 WebSocket을 분리해야 하는가
• 혼잡도 계산·외부 API 호출을 비동기화하거나 별도 서비스로 격리해야 하는가
• 무중단 목표 때문에 다중 EC2와 로드밸런서가 필요한가

성능 한계는 가장 높은 순간 RPS가 아니라 SLO를 연속으로 만족하는 최대 지속 처리량으로 정의한다.

C_knee = SLO 또는 정합성이 처음 깨지는 지속 부하
C_safe = C_knee × 0.7
필요 용량 = 계획 피크 × 별도 운영 여유율

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

2. MAU·DAU 재선정과 RPS 산정

2.1 외부 벤치마크와 내부 가정 분리

BlaBlaCar는 전체 서비스의 DAU를 공개하지 않는다. 따라서 국가·연도 범위가 일치하는 스페인 2025 공식 자료로 DAU/MAU 활동 프록시를 만든다. 모여타 MAU는 1,150,000명으로 고정하며 이 값에 침투율을 다시 적용하지 않는다.

공개 지표	값	사용 방법
2025 스페인 평균 월간 고유 활성 사용자	300,000~400,000	중앙값 350,000을 MAU 기준으로 사용
2025 스페인 연간 승객	4,000,000	일간 승객 활동 프록시

• BlaBlaCar 스페인 2025 MAU·승객 수

공개값에서 다음 비율을 계산한다.

일 평균 승객 활동 = 4,000,000 ÷ 365 = 10,959/day
승객 활동 DAU/MAU = 10,959 ÷ 300,000~400,000 = 2.740~3.653%
채택 DAU/MAU = 10,959 ÷ 350,000 = 3.131%

모여타 DAU 범위 = 1,150,000 × 2.740~3.653% = 31,507~42,009
채택 DAU = 1,150,000 × 3.131% = 36,008

고정 MAU	BlaBlaCar DAU/MAU 범위	추정 DAU 범위	채택 DAU
1,150,000	2.740~3.653%	31,507~42,009	36,008

위 DAU는 로그인 기준 고유 DAU 실측값이 아니라 승객 건수/365를 사용한 일간 활동 프록시다. 운전자·검색만 한 사용자를 빠뜨리고 하루 복수 이용자를 중복 집계할 수 있으므로 제품 KPI로 쓰지 않는다. 운영 로그가 없을 때 부하테스트 초기값을 정하는 벤치마크에만 사용하고, 이후 고유 DAU·인당 세션·세션당 호출 횟수로 교체한다.

2.2 RPS 공식

일 세션 = DAU × 1회

피크 세션 시작률
= DAU × 일 세션/DAU × 피크 집중률 70%
  ÷ 피크 4시간 × 순간 피크 계수 2.0

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

구분	DAU/MAU	DAU	피크 세션/s	계산 RPS
하단	2.740%	31,507	3.063	39.82
중앙	3.131%	36,008	3.501	45.51
상단	3.653%	42,009	4.084	53.09

따라서 운영 데이터가 없을 때의 첫 혼합 부하 기준은 약 50 RPS로 두면 된다. 인당 일 세션이 2회면 91 RPS, 3회면 137 RPS로 선형 증가한다. 이 값은 V1 용량 상한이 아니므로 한계 탐색은 별도로 25→50→75→100→150→200→300→400→512 RPS를 적용해 C_knee까지 계속한다.

세션당 HTTP 13건은 현재 시퀀스를 목록·검색 4, 상세 4, 혼잡도 3, 쓰기 1, 인증·기타 1로 분해한 내부 설계값이다. 중앙 RPS 45.51의 endpoint 분배는 목록·검색 14.00, 상세 14.00, 혼잡도 10.50, 쓰기 3.50, 인증·기타 3.50 RPS다. 운영 로그가 생기면 반드시 세션/DAU와 endpoint 호출 횟수로 교체한다.

2.3 행사 종료 burst 재계산

특정 행사 사용자는 해당 구간 DAU의 10%가 10분 안에 진입한다고 가정한다. 각 사용자는 행사 세션에서 HTTP 요청 15건을 만들고, 50%가 채팅에 접속하며, 접속 사용자는 10분 동안 메시지 6건을 보낸다.

요청률은 총 요청 수를 보존하는 삼각형 부하로 만든다.

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

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

4인 팟에서 발신자를 제외한 3명에게 전달된다면 중앙 기준 네트워크 전달량은 최대 약 108 deliveries/s다. 이벤트 사용자 10%, WS 접속 50%, 15 HTTP/user, 6 messages/user는 모두 내부 가정이다. 예상 burst는 160→180→210 RPS, 용량 탐색은 250→300→400→512 RPS로 이어간다. WS는 연결·메시지를 별도 증가시켜 한계를 찾는다. 방 크기가 달라지면 inbound × 평균 수신자 수로 다시 산정한다.

3. 부하·관측 구조

별도 Terraform 스택은 loadtest-infra/에 두고 임시 Prometheus·Grafana EC2, 관측용 접근 규칙, exporter 설치 문서만 관리한다. 부하 발생기 EC2는 만들지 않으며 기존 V1 Terraform state와 파일을 수정하지 않는다. Public 80/443 규칙은 기존 infra/ state만 소유하고, 별도 스택은 테스트 기간에만 monitoring SG에서 exporter port로 들어가는 규칙을 추가한다.

로컬 부하 발생기
 ├─ HTTP 프로세스 ─┐
 ├─ WS 프로세스 ───├─ Public DNS/EIP → HTTPS/WSS → Nginx → Spring ─┬→ MySQL
 │                    │                                └→ FastAPI → 외부 LLM
 └─ 로컬 JSON/CSV 결과

V1 EC2
 ├─ Node Exporter: 호스트 CPU·메모리·디스크·네트워크·FD
 ├─ cAdvisor: 컨테이너 CPU·메모리·throttling·I/O
 ├─ Micrometer: HTTP·Tomcat·JVM·HikariCP
 ├─ mysqld-exporter: MySQL connection·lock·buffer·redo
 └─ nginx exporter/access log: 연결·upstream 시간
              ↓ 5초 scrape
임시 Prometheus + Grafana EC2

부하 경로는 반드시 공개 도메인 또는 EIP의 https://·wss://를 사용한다. 이로써 공개 DNS, 인터넷 경로, TLS, Nginx를 포함한 실제 진입 경로를 측정한다. V1 private IP는 부하 대상이 아니며 Prometheus EC2가 exporter를 수집하는 관측 경로에만 사용한다.

Node Exporter와 cAdvisor는 Terraform이 생성한 SSM 문서로 설치·제거할 수 있다. Spring, MySQL, Nginx exporter는 인증 정보와 서비스 설정이 필요하므로 자격 증명을 Terraform state에 넣지 않고 별도로 구성한 뒤 scrape target만 Terraform 변수로 연결한다.

4. 병목별 세분화 테스트

T0. 로컬 부하 발생기 검증

• V1 테스트 전에 응답이 고정된 endpoint로 로컬 호스트의 한계를 측정한다.
• 로컬 CPU 60% 미만, swap 0, 실측 업로드 대역폭 70% 미만, dropped iteration 0, 목표 요청 도달률 95% 이상을 유지한다.
• 유선/Wi-Fi, VPN·proxy 사용 여부, 공인 IP, target RTT·jitter·packet loss와 로컬 하드웨어 사양을 모든 결과에 기록한다.
• HTTP와 WebSocket은 별도 로컬 프로세스로 실행한다. 동일 호스트에서 여유율을 만족하지 못하면 같은 통제 네트워크의 로컬 머신 두 대로 나눈다.

T1. 네트워크·TLS·Nginx 연결 처리

동일한 가벼운 endpoint에 대해 다음을 비교한다.

• keep-alive 활성과 매 요청 신규 연결
• HTTP와 HTTPS
• 1→10→50→100→200→400 connections/s

측정값은 TCP connect, TLS handshake, Nginx active/reading/writing/waiting, accept 실패, host socket 수, FD, listen queue, Nginx container CPU와 throttling이다. upstream이 여유로운 상태에서 connect 시간이 먼저 상승하면 Nginx·OS 계층 병목으로 판정한다.

T2. Spring 요청 처리와 JVM

DB·외부 API를 호출하지 않는 가장 가벼운 endpoint와 실제 endpoint를 비교한다.

• BlaBlaCar 활동률 기준 40→46→53 RPS를 먼저 재현
• 한계 탐색은 25→50→75→100→150→200→300→400→512 RPS
• 임계점 부근부터 10~20% 단위 증가
• 각 단계 워밍업 5분, 측정 10분, 3회 반복

Tomcat busy/max, 요청 queue, JVM heap·direct memory, allocation rate, GC pause, process CPU, context switch, container throttling을 측정한다. DB 지연 없이 Tomcat과 CPU가 먼저 포화되면 Spring 계산·직렬화·thread 설정 문제다.

T3. 목록 쿼리

다음 축을 독립적으로 바꾼다.

• 현재 V1, MAU 115만 예상 누적치, 그 2배의 데이터 건수
• 첫 페이지와 깊은 페이지
• 동일 검색조건 반복과 다양한 위치·필터
• cold cache와 warm cache
• 목록 크기 10·20·50

쿼리 p95/p99, rows examined/sent, buffer-pool hit, temporary table, sort, MySQL CPU, disk read latency, Hikari usage/acquire/pending을 측정한다. 첫 페이지 반복 결과만으로 조회 용량을 판정하지 않는다.

T4. 상세 조회와 N+1·직렬화

• 존재하는 팟과 없는 팟
• 참여자·정산·채팅 이력 크기별 상세
• 동일 상세 반복과 ID 분산

DB query count/request, SQL 합계시간, 응답 직렬화 시간, response bytes, Spring CPU와 GC를 측정한다. DB 시간이 짧지만 전체 응답이 길면 객체 변환·JSON 직렬화 또는 과도한 응답 크기로 판정한다.

T5. 혼잡도 외부 호출

외부 의존성을 다음 고정 조건으로 바꿔가며 테스트한다.

• 지연 50·200·1,000·3,000ms
• 오류율 0·1·5·20%
• 동일 spot과 10·100개 spot 분산

Spring outbound connection pool, pending call, Tomcat busy, FastAPI worker queue, timeout, retry 수를 측정한다. 트랜잭션·Hikari 사용 시간이 외부 지연과 함께 증가하면 트랜잭션 범위가 외부 호출을 포함한 것이다.

T6. 혼잡도 DB 최신값·이력 저장

외부 계산 결과를 고정해 외부 API 영향을 제거한 뒤 다음을 비교한다.

• 최신값 upsert만 수행
• 이력 insert 포함
• 동일 spot과 다수 spot 분산
• K=1·5·20

row lock current waits/time, deadlock, transaction duration, redo bytes, fsync, dirty page, EBS queue·await, Hikari pending을 측정한다. 동일 spot에서만 급격히 나빠지면 row lock, 모든 spot에서 나빠지면 redo·I/O 또는 인덱스 비용이다.

T7. 참여 요청 저장

서로 다른 팟에 쓰기를 분산해 단순 insert 처리량을 먼저 측정한다. 이 값은 좌석 경쟁과 분리된 쓰기 기준선이다.

• 1→5→10→20→40→80 writes/s
• 성공·중복·제약조건 오류를 분리 집계

T8. 인기 팟 승인 hot-row

RPS가 아니라 동시에 같은 팟 행에 도착하는 요청 수를 제어한다.

• 같은 팟에 2·5·10·20·50·100 동시 승인
• 서로 다른 팟에 같은 동시성을 주는 대조군
• lock을 0·100·500·2,000ms 점유하는 조건

lock wait, deadlock, Hikari pending, 승인 latency와 함께 잔여 좌석 음수, 정원 초과, 중복 승인을 검증한다. 정합성 오류는 단 한 건이어도 실패다.

T9. WebSocket 연결 자체

메시지를 보내지 않고 연결 비용만 측정한다.

• 수요 예측 동시 연결 1,575→1,800→2,100, 용량 탐색 500→1,000→1,500→3,000→5,000
• 연결률 5.25→6→7→10→20→50 connections/s
• 30분 idle 유지 후 연결 해제와 재연결

handshake p95/p99, 성공률, Nginx와 Spring FD, ESTABLISHED/TIME_WAIT, heap·direct memory/connection, GC, heartbeat traffic을 측정한다.

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

연결 수를 고정하고 다음 축을 분리한다.

• 저장 없는 heartbeat와 DB 저장 채팅 메시지
• 한 방 집중과 여러 방 분산
• 수신자 1·3·9명
• 수요 예측 inbound 31.5→36→42 msg/s
• 용량 탐색 inbound 10→20→50→100→300 msg/s

end-to-end 전달 p95/p99, 유실·중복·순서 오류, outbound deliveries/s, Spring CPU, network, DB commit, Hikari pending을 측정한다.

T11. REST·WebSocket 공유 자원 간섭

WebSocket 연결을 0, 예측 하단·중앙·상단 1,575·1,800·2,100, 용량 탐색값 3,000·5,000으로 고정하고 같은 REST 부하를 반복한다. 연결이 없는 대조군 대비 REST p95, 처리량, Spring CPU·메모리 변화율을 기록한다. 임의의 WS 단계에서 REST p95가 20% 이상 악화되고 자원 상관관계가 확인되면 WebSocket 실행기 또는 서비스 분리를 우선 검토한다.

T12. 장애·복구

C_safe의 70% 부하에서 Nginx, Spring, FastAPI, MySQL을 하나씩 중지·복구한다. EC2 reboot와 백업 복원은 별도 격리 환경에서 수행한다.

• 오류가 시작된 시각부터 5분 연속 정상화될 때까지의 RTO
• 기능별 장애 범위
• WebSocket 재연결률
• retry storm과 queue 회복 시간
• 마지막 정상 백업부터의 RPO

단일 EC2·단일 MySQL은 호스트 장애 중 무중단을 제공할 수 없으므로 이 테스트는 고가용성을 증명하는 것이 아니라 현재 복구 능력을 수치화한다.

5. 단계와 중단 조건

1. 고정된 이미지·DB snapshot·CPU credit 상태를 기록한다.
2. 단일 사용자 기능과 결과 정합성을 검증한다.
3. 5분 워밍업 후 격리 테스트를 수행한다.
4. BlaBlaCar 기준 40→46→53 RPS와 세션 민감도 91→137 RPS 순으로 혼합 부하를 수행한다.
5. 최초 임계점 부근을 10~20% 간격으로 다시 측정한다.
6. C_safe에서 60~120분 soak test를 수행한다.
7. 예측 burst 160→180→210 RPS와 250→300→400→512 RPS 탐색 burst의 복구를 측정한다.
8. 한 번에 개선 하나만 적용하고 동일 snapshot·시나리오로 재측정한다.

다음 중 하나면 해당 단계를 중지한다.

• 5xx·timeout 5% 초과가 2분 지속
• OOM, container restart, disk full
• 좌석 또는 메시지 정합성 위반
• 부하 발생기가 목표 RPS의 95%를 전달하지 못함
• DB 복구가 필요한 비정상 상태

6. 확장 방향을 결정하는 결과표

증거	확장 판단
Host CPU·container throttling이 먼저 포화, DB 여유	EC2 크기·컨테이너 quota 재배분 우선
MySQL CPU·lock·I/O와 Hikari pending이 함께 증가	쿼리·트랜잭션 개선 후 DB 분리/RDS 검토
외부 API 지연에 Tomcat busy·outbound pending이 비례	timeout·cache·single-flight·bulkhead·비동기화
WebSocket 연결만으로 heap·FD가 포화	WS gateway 또는 Spring 프로세스 분리
메시지 저장 시에만 REST가 악화	채팅 저장 비동기화 또는 DB 쓰기 경로 분리
단일 컨테이너 장애 RTO는 충족하지만 EC2 RTO 불충족	다중 EC2·ALB·외부 DB 필요
C_safe < 계획 피크 × 운영 여유율	최적화 또는 수평/수직 확장 후 재시험

최종 보고서에는 시나리오별 목표·실제 RPS, p50/p95/p99, 오류율, 로컬 발생기 headroom, 최초 포화 지표, C_knee, C_safe, 정합성, RTO/RPO, 원시 결과 위치와 동일 조건 3회 결과를 포함한다.