capacity-planning-deep.js·5 scenarios
production capacity provisioning workflow с реальными числами
back-of-envelope учит грубо посчитать RPS, storage, bandwidth «за минуту на собеседовании». Этого достаточно для интервью, но в продакшене этого мало. Тебе нужно обоснованно решить сколько именно нод, с каким headroom, с какой autoscale-политикой, чтобы пережить пиковую нагрузку (Black Friday, viral эпизод, отказ AZ) — не сжигая 10× денег на overprovisioning в будни.
Разница между «провижин на пик + headroom × replication» и «давайте просто t3.large» — это разница между архитектором и джуном, который через месяц после launch будет хоронить прод в 3 часа ночи. Capacity planning — это не про «сколько RAM надо», это дисциплина: baseline → forecast → peak factor → replication → headroom → compute. Пропустишь шаг — получишь либо outage, либо вдвое больший cloud bill, чем у конкурента.
Этот гайд — про серьёзное capacity planning: Little's law, Universal Scalability Law (USL), headroom-философию, predictive vs reactive scaling, demand forecasting и storage projections. Темы, которые отделяют грамотного SRE/архитектора от копи-паста из чужих terraform-конфигов.
«Provision на P99 пик × N% headroom × replication factor. Headroom <30% — будете гореть на каждом всплеске и упадёте при первом же отказе AZ. Headroom >100% — сжигаете деньги. Sweet spot обычно 40-60% utilization в норме — этого хватает, чтобы потеря 1 из 3 AZ не уронила прод.»
Шесть шагов workflow:
1. Baseline — что у нас сейчас (RPS, latency, storage growth)
2. Forecast — куда растём (linear/exponential/seasonal model)
3. Peak factor — пик / норма (обычно 3-10×, в commerce до 50×)
4. Replication — factor для HA (3× минимум для cross-AZ prod)
5. Headroom — buffer для всплесков и failover (30-50%)
6. Compute — node count × CPU × RAM × storage × network
Капасити-план без хотя бы одного из шагов = угадывание под другим названием.
Топология — типичный stateless web-tier: Load Balancer, три App Instance, общий Redis Cache и Postgres. Намеренно простая — capacity planning интересен не геометрией, а цифрами на каждом узле и связкой между шагами workflow.
ADR на узле App Instance 1 развёрнут: контекст с реальными post-mortem (Reddit «hug of death», Twitter «Black Hawk Down», Stripe Black Friday), решение — шесть шагов workflow и инструменты (Little's law, USL, queueing theory). Это короткий конспект всего урока, привязанный к узлу диаграммы — на него можно сослаться при code review архитектуры.
Пять анимационных сценариев соответствуют шагам workflow:
Шаг 1: измеряем что есть сейчас. avg 1K RPS, p99 100ms, app servers на 30% утилизации, БД 2TB и растёт +5GB/день. Цифры — это якорь, без них планирование = гадание.
Шаги 2-3: forecast +20% per quarter и умножение на исторический peak factor. 1K RPS × 50 (Black Friday для commerce) = 50K RPS. Provisionim под 50K, не под 1.2K.
Шаг 4: каждый компонент умножается на replication factor. 50K RPS × 3 AZ = 150K total capacity. Per-instance 5K RPS → 30 instances total. 2TB × 3 replicas = 6TB durable storage.
Шаг 5: если взять ровно 30 instances под 50K peak, потеря одного instance кладёт остальные на 100% и запускает каскад. +30% buffer (40 instances) держит N-1 fail tolerance.
Reactive autoscale: trigger по CPU > 80%, lag 1-5 минут (warmup + image pull). Виральный твит за 30 секунд уложит до того, как новые ноды поднимутся. Predictive scaling (AWS Predictive Scaling, GCP Autoscaler, ML на historical patterns) provisionim до того, как нагрузка пришла. Реальные системы комбинируют: predictive baseline + reactive surge для непредсказуемых событий.
L = λ × W
L = average concurrent requests in system
λ = arrival rate (RPS)
W = average time per request (latency, sec)
Это не «математика ради математики». Применение:
L = 10000 × 0.08 = 800 одновременных запросов.Little's law — это база всей queueing theory. На собеседовании покажешь, что считаешь не «сколько RAM», а что на самом деле сидит в системе.
Линейный scale-out — миф. Реальность:
C(N) = N / (1 + α(N-1) + β·N·(N-1))
α — contention (shared resource: lock, БД, кеш)
β — coherence (synchronization between nodes: cache invalidation, gossip)
При больших N coherence-член (β·N²) начинает доминировать → throughput падает с добавлением нод. Это объясняет, почему «просто добавим серверов» работает до 10-20 машин и упирается в потолок.
Цели capacity-плана:
Практически: load test на 1, 2, 4, 8, 16, 32 нодах, fit USL-кривую (есть готовые fitters), посмотри где knee. Дальше — sharding по tenant/region.
| Школа | Target utilization | Когда применять |
|---|---|---|
| Google SRE | 50% | distributed services, MTTR > minutes |
| AWS («plan for 2×») | 50% (= 100% headroom) | unpredictable workloads, Lambda |
| Cost-aggressive | 70-80% | well-understood batch workloads |
| Reliability-paranoid | 30-40% | financial, healthcare critical path |
Почему 50%: при отказе 1 из 2 AZ оставшаяся handles удвоенную нагрузку без degradation. Если работали на 70% — после failure будет 140%, deploy fails, cascading. Если 30% — платишь за идлящий cloud bill.
Stripe Black Friday: ~50× normal, planning cycle 3 месяца. YouTube Felix Baumgartner skydive 2012: 8M concurrent live viewers, pre-provisioned за неделю.
storage_at_T = current + (write_rate × retention_days × replication_factor)
Не забывай:
Egress часто — главный bill. AWS egress в интернет ~$0.09/GB после первых 100 GB free. 1 PB/мес = $90K только за вывод данных. CDN кеш дешевле в 5-10×. Cloud cost обычно: compute 30%, storage 20%, egress 30%, остальное — managed services.
Контекст. Команда стартапа catch-22: провижин по среднему usage = первая виральная фича катастрофически уронит прод (Reddit hug of death). Провижин по 100× peak = burn rate уничтожит runway за квартал. Нет «правильного» ответа — есть дисциплинированный workflow, который минимизирует обе крайности.
Решение. Шесть шагов workflow, документированы как ADR в архитектуре:
Baseline. Метрики собираем непрерывно (Prometheus, Datadog, CloudWatch). Без baseline планировать нечего. Минимально: RPS, p50/p99 latency, CPU/RAM utilization per service, storage growth rate, error rate. Через 4-6 недель накапливается weekly/daily паттерн.
Forecast. Linear regression — достаточно для большинства. Holt-Winters seasonal decomposition если есть явная сезонность. Prophet/ARIMA — для weekly+monthly+holiday паттернов. ML (LSTM/transformer) — только если cost overprovisioning > cost ML-инфры (Uber, Airbnb).
Peak factor. Берём из истории своего бизнеса. Нет истории — берём industry baseline (commerce 30-50×, news 10-20×, SaaS 2-3×). Если есть analyst — попроси, чтобы он предсказывал peak факторы под кампании (Black Friday → 50×, новый launch → 5-10×).
Replication. Минимум 3× для cross-AZ HA в проде. 2× не хватает (split-brain в кворуме). 6× — для cross-region disaster recovery. Replication multiplies всё: storage cost, network bandwidth между AZ (AWS берёт $0.01/GB за inter-AZ), write amplification.
Headroom. Google SRE 50% — дефолт. Compute = expensive resource → 70% можно если warmup быстрый и autoscale надёжный. Database = scarce resource → 30-40% обязательно (БД масштабируется болезненно). Headroom это не «жирно» — это insurance, которая платит при failure events.
Compute. Перевод в железо. CPU baseline на per-request: измерили на load test, не угадали. Network bandwidth: 1 Gbps на инстанс — норма, 10 Gbps — премиум. Storage IOPS: gp3 → 16K IOPS дефолт, дальше — io2 за x10 cost.
Альтернативы.
Последствия.
hot-key-mitigation). Capacity-план должен учитывать per-shard P99, не cluster average.Capacity planning — это инвестиция времени и инструментов. Скип оправдан в трёх случаях:
Раняя стадия (MVP, < 100 DAU). Узкое место — product-market fit, не infra. Один t3.medium + managed RDS, autoscale 1→3 instances, всё. Тратить недели на USL fitting когда у тебя 10 users = premature optimization. Возвращаешься к workflow когда видишь steady traffic growth.
Spiky, low-baseline serverless workloads. Lambda + DynamoDB on-demand + S3 решают capacity автоматически за тебя за деньги. Если cost не главное (internal tools, low-volume APIs), просто включай on-demand и не задумывайся. Workflow нужен когда счёт >$10K/мес или когда performance критичен (cold start kills UX).
Stable, predictable batch workloads без peak. Hourly cron job, batch ETL ночью, predictable load — берёшь reserved instances на год, headroom 20%, забываешь. USL и predictive scaling — для interactive traffic с variance.
Во всех остальных случаях (interactive web/mobile, user-facing API, anything с variable load) — workflow обязателен. Шесть шагов занимают день на первый раз, час на quarterly refresh.
back-of-envelope — базовые оценки RPS / storage / bandwidth.numbers-to-know — Jeff Dean numbers, latency константы для расчётов.latency-vs-throughput — почему оптимизация одного убивает другое.availability-numbers — 99.9% vs 99.99%, MTBF/MTTR.performance-vs-scalability — vertical vs horizontal scaling trade-offs.hot-key-mitigation — почему average usage не показывает per-shard перегрузку.Книги и источники:
Применяется в кейсах: