Ёмкость и планирование нагрузки

Почему нельзя загружать под завязку

Причина в случайности. Запросы приходят не ровным строем, а пачками, и обслуживаются тоже за разное время. Когда обработчик свободен половину времени, пачка рассасывается быстро. Когда он занят 90% времени, каждая пачка становится очередью, а очередь - это ожидание, которое добавляется к обслуживанию.

Полные числа моего замера: загрузка 50% - среднее 20,1 и квантиль 0,99 равен 92,8 миллисекунды; 70% - 32,8 и 146,3; 80% - 50,7 и 233,4; 90% - 99,2 и 463,6; 95% - 190,0 и 797,8. Обрати внимание: от 90% к 95% нагрузка выросла на пять процентов, а время ответа - вдвое.

// Отсюда практика планирования. Целятся в загрузку 50-70% в обычное время, чтобы был запас на пик и на потерю части мощности. Считают не по среднему, а по пиковой минуте: сервис, живущий в среднем на 40%, в вечерний час может быть на 85%. И помнят, что при отказе одной из трёх машин оставшиеся получают полуторную нагрузку - если они уже работали на 70%, то мгновенно окажутся за сотней.

загрузка

доля времени, которую обработчик занят

очередь

ожидание перед обслуживанием; именно она разгоняет время ответа

Сколько нужно и откуда берётся число

Базовый расчёт устроен просто. Если один экземпляр обрабатывает запрос за 10 миллисекунд, то на одном потоке это 100 запросов в секунду. Нужно держать 2000 - значит, нужно 20 обработчиков при стопроцентной загрузке, а с целевой загрузкой 60% уже 34. Плюс запас на отказ: если хотим пережить потерю одной машины из пяти, добавляем ещё четверть.

Второй вход в тот же расчёт - через число одновременных запросов. Среднее число запросов «внутри» сервиса равно потоку, умноженному на время обработки: 2000 в секунду по 50 миллисекунд - это 100 запросов одновременно. Это же число задаёт размеры пулов - заранее подготовленных запасов соединений к базе, потоков и рабочих мест.

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

пропускная способность

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

число одновременных запросов

поток, умноженный на время обработки; задаёт размеры пулов

Пики и скорость появления ёмкости

Готовность к пику держится на двух вопросах сразу: «сколько» и «как быстро». Автомасштабирование выглядит спасением, пока не посчитаешь время реакции: заметить рост (десятки секунд), принять решение, запустить машину или контейнер, дождаться прогрева приложения и наполнения кэшей. В сумме легко набегают минуты, а пик распродажи или рассылки приходит за секунды.

Отсюда разделение. Плавные предсказуемые изменения (день-ночь, будни-выходные) закрывают автомасштабированием. Известные заранее пики - предварительным увеличением по расписанию, за час до события. Внезапные всплески - запасом, который уже стоит и прогрет, плюс ограничением частоты запросов и очередями, которые превращают отказ в ожидание.

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

время появления ёмкости

сколько проходит от роста нагрузки до готового обслуживать экземпляра

предварительное увеличение

поднять мощность заранее под известное событие

ограничение частоты

приём, превращающий отказ в ожидание или в вежливый отказ части запросов

Как отвечать: «Загрузка процессора 85%, время ответа выросло вдвое. Докупать сервера?»

Сначала проверю, что упёрлись именно в процессор, а не в число соединений к базе, диск или чужой сервис - узкое место редко там, где смотрят в первую очередь. Но само по себе поведение нормальное и ожидаемое: время ответа растёт не линейно, а разгоняется у предела. Я моделировал очередь с обслуживанием по десять миллисекунд: при загрузке 50% среднее время 20 миллисекунд, при 90% - 99, а от 90% к 95% оно ещё удваивается. То есть последние проценты загрузки стоят дороже всех предыдущих. Поэтому целюсь в 50-70% в обычное время и считаю по пиковой минуте, а не по среднему за сутки. И обязательно закладываю запас на отказ: если из трёх машин выпадет одна, оставшиеся получат полуторную нагрузку, и при исходных 70% они мгновенно окажутся за сотней.

Ответ сначала ставит под сомнение диагноз, потом объясняет нелинейность числами и заканчивается запасом на отказ. Это разговор про планирование, а не про покупку железа.

На чём валятся

• −Планируют загрузку под 90% и удивляются росту времени ответа.
• −Считают по среднему за сутки, а не по пиковой минуте.
• −Не закладывают запас на отказ: выпадение одной машины из трёх добавляет остальным половину нагрузки.
• −Надеются на автомасштабирование там, где пик приходит быстрее, чем поднимается экземпляр.
• −Верят арифметике без нагрузочного испытания и упираются в узкое место, которого не было в расчёте.