Рабочая нагрузка против использования

Два разных числа, оба необходимы

Планирование мощности не удаётся, когда команды измеряют только один из двух существенных измерений.

Рабочая нагрузка: спрос на систему извне. Запросы в секунду, операции в минуту, мегабайты в секунду, одновременные пользователи. Рабочая нагрузка описывает, что мир требует от вас.

Использование: насколько полно работает система при обслуживании этого спроса. Процент CPU, используемая память, глубина очереди, пропускная способность сети, операции ввода-вывода диска. Использование описывает, как система ощущается под этим спросом.

Только рабочая нагрузка говорит вам, что приближается, но не можете ли вы её обслужить. Только использование говорит вам, насколько вы заполнены, но не говорит вам, что ожидать завтра. Вам нужны оба, отложены рядом друг с другом, чтобы принять решения по мощности.

Коэффициент мощности = рабочая нагрузка / использование. Если вы обслуживаете 1000 запросов в секунду при 50% CPU, ваш коэффициент мощности составляет 2000 RPS на 100% CPU на сервер. Этот коэффициент преобразования позволяет вам преобразовать прогнозируемую рабочую нагрузку в требуемое количество серверов.

Олспоу подчёркивает измерение с правильной гранулярностью. Один образец в минуту скрывает пики в 30 секунд. Один образец в час скрывает всё. Реальная работа с мощностью требует разрешения менее одной минуты для пиковых событий и разрешения в минуту для тренда. Что-либо более грубое создаёт опасную ложную уверенность.

Что инструментировать

Ваша команда запускает инструментарий мощности для нового запуска продукта (сервис транскодирования видео). Вы можете выбрать до 8 метрик для отслеживания с разрешением менее одной минуты. Сервис принимает загрузки видео, ставит их в очередь, транскодирует в несколько форматов и записывает выходные данные в объектное хранилище.

Тренд, сезонность, неопределённость

Три слоя каждого прогноза

Олспоу и книга Google SRE согласны со структурой полезного прогноза: тренд, сезонность и границы неопределённости. Пропустите любой из них и прогноз становится вводящим в заблуждение.

Тренд: наклон спроса в течение месяцев или лет. Часто моделируется с линейной регрессией для коротких окон, экспоненциальной или кусочно-линейной для совокупного роста. Линия тренда отвечает на вопрос 'куда направлен спрос в целом?'

Сезонность: циклические закономерности в несколько временных масштабов. Ежедневная (пиковый трафик днём), еженедельная (пики в выходные), ежегодная (Black Friday, налоговый сезон, учебный год). Мультипликативная сезонность масштабируется с трендом; аддитивная сезонность добавляет постоянное смещение.

Границы неопределённости: конус прогноза. Прогноз без границ — это предположение. Реальные прогнозы публикуют центральную оценку с явными верхними и нижними границами, обычно при 90% или 95% уверенности. Конус расширяется по мере того, как вы проецируете дальше в будущее. Прогноз на 4 недели может иметь границы ±10%; прогноз на 12 месяцев часто имеет границы ±50%.

Разделение бизнес-роста и технического спроса: планирование мощности прогнозирует технический объём работ, но команды бизнеса прогнозируют доход, регистрации или кампании. Работа планировщика мощности — переводить бизнес-прогнозы в технический спрос: рост на 30% регистраций может означать на 30% больше вызовов API, но может означать на 80% больше, если новые пользователи используют систему более активно, или только 15%, если они конвертируют с более низкими ставками. Коэффициент конверсии имеет значение столько же, сколько и основной бизнес-прогноз.

Прогнозирование праздничного трафика

Ваш сервис обслуживает сайт электронной коммерции. Трафик Black Friday в прошлом году был 5x среднего ноября, поддерживаемый 12 часов. Бизнес вырос на 40% год к году. Маркетинг запускает платную акцию, которая, как ожидается, добавит дополнительные 20% к трафику Black Friday в этом году.

