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

Введение

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

В 2018 году Kayenta, инструмент с открытым исходным кодом для автоматического анализа канареек, стал доступен в рамках проекта Spinnaker¹. В этой статье мы описываем, как мы интегрировали Kayenta в нашу существующую инфраструктуру развертывания, значительно повысив надежность нашего конвейера развертывания и создав предварительные условия для автоматизированного производственного развертывания. Более того, чтобы получить более полную картину, мы дополнили Kayenta подходом на основе машинного обучения для обнаружения аномалий в файлах журнала ошибок.

Вкратце, Kayenta сравнивает два временных ряда и предупреждает, когда отклонение превышает определенный порог. В качестве источника этих показателей приложения мы используем New Relic Insights. Для этого бэкэнда мы также предоставили код с открытым исходным кодом в Kayenta ³. Также доступна поддержка других бэкэндов (Datadog, Prometheus и др.). Для получения общей информации об автоматическом канареечном анализе, пожалуйста, обратитесь к отличным статьям от Google ¹ и Netflix ².

От CI к CD

В Adobe мы занимаемся автоматизацией несколько лет. Помимо автоматизации тестирования, автоматическое развертывание - это одна из опор, позволяющих контролировать накладные расходы на обслуживание и поддерживать высокий уровень стабильности. С годами наш сервисный ландшафт превратился в многорегиональную распределенную систему с несколькими облаками. Несмотря на наши развертывания с помощью одной кнопки, надзор за тщательным развертыванием одного компонента в более чем 6 производственных центрах обработки данных может занять инженера на пару часов, когда мониторинг необходимо выполнять вручную. Поэтому в нашей последней инициативе по оптимизации мы сосредоточились на фазе развертывания и мониторинга. Публичный выпуск Kayenta произошел как раз в нужное время.

Преимущества

Как объясняется в блоге Google Cloud, есть определенные преимущества от добавления автоматизированного канареечного анализа. Для нас наиболее важны следующие преимущества:

  • Снижение накладных расходов и, в конечном итоге, увеличение скорости работы нашей организации были первоначальными спусковыми механизмами нашей работы.
  • Учет человеческих ошибок добавил нам еще одно измерение: сложность зрелых сервисов, находящихся в эксплуатации в течение многих лет, требует от инженеров, которые понимают многие аспекты этого сервиса во время развертывания. Подобно автоматическим тестам, автоматизация мониторинга дает разработчикам инструмент для «кодирования своих ожиданий» относительно статистической дисперсии определенных показателей. В нашей настройке конфигурация Kayenta хранится как часть кода в репозиториях Git, что позволяет легко поддерживать все в одном месте. Это также соответствует нашей стратегии, позволяющей командам разработчиков полностью владеть своими услугами.
  • Автоматизация принятия решения о повышении или откате позволяет учитывать расширенные показатели. Выполнять их вручную при каждом развертывании было бы слишком утомительно. Точно так же решения четко определяются и документируются с помощью метрик и аналитики, на которых они основаны.
  • В дополнение к временным рядам, поддерживаемым через Kayenta, мы добавили анализатор журнала ошибок, который ищет аномалии файла журнала в канарейке. Это служит для обнаружения сообщений об ошибках, которых раньше не было. Это то, что нельзя было сделать раньше, потому что объем журнала слишком велик для просмотра вручную.

Наше решение

Прежде чем добавить Kayenta в наш конвейер развертывания, мы оценили несколько вариантов. В конце концов мы решили интегрировать автономный Kayenta в наш конвейер развертывания, потому что переход на другой инструмент развертывания, такой как Spinnaker, не был вариантом в настройке нашего предприятия.

Автоматический канареечный анализ с использованием сине-зеленого развертывания

