Миф: облако масштабируется мгновенно и бесконечно

MAATRIX

«Облако само добавит мощности, как только вырастет нагрузка» — фраза, которая звучит на каждой презентации про эластичность и почти никогда не проверяется на практике до момента, когда нагрузка действительно вырастает. Автомасштабирование в облаке реально работает, но не мгновенно и не бесконечно: у него есть задержка запуска, есть жёсткие квоты по регионам и типам ресурсов, и оно бессильно, если само приложение не умеет работать в нескольких экземплярах одновременно. Разберём, где заканчивается маркетинг и начинается инженерная реальность.

Откуда берётся миф о мгновенной и безлимитной эластичности

Формулировки вроде «масштабируется по требованию» и «practically unlimited scale» в описаниях облачных платформ технически не врут — они просто не уточняют временные рамки и условия. «По требованию» может означать и секунды, и минуты, в зависимости от типа ресурса. «Практически неограниченно» означает «в пределах квот, которые вам согласовал провайдер», а не «без пределов вообще».

Миф закрепляется по трём причинам одновременно: демо на конференциях показывают идеальный сценарий (прогретые образы, знакомый провайдеру тип нагрузки, регион с запасом мощностей); маркетинговые тексты пишут для тех, кто ещё не настраивал автоскейлинг сам, а точные цифры задержки и лимитов живут в документации на два уровня глубже лендинга; и, наконец, при плавном росте нагрузки автомасштабирование действительно успевает среагировать незаметно — проблема проявляется только на резком скачке, когда решение «просто переехать в облако и не думать про capacity planning» уже встроено в архитектуру и в голову команды.

Результат — команда узнаёт о реальном поведении автоскейлинга не на тесте, а во время всплеска трафика, когда цена ошибки максимальна.

Задержка автомасштабирования: почему «мгновенно» занимает минуты

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

1. Метрика должна пересечь порог и это должно быть зафиксировано — системы мониторинга агрегируют метрики с окном в десятки секунд и требуют, чтобы порог держался несколько периодов подряд, а не одну случайную точку. Это защита от ложных срабатываний и одновременно минимальная задержка реакции.
2. Планировщик находит доступную мощность — облаку нужно подобрать физический хост с нужным типом ресурса в нужной зоне доступности. Если мощности не хватает, планировщик пробует соседние зоны — это тоже время.
3. Инстанс проходит цикл загрузки — диск, сеть, загрузка образа ОС или контейнера, запуск сервисов.
4. Приложение внутри должно фактически подняться — часто это дольше, чем всё облачное провижининг вместе взятое: прогрев JIT, подключение к базе и пулам соединений, прогрев локальных кэшей, миграции при старте.
5. Инстанс проходит health check и попадает в балансировщик — до этого момента он не принимает трафик, даже если формально уже «запущен».

Отдельная и особенно чувствительная проблема — холодный старт (cold start) в serverless- и контейнерных платформах, где инстансы между всплесками нагрузки вообще не существуют и создаются с нуля по первому запросу. Для лёгких функций это доли секунды, для тяжёлых образов с большим рантаймом (Java, .NET, крупные ML-модели) — заметно дольше. Точные цифры сильно зависят от платформы, размера образа и региона — ориентируйтесь не на усреднённые бенчмарки из интернета, а на замер именно вашего образа на реальной инфраструктуре.

Практический вывод: между «нагрузка выросла» и «новый инстанс реально принимает трафик» лежит интервал, который нужно пережить существующими мощностями. Если запас прочности заложен впритык к текущей нагрузке, именно эти минуты и становятся временем деградации или падения сервиса — автоскейлер отработает штатно, но недостаточно быстро, чтобы это почувствовал только инженер, а не пользователь.

Квоты и лимиты: где кончается «бесконечность»

У любого облачного провайдера де-факто есть верхние пределы на аккаунт, подписку или проект — по умолчанию они консервативны, потому что провайдеру нужно защитить себя от случайного или злонамеренного взрывного потребления ресурсов одним клиентом. Это касается практически всех типов ресурсов:

• Количество инстансов определённого типа в регионе — у нового или небольшого аккаунта лимит на число одновременных виртуальных машин конкретной линейки в конкретном регионе может быть намного меньше, чем кажется достаточным «на всякий случай».
• Специализированные и дефицитные ресурсы — жёстче всего. GPU-инстансы, узлы с большим объёмом оперативной памяти, выделенные bare-metal — физически ограниченный, дорогой ресурс даже для самого провайдера. Квота на такие типы часто выдаётся по отдельному запросу и не растёт автоматически вместе со счётом.
• Сетевые лимиты — число публичных IP-адресов, пропускная способность интерфейса, число соединений через один NAT-шлюз или балансировщик.
• API rate limit самой платформы — если автоскейлер шлёт много запросов на создание ресурсов за короткое время, можно упереться в лимит API управления, а не в лимит вычислительных ресурсов.
• Лимиты смежных сервисов — подключения к managed-базе, пропускная способность объектного хранилища, квота очереди сообщений. Даже если инстансы масштабируются без проблем, узким местом становится сервис, к которому они все обращаются.

Увеличение квоты почти всегда — это отдельный процесс: заявка в поддержку, объяснение сценария использования, ожидание рассмотрения от нескольких часов до нескольких дней. В критический момент реального всплеска трафика на это время уже не рассчитывайте — квоты нужно поднимать заранее, до пиковой нагрузки, а не во время неё. Разбор похожей ловушки, когда счёт за облако растёт, а видимой нагрузки для этого как будто нет, — в статье «Счёт за облако вырос вдвое без роста нагрузки»: там же видно, как непрозрачно устроена связь между потреблением ресурсов и тем, что реально попадает в счёт.

Приложение должно быть спроектировано для горизонтального масштабирования

Самое дорогое заблуждение в этом мифе — не про скорость и не про квоты, а про то, что облако якобы масштабирует *приложение*. На самом деле облако масштабирует только количество запущенных копий процесса. Готово ли приложение к тому, чтобы работать в нескольких копиях одновременно, — целиком зона ответственности того, кто его писал.

Ключевое условие горизонтального масштабирования — статeless-архитектура (stateless): каждый инстанс приложения не хранит у себя ничего, без чего он не сможет ответить на следующий запрос. Практически это означает:

• Сессии пользователей — не в памяти процесса. Если сессия живёт в локальной переменной или файле конкретного инстанса, второй и третий инстанс о ней ничего не знают — пользователя будет «раскидывать» между серверами. Решение — вынести сессии во внешнее общее хранилище (Redis, Memcached, БД).
• Файлы, загруженные пользователями, — не на локальном диске инстанса. Загрузка на один инстанс и запрос к другому — классическая причина «файл только что был, а теперь 404». Нужно объектное хранилище (S3-совместимое) или общая сетевая ФС.
• Локальный кэш в памяти процесса — ускорение, а не источник истины. Если инстансы кэшируют по-разному, а логика опирается на актуальность кэша, при масштабировании начнутся рассинхронизации. Для общего кэша нужен вынесенный слой (Redis и подобные).
• Фоновые задачи и очереди — не «одна на сервер». Если крон-задача или воркер завязаны на единственность процесса, при запуске нескольких копий задача либо выполнится параллельно несколько раз (дублирование заказов, писем, начислений), либо начнёт конфликтовать за ресурсы. Нужна распределённая блокировка или очередь с гарантией однократной обработки.
• Конфигурация и секреты — идентичны на всех инстансах. Ручная правка конфига «чтобы прямо сейчас починить» на одном сервере — источник поведения, которое воспроизводится только на части инстансов.

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

Вертикальное и горизонтальное масштабирование — не взаимозаменяемы

Часть путаницы в этом мифе — от смешения двух разных механизмов масштабирования, у которых разная скорость и разные ограничения:

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

Как тестировать реальное поведение автоскейлинга заранее

Единственный способ узнать, как ваша система масштабируется на самом деле, — прогнать её через управляемую нагрузку до того, как это сделает реальный трафик. Маркетинговое «бесконечно» не заменяет этот тест ни при каких обстоятельствах.

Практический план проверки:

1. Замерьте время от срабатывания метрики до готовности инстанса принимать трафик. Создайте контролируемую нагрузку, которая пересекает порог автоскейлера, и зафиксируйте по логам весь путь: момент триггера → запуск инстанса → health check → появление в балансировщике. Это и есть ваша настоящая задержка, а не число из документации провайдера.
2. Проверьте поведение на резком скачке, а не только на плавном росте. Плавающая нагрузка и мгновенный всплеск («молния» после публикации в популярном канале, распродажа) — разные сценарии: настройки по умолчанию обычно рассчитаны на плавный рост и намеренно консервативны, чтобы не плодить инстансы от случайного пика.
3. Убедитесь, что запас мощности переживает интервал задержки. Если минимальное число всегда запущенных инстансов рассчитано впритык под среднюю нагрузку, любой скачок будет упираться в те самые минуты ожидания новых копий.
4. Проверьте квоты заранее, а не постфактум. Запросите у провайдера лимиты по нужным типам ресурсов в нужном регионе и сверьте их с худшим правдоподобным пиковым сценарием, а не со средней нагрузкой.
5. Гоняйте тест из окружения, приближенного к продакшену, а не с ноутбука разработчика — иначе результаты будут врать в обе стороны из-за сети и ресурсов клиента. Этот антипаттерн разобран в статье «Антипаттерн: нагрузочное тестирование на ноутбуке разработчика».
6. Найдите порог отказа заранее, а не в проде. Постепенно наращивайте нагрузку (step load) и следите не только за RPS, а за латентностью и error rate — момент, где они резко растут, и есть реальная граница вашей текущей конфигурации. Методика — в материале «Порог отказа под нагрузкой: как найти его тестом и не положить продакшен».

Инструменты для такого теста (k6, Locust, wrk, Apache Bench и подобные) дают управляемую, воспроизводимую нагрузку — в отличие от реального трафика, который придёт один раз и не даст второй попытки разобраться в причинах сбоя.

Практические выводы для планирования инфраструктуры

Из разбора мифа следует не «облако не масштабируется» — а «облако масштабируется на условиях, которые нужно знать заранее и проверить самому»:

• Закладывайте буфер мощности, который переживает задержку автоскейлера, а не рассчитывайте только на его срабатывание.
• Заранее запрашивайте увеличение квот под реалистичный пиковый сценарий, особенно для GPU и других специализированных ресурсов — по факту всплеска поднять лимит быстро не получится.
• Проектируйте приложение как stateless с самого начала: вынесенные сессии, файлы, кэш, идемпотентные фоновые задачи. Без этого автоскейлинг создаёт копии процесса, а не масштабирует систему.
• Не путайте вертикальное и горизонтальное масштабирование — у них разная скорость, потолок и требования к приложению.
• Проверяйте поведение автоскейлинга нагрузочным тестом на окружении, приближенном к продакшену, а не полагайтесь на цифры из маркетинга.

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

Частые вопросы