Стратегии деплоя: rolling, blue-green, канарейка

Постепенная замена и почему её мало

Постепенная замена (rolling) означает: гасим один экземпляр, поднимаем новый, ждём, переходим к следующему. Мой замер показал, что дьявол в слове «ждём», и я намерил три разных исхода на одном стенде.

Разом: 79% запросов с ошибкой. По одному, дожидаясь, пока новый экземпляр начнёт отвечать, но подряд, без пауз: 49% ошибок - неожиданно много. Причина оказалась не в приложении: балансировщик помнит, кто из экземпляров недавно не ответил, и какое-то время его не трогает. При быстрой замене живых кандидатов в его картине мира просто не остаётся. Проверил гипотезу: тот же выкат с паузой дольше этого окна памяти дал 914 запросов и НОЛЬ ошибок. Столько же дал вариант, где после каждого шага балансировщику велели перечитать конфигурацию.

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

постепенная замена

менять экземпляры по одному, а не все разом

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

сигнал «этот экземпляр можно нагружать»

окно памяти о неудаче

время, в течение которого балансировщик не трогает сбоивший экземпляр

Две площадки и канарейка

Схема с двумя площадками (blue-green) устроена иначе: рядом с работающей версией поднимают полную копию новой, прогревают её, проверяют, а потом одним движением переводят трафик. Плюс - откат тоже одним движением и почти мгновенный. Минус - на время выката нужен двойной запас железа, и общая база данных всё равно одна на обе площадки.

Канарейка - это когда новую версию сначала показывают маленькой доле пользователей. Настроил веса 9 к 1 и отправил 200 запросов: 180 ушли на старую версию, 20 на новую, ровно 10%. Дальше долю поднимают, если метрики не испортились.

// Полезная арифметика, которую редко проговаривают. Если новая версия ломается на каждом запросе, а трафика на неё 10%, то вероятность заметить это после 5 запросов - 41%, после 10 - 65%, после 20 - 88%, после 50 - 99%. Считается как единица минус 0,9 в степени числа запросов. Отсюда прямой вывод: канарейку держат не «пять минут для галочки», а до того числа запросов, при котором поломку видно почти наверняка. И смотрят при этом на метрики ошибок и задержек по каждой версии отдельно, иначе 10% плохих ответов утонут в общем графике.

две площадки

полная копия рядом и переключение трафика одним движением

канарейка

маленькая доля трафика на новую версию, чтобы поймать поломку рано

Откат: почему он не всегда возможен

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

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

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

совместимое изменение схемы

такое, при котором и старый, и новый код работают

точка невозврата

шаг, после которого откат кода уже не вернёт работоспособность

Как отвечать: «Как выкатить новую версию без простоя?»

Смотрю на две вещи: сколько запросов пострадает и как быстро я смогу вернуться. Постепенная замена по одному экземпляру - база, но её мало: я мерил на стенде, замена разом дала 79% ошибок, а замена по одному подряд, без пауз, всё равно 49%, потому что балансировщик какое-то время не трогает экземпляр, который только что не отвечал. Ноль ошибок получился, когда после каждого шага балансировщик узнавал о новом экземпляре. Поэтому мне нужны проверка готовности, запрет гасить следующий до подтверждения предыдущего и корректное завершение старого процесса. Если версия рискованная, добавляю канарейку: держу её не по часам, а до числа запросов, при котором поломку видно почти наверняка - при 10% трафика это порядка полусотни запросов. И отдельно проверяю, что откат возможен: изменения схемы делаю совместимыми в обе стороны, иначе откатывать будет некуда.

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

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

• −Гасят все экземпляры разом и называют это выкатом без простоя.
• −Считают, что достаточно поднять новый экземпляр: балансировщик узнаёт об этом не сразу.
• −Держат канарейку по часам, а не по числу запросов, и выпускают поломку в прод.
• −Смотрят общие метрики вместо разбивки по версиям и не видят 10% плохих ответов.
• −Делают несовместимое изменение схемы и обнаруживают, что откат кода уже ничего не чинит.