용량 추정기

대기열은 포화 지점이 아니라 그 전에 폭발하기 때문입니다. 평균 95% 바쁜 CPU는 트래픽이 흔들릴 때마다 대기열이 한없이 자라는 CPU이고, 트래픽은 항상 흔들립니다. 사용률 목표는 피크, 배포, 재시도, 그리고 느린 의존성 하나를 흡수하는 여유입니다. 70%는 지연에 민감한 서비스의 업계 기본값이며, 지연을 견딜 수 있는 배치 워커는 더 뜨겁게 돌릴 수 있고, 사용자를 상대하고 뾰족한 것은 무엇이든 더 차갑게 돌려야 합니다.

서로 다른 질문에 답합니다. 코어는 CPU 서비스 시간에서 옵니다. 각 요청이 프로세서를 얼마나 소비하는지입니다. 처리 중인 요청은 Little's law에서 옵니다. 속도에 응답 시간을 곱한 것으로, 프로세서 부하가 아니라 동시 처리 수, 즉 연결, 스레드, 열린 채로 유지되는 메모리를 측정합니다. 하위 호출이 느린 서비스는 코어 2개를 쓰면서 500개의 요청을 처리 중으로 유지할 수 있으며, CPU가 바닥나기 훨씬 전에 연결 풀이 바닥납니다. 둘 다 크기를 정하세요. 무시한 쪽이 장애가 됩니다.

부하 테스트는 보통 너그러운 클라이언트로부터 한 가지 요청 형태에 답하는, 따뜻하고 안정적이며 캐시가 뜨거운 서비스를 측정합니다. 프로덕션은 콜드 스타트, TLS 핸드셰이크, 재시도, 느린 요청의 긴 꼬리, 시끄러운 이웃, 그리고 10분 동안 용량을 절반으로 만드는 배포를 더합니다. 이 추정기는 의도적으로 보수적입니다. 평균 CPU 시간, 사용률 상한, 전체 서버, 이중화 추가. 부하 테스트는 가능성의 천장으로, 이 숫자는 프로비저닝할 바닥으로 취급하세요. 계획에서의 진실은 바닥입니다.

한 번의 장애로부터입니다. 죽은 호스트, 로테이션에서 빠진 잘못된 배포, 단일 인스턴스를 가져가는 가용성 영역 이벤트. N+1이 있으면 남은 N대의 서버가 여전히 목표를 충족합니다. 먼저 트래픽에서 N의 크기를 정하고 그다음에 예비를 더하는 이유가 바로 그것입니다. 2N은 다른 약속입니다. 보통 리전을 넘나드는 두 개의 완전한 복사본으로, 복사본 전체를 잃어도 살아남아야 하는 서비스를 위한 것입니다. 요금이 두 배가 되므로, 그 부재가 헤드라인으로 측정되는 서비스를 위해 삽니다.

추측하지 말고 측정하세요. 실행 중인 서비스에서는 일정 구간 동안 소비된 총 CPU 초를 같은 구간에 처리한 요청 수로 나눕니다. 애플리케이션 성능 모니터링 도구는 요청당 CPU로 직접 보고합니다. Linux에서는 /proc의 프로세스 CPU 시간이나 컨테이너 메트릭에서 도출할 수 있습니다. 하루 평균이 아니라 현실적으로 가장 바쁜 1시간의 숫자를 사용하세요. 평균으로 계획한 용량은 바로 그 용량을 산 목적인 피크에서 실패합니다.