상시 트래픽 시뮬레이터 PRD
Background
qa/load/k6/에는 facility-search, booking-create-throughput, ticket-seat-select-spike, cart-add-item-concurrency 4개 시나리오가 있으나, 이들은 CI·수동 트리거로 단발 실행되는 회귀 테스트다(qa/load/README.md는 “측정값은 회귀 추세 추적용 — 절대치 비교 금지”를 명시). 요구사항은 이와 성격이 다르다 — “B2C 3000TPS·B2B 100TPS는 일회성 부하 테스트가 아니라 실제 운영 서비스처럼 24시간 상시 발생하는 일상 트래픽이며, 배달앱의 식사시간 피크처럼 평상시엔 잔잔하다가 특정 시간대에 피크를 치는 일주기 패턴”이고, “마케팅 이벤트(티케팅·한정판)는 20000TPS 스파이크”다.
또한 [배포 파이프라인·환경 분리](../배포 파이프라인·환경 분리/PRD.md) 과제로 dev·prod 환경이 분리되면, 상시 트래픽은 prod 환경을 대상으로 발생시킨다 — dev는 배포 직후 회귀 확인용이지 상시 운영 트래픽의 대상이 아니다. 현재 backend는 단일 인스턴스로 로컬 기동되며 로드밸런서가 없어, “다중 인스턴스 운영”이라는 상시 트래픽의 전제 자체가 인프라적으로 갖춰져 있지 않다.
Problem Definition
- 부하 발생기가 단발 실행 스크립트로만 존재하고, 상시(24시간 지속) 구동·온오프 제어·상태 조회가 가능한 시스템이 없다.
- 시간대별로 트래픽 강도를 변화시키는 일주기 패턴 곡선이 정의된 적이 없다 — 모든 기존 k6 스크립트는 고정 부하 또는 단순 스파이크만 표현한다.
- 마케팅 이벤트 스파이크(20000TPS)를 예약된 시각에 자동으로 트리거하는 메커니즘이 없다.
- backend가 단일 인스턴스이며 로드밸런서가 없어, 상시 고부하를 흡수할 다중 인스턴스 인프라가 갖춰지지 않았다.
- B2B 협력사 시나리오(② 과제 의존)가 아직 API로 존재하지 않아, “하루 1,000건 이상” 시나리오를 만들 대상이 없다.
- 소진성 자원 고갈 위험:
booking의 예약 슬롯,goods의 재고,ticketing의 좌석은 모두 유한한 자원이다. 3000TPS 규모의 쓰기 트래픽을 상시(24시간) 발생시키면 짧은 시간에 이 자원들이 고갈되어 이후 모든 쓰기 요청이 409(충돌/소진)로 수렴하고, “일주기 곡선을 따라 흐르는 상시 트래픽”이라는 목표 자체가 무너질 위험이 있다 — 이에 대한 재충전(reseed) 전략이나 조회 위주 시나리오 구성이 없다.
Goals / Non-Goals
Goals
- docker-compose로 backend 다중 인스턴스 + 로드밸런서(Nginx 등)를 구성한다.
- 대상은 prod 환경이다 — 일주기 트래픽·마케팅 스파이크 모두 prod에 대해서만 발생시킨다.
- 24시간 일주기 트래픽 패턴 생성기를 구축한다 — B2C 시나리오는 평시 저부하에서 피크 3000TPS까지, B2B 시나리오는 평시 저부하에서 피크 100TPS까지 시간대별로 증감한다.
- B2C 트래픽은 조회 위주로 구성한다 — 목표 TPS의 70% 이상은 조회 시나리오(시설 검색, 상품·이벤트 목록·상세 조회)로, 30% 이하만 소진성 쓰기 시나리오(예약 생성, 주문, 티켓 구매)로 배분한다. 소진성 쓰기로 소비되는 예약 슬롯·재고·좌석은 10분 주기로 재충전(reseed)하는 배치 작업을 함께 운영해, 상시 트래픽이 자원 고갈로 붕괴되지 않게 한다.
- 마케팅 이벤트(티케팅·한정판) 스파이크를 예약된 시각에 자동 트리거해 20000TPS를 목표치로 도전한다.
- B2B 협력사 시나리오(상품·티켓 등록)를 지속 발생시켜 하루 누적 1,000건 이상을 보장한다.
- 시뮬레이터는 상시 구동(데몬)되며 온오프 제어가 가능하다.
Non-Goals
- 실사용자 트래픽 대체 — 이 시뮬레이터는 항상 synthetic(가상) 트래픽이며 실제 사용자 트래픽을 대체하지 않는다.
- 실제 클라우드 프로덕션 환경 부하 — “prod”는 [배포 파이프라인·환경 분리](../배포 파이프라인·환경 분리/PRD.md)에서 정의하는 로컬 docker-compose 기준 prod 환경이다.
- 정확한 실사용자 지역별 분포 재현 — 지리적 분산은 다루지 않는다.
User Scenarios
페르소나: 본인(개발자 겸 운영자).
- 해피 패스 — 일상 트래픽: 시뮬레이터를 기동하면 24시간 동안 일주기 곡선을 따라 prod 환경에 B2C(조회 70%+쓰기 30%)·B2B 트래픽이 자동으로 증감하며 흐른다. [옵저버빌리티 스택 도입](../옵저버빌리티 스택 도입/PRD.md) 대시보드에서 실시간으로 확인한다.
- 이벤트 — 마케팅 스파이크: 예약된 마케팅 이벤트 시각이 도달하면 시뮬레이터가 [마케팅 이벤트 고부하 대응](../마케팅 이벤트 고부하 대응/PRD.md) 과제의 한정판·티케팅 엔드포인트를 대상으로 20000TPS까지 자동 증폭시킨다.
- 예외 — 목표 미달성: 인프라 한계로 목표 TPS(상시 트래픽 또는 마케팅 스파이크 20000TPS)에 도달하지 못하면, 시뮬레이터가 실제 도달 TPS와 목표 대비 병목을 기록한다 — 실패로 중단하지 않는다.
- 예외 — 자원 고갈: 예약 슬롯·재고·좌석이 소진돼 쓰기 요청이 연속으로 409를 반환하면, 재충전(reseed) 배치가 다음 주기에 자원을 보충해 트래픽이 계속 흐르게 한다.
- 정지: 시뮬레이터 중지 명령을 내리면 트래픽이 graceful하게 0으로 수렴한다.
- B2B 지속 발생: [B2B 파트너 연동](../B2B 파트너 연동/PRD.md)의 상품·티켓 등록 API를 대상으로 하루 종일 낮은 빈도로 지속 호출해 누적 1,000건 이상을 만든다.
Benchmarking
| 제품/사례 | 카테고리 | 참조 패턴 | URL |
|---|---|---|---|
k6 ramping-arrival-rate executor | 오픈소스 부하 테스트 도구 | 시간 구간별로 목표 도착률(arrival rate)을 지정해 서버가 기동·웜업·피크·감쇠를 거치는 시나리오를 표현하는 executor — 본 과제의 일주기 곡선·마케팅 스파이크 곡선을 구현하는 핵심 메커니즘으로 채택 | K6 성능테스트 도구 - Constant/Ramping Arrival Rate |
| 배달앱 업계의 피크타임 트래픽 패턴 | 배달 플랫폼 일반 운영 관례 | 점심(11:30 | K6 도입기 — 월급쟁이부자들 기술블로그 |
Functional Requirements
| ID | 요구사항 | 우선순위 |
|---|---|---|
| FR-1 | docker-compose에 backend 인스턴스 N개(초기 3개) + 로드밸런서(Nginx 등) + 인스턴스별 헬스체크를 구성한다. 대상은 prod 환경이다 | P0 |
| FR-2 | ramping-arrival-rate(또는 동등 executor)로 24시간 일주기 곡선 스크립트를 작성한다 — B2C 시나리오가 시간대별 목표 TPS(피크 3000TPS)를 따르며, 조회 70% 이상 / 쓰기 30% 이하로 구성한다 | P0 |
| FR-3 | 소진성 쓰기(예약 슬롯·재고·좌석 소비)로 인한 자원 고갈을 방지하기 위해, 10분 주기로 자원을 재충전(reseed)하는 배치 작업을 운영한다 | P0 |
| FR-4 | B2B 시나리오([B2B 파트너 연동](../B2B 파트너 연동/PRD.md) 의존)가 시간대별 목표 TPS(피크 100TPS)를 따르며 하루 누적 1,000건 이상을 보장한다 | P0 |
| FR-5 | 마케팅 이벤트 스파이크 시나리오 — 예약된 시각에 20000TPS를 목표로 단시간 증폭 후 감쇠하는 곡선을 [마케팅 이벤트 고부하 대응](../마케팅 이벤트 고부하 대응/PRD.md) 엔드포인트에 대해 실행한다 | P0 |
| FR-6 | 시뮬레이터는 실시간 상태(현재 목표 TPS, 실제 도달 TPS, 활성 시나리오)를 조회할 수 있어야 한다 — 이것이 최소 보장이며, 구현 수단(상태 API/로그/둘 다)은 TDD에서 결정한다 | P0 |
| FR-7 | 시뮬레이터 온오프 제어(시작/중지/일시정지) 인터페이스를 제공한다 | P1 |
| FR-8 | 목표 TPS 미달성 시 달성률(%)과 병목 추정(클라이언트(k6) 한계 vs 서버 한계)을 담은 격차 리포트를 생성한다 | P1 |
| FR-9 | 대량 동시 인증이 병목이 되지 않도록 시나리오별 사용자 프로필(가입 유저 풀, 인증 토큰 재사용)을 사전 준비한다 | P2 |
Non-Functional Requirements
- 일상 트래픽 곡선은 목표 TPS 대비 ±10% 이내로 추종한다.
- 마케팅 스파이크는 목표 시각 기준 ±30초 이내에 20000TPS 도달을 시도한다(도달 실패 시 FR-8 리포트로 대체하며 시스템 중단으로 이어지지 않는다).
- 시뮬레이터 자체의 리소스 사용량이 관측 대상 앱과 분리되어 측정을 왜곡하지 않아야 한다(별도 컨테이너로 격리, 로컬 자원 제약 시 상한을 명시한다).
- FR-3의 재충전 배치는 실제 사용자 트래픽과 구분되는 synthetic 데이터로만 동작하며, 재충전 자체가 관측 대상 앱에 순간 부하 스파이크를 만들지 않도록 점진적으로(예: 10분 주기 내 분산) 수행한다.
Operations
- 시뮬레이터의 목표 대비 실제 TPS 격차, 활성 시나리오, 다음 마케팅 스파이크 예정 시각, 재충전 배치 실행 이력을 [옵저버빌리티 스택 도입](../옵저버빌리티 스택 도입/PRD.md) 대시보드에 노출한다.
- 목표 TPS 대비 50% 미만 달성이 지속되면 [지능형 장애 알림](../지능형 장애 알림/PRD.md) 채널로 통지하되, 관측 대상(prod 앱)의 장애와는 별도로 “시뮬레이터 자체 이상”으로 태깅해 구분한다.
Success Metrics
- 24시간 연속 구동 시 크래시 0건.
- 일주기 곡선 추종 오차는 10분 버킷 단위로 집계하며, ±10% 이내를 달성하는 버킷 비율 90% 이상.
- 마케팅 스파이크는 20000TPS를 목표치로 도전한다. 목표 미달 시에는 실패로 간주하지 않고, 실제 도달 TPS와 병목 구간을 기록한다. ([마케팅 이벤트 고부하 대응](../마케팅 이벤트 고부하 대응/PRD.md)와 동일 기준.)
- B2B 1,000건/일 누적 달성.
- 자원 재충전(FR-3) 동작 중 소진성 쓰기 요청의 409 응답률이 특정 시간대에 50%를 초과하는 구간이 없음을 확인한다.
Milestones
- M1: 다중 인스턴스 + 로드밸런서 구성(FR-1, 선행). [배포 파이프라인·환경 분리](../배포 파이프라인·환경 분리/PRD.md)의 prod 환경 정의가 선행돼야 한다.
- M2: 일주기 B2C 트래픽 곡선 + 자원 재충전 배치(FR-2, FR-3).
- M3: 일주기 B2B 트래픽 곡선(FR-4) — [B2B 파트너 연동](../B2B 파트너 연동/PRD.md) 완료 의존.
- M4: 마케팅 스파이크 시나리오(FR-5) — [마케팅 이벤트 고부하 대응](../마케팅 이벤트 고부하 대응/PRD.md) 완료 의존.
- M5: 상태 조회·온오프 제어·리포트(FR-6~FR-9).
- M6: [옵저버빌리티 스택 도입](../옵저버빌리티 스택 도입/PRD.md)·[지능형 장애 알림](../지능형 장애 알림/PRD.md) 완료 후 통합 관측 검증(최종, 모든 과제의 마지막 단계).
Open Questions
- “다중 인스턴스”가 개인 개발 머신의 물리적 자원 한계 내에서 20000TPS에 현실적으로 도달 가능한지 — 목표는 20000TPS로 유지하되(위 Success Metrics 참조), 클라우드 임시 인스턴스 임차 등으로 실제 처리량을 높일지는 M4 진행 중 재검토한다.
- 시뮬레이터가 생성하는 대량 데이터(주문·예약·티켓)가 실제 개발 중 생성되는 데이터와 섞이지 않도록 synthetic 사용자 구분(네임스페이스/prefix) 정책과 DB 정리 주기를 정해야 한다.
- prod 환경이 물리적으로 dev와 완전히 분리된 별도 컨테이너 스택인지, 같은 머신의 다른 포트인지는 [배포 파이프라인·환경 분리](../배포 파이프라인·환경 분리/PRD.md)의 결정에 따른다.
- (정보성) docker-compose.yml은 본 과제(FR-1, 다중 인스턴스+LB)뿐 아니라 [옵저버빌리티 스택 도입](../옵저버빌리티 스택 도입/PRD.md)(인프라+옵저버빌리티 스택 편입)·[배포 파이프라인·환경 분리](../배포 파이프라인·환경 분리/PRD.md)(dev/prod 분리)도 함께 수정한다 — 파일 소유·병합 순서는 TDD·티켓 분해 단계에서 조율 대상으로 남긴다.
Document History
| 날짜 | 변경 내용 |
|---|---|
| 2026-07-03 | 최초 작성 — “일회성 부하 테스트”에서 “prod 대상 상시 트래픽 시뮬레이터”로 범위 확정 |
| 2026-07-03 | 재검수 1차 반영: 소진성 자원(슬롯/재고/좌석) 고갈로 인한 트래픽 붕괴 위험을 Problem Definition에 추가하고 재충전(reseed) 전략을 FR-3으로 신설, B2C 트래픽을 조회 70%/쓰기 30% 비중으로 구체화, 20000TPS Success Metrics를 “목표 도전 + 미달 시 도달분·병목 기록”으로 ③과 통일(최소 50% 하향 표현 삭제), FR-6(구 FR-5) 상태 조회를 최소 보장으로 고정하고 구현 수단은 TDD 위임, 일주기 추종 오차 집계 단위를 10분 버킷으로 명시, docker-compose.yml 소유·병합 경계를 Open Questions에 정보성으로 추가 |