В наших промежуточных и производственных системах мы выполняем традиционное сине-зеленое развертывание с канареечной поддержкой. В качестве поэтапного подхода мы просто заменили этап ручного мониторинга автоматизацией (шаг пятый в списке ниже):

  1. Один кластер живых экземпляров работает с использованием текущей активной версии, в дальнейшем называемой базовой.
  2. Второй кластер масштабируется с использованием небольшого количества экземпляров, далее это называется экспериментом.
  3. После того, как первая небольшая партия экземпляров готова, мы запускаем набор тестов работоспособности. Эти тесты предназначены для того, чтобы охватить критические пути наших экземпляров.
  4. Если с тестами все в порядке, трафик переключается на экспериментальные экземпляры.
  5. Во время смены трафика Kayenta регулярно анализирует временные ряды New Relic и журналы ошибок.
  6. Если эксперимент пройдет успешно, трафик в экспериментальном кластере будет постепенно увеличиваться и, наконец, отключаться.

Canary log analyzer

В дополнение к аналитике временных рядов мы настроили один из наших собственных компонентов, анализатор журналов Canary, в качестве одного из бэкэндов мониторинга в Kayenta (помимо New Relic). По сути, он обнаруживает аномалии на основе выходных данных журнала ошибок и сообщает о них в виде показателей. Сообщения журнала ошибок, которые не появлялись ранее в течение нескольких недель, считаются аномалиями. Как и в случае с обычными временными рядами, Кайента будет сравнивать аномалии, исходящие от исходного уровня, с аномалиями, полученными в результате эксперимента.

Обучение

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

  • Наличие отдельных экспериментальных и базовых кластеров предотвращает ухудшение показателей из-за разогрева при масштабировании новых экземпляров в рамках процесса сокращения. Это помогает, потому что набор отслеживаемых экземпляров не изменится.
  • Соответствие зоны доступности (AZ) на AWS: при использовании настроек, развернутых в нескольких зонах доступности, важно выбирать базовые и экспериментальные экземпляры из одних и тех же зон доступности. Несмотря на то, что на простых информационных панелях это может быть невидимо для человека, Kayenta будет смотреть на временные ряды гораздо более подробно, чем человек, и замечать, когда тайминги различаются из-за AZ.
  • Низкочастотные метрики. Сравнение низкочастотных показателей от очень неравно больших наборов хостов нарушает сопоставимость, особенно когда шансы увидеть ненулевое число за период времени высоки. Например, предположим, что 100 запросов в секунду во всех экземплярах с частотой ошибок в один процент. При мониторинге сине-зеленого развертывания с 99 базовыми экземплярами и одним канареечным экземпляром с интервалом в одну секунду, мы ожидаем, что постоянная частота ошибок составит один процент на базовой стороне и одна ошибка каждые 100 секунд на стороне эксперимента. Следовательно, частота ошибок на канареечной стороне будет равна нулю в большинстве интервалов в одну секунду. Напротив, если мы посмотрим на два экземпляра мониторинга наборов одинакового размера, мы могли бы просто использовать абсолютные числа ошибок для сравнения друг с другом.

Дополнительное обучение

  • Статистическая значимость. Как всегда, при анализе показателей важно иметь релевантный трафик. В наших промежуточных средах мы не могли использовать показатели с высоким стандартным отклонением, такие как время ответа базы данных. Только более общие показатели, такие как частота ошибок и время транзакции, дали надежные результаты. Очевидно, что для получения точных результатов недостаточно было провести небольшое количество тестов на платформе. У нас были лучшие результаты в наших производственных системах с несколькими тысячами запросов в минуту на каждый экземпляр.
  • Настройка показателей занимает много времени. Конечно, можно начать с определенных показателей (частота ошибок, Apdex New Relic, время транзакции). Однако Kayenta может проявить больше сильных сторон, когда команды разработчиков активно вносят свой вклад в конфигурации метрик и сами поддерживают их.
  • Использование Kayenta как автономной службы работает очень хорошо, как только становится понятно, как она работает внутри компании.

Вывод

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

Инвестирование в автоматизированный канареечный анализ было риском без каких-либо гарантий, что он будет хорошо работать в нашем сценарии. Год спустя мы можем назвать это успехом. Это позволило нам уверенно автоматизировать развертывание на всем пути к производству с более последовательными и подробными результатами мониторинга.

[1]: https://cloud.google.com/blog/products/gcp/introduction-kayenta-an-open-automated-canary-analysis-tool-from-google-and-netflix

[2]: https://medium.com/netflix-techblog/automated-canary-analysis-at-netflix-with-kayenta-3260bc7acc69

[3]: https://github.com/spinnaker/kayenta