что такое канареечный релиз
Стратегии деплоя в Kubernetes: rolling, recreate, blue/green, canary, dark (A/B-тестирование)
Прим. перев.: Этот обзорный материал от Weaveworks знакомит с наиболее популярными стратегиями выката приложений и рассказывает о возможности реализации наиболее продвинутых из них с помощью Kubernetes-оператора Flagger. Он написан простым языком и содержит наглядные схемы, позволяющие разобраться в вопросе даже начинающим инженерам.
Схема взята из другого обзора стратегий выката, сделанного в Container Solutions
Одной из самых больших проблем при разработке cloud native-приложений сегодня является ускорение деплоя. При микросервисном подходе разработчики уже работают с полностью модульными приложениями и проектируют их, позволяя различным командам одновременно писать код и вносить изменения в приложение.
Более короткие и частые развертывания имеют следующие преимущества:
В этой публикации мы обсудим различные стратегии деплоя в Kubernetes, в том числе rolling-развертывания и более продвинутые методы, такие как канареечные (canary) выкаты и их разновидности.
Стратегии деплоя
Существует несколько различных типов стратегий развертывания, коими можно воспользоваться в зависимости от цели. Например, вам может потребоваться внести изменения в некое окружение для дальнейшего тестирования, или в подмножество пользователей/клиентов, или возникнет необходимость провести ограниченное тестирование на пользователях, прежде чем сделать некую функцию общедоступной.
Rolling (постепенный, «накатываемый» деплой)
Это стандартная стратегия развертывания в Kubernetes. Она постепенно, один за другим, заменяет pod’ы со старой версией приложения на pod’ы с новой версией — без простоя кластера.
Kubernetes дожидается готовности новых pod’ов к работе (проверяя их с помощью readiness-тестов), прежде чем приступить к сворачиванию старых. Если возникает проблема, подобное накатываемое обновление можно прервать, не останавливая всего кластера. В YAML-файле с описанием типа deployment’а новый образ заменяет собой старый образ:
Параметры накатываемого обновления можно уточнить в файле манифеста:
Recreate (повторное создание)
В этом простейшем типе развертывания старые pod’ы убиваются все разом и заменяются новыми:
Соответствующий манифест выглядит примерно так:
Blue/Green (сине-зеленые развертывания)
Стратегия сине-зеленого развертывания (иногда ее ещё называют red/black, т.е. красно-чёрной) предусматривает одновременное развертывание старой (зеленой) и новой (синей) версий приложения. После размещения обеих версий обычные пользователи получают доступ к зеленой, в то время как синяя доступна для QA-команды для автоматизации тестов через отдельный сервис или прямой проброс портов:
После того, как синяя (новая) версия была протестирована и был одобрен ее релиз, сервис переключается на неё, а зеленая (старая) сворачивается:
Canary (канареечные развертывания)
Канареечные выкаты похожи на сине-зеленые, но лучше управляются и используют прогрессивный поэтапный подход. К этому типу относятся несколько различных стратегий, включая «скрытые» запуски и А/В-тестирование.
Эта стратегия применяется, когда необходимо испытать некую новую функциональность, как правило, в бэкенде приложения. Суть подхода в том, чтобы создать два практически одинаковых сервера: один обслуживает почти всех пользователей, а другой, с новыми функциями, обслуживает лишь небольшую подгруппу пользователей, после чего результаты их работы сравниваются. Если все проходит без ошибок, новая версия постепенно выкатывается на всю инфраструктуру.
Хотя данную стратегию можно реализовать исключительно средствами Kubernetes, заменяя старые pod’ы на новые, гораздо удобнее и проще использовать service mesh вроде Istio.
Например, у вас может быть два различных манифеста в Git: обычный с тегом 0.1.0 и «канареечный» с тегом 0.2.0. Изменяя веса в манифесте виртуального шлюза Istio, можно управлять распределением трафика между этими двумя deployment’ами:
Пошаговое руководство по реализации канареечных развертываний с помощью Istio можно найти в материале GitOps Workflows with Istio. (Прим. перев.: Мы также переводили материал про канареечные выкаты в Istio здесь.)
Канареечные развертывания с Weaveworks Flagger
Weaveworks Flagger позволяет легко и эффективно управлять канареечными выкатами.
Flagger автоматизирует работу с ними. Он использует Istio или AWS App Mesh для маршрутизации и переключения трафика, а также метрики Prometheus для анализа результатов. Кроме того, анализ канареечных развертываний можно дополнить вебхуками для проведения приемочных (acceptance) тестов, нагрузочных и любых других типов проверок.
На основе deployment’а Kubernetes и, при необходимости, горизонтального масштабирования pod’ов (HPA), Flagger создает наборы из объектов (deployment’ы Kubernetes, сервисы ClusterIP и виртуальные сервисы Istio или App Mesh) для проведения анализа и реализации канареечных развертываний:
Реализуя контур управления (control loop), Flagger постепенно переключает трафик на канареечный сервер, параллельно измеряя ключевые показатели производительности, такие как доля успешных HTTP-запросов, средняя продолжительность запроса и здоровье pod’ов. Основываясь на анализе KPI (ключевых показателей эффективности), канареечная часть либо растет, либо сворачивается, и результаты анализа публикуются в Slack. Описание и демонстрацию этого процесса можно найти в материале Progressive Delivery for App Mesh.
Dark (скрытые) или А/В-развертывания
Скрытое развертывание — еще одна вариация канареечной стратегии (с ней, кстати, Flagger тоже может работать). Разница между скрытым и канареечным развертыванием состоит в том, что скрытые развертывания имеют дело с фронтендом, а не с бэкендом, как канареечные.
Другое название этих развертываний — А/В-тестирование. Вместо того, чтобы открыть доступ к новой функции всем пользователям, ее предлагают лишь ограниченной их части. Обычно эти пользователи не знают, что выступают тестерами-первопроходцами (отсюда и термин «скрытое развертывание»).
С помощью переключателей функциональности (feature toggles) и других инструментов можно следить за тем, как пользователи взаимодействуют с новой функцией, увлекает ли она их или они считают новый пользовательский интерфейс запутанным, и другими типами метрик.
Flagger и A/B-развертывания
Помимо маршрутизации с учётом весов, Flagger также может направлять на канареечный сервер трафик в зависимости от параметров HTTP. При А/В-тестировании можно использовать заголовки HTTP или файлы cookie для перенаправления определенного сегмента пользователей. Это особенно эффективно в случае frontend-приложений, требующих привязки сессии к серверу (session affinity). Дополнительную информацию можно найти в документации Flagger.
Автор выражает благодарность Stefan Prodan, инженеру Weaveworks (и создателю Flagger), за все эти потрясающие схемы деплоя.
Простой и безопасный способ автоматизации канареечных деплоев с помощью Helm
Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.
Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:
Еще проще представить такой вариант можно на kubectl, а в документации по Kubernetes даже есть полноценный туториал по этому сценарий. Но главный вопрос этого поста заключается в том, как мы собираемся автоматизировать этот процесс, используя Helm.
Автоматизация канареечного деплоя
Прежде всего нам понадобится карта чартов Helm, в которую уже внесены обсуждаемые нами выше ресурсы. Выглядеть она должна быть примерно так:
Основа концепции Helm — управление мультиверсиями релизов. Stable-версия — это наша основная стабильная ветка кода проекта. Но с помощью Helm мы можем развернуть канареечный релиз с нашим экспериментальным кодом. Главное — сохранить обмен трафиком между стабильной версией и канареечным релизом. Управлять всем этим мы будем с помощью специального селектора:
Наши как «канареечные», так и stable-ресурсы деплоя будут указывать эту метку на модулях. Если все настроить правильно, то во время деплоя канареечной версии нашей карты чартов Helm мы увидим, что трафик будет направляться на свежеразвернутые модули. Стабильная версия этой команды будет выглядеть так:
Теперь давайте проверим наш канареечный релиз. Чтобы задеплоить канареечную версию, нам надо помнить о двух вещах. Название релиза должно отличаться, чтобы мы не накатили апдейт на текущую stable-версию. Версия и тег также должны отличаться, чтобы мы могли развернуть другой код и определить различия по меткам ресурсов.
Вот, собственно, и все! Если пингануть службу, то можно увидеть, что канареечное обновление маршрутизирует трафик только часть времени.
Если вы ищите инструменты автоматизации деплоя, которые включают в себя описанную логику, то обратите внимание на Deliverybot и на инструменты автоматизации Helm на GitHub. Чарты Helm, используемые для реализации описанного выше способа лежат на Github, вот тут. Вообще, это был теоретический обзор того, как реализовать автоматизацию деплоя канареечных версий на практике, с конкретными концепциями и примерами.
Canary Releases
Что такое канареечный релиз?
Метод снижения риска внедрения новой версии программного обеспечения в “производственную среду”. Происходит путем плавного развертывания изменений для небольшой группы пользователей.
Термин «канареечный релиз» придуман по аналогии с тем, как шахтеры в угольных шахтах брали с собой канареек в клетках, чтобы обнаруживать опасный уровень угарного газа. Если в шахте скапливалось много угарного газа, то он убивал канарейку до того, как становился опасным для шахтеров, и они успевали спастись.
В чем основная суть метода?
Новый функционал или его обновлённая часть публикуется для ограниченной аудитории по мере готовности на продакшен окружение. Перед деплоем достаточно убедиться, что код не содержит синтаксических ошибок. Этот шаг может быть частью ci пайплаина. Первые пользователи, которые увидят изменения, могут быть разработчиками или тестировщиками. После проверки функционала, который уже находится в той среде, где с ним начнут взаимодействовать реальные пользователи, можно открыть доступ настоящим пользователям частично или полностью. В случае нахождения ошибок фичу можно моментально закрыть от пользователей и минимизировать потери (репутационные, финансовые).
Использовать предпродакшен среду, на которую сначала публикуются изменения, после этапа проверки и тестирования. Изменения попадают в продакшен среду, где еще раз проверяются на ошибки связанные с интеграцией, которые могли возникнуть из за неточности двух окружений.
Какие плюсы у канареечного релиза?
Какие накладные расходы для использования канареечных релизов?
Почему стоит использовать канареечные релизы?
Масштабирование, снижение количества ошибок, автоматизация ручной работы. При ускорении time to market и увеличении количества релизов ограничением становятся тестовые окружения, где в один момент времени может быть только одно изменение в тесте.
Фундаментальные проблемы нескольких предпродакшен окружений: при росте инфраструктуры и сложности приложения сложность поддержки тестовых окружений будет расти, увеличивая стоимость поддержки окружения и снижая частоту релизов. Тестовое окружение не может быть идентичным продакшен, а пользовательский трафик не может быть сопоставим.
Как эффективно релизить монолит, в который коммитят 150+ разработчиков из разных офисов
Я работаю инженером в Miro в команде, отвечающей за улучшение процесса релизов.
За последний год у нас появился зарубежный офис разработки, инженерная команда выросла вдвое, а полгода назад компания временно перешла на удалёнку. Параллельно с этим происходил постоянный кратный рост количества пользователей нашего продукта.
На фоне этих изменений нам важно было не терять в качестве и скорости, поэтому мы серьёзно обновили процесс серверных релизов. Расскажу про изменения, которые в итоге повысили долю успешных релизов.
Серверные релизы
Наш backend — это монолитное Java-приложение, которое может быть запущено с разными ролями для выполнения разных задач. Для работы backend мы используем AWS инстансы (CPU 4 ядра, RAM 16 ГБ). Большая часть backend-серверов – приложение, которое держит постоянное веб-сокетное подключение с клиентом, чтобы пользователи всегда видели реальное состояние досок в Miro. Для этих серверов мы используем роль Board-сервер (пользователи попадают на них при работе на досках). Для работы с бизнес-логикой и API-запросами используем роль API-сервер.
Релизы мы делаем бесшовными (graceful deploy) и стараемся проводить их во время наименьшей нагрузки на сервис. Во время планового релиза у нас в среднем 60.000 онлайн-пользователей и 50 работающих board-серверов.
Мы считаем релиз успешным, если он вышел в срок и в него попали все задачи, которые были готовы к релизу на момент его запуска. Соответственно, релиз считается неуспешным, если что-то пошло не так, потому что ошибки, которые потребовали остановки или отката релиза, увеличивают время доставки (time to market).
Любые изменения в процессе проведения релизов мы оцениваем исходя из того, насколько они приближают нас к успешному релизу.
Успешный релиз — это релиз, который вышел в срок и в который попали все задачи, готовые к релизу на момент его запуска.
Процесс подготовки релиза:
На каждый пулл-реквест прогоняется релевантный набор e2e тестов. Добавить изменения в мастер можно только при успешном прохождении всех тестов. Внутри автотестов есть маппинг соответствия тестов и кода продукта. Набор e2e-тестов для пулл-реквеста определяется нашим инструментом, который выбирает тесты, основываясь на этом маппинге и анализируя изменённые файлы в пулл-реквесте.
Каждый собранный мастер проходит полную регрессионную проверку. Релиз возможен, если все тесты прошли успешно. Упавшие тесты правят команды, ответственные за функциональность.
Для того чтобы релиз вышел автоматически, мы используем Allure Enterprise Edition, в котором отмечаем false-positive тесты как Resolved.
Процесс релиза:
Ищем сборку со 100% успешных тестов и версией, которая больше текущей версии на продакшене.
Запускаем канареечный релиз.
Мониторим метрики релиза в течение 4х часов.
Ставим статус Approved или Broken по завершении канареечного релиза. При статусе Approve основной релиз автоматически запускается следующим утром, при Broken запуска не произойдет.
Для релиза на API- и board-серверах создаём инстансы с новой версией. Количество инстансов рассчитываем, исходя из текущей нагрузки и добавляем 20%, чтобы не допустить высокой нагрузки во время или сразу после релиза.
Пользователи постепенно переходят на новые сервера, старые сервера мы выключаем и удаляем.
Релиз от создания инстансов до полного перехода на новую версию занимает полтора часа.
Канареечный релиз
Канареечный релиз нужен для того, чтобы валидировать изменения на небольшой случайной выборке пользователей. В ходе него мы поднимаем несколько серверов с новой версией и наблюдаем за ситуацией. Если на канареечном релизе всё идёт хорошо — релизимся на все сервера.
Процесс канареечного релиза
Канареечный релиз не способ тестирования на проде, а дополнительный эшелон защиты. Он позволяет уменьшить количество пользователей, которые столкнулись с ошибкой, если кейс сложный или если он повторяется только на инфраструктуре продакшена.
Для быстрой реакции на ошибки в канареечном релизе мы ввели роль дежурного серверного разработчика, которую выполняет каждый разработчик по очереди. Дежурный разработчик в течение четырех часов работы канареечного релиза реагирует на новые ошибки в Sentry и на общие предупреждения из Grafana, может остановить релиз самостоятельно при необходимости. После завершения канареечного релиза он обновляет статус релизной сущности в Bamboo: Approved или Broken.
В случае срочных релизов вне расписания команды могут запустить релиз через деплой в Bamboo самостоятельно, для этого в каждой команде есть инженеры с необходимыми правами.
Пользователи попадают на канареечный релиз случайным образом, с помощью балансировщика. Случайная выборка позволяет валидировать релизы на разных пользователях, но имеет и недостатки: без изменения в коде не позволяет балансировать типами пользователей и аккаунтами, не даёт проверять функциональность на конкретных аккаунтах или досках.
Выкатить канареечный релиз на определённую выборку пользователей мы можем, только если функционал был написан с Feature Toggle, а это уже реализация через код, а не через релизы.
Hot Fix в канареечном релизе
Раньше, находя ошибку в канареечном релизе, мы блокировали мердж в мастер и весь релиз. Это было неудобно, так как блокировало работу других команд и задерживало время выхода релиза.
Нам хотелось найти подход, при котором мы могли задерживать выход релиза минимально. Мы изучили существующие подходы (Trunk-Based Development, GitFlow и т.д.) и остановились на GitLab Flow.
Как мы работаем с Hot Fix по GitLab Flow:
Отводим релизные ветки от версии из канареечного релиза.
Мерджим фикс в мастер.
Выполняем git cherry-pick в релизной ветке.
Запускаем канареечный релиз на релизной ветке.
Запускаем следующий плановый канареечный релиз на версии мастера с фиксом или выше.
Подход помог нам вдвое снизить максимальное количество дней без релиза и количество перезапусков канареечных релизов, с четырёх до двух.
Предсказуемость и прозрачность процесса релиза
Для повышения качества релиза мы поддерживаем его прозрачность и предсказуемость. Используем для этого автоматические уведомления и дашборды с ключевыми метриками.
Раньше мы публиковали большой changelog один на все команды: в общем канале со всеми изменениями в релизе. Командам было трудно и больно ориентироваться в нём. Поэтому к общему changelog мы добавили командные changelog, в котором каждая команда видит статусы только по своим задачам и версию релиза, в которой они реализованы.
Дашбордами в Grafana мы пользуемся при работе с внеплановым релизами, чтобы быстрее их завалидировать. Во время плановых релизов нам хватает алертов из Grafana на основе метрик из Prometheus.
Всю статистику по релизам из Jira и Bamboo мы собираем и визуализируем в Looker, чтобы на основе исторических данных принимать решения о качестве процессов и улучшать их.
Данные по ошибкам, количество созданных и закрытых задач.
Сейчас мы внедряем фичу, которая позволяет командам блокировать ручные и автоматические релизы, если в мастере есть ошибка. Благодаря ей мы сможем автоматически собирать статистику количества сломанных мастеров, времени фикса и понимать, какие ошибки заблокировали выход релиза.
Изменения, которые увеличили долю успешных релизов
Канареечные релизы помогли сократить количество откатов релизов на 95%.
Отдельные changelog для каждой команды повысили общую прозрачность процесса. Теперь каждая команда вовремя и удобным способом получает уведомления о том, когда выходит их функциональность.
Мониторинг канареечного релиза дежурным серверным разработчиком уменьшил время реакции команды на найденный ошибки.
Подход GitLab Flow для hotfix позволил задерживать выход релиза минимально и исправлять ошибку, не блокируя работу других команд. Автоматические релизы стимулируют команды держать мастер всегда готовым к релизу.
Сбор и анализ всей истории релизов в Looker помогает проверять гипотезы и постоянно улучшать процесс.
Ближайшие планы
Конечная наша цель — выстроить процесс так, чтобы все релизы были успешными и пользователи никогда не сталкивались с ошибками. Для этого мы планируем следующие изменения:
Разбить монолит на микросервисы. Мы начинаем двигаться в эту сторону, но это отдельный большой проект вне темы статьи, поэтому останавливаться здесь на этом не буду.
Увеличить скорость релиза. Сейчас релиз на board-серверах занимает час, релиз на API-серверах — полчаса. Мы хотим быстрее.
Дать командам инструмент для автономного управления релизами. Сейчас есть возможность запустить канареечный релиз для hotfix, но команды не могут воспользоваться GitLab Flow полностью самостоятельно. Например, не могут самостоятельно отвести релизную ветку. У нас по умолчанию включена функция «Branch merging enabled», поэтому ветки при сборке содержит код мастера, а для релизных веток командам нужна помощь со стороны для ручного отключения этой фичи.
Сократить время от момента нахождения ошибки до вывода фикса на канареечный релиз. Сейчас у нас это может занимать до 6 часов рабочего времени в худших случаях из-за сложностей в коммуникациях или процессах.
Управлять нагрузкой на канареечных релизах, чтобы с ростом пользователей мы имели возможность увеличивать скорость прогона релиза, не меняя доли пользователей, участвующих в нём.
Добавить пользовательские метрики в валидацию релиза. Пока используем только технические метрики и метрики с багами.
Буду рада, если в комментариях поделитесь опытом повышения доли успешных релизов, особенно если вы уже реализовали описанные выше задачи.
Тестируем на проде: Canary Deployment
Канарейка — маленькая птица, которая постоянно поет. Эти птички чувствительны к метану и угарному газу. Даже от небольшой концентрации лишних газов в воздухе они теряют сознание или умирают. Золотоискатели и шахтеры брали птичек на добычу: пока канарейки поют, можно работать, если замолчали — в шахте газ и пора уходить. Шахтеры жертвовали маленькой птичкой, чтобы выбираться из шахт живыми.
Подобная практика нашла себя и в IT. Например, в стандартной задаче деплоя новой версии сервиса или приложения на продакшн с тестированием перед этим. Тестовое окружение может быть слишком дорогим, автоматизированные тесты не покрывают все, что хотелось бы, а не тестировать и жертвовать качеством рискованно. Как раз в таких случаях помогает подход Canary Deployment, когда немного настоящего продакшн-трафика пускается на новую версию. Подход помогает безопасно проверить новую версию на продакшн, жертвуя малым ради большой цели. Подробнее, как работает подход, чем полезен и как его реализовать, расскажет Андрей Маркелов (Andrey_V_Markelov), на примере реализации в компании Infobip.
Андрей Маркелов — ведущий инженер-программист в Infobip, уже 11 лет занимается разработкой приложений на Java в области финансов и телекоммуникаций. Разрабатывает Open Source продукты, активно участвует в Atlassian Community и пишет плагины для продуктов Atlassian. Евангелист Prometheus, Docker и Redis.
О компании Infobip
Это глобальная телекоммуникационная платформа, которая позволяет банкам, ретейлу, интернет-магазинам и транспортным компаниям отправлять сообщения своим клиентам с помощью SMS, push, писем и голосовых сообщений. В таком бизнесе важна стабильность и надежность, чтобы клиенты вовремя получали сообщения.
IT-инфраструктура Infobip в цифрах:
Релизы
Типичный релиз у нас проходит так. Например, есть сервисы A, B, C, D и E, каждый из них разрабатывается отдельной командой.
В какой-то момент команда сервиса А решает задеплоить новую версию, но команды сервисов B, C, D и E об этом не знают. Вариантов, как поступит команда сервиса А, два.
Проведет инкрементальный релиз: сначала заменит одну версию, а потом вторую.
Но есть второй вариант: команда найдет дополнительные мощности и машины, задеплоит новую версию, а потом переключит роутер, и версия начнет работать на продакшн.
В любом варианте после деплоя почти всегда возникают проблемы, даже если версия протестирована. Тестировать можно руками, можно автоматизированно, можно не тестировать — проблемы возникнут в любом случае. Самый простой и правильный способ их решить — откатиться назад на работающую версию. Уже потом можно разбираться с ущербом, с причинами и исправлять их.
Проблемы нам не нужны. Если клиенты обнаружат их быстрее нас, это ударит по репутации. Поэтому мы должны находить проблемы быстрее клиентов. Работая на опережение, мы минимизируем ущерб.
В то же время, мы хотим ускорить деплой, чтобы это происходило быстро, легко, само собой и без напряжения со стороны команды. Инженеров, DevOps-инженеров и программистов надо беречь — релиз новой версии это стресс. Команда это не расходный материал, мы стремимся рационально использовать человеческие ресурсы.
Проблемы деплоя
Клиентский трафик непредсказуем. Невозможно предсказать, когда клиентский трафик будет минимальным. Мы не знаем, где и когда клиенты начнут свои кампании — может, сегодня ночью в Индии, а завтра в Гонконге. С учетом большой разницы во времени, деплой даже в 2 часа ночи не гарантирует, что клиенты не пострадают.
Проблемы провайдеров. Мессенджеры и провайдеры — наши партнеры. Иногда у них бывают сбои, которые вызывают ошибки во время деплоя новых версий.
Распределенные команды. Команды, которые разрабатывают клиентскую часть и бэкенд, находятся в разных часовых поясах. Из-за этого они часто не могут договориться между собой.
Дата-центры нельзя повторить на стейдже. В одном дата-центре 200 стоек — повторить это в песочнице даже приблизительно не получится.
Даунтаймынедопустимы! У нас есть допустимый уровень доступности (Error Budget), когда мы работаем 99,99% времени, например, а оставшиеся проценты это «право на ошибку». Достичь 100% надежности невозможно, но важно постоянно следить за падениями и простоями.
Классические варианты решения
Писать код без багов. Когда я был молодым разработчиком, ко мне подходили менеджеры с просьбой провести релиз без багов, но это не всегда возможно.
Писать тесты. Тесты работают, но иногда совсем не так, как хочет бизнес. Зарабатывать деньги — это не задача тестов.
Тестировать на стейдже. За 3,5 года моей работы в Infobip я ни разу не видел, чтобы состояние стейджа хотя бы частично совпадало с продакшн.
Мы даже пытались развить эту идею: сначала у нас был стейдж, потом препродакшн, а потом препродакшн препродакшна. Но и это не помогло — они не совпадали даже по мощности. Со стейджем мы можем гарантировать базовую функциональность, но не знаем, как она будет работать при нагрузках.
Релиз делает тот, кто разрабатывал. Это хорошая практика: даже если кто-то меняет название комментария, сразу добавляет в продакшн. Это помогает развивать ответственность и не забывать о внесенных изменениях.
Дополнительные сложности тоже есть. Для разработчика это стресс — тратить много времени, чтобы все проверить вручную.
Согласованные релизы. Этот вариант обычно предлагает менеджмент: «Давайте договоримся, что каждый день будете тестировать и добавлять новые версии». Это не работает: всегда есть команда, которая ждет все остальных или наоборот.
Smoke-тесты
Еще один способ решить наши проблемы с деплоем. Рассмотрим, как работают smoke-тесты на предыдущем примере, когда команда A хочет задеплоить новую версию.
Сначала команда деплоит один инстанс на продакшн. Сообщениями в инстанс от моков имитируется реальный трафик, чтобы он совпадал с нормальным ежедневным трафиком. Если все хорошо, команда переключает новую версию на пользовательский трафик.
Второй вариант — деплоить с дополнительным железом. Команда тестирует его на продакшн, потом переключает, и все работает.
Canary-релизы
Из-за недостатков smoke-тестов мы начали использовать canary-релизы.
Практика, подобная тому, как шахтеры использовали канареек для индикации уровня газов, нашла себя и в IT. Мы пускаем немного настоящего продакшн-трафика на новую версию, при этом стараемся уложиться в Service Level Agreement (SLA). SLA — это наше «право на ошибку», которое мы можем использовать раз в год (или за какой-то другой промежуток времени). Если все будет хорошо, добавим больше трафика. Если нет — вернем предыдущие версии.
Реализация и нюансы
Как мы реализовали canary-релизы? Например, группа клиентов отправляет сообщения через наш сервис.
Деплой проходит так: убираем один узел из-под балансировщика (1), меняем версию (2) и отдельно пускаем немного трафика (3).
В целом, в группе будут счастливы все, даже если один пользователь будет недоволен. Если все хорошо — меняем все версии.
Покажу схематично, как это выглядит для микросервисов в большинстве случаев.
Есть Service Discovery и еще два сервиса: S1N1 и S2. Первый сервис (S1N1) оповещает Service Discovery, когда стартует, а Service Discovery его запоминает. Второй сервис с двумя узлами (S2N1 и S2N2) тоже оповещает Service Discovery при старте.
Второй сервис для первого работает как сервер. Первый запрашивает у Service Discovery информацию о своих серверах, а когда получает — ищет и проверяет их («health check»). Когда проверит, то отправит им сообщения.
Когда кто-то хочет задеплоить новую версию второго сервиса, он сообщает Service Discovery, что вторая нода будет canary-нодой: на нее будет отправляться меньше трафика, потому что сейчас пройдет деплой. Убираем canary-ноду из-под балансировщика и первый сервис не отправляет в нее трафик.
Меняем версию и Service Discovery знает, что вторая нода теперь canary — можно давать ей меньше нагрузки (5%). Если все хорошо, меняем версию, возвращаем нагрузки и работаем дальше.
Чтобы все это реализовать, нам нужны:
Балансировка
Это первое, о чем мы должны задуматься. Есть две стратегии балансировки.
Простейший вариант, когда одна нода всегда canary. Эта нода всегда получает меньше трафика и мы начинаем деплой с нее. В случае проблем мы сравним ее работу до деплоя и во время него. Например, если ошибок стало в 2 раза больше, значит и ущерб вырос в 2 раза.
Canary-нода задается в процессе деплоя. Когда деплой закончится и мы снимем с нее статус canary-ноды, баланс трафика восстановится. С меньшим количеством машин мы получим честное распределение.
Мониторинг
Краеугольный камень canary-релизов. Мы должны точно понимать, зачем мы это делаем и какие метрики хотим собирать.
Примеры метрик, которые мы собираем с наших сервисов.
Counter. Это некоторая возрастающая величина, например, количество ошибок. Эту метрику просто интерполировать и изучать график: вчера было 2 ошибки, а сегодня 500, значит, что-то пошло не так.
Количество ошибок в минуту или в секунду, это важнейший показатель, который можно вычислить используя Counter. Эти данные дают четкое представление о работе системы на дистанции. Рассмотрим на примере графика количества ошибок в секунду для двух версий продакшн-системы.
В первой версии было мало ошибок, возможно, не работал аудит. Во второй версии все намного хуже. Можно точно сказать, что есть проблемы, поэтому мы должны откатить эту версию.
Gauge. Метрики похожи на Counter, но мы записываем значения, которые могут как увеличиваться, так и уменьшаться. Например, время выполнения запросов или размер очереди.
На графике пример времени отклика (latency). По графику видно, что версии похожи, с ними можно работать. Но если приглядеться, то заметно, как меняется величина. Если время выполнения запросов увеличивается при добавлении пользователей, то сразу понятно, что есть проблемы — раньше такого не было.
Summary. Один из важнейших показателей для бизнеса — перцентили. Метрика показывает, что в 95% случаев наша система работает так, как мы хотим. Мы можем смириться, если где-то проблемы, потому что понимаем общую тенденцию, насколько все хорошо или плохо.
Инструменты
Prometheus. Хорошо себя проявил в Infobip. Он позволяет реализовать многомерные метрики, потому что используются лейблы.
Анализ версий
Есть несколько стратегий анализа версий.
Смотреть метрики только canary-ноды. Один из простейших вариантов: задеплоили новую версию и изучаем только работу. Но если инженер в это время начнет изучать логи, постоянно нервно перезагружая страницы, то это решение ничем не отличается от остальных.
Canary-нода сравнивается с любой другой нодой. Это сравнение с другими инстансами, которые работают на полном трафике. Например, если с маленьким трафиком дела обстоят хуже, или не лучше, чем на реальных инстансах, то что-то не так.
Canary-нода сравнивается с собой в прошлом. Ноды, выделенные для canary, можно сравнивать с историческими данными. Например, если неделю назад все было хорошо, то можем ориентироваться на эти данные, чтобы понять текущую ситуацию.
Автоматизация
Мы хотим освободить инженеров от ручного сравнения, поэтому важно реализовать автоматизацию. Процесс деплоя (deployment pipeline) обычно выглядит так:
На этом этапе мы реализуем автоматическое сравнение. Как оно может выглядеть и почему лучше, чем проверка после деплоя, рассмотрим на примере из Jenkins.
Это pipeline к Groovy.
Описание метрики. Посмотрим, как может выглядеть функция compare на примере DSL.
Допустим, мы сравниваем количество ошибок и хотим узнать количество ошибок в секунду за последние 5 минут.
У нас есть два значения: базовое и canary-ноды. Значение у canary-ноды — текущее. Базовое — baseValue — это значение любой другой не canary-ноды. Сравниваем значения между собой по формуле, которую ставим исходя из своего опыта и наблюдений. Если значение canaryValue плохое, то деплой не удался, и мы откатываемся.
Зачем это все нужно?
Человек не может проверить сотни и тысячи метрик, тем более сделать это быстро. Автоматическое сравнение помогает проверить все метрики и быстро оповещает о проблемах. Время оповещения критично: если что-то случилось за последние 2 секунды, то ущерб будет не такой большой, как если бы это произошло 15 минут назад. Пока кто-то заметит проблему, напишет в поддержку, а поддержка нам, чтобы откатить, можно потерять клиентов.
Если процесс прошел и все хорошо, мы деплоим все остальные ноды автоматически. В это время инженеры не делают ничего. Только когда они запускают canary, решают, какие метрики взять, сколько по времени делать сравнение, какую стратегию использовать.
Если возникли проблемы — автоматически откатываем canary-ноду, работаем на прошлых версиях и исправляем ошибки, которые нашли. По метрикам их легко найти и увидеть ущерб от новой версии.
Препятствия
Реализовать это, конечно, непросто. Прежде всего нужна общая система мониторинга. У инженеров свои метрики, у поддержки и аналитиков — другие, у бизнеса третьи. Общая система — это общий язык, на котором разговаривают бизнес и разработка.
Нужно проверить на практике стабильность метрик. Проверка помогает понять, какой минимальный набор метрик нужен, чтобы обеспечить качество.
Как этого достичь? Использовать canary-сервис не в момент деплоя. Добавляем на старой версии некий сервис, который в любой момент времени сможет взять любую выделенную ноду, уменьшить трафик без деплоя. После сравниваем: изучаем ошибки и ищем ту грань, когда мы достигаем качества.
Какую пользу мы получили от canary-релизов
Минимизировали процент ущерба от багов. Большинство ошибок деплоя происходит из-за несогласованности каких-то данных или приоритета. Таких ошибок стало намного меньше, потому что мы можем решить проблему в первые секунды.
Оптимизировали работу команд. У новичков есть «право на ошибку»: они могут деплоить в продакшн без страха ошибиться, появляется дополнительная инициатива, стимул работать. Если они что-то сломают, то это будет не критично, а ошибившегося не уволят.
Автоматизировали деплой. Это уже не ручной процесс, как раньше, а настоящий автоматизированный. Но он проходит дольше.
Выделили важные метрики. Вся компания, начиная от бизнеса и инженеров, понимает, что действительно важно в нашем продукте, какие метрики, например, отток и приток пользователей. Мы контролируем процесс: тестируем метрики, вводим новые, смотрим, как работают старые, чтобы строить систему, которая будет зарабатывать деньги производительнее.
У нас много классных практик и систем, которые нам помогают. Несмотря на это, мы стремимся быть профессионалами и делать свою работу качественно, вне зависимости от того, есть у нас система, которая нам поможет, или нет.
Инженерные подходы и практики — основной фокус конференции TechLead Conf. Если вы достигли успехов на пути к техническому совершенству и готовы рассказать, что вам в этом помогло, — подавайте заявку на доклад.
TechLead Conf пройдет 8 и 9 июня онлайн. Карантин не повод останавливать профессиональное общение, поэтому сейчас мы как раз тестируем новые форматы и к июню будем во всеоружии, чтобы конференция была именно конференцией — с вопросами, дискуссиями и нетворкингом.