Traffic Estimation Capacity Planning

트래픽 추정은 사용자 수 -> 행동 빈도 -> 평균/피크 QPS -> 저장량/대역폭/메모리 -> 여유율로 바꾸는 작업이다.
추정값은 정답이 아니라 설계 선택의 근거다. 같은 2,000 QPS라도 읽기인지 쓰기인지, 특정 key에 몰리는지, retry가 붙는지에 따라 구조가 달라진다.
이 챕터의 중심은 계산식 암기가 아니라 성능, 정합성, 장애 격리, 운영 복잡도 중 무엇을 바꿀지 설명하는 것이다.

DAU와 MAU는 사용자의 규모를 말하고, QPS와 TPS는 시스템이 초당 감당해야 하는 일을 말한다.
평균 QPS만으로는 부족하다. 활성 시간대, 이벤트 피크, retry, batch, fanout을 분리해야 병목 위치가 보인다.
읽기와 쓰기는 따로 계산한다. 읽기는 cache, replica, CDN으로 흘릴 수 있지만 쓰기는 lock, index, transaction, idempotency에 걸린다.
저장량은 건수 * payload size * 보존 기간으로 시작하고 index, replication, 압축, 삭제 정책을 더한다.
대역폭은 응답 크기와 egress 비용을 드러내고, 메모리는 hot set과 TTL 정책을 드러낸다.
여유율은 낭비가 아니라 실패 중 버티는 능력이다. 다만 과한 여유율은 비용과 운영 복잡도를 키운다.

사용자의 규모를 정한다.
- MAU, DAU, 동시 접속자, 활성 시간대를 분리한다.
행동을 세분화한다.
- 조회, 생성, 수정, 결제, 알림 발송, 검색처럼 비용이 다른 행동을 따로 적는다.
평균과 피크를 계산한다.
- 평균은 baseline이고 피크는 설계 기준이다.
읽기와 쓰기를 나눈다.
- read QPS, write TPS, hot key, hot row, fanout을 따로 본다.
저장량과 전송량을 계산한다.
- payload, index, 보존 기간, 응답 크기, cache hot set을 숫자로 둔다.
병목을 설계 선택으로 연결한다.
- cache, queue, read replica, partition, rate limit, retention, bulkhead 중 무엇이 필요한지 결정한다.
검증 지표를 붙인다.
- p95 latency, error rate, CPU, connection pool, queue age, DB write latency, cache hit ratio를 남긴다.

QPS가 낮으면 단순 구조로 충분하다고 생각하기 쉽다.
- 실제 병목은 평균보다 hot key, lock, 외부 API quota, batch 겹침에서 먼저 온다.
read 95%, write 5%면 읽기만 중요하다고 착각하기 쉽다.
- 쓰기 5%가 주문 재고, 결제 승인, 포인트 적립처럼 정합성 경계에 걸리면 쓰기 쪽이 설계를 지배한다.
저장량 계산을 DB 용량으로만 보는 경우가 많다.
- index, replica, backup, 로그, 분석용 적재, 보관 저장소까지 포함해야 운영 비용을 설명할 수 있다.
여유율을 항상 크게 잡으면 안전하다고 느끼기 쉽다.
- 큰 여유율은 비용을 올리고, scaling 정책과 alert가 없으면 장애 중 실제로 쓰이지 못한다.

01. QPS TPS DAU MAU 추정 상세.md: 사용자 규모와 행동 빈도를 초당 부하로 바꾸는 기준을 다룬다.
02. Read Write 비율과 Peak Traffic 상세.md: 읽기/쓰기 병목과 피크 모양을 분리한다.
03. Storage Bandwidth Memory 추정 상세.md: 저장량, 대역폭, cache memory를 계산해 비용과 운영 경계를 잡는다.
04. Capacity Planning과 여유율 상세.md: headroom, failover, autoscaling, backlog drain을 설계 기준으로 바꾼다.
05. 추정값을 설계 결정으로 연결 상세.md: 숫자를 cache, queue, replica, shard, rate limit 같은 선택으로 연결한다.

동블