규모 추정은 자릿수를 맞추는 일이다

한 줄 요약

용량 산정의 목적은 정확한 숫자가 아니라 자릿수를 맞추는 것이다. 인스턴스 3대가 필요한지 30대가 필요한지가 갈리면 설계 전체가 달라진다.

왜 이게 필요했나

시스템 설계는 네 단계로 진행된다. 요구사항 명확화 → 규모 추정 → 고수준 설계 → 상세 설계(병목 파악과 해결). 두 번째 단계를 건너뛰면 나머지가 전부 공상이 된다.

간단한 예를 보자. 쓰기가 하루 1억 건이면 QPS 는 약 1,160 이다(1억 ÷ 86,400). 읽기가 그 10배면 QPS 약 11,600 이다. 5년치 1,800억 건에 레코드당 500바이트를 곱하면 약 90TB 다. 이 세 숫자가 나오면 "단일 인스턴스로 충분한가", "샤딩이 필요한가", "캐시 없이 가능한가" 같은 질문에 근거를 갖고 답할 수 있다.

어떻게 동작하나

측정에서 대수로 가는 길에는 두 개의 안전장치가 있다.

첫째는 헤드룸이다. 측정된 최대 처리량을 그대로 쓰면 안 된다. 안전 처리량은 측정값의 70% 정도로 잡는다. 나머지 30% 는 트래픽 변동, 배포 중 인스턴스 감소, 예상치 못한 느린 요청을 위한 자리다. 인스턴스당 190 RPS 를 측정했다면 안전 처리량은 133 RPS 다.

둘째는 올림이다. 목표 300 RPS 를 133 으로 나누면 2.25 대가 나오는데, 2대로는 부족하므로 3대다. 용량 계산에서 소수점 아래를 버리면 그 순간 계획은 실패한다.

풀 사이징에서도 같은 사고가 필요하다. 인스턴스 하나의 권장 풀 크기를 60 으로 정했다면 반드시 함대 단위로 곱해 본다. 인스턴스 40대 × 60 = 2,400 연결인데 데이터베이스의 max_connections 가 200 이라면, 각 인스턴스의 계산은 모두 옳았지만 시스템은 배포 직후 죽는다. 로컬 최적이 전역 최적이 아닌 전형적인 사례다.

현장에서 만나는 모습

용량 문서에서 가장 흔한 결함은 조건이 없다는 것이다. "우리 서비스는 초당 500건을 처리한다"는 문장에는 동시성도, p95 도, 에러율도, 측정 시점도 없다. 같은 서비스가 동시성 2에서는 p95 20ms 로 500 RPS 를 내고 동시성 50에서는 p95 900ms 로 520 RPS 를 낸다면, 두 번째 숫자는 용량이 아니라 이미 포화된 상태의 관측값이다.

그래서 용량은 항상 SLA 와 함께 적어야 한다. "p95 200ms 이하, 에러 0 조건에서 인스턴스당 133 RPS" 처럼 써야 다음 사람이 같은 기준으로 재현할 수 있다.

현장 판단의 순서

1. 목표 트래픽을 정한다(피크 기준, 평균 아님).
2. 인스턴스 하나의 안전 처리량을 SLA 조건에서 측정한다.
3. 헤드룸을 반영해 70% 로 낮춘다.
4. 나눠서 올림한다.
5. 공유 자원(DB 커넥션, 캐시, 큐)의 상한과 곱셈으로 다시 검산한다.

다음 확인에서 볼 것

이 모듈은 실습 없이 개념과 계산을 확인하는 퀴즈로 마칩니다. 앞의 세 모듈에서
만든 기준선·사다리·병목 리포트의 숫자를 평균 QPS, 피크 배수, 헤드룸을 반영한
안전 처리량과 필요한 인스턴스 수로 바꾸는 과정을 검산합니다.