35장. 안전한 부하 실습 환경

부하 대상은 로컬 fixture 또는 소유자가 서면 승인한 격리 staging이다. 실제 운영·타인 서비스·공개 API를 대상으로 실행하지 않는다. 최대 VU·arrival rate·duration·egress·비용과 자동 중단 threshold를 먼저 설정한다. load generator와 대상의 자원 한계를 모두 관측한다.

실습 전 합성 데이터와 teardown, 외부 provider simulator, alert 억제 대신 test 표식, 담당자 연락을 준비한다. 실행 중 오류 예산·queue·DB·비용이 중단선을 넘으면 즉시 ramp down한다. 종료 뒤 backlog·autoscaling·cache·데이터가 baseline으로 복귀했는지 확인한다. GitHub Actions의 cron이나 반복 dispatch를 외부 부하 발생기로 사용하지 않는다.

출간 베타에서는 두 장비와 두 네트워크에서 같은 짧은 test를 실행해 환경 차이를 확인한다. 독자는 p95·오류율·dropped iteration·업무 대사를 함께 해석하고, 결과가 다르면 측정 위치와 조건부터 비교해야 한다. SRE는 overload·복구를, DBA는 plan·pool을, FinOps 담당자는 단위 비용을 검토한다. 명령·그래프·결론이 같은 run ID와 artifact로 역추적되어야 최종 교정에 통과한다.

본문의 threshold와 용량 숫자는 독자가 그대로 운영 SLA로 복사하지 않도록 모두 fixture임을 표시한다. 실제 적용은 사용자 SLO, 관측 분포, 비용과 승인된 부하 결과로 다시 계산한다.

예를 들어 분당 요청 수를 동시 처리량으로 바꿀 때 단위를 코드에 드러내고 소수점 오차 때문에 pod가 하나 더 계산되지 않는지 경계값을 시험한다.

function requiredPods(rpm, serviceSeconds, targetUtilization, headroom) {
  const concurrent = (rpm / 60) * serviceSeconds;
  const raw = (concurrent * headroom) / targetUtilization;
  return Math.ceil(raw - 1e-12);
}

console.assert(requiredPods(6000, 0.2, 0.65, 1.3) === 40);

이 계산은 출발점일 뿐이다. 실제 pod 수는 CPU가 아니라 connection pool, downstream quota, cold start, node 장애와 zone 손실 조건을 포함한 승인된 부하 실험으로 확정한다.