Capacity planning: считать отдельные tiers и проверять SLO

Capacity — максимальная полезная нагрузка конкретного workload, которую система держит при заданных correctness, latency и error SLO. CPU count или число replicas сами по себе capacity не определяют.

Workflow

1. Forecast organic growth и inorganic events дальше provisioning lead time.
2. Зафиксировать endpoint mix, payload, cache state, regions и SLO.
3. Load test каждый tier и whole path, включая failure mode.
4. Найти safe operating point с headroom, а не short burst maximum.
5. Добавить explicit N+k redundancy по выбранному failure target.
6. Проверить quotas, warm-up, autoscaler lag и overload controls.
7. Пересчитывать после software/data/workload changes.

Сценарии

Achieved throughput считается только пока latency/error SLO выполняется. Closed-loop test может скрыть overload, если клиенты сами замедляют arrivals; production-shaped generator и telemetry обязательны.

Учебное допущение: λ=2,000 completed requests/s, W=0.120 s end-to-end. L=λW=240 average in-flight requests. Если DB занимает в среднем 0.020 s на request, отдельная DB boundary даёт около 40 average concurrent occupancies. Ни одно число автоматически не является connection pool size: нужны variance, queueing, transaction scope и headroom.

Учебные допущения: hard app maximum 2,000 RPS в тесте, 25% operating headroom → 1,500 planned RPS/unit. Forecast peak 12,000 → ceil(12,000/1,500)=8 healthy units. N+2 target → 10 total. Data RF не умножает stateless app count; database failover capacity считается своим workload.

Учебные допущения: 500 GB primary + 5 GB/day × 365 = 2,325 GB = 2.325 TB primary. RF3 total copies = 6.975 TB raw до indexes, compaction, WAL, snapshots и backups. Retention и restore bandwidth могут быть главным limit.

AWS gp3 на дату research ledger включает baseline 3,000 IOPS и 125 MiB/s; provisioned maxima и ratios меняются, поэтому production decision сверяется с current docs и проверяется реальным block-size mix.

Known campaign/launch pre-scales заранее и прогревает caches. Reactive autoscaling остаётся защитой второго уровня, но имеет измеренный detection/provision/warm-up lag. При saturation система shed optional work, ограничивает queues и сохраняет critical path.

Что считать отдельно

• stateless request capacity and N+k;
• cache memory, hit ratio and refill rate;
• primary write/read/lock/connection capacity;
• replicas: read load plus takeover at failover;
• storage logical bytes, RF, index/compaction/WAL overhead;
• backup retention, restore time and cross-region bandwidth;
• queue backlog growth and drain time.

Связанные темы

[CONCEPT]latency-vs-throughput

[CONCEPT]performance-vs-scalability

Первичные источники

• Little 1961: https://doi.org/10.1287/opre.9.3.383
• Google SRE capacity planning: https://sre.google/sre-book/introduction/
• Google SRE service best practices: https://sre.google/sre-book/service-best-practices/
• AWS EBS gp3: https://docs.aws.amazon.com/ebs/latest/userguide/general-purpose.html