Знание вашего потолка

Найдите потолок до того, как это сделает production

Прогнозирование говорит вам, что приближается. Пороговые тесты говорят вам, может ли система это обслужить. Олспоу рассматривает пороговое тестирование как незаменимый вклад в планирование мощности: вы не знаете вашей истинной мощности, пока не тестировали её под контролируемой нагрузкой.

Три типа пороговых тестов:

- Синтетический тест нагрузки: генератор нагрузки (k6, Locust, JMeter, vegeta) направляет трафик на целевой сервис в staging. Увеличивайте нагрузку, пока что-то не сломается. Точка разрыва — это потолок. Лучше всего для изолированного тестирования сервиса.

- Учебное пожарное испытание production: намеренно сокращайте мощность в production (осушите процент серверов, убейте регион) и наблюдайте, как оставшаяся мощность обрабатывает реальный трафик. Тестирует истинное поведение production, включая неожиданные взаимодействия. Наивысокая уверенность, но наивысокий риск.

- Shadow load: воспроизводите реальный production трафик на целевом сервисе, работающем параллельно production. Захватывает реальные модели рабочей нагрузки (редкий микс запросов, странные user agents) без воздействия на пользователей. Сильный компромисс.

Запас — это буфер между текущей нагрузкой и потолком. Правила SRE:

- 50% запаса в установившемся режиме для сервиса в одном регионе (чтобы отказ региона не исчерпал оставшийся регион)

- 30% запаса для сервиса в нескольких регионах с избыточностью N+2

- 100%+ запаса, приближаясь к известным пиковым событиям (Black Friday, финалы спорта)

Запас не отходы. Это стоимость того, чтобы не звонить инженерам в 3 часа ночи, не потерять клиентов во время скачка и не страдать от каскадного отказа, когда один регион выходит из строя. Финансовые команды иногда пытаются сократить запас; инженеры по мощности должны сформулировать стоимость работы в тесном режиме, чтобы сделать этот разговор фактическим, а не эмоциональным.

Проектирование порогового теста

Вы наследуете сервис без документированного потолка мощности. Текущая production нагрузка составляет 800 запросов в секунду на 12 серверах, средний CPU 35%. Маркетинг объявляет кампанию через 6 недель, которая, как ожидается, направит трафик к пику 3000 RPS.

Вверх, наружу или по диагонали

Когда добавлять мощность, добавлять боксы или оба

Три основных стратегии масштабирования, каждая с различными профилями стоимости и надёжности:

Вертикальное масштабирование (масштабирование вверх): большие машины. Замените 8-ядерные серверы на 32-ядерные серверы. Самый простой путь; работает до достижения ограничений одной машины. Единственная точка отказа остаётся. Стоимость растёт нелинейно: 32-ядерная машина часто стоит больше, чем 4x 8-ядерная.

Горизонтальное масштабирование (масштабирование наружу): больше машин. Добавьте серверы за балансировщиком нагрузки. Мощность масштабируется линейно с количеством серверов. Режимы отказа сдвигаются: вы должны обрабатывать распределённую координацию, но отказ одного сервера больше не разрушает сервис. Операционная сложность увеличивается.

Диагональное масштабирование (термин Олспоу): сначала масштабируйте вверх до удобного размера на сервер, затем масштабируйте наружу оттуда. Объединяет более простые операции больших серверов с избыточностью нескольких серверов. Большинство production сервисов живут в территории диагонального масштабирования.

Зарезервированная против по запросу ценообразование: поставщики облака награждают предсказуемость. Зарезервированная мощность на 30-60% дешевле, чем по запросу, но требует обязательства на 1-3 года. Планировщики мощности обычно закрепляют спрос в установившемся режиме с зарезервированной мощностью и выбиваются в по запросу для пиков. Неправильная оценка этого разделения может либо тратить деньги (избыточное резервирование), либо подвергать бюджет риску (недостаточное резервирование во время пиков).

Spot-экземпляры и прерываемые рабочие нагрузки: на 60-90% дешевле, чем по запросу, но могут быть отозваны за несколько минут уведомления. Подходят для пакетных заданий, аналитики, обучающих рабочих нагрузок или любого сервиса, разработанного для корректного прерывания. Production трафик, ориентированный на пользователя, обычно избегает spot.

Выбор пути масштабирования

Ваш сервис транскодирования видео работает на 8 среднесрочных облачных экземплярах (по 8 ядер каждый). Вы ожидаете роста в 3 раза в течение следующих 6 месяцев. Рабочая нагрузка привязана к CPU, параллелизируется на видео, и каждое видео-транскодирование занимает 90 секунд от начала до конца. Зарезервированные экземпляры стоят 50% по запросу. Spot-экземпляры стоят 30% по запросу, но могут быть прерваны с уведомлением в 2 минуты.

Карьеры планирования мощности

Где навыки планирования мощности платят

Планирование мощности редко является самостоятельным названием должности. Навыки появляются в нескольких ролях:

Инженер надёжности сайта: планирование мощности — это основная ответственность SRE. Большинство SRE команд имеют одного или двух инженеров, которые специализируются на мощности, владея моделями прогнозирования, пороговыми тестами и автоматизацией провизионирования.

Инженер облачной стоимости / FinOps: новее роль, сосредоточенная на оптимизации облачных расходов. Объединяет планирование мощности с финансовым моделированием, переговорами по контрактам и управлением портфелем зарезервированных экземпляров. Платит чрезвычайно хорошо в крупных облачных компаниях, поскольку счета облака часто являются вторым по величине расходом после зарплат.

Инженер производительности: сосредоточивается на эффективности за узел и пороговом тестировании. Работа: извлечь больше мощности из одного и того же оборудования через профилирование, оптимизацию и архитектурные изменения. Тяжелые знания систем и языка среды выполнения.

Специалист по планированию мощности: в очень крупных компаниях (Google, Meta, Amazon, Netflix) существуют выделенные команды планирования мощности. Они владеют моделями прогнозирования по всему парку, ведут переговоры о провизионировании в масштабе и координируют с финансами по многолетним дорожным картам оборудования.

Навыки, которые нарастают: анализ временных рядов (R, Python statsmodels, Prophet), теория очередей (M/M/1, M/M/c, закон Литтла), по крайней мере один инструмент управления конфигурацией, по крайней мере один облачный панель затрат и способность написать отчёт прогноза, который CFO может понять и действовать на нём. Технические навыки получают вам интервью; коммуникационные навыки получают вам бюджет.

Завёртывание

Что вы теперь знаете

Планирование мощности — это непрерывная дисциплина, а не ежегодное упражнение. Вы рассмотрели:

- Коридор между недостаточным и избыточным провизионированием

- Рабочую нагрузку против использования как две измерения измерения

- Тренд, сезонность и границы неопределённости как три слоя каждого прогноза

- Пороговые тесты (синтетические, shadow, учебные) как единственный способ узнать истинную мощность

- Буферы запаса и почему они не отходы

- Диагональное масштабирование и решение о ценообразовании зарезервированные/по запросу/spot

- Пути карьеры, где эти навыки получают бюджетные органы

Два идеи имеют значение. Прогнозируйте с границами, никогда с единственными точками. И измеряйте ваш потолок до того, как это сделает production. Несите эти два вперёд и остальное следует.

Рекомендуемое чтение: 'The Art of Capacity Planning' Олспоу (O'Reilly, 2017 второе издание), соответствующие главы в книге Google SRE (бесплатно на sre.google/books/) и 'Systems Performance' Брендана Гретча для основной работы систем. Урок-компаньон по геометрии углубляется в визуальную структуру: закон Литтла как область, кривые очередей, наклоны тренда и конверты запаса.