Chaos engineering — это подход к проверке устойчивости приложений. Грубо говоря, мы умышленно ломаем что‑либо в системе, чтобы посмотреть, как она будет себя вести, и делаем из этого эксперимента полезные выводы о надёжности и уязвимостях.

Перевели статью, о том, как применить этот подход к HashiCorp Vault — системе по управлению секретами.

Что такое HashiCorp Vault

HashiCorp Vault — это система управления секретами и шифрованием на основе идентификации. Секрет — это всё, к чему вы хотите ограничить доступ, например ключи шифрования API, пароли и сертификаты.

Архитектура HashiCorp Vault

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

При работе в режиме HA серверы Vault имеют два состояния: резервное и активное. Постоянно активен только один экземпляр. Все резервные экземпляры находятся в режиме готовности (hot standbys). Запросы обрабатывает только активный сервер, а резервный — перенаправляет все запросы на активный. Если активный сервер по какой‑то причине заблокирован, выходит из строя или теряет сетевое подключение, один из резервных серверов становится активным. Служба Vault может продолжать работать при условии, что большинство серверов (кворум) остаются онлайн. Подробнее о производительности резервных нод читайте в нашей документации.

Что такое chaos engineering?

Chaos engineering — это практика поиска рисков надёжности в системах путём преднамеренного внедрения неисправностей. Эта практика помогает выявлять недостатки в системах, сервисах и архитектуре до того, как произойдёт реальный сбой. Вы можете повысить доступность, снизить среднее время до устранения сбоя (MTTR), снизить среднее время обнаружения сбоя (MTTD), уменьшить количество ошибок, попадающих в продукт, и уменьшить количество сбоев. У команд, которые часто проводят эксперименты по Chaos engineering, доступность может достигать 99,9%.

При проведении экспериментов Chaos engineering вы:

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

Подробнее о практиках и инструментах Chaos Engineering вы можете узнать в статье Слёрма или посмотрев вебинар.

Chaos engineering и Vault

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

изменения кода и конфигурации, влияющие на производительность приложения;
потеря лидер ноды;
потеря кворума в кластере Vault;
недоступность основного кластера;
высокая нагрузка на кластеры Vault.

Чтобы снизить эти риски, командам необходимо тестировать и проверять устойчивость Vault. Здесь на помощь приходит Chaos engineering. Рассмотрим эксперименты с использованием Gremlin — платформы для Chaos engineering.

Цель Chaos engineering

Несмотря на название, цель Chaos engineering не в том, чтобы создать хаос, а в том, чтобы его уменьшить. Ведь в конечном итоге вы должны выявить и исправить проблемы. Chaos engineering — не случайное или бесконтрольное тестирование. Это методический подход, поэтому все эксперименты стоит планировать и тщательно обдумывать. Вы должны хорошо понимать, когда и как прекратить эксперимент, как следить за хелсчеками и состоянием систем.

Помните, что Chaos engineering не альтернатива юнит‑тестам, интеграционным тестам или сравнительному анализу производительности (performance benchmarking). Он дополняет их, и его можно проводить параллельно. Например, одновременные эксперименты по Chaos engineering и тестам производительности могут помочь выявить проблемы, которые возникают только под нагрузкой. Это увеличивает вероятность обнаружения проблем надёжности, которые могут возникнуть при эксплуатации.

Пять этапов Chaos engineering

Эксперимент по Chaos engineering состоит из пяти основных этапов:

Создание гипотезы. Гипотеза — это обоснованное предположение о том, как ваша система будет вести себя в определённых условиях. То есть это ожидаемая реакция на определённый тип сбоя. Например, если Vault потеряет лидер ноду в кластере из трёх нод, Vault должен продолжать отвечать на запросы, а в качестве лидер ноды должна быть выбрана другая нода. При формировании гипотезы, начните с малого и сосредоточьтесь на одной части вашей системы. Это облегчит тестирование этой конкретной части без влияния на другие.
Определение устойчивого состояния. Устойчивое состояние системы — это её производительность и поведение в нормальных условиях. Определите показатели, которые лучше всего указывают на надёжность вашей системы и отследите их в нормальных условиях. Это базовый уровень, с которым вы будете сравнивать результаты эксперимента. Примеры показателей устойчивого состояния включают Vault.core.handle_login_request и vault.core.handle_request. Дополнительные ключевые метрики можно найти здесь.
Создание и проведение эксперимента. На этом этапе вы определяете параметры эксперимента. Как вы будете проверять свою гипотезу? Например, при тестировании времени отклика приложения Vault вы можете имитировать медленное соединение и создать задержку.

Здесь же вам нужно определить условия, при которых вы прервёте эксперимент. Например, если задержка приложения Vault превышает пороговые значения эксперимента, вы должны немедленно остановить его. Обратите внимание, что прерванный эксперимент не равен проваленному. Это просто означает, что вы обнаружили риск для надёжности.

После определения эксперимента и условий прерывания вы можете создать экспериментальные системы с помощью Gremlin.

Отслеживание результатов. Во время эксперимента отслеживайте ключевые показатели вашего приложения. Посмотрите, как они соотносятся с базовыми показателями, и сделайте выводы о результатах теста. Например, если «чёрная дыра» в вашем кластере Vault быстро увеличивает загрузку процессора, возможно, у вас слишком быстрое время отклика на запросы API. Или веб‑приложение может начать выдавать пользователям HTTP 500 вместо понятных сообщений об ошибках. В обоих случаях это нежелательные результаты, которые необходимо устранить.
Внесите изменения и улучшения. После анализа результатов и сравнения показателей, устраните проблему. Внесите необходимые изменения в приложение или систему, разверните изменения, а затем проверьте, что изменения устранили проблему, повторив этот процесс. Так вы постепенно повысите устойчивость системы. Это более эффективный подход, чем попытка сразу внести масштабные изменения во всё приложение.

Реализация

В этом разделе описаны четыре эксперимента для тестирования кластера Vault. Прежде, чем вы сможете провести эти эксперименты, вам потребуется:

Кластер Vault с высокой доступностью (HA).
Аккаунт Gremlin (зарегистрируйтесь бесплатно на 30 дней).
Инструмент для оценки производительности Vault.
Информирование организации (предупредите остальных, что вы проводите эксперименты на этом кластере).
Базовый мониторинг.

Эксперимент 1: влияние потери лидер ноды

В первом эксперименте вы проверите, сможет ли Vault продолжать отвечать на запросы, если лидер нода станет недоступна. Если активный сервер заблокирован, выходит из строя или теряет сетевое подключение, один из резервных серверов Vault становится активным экземпляром. Вы будете использовать эксперимент с «чёрной дырой», чтобы заблокировать сетевой трафик к лидер ноде и от неё, а затем отслеживать состояние кластера.

Гипотеза

Если Vault потеряет лидер ноду в кластере из трёх нод, то Vault должен продолжать отвечать на запросы, и другая нода должна стать лидером.

Определение устойчивого состояния с помощью инструмента мониторинга

Наше устойчивое состояние основано на трёх показателях:

сумма всех запросов, обработанных Vault;
vault.core.handle_login_request;
vault.core.handle_request.

Приведённый ниже график показывает, что сумма запросов колеблется в районе 20 тысяч, в то время как handle_login_request и handle_request колеблются между показателями 1 и 3.

Проведение эксперимента

В этом эксперименте на лидер ноде в течение 300 секунд (5 минут) проводится эксперимент с «чёрной дырой». Эксперименты с «чёрной дырой» блокируют сетевой трафик от хоста и отлично подходят для имитации любого количества сетевых сбоев, включая неправильно настроенные брандмауэры, сбои сетевого оборудования и т. д. Пяти минут достаточно, чтобы измерить влияние и наблюдать реакцию Vault.

На скриншоте вы можете увидеть текущий статус эксперимента в Gremlin:

Наблюдение

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

Вы можете убедиться в этом, проверив ноды в кластере с помощью команды Vault operator raft:

Улучшение устойчивости кластера

Судя по этим результатам, немедленных изменений не требуется, но есть возможность расширить масштабы этого теста. Что произойдет, если две ноды выйдут из строя? Или все три? Если это действительно беспокоит вашу команду, попробуйте повторить эксперимент и убрать ещё несколько нод. Вы можете попробовать увеличить масштаб кластера до четырёх нод вместо трёх и посмотреть, как это изменит ваши результаты. Не забывайте, что в Gremlin есть кнопка Halt для остановки текущего эксперимента, если произошло что‑то непредвиденное. Помните об условиях прерывания и не бойтесь останавливать эксперимент, если эти условия выполняются.

Эксперимент 2: влияние потери кворума

Следующий эксперимент проверяет, сможет ли Vault продолжать отвечать на запросы при отсутствии кворума. Для этого в эксперименте с «чёрной дырой» две ноды их трёх будут отключены от сети. В таком сценарии Vault не сможет добавить или удалить ноду или зафиксировать дополнительные записи в журнале. В этой инструкции от HashiCorp описаны шаги, необходимые для восстановления работы кластера, и этот эксперимент поможет их проверить.