부하 테스트와 용량 산정

목적이 다르므로 언제 하는지도 다릅니다.

둘째의 "어떻게" 가 핵심입니다. 한계를 넘었을 때 느려지기만 하는지, 오류를 돌려주는지, 아니면 통째로 죽는지가 완전히 다릅니다. 죽는 구조면 한계에 닿기 전에 막아야 합니다.

넷째는 짧은 테스트로는 절대 안 보입니다. 메모리 누수, 커넥션 누수, 디스크 채움은 시간이 지나야 드러납니다. 큰 변경 뒤에는 몇 시간짜리를 한 번 돌리는 것이 값이 큽니다.

흔한 실수: 부하 테스트만 하고 끝내는 것. 목표 트래픽에서 통과했다는 것은 그 지점까지만 안다는 뜻이고, 여유가 얼마나 남았는지는 모릅니다. 한계를 한 번은 찾아 둬야 증설 시점을 정할 수 있습니다.

평균이 아니라 몰리는 순간에서 시작합니다.

1. 몰리는 시간대의 초당 요청을 구합니다. 하루 요청을 86400 으로 나눈 값은 실제 필요량이 아닙니다. 대개 몰리는 시간이 하루 요청의 큰 몫을 가져갑니다.
2. 서버 한 대의 처리량을 잽니다. 목표 지연을 지키면서 낼 수 있는 초당 요청입니다. 최대 처리량이 아니라 목표 지연 안에서의 처리량입니다.
3. 나눕니다. 필요 대수 = 몰리는 초당 요청 / 대당 처리량.
4. 여유를 더합니다. 한 대가 빠져도 남은 대수가 받을 수 있어야 합니다.
5. 뒤쪽 한계를 확인합니다. DB 연결 수, 외부 API 한도가 대수를 곱한 만큼 늘어납니다.

4번이 대수를 실제로 정합니다. 세 대로 딱 맞으면 한 대가 빠질 때 남은 둘이 1.5배를 받습니다. 그걸 견디는지가 진짜 기준입니다.

5번을 자주 놓칩니다. 서버 10대에 커넥션 풀 50이면 DB 는 500개의 연결을 받습니다. 우리 쪽을 늘려서 뒤쪽을 무너뜨리는 것이 증설 사고의 흔한 모양입니다.

흔한 실수: 대당 처리량을 최대치로 잡는 것. 최대 처리량 지점은 이미 지연이 나빠진 구간입니다. 목표 지연을 지키는 지점으로 잡아야 계산이 현실과 맞습니다.

지표가 같이 오르는지 따로 노는지를 봅니다.

둘째와 다섯째를 구분하는 것이 중요합니다. 둘 다 CPU 가 한가한데, 하나는 우리 DB 고 하나는 남의 API 입니다. 대응이 완전히 다릅니다.

부하를 단계적으로 올리면서 처리량과 지연을 같이 그리면 무릎이 보입니다. 처리량이 더 안 오르는데 지연만 오르기 시작하는 지점이 한계입니다. 그 지점 직전의 자원 지표를 보면 무엇이 먼저 찼는지 드러납니다.

동시 사용자 수를 늘려도 처리량이 그대로면, 병목이 우리 서버 바깥에 있을 가능성이 큽니다. 부하 생성기 자신이 한계일 수도 있으므로 그것도 의심해야 합니다.

흔한 실수: 평균 지연만 보는 것. 평균은 멀쩡한데 상위 구간이 무너지는 경우가 많고, 사용자가 겪는 것은 그 상위 구간입니다.

가장 크게 어긋나는 것은 데이터입니다.

첫 줄과 둘째 줄이 압도적입니다. 운영에서 느린 질의는 대개 데이터가 쌓였거나 한 사용자가 유난히 많은 데이터를 가졌기 때문인데, 깨끗한 시험 데이터로는 절대 안 보입니다.

캐시도 조심해야 합니다. 같은 요청을 반복해 던지면 적중률이 100%에 가까워져 실제보다 훨씬 좋은 숫자가 나옵니다. 키를 실제 분포와 비슷하게 흩어야 의미가 있습니다.

외부 의존을 가짜로 바꿀 때는 지연도 같이 흉내 내야 합니다. 즉시 응답하는 가짜를 두면 타임아웃과 재시도 경로가 한 번도 안 돌아 본 채 배포됩니다.

흔한 실수: 시험 통과를 운영 안전으로 읽는 것. 통과한 것은 그 데이터와 그 구성에서 통과한 것입니다. 차이를 목록으로 적어 두고, 그중 무엇을 못 본 채 배포하는지 알고 넘어가는 편이 낫습니다.