🚀 Стратегии деплоя приложения в прод

Сегодня поговорим про стратегии деплоя приложений, работающих распределено на множестве машин. На картинке выше стратегии приведены для Kubernetes, но они также применимы и к любым другим приложениям работающим вне кубера.


1️⃣ Recreate
Метод recreate или пересоздание. Он заключается в том, что сначала полностью выключается старая версия сервиса, потом поднимается новая на тех же машинах.

Это самый простой метод деплоя. Но есть проблема, downtime что какое то время сервис будет остановлен и недоступен. Это может быть критично, если ваш сервис должен работать 24/7



2️⃣ Rolling Update
Rolling update или постепенное обновление. Заключается в том, что мы постепенно заменяем старую версию на новую на одной машине за другой. В итоге новая версия выкатывается, постепенно наращивая трафик.

Минус здесь в том, что это долгий процесс. В рекламе размеры сервиса могут доходить до 200 машин на один регион. Также, нужно сложно настраивать, как направлять трафик от машин со старыми версиями сервиса на новые.



3️⃣ 🦜 Canary (Канареечный или Smoke деплой)
Исторически название взято у шахтеров. Уходя на работу в шахту, они брали с собой клетку с канарейками, и пока те пели, можно было спокойно работать. Но если канарейки замолкали и умирали, горняки знали, что произошла утечка газа и быстро эвакуировались.

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

У такого способа тоже есть недостатки. Нужно уметь управлять трафиком и в нужный момент перенаправлять его с канарейки на рабочие машины



4️⃣ 🟦🟩 Blue-Green
Суть заключается в том, что мы рядом со старой версией (синей) поднимаем рабочие машины с новой версией (зеленой). А потом просто переключаем трафик с одной среды на другую

Из плюсов это то, что переключение между версиями происходит мгновенно. И в случае проблем всегда может переключится обратно на старую версию

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



5️⃣ 🅰️🅱️ A/B Testing
Из моего опыта, я бы рассматривал A/B тестирование не как способ деплоя, а скорее как этап, который следует за ним. В рекламе, как правило, каждую новую фичу или модель требуется A/B тестировать на половине продового трафика. В результате чего мы измеряем

- Бизнес метрики: выручку, прибыль, долю просмотров креатива, click-through rate, расходы на оплату издателям
- Технические метрики: network cost, расходы на работу удаленных машин, latency
- ML метрики: AUC, Precision@K

и далее принимаем решение об окончательной выкатке обновлений на весь трафик.

#devops