Оценщик ёмкости

Сколько серверов вам на самом деле нужно? Отвечайте арифметикой, а не ощущениями: дайте оценщику вашу скорость запросов, время CPU, которое сжигает каждый запрос, и время ответа, которое видят пользователи, и он вернёт ядра, которые трафик держит занятыми, целые серверы для выделения — с применённой вашей политикой резервирования, — параллелизм, который ваши пулы соединений должны пережить, и то, как та же служба выглядит при двух-, пяти- и десятикратном трафике.

Формулы простым языком

Ядра. Умножьте скорость запросов на секунды CPU, которые потребляет каждый запрос: это то, сколько ядер трафик держит занятыми при 100%. Затем разделите на вашу целевую загрузку — при 70% каждое выделенное вами ядро считается лишь как 0,7 планового ядра, а остальные 0,3 — это запас, который держит очереди короткими, когда трафик колеблется. Нужно ядер = запросов/с × секунды CPU на запрос ÷ целевая загрузка.

Серверы. Разделите ядра на ядра на сервер и округлите вверх — не существует такой вещи, как 0,4 сервера, а округление вниз — это то, как план, работающий в среднем, проваливается на пике. Резервирование применяется после: N+1 добавляет один запасной сервер к округлённому числу; 2N удваивает весь флот. Параллелизм — это отдельное число из Little's law: запросы в полёте = запросов/с × время ответа в секундах. Он определяет размер пулов потоков, соединений с базой данных и файловых дескрипторов — пределов, в которые службы на самом деле упираются, пока их CPU ещё бездельничают. Исходящий трафик, когда вы даёте размер ответа, равен запросов/с × размер × 8 — биты, из которых состоит ваш счёт за сеть. Сопутствующая статья, сколько серверов вам на самом деле нужно, объясняет, откуда берётся каждая входная величина и почему бенчмарки поставщиков не согласуются со всем этим.

Собратья по планированию: калькулятор бюджета ошибок SLA превращает цель доступности, которую защищает эта ёмкость, в минуты, а калькулятор хранения резервных копий определяет размер стороны хранения той же системы.

Часто задаваемые вопросы

Почему планировать на 70% загрузки, а не на 100%?

Потому что очереди взрываются до насыщения, а не в нём. CPU, занятый в среднем на 95%, — это CPU, чья очередь растёт безгранично при каждом колебании трафика, а трафик колеблется всегда. Цель загрузки — это запас, который поглощает пики, развёртывания, повторные попытки и одну медленную зависимость. Семьдесят процентов — отраслевое значение по умолчанию для служб, чувствительных к задержке; пакетные работники, терпящие задержку, могут работать горячее, а всё, что обращено к пользователям и имеет всплески, должно работать холоднее.

В чём разница между ядрами и запросами в полёте?

Они отвечают на разные вопросы. Ядра происходят из времени обслуживания CPU: сколько процессора потребляет каждый запрос. Запросы в полёте происходят из Little's law: скорость, умноженная на время ответа, и они измеряют параллелизм — соединения, потоки, удерживаемую открытой память, — а не нагрузку на процессор. Служба с медленными нисходящими вызовами может держать 500 запросов в полёте, используя два ядра, и у неё закончится пул соединений задолго до того, как закончится CPU. Определяйте размер обоих, иначе тот, что вы проигнорировали, станет аварией.

Мой нагрузочный тест говорит, что один сервер обрабатывает 2 000 запросов в секунду. Почему этот оценщик не согласен?

Нагрузочные тесты обычно измеряют тёплую, стабильную службу с горячим кешем, отвечающую на запросы одной формы от щедрого клиента. Производство добавляет холодные старты, рукопожатия TLS, повторные попытки, длинный хвост медленных запросов, шумных соседей и развёртывание, которое уполовинивает ёмкость на десять минут. Оценщик намеренно консервативен — среднее время CPU, потолок загрузки, целые серверы, добавленное резервирование. Относитесь к нагрузочному тесту как к потолку возможного, а к этому числу — как к полу того, что нужно выделить; истина для планирования — это пол.

От чего на самом деле защищает N+1?

От одного отказа: мёртвого хоста, плохого развёртывания, выведенного из ротации, события зоны доступности, которое уносит один экземпляр. С N+1 оставшиеся N серверов всё ещё выполняют цель — в этом смысл сначала определить N по трафику и добавить запасной после. 2N — это другое обещание: две полные копии, обычно между регионами, для служб, которые должны пережить потерю целой копии. Оно удваивает счёт, поэтому его покупают для служб, чьё отсутствие измеряется заголовками.

Как получить моё время обслуживания CPU на запрос?

Измеряйте его, а не угадывайте. На работающей службе: общее число секунд CPU, потреблённых за окно, делённое на запросы, обслуженные в том же окне. Инструменты мониторинга производительности приложений сообщают его напрямую как CPU на запрос; в Linux его можно вывести из времени CPU процесса в /proc или из метрик ваших контейнеров. Используйте число из вашего самого занятого реалистичного часа, а не среднее за весь день — ёмкость, спланированная по средним, проваливается именно на том пике, ради которого её покупали.