Стратегии деплоя и IaC: zero downtime, serverless, Terraform

Третий урок раздела. Выкатить новую версию так, чтобы пользователь ничего не заметил, это отдельное ремесло. Наивный деплой “погасил старое, поднял новое” даёт минуту простоя и теряет запросы. Здесь стратегии выката без простоя, serverless как крайний случай и описание инфраструктуры кодом, чтобы её можно было воспроизвести, а не собирать кликами в консоли.

Идея: всегда есть кто-то здоровый, кто принимает трафик

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

Предусловие для всех них: stateless-приложение. Если инстанс не хранит состояние локально, его можно безопасно убить и поднять. Со stateful-частями (база) так нельзя, поэтому их обновляют отдельно и аккуратно, через миграции.

Стратегии выката

• Rolling: обновляем инстансы по одному. Балансировщик через health-проверку шлёт трафик только на готовые. Простой вариант по умолчанию, минус в том, что какое-то время в проде сосуществуют две версии.
• Blue/Green: поднимаем полную вторую среду с новой версией, прогреваем, потом мгновенно переключаем на неё трафик. Откат это переключение обратно, он мгновенный. Минус в удвоении ресурсов на время выката.
• Canary: направляем на новую версию сначала малую долю трафика, следим за метриками и ошибками, и только потом поднимаем долю. Самый безопасный, но требует хорошей наблюдаемости, чтобы вовремя заметить деградацию.

Миграции без простоя

Главная ловушка zero-downtime это база. Пока сосуществуют две версии приложения, схема должна подходить обеим. Поэтому ломающие изменения делают в несколько шагов (expand and contract): сначала добавляют новое, не ломая старое, потом переключают код, и лишь потом, когда старая версия выведена, удаляют лишнее. Переименовать колонку одним шагом во время rolling-деплоя означает уронить ту версию, которая ещё ждёт старого имени.

Serverless: когда серверов как будто нет

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

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