부하 한계사용자 44명일 때 한계를 미리 쟀다
구분
CASE 09 · 운영 한계
운영 한계 · k6
상태
측정 · 스테이징
2026
역할
설계 · 판정 · 운영
코드는 AI
분야
운영 + 검증
k6 · 스테이징 · 롤백 드릴
CASE-09운영
144ms
300 RPS에서 p95 · 오류 0
300 RPS
인증 600
상한
개요
부하 한계
트래픽·장애·롤백을 겪어 본 적이 없었습니다. 이 규모에서 장치를 더 만드는 것은 과잉이라 한계를 재는 것으로 답하기로 했습니다. 프로덕션과 분리된 스테이징(D1·KV 별도, 인증 경로는 프로덕션과 동일)을 신설하고 k6로 밀었습니다. 발신은 노트북 한 대였습니다.
01
측정
| 경로 | 부하 | 결과 |
|---|---|---|
| 무인증 D1 왕복 | 10 → 300 RPS | 15,842 요청 · 오류 0 · p95 144ms |
| 상한 탐색 | 300 → 1,000 RPS | 전 응답 200이지만 D1 ping 실패 2.58% · p95 2.27s · 발신 VU 1,186/1,200 포화 |
| 인증 읽기(JWT + 범위 조회) | 최고 600 req/s | 오류 0 · p95 144 → 820ms · VU 상한 도달 |
| 롤백 드릴 | v1 → v2 → v1 | 2.7초 · 직후 헬스 UP |
02
판독
저하는 500~750 RPS 사이에서 시작합니다. 다만 그 구간에서 발신 쪽 VU도 포화됐기 때문에 서버 단독 한계로는 확정하지 않았습니다. 가르려면 분산 발신이 필요하고 그건 이번 범위 밖입니다.
HTTP 오류율이 끝까지 0이었던 이유가 더 중요했습니다. 헬스 엔드포인트가 항상 200에 본문으로 상태를 싣는 설계라 D1 저하가 5xx가 아니라
HTTP 오류율이 끝까지 0이었던 이유가 더 중요했습니다. 헬스 엔드포인트가 항상 200에 본문으로 상태를 싣는 설계라 D1 저하가 5xx가 아니라
DEGRADED로 보고됐고 그래서 부하 테스트가 이 구간을 잡았습니다. 5xx만 보는 모니터링이었다면 정상으로 읽혔을 구간입니다.03
걸린 것
롤백 직후 시크릿 편집이 막혔습니다. 롤백은 배포만 되돌리고 최신 버전은 그대로라 둘이 어긋나기 때문입니다. 재배포로 정렬한 뒤 편집해야 했고 이 순서를 장애 대응 절차에 넣었습니다.
기록
잰 숫자와 출처
측정 · k6
144ms300 RPS에서 p95 · 오류 0
측정 · k6 · D1 ping
500~750저하가 시작된 RPS · 단일 발신
측정 · k6
≈600인증 읽기 무릎 req/s
측정 · 드릴 기록
2.7초롤백 드릴 v1 → v2 → v1
결과
300 RPS p95 144ms · 오류 0 · 저하 구간 500~750 RPS(단일 발신 기준) · 인증 읽기 무릎 ≈600 req/s · 롤백 2.7초 · 5xx 기반 모니터링의 사각 확인
배운 것
측정은 장치보다 쌌습니다. 반나절에 숫자가 나왔고 새 코드는 스테이징 설정과 스크립트뿐이었습니다. 그리고 "항상 200"이라는 헬스 설계 결정이 실제 부하에서 처음으로 값을 했습니다.
