Затем нужно оценить сценарий и продолжительность процедуры масшабирования. Если у вас масштабирование устроено по принципу “жмём кнопку, платим сколько угодно, через минуту получаем мощности”, то у вас нет этой проблемы.
Если ваше масштабирование устроено иначе, то запас какой-то иметь придётся, хотя бы на выживание во время масштабирования.
Что включить в расчеты:
– Неожиданный пользовательский трафик, который вы хотите выдерживать. Сюда же входят маркетинговые кампании.
– Выход из строя части инфраструктуры. У любого поставщика услуг есть какие-то гарантии, ознакомьтесь с ними.
– Сломанная часть продакшена в результате неудачного релиза. Здесь всё зависит от вашей процедуры релиза.
– Ещё какие-то особые локальные сценарии.
То есть, нужно понимать, как обслуживать высокий уровень трафика при частично потерянной инфраструктуре из-за провайдера и во время релиза. Вы можете сказать: “Если у нас не будет работать часть инфраструктуры или будет высокий трафик, мы не будем катить релиз”. Обязательно произойдет ситуация, когда это будет необходимо.
Нужно ли запасать мощности на случай DDoS? Я считаю, что в этом нет смысла – всё равно не хватит.
Деньги: любой запас стоит денег. Всю схему запаса нужно посчитать и согласовать с бизнесом: какой трафик в каком случае вы должны обслуживать, а какой не должны. Дальше выстраивать схему резервирования с учётом этой информации.
30. Считайте запас критического пути
Снова про запасы.
Обработка запроса пользователя состоит из трёх основных стадий:
– получение запроса по сети
– обработка бэкендом
– выдача ответа по сети
В стадии "обработка бэкендом" может скрываться бездна этапов: походы в базы данных, сотню других микро- и немикро- сервисов, кэши и тп. Возможно, вы уже молодец и сделали бенчмарк, где измеряете производительность компонентов в синтетической среде. Воспроизвести эквивалент продакшн-среды для бенчмарков это дорогостоящая и трудоёмкая задача – этим очень мало кто занимается.
Если вы делаете бенчмарки в синтетической среде с помощью заглушек, то вы ничего не знаете о производительности системы в реальности. Самым медленным или ограниченным звеном во всей цепи может быть что-то, чему вы вообще не придаёте значения.
Опишите свою схему обработки запроса, проанализируйте пропускную способность каждого компонента и стыки между ними, опишите критический путь выполнения запроса и оцените узкие места.
31. Заведите запасной мониторинг
Этот пункт немного параноидальный, но тоже взялся не просто так, а из очередного увлекательного опыта.
Мониторинг – это система наблюдения за жизненно важными показателям вашей системы. Вообще предполагается, что надежность системы мониторинга должна быть выше,
