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 состоит из пяти основных этапов:

1. Создание гипотезы. Гипотеза — это обоснованное предположение о том, как ваша система будет вести себя в определённых условиях. То есть это ожидаемая реакция на определённый тип сбоя. Например, если Vault потеряет лидер ноду в кластере из трёх нод, Vault должен продолжать отвечать на запросы, а в качестве лидер ноды должна быть выбрана другая нода. При формировании гипотезы, начните с малого и сосредоточьтесь на одной части вашей системы. Это облегчит тестирование этой конкретной части без влияния на другие.

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

3. Создание и проведение эксперимента. На этом этапе вы определяете параметры эксперимента. Как вы будете проверять свою гипотезу? Например, при тестировании времени отклика приложения Vault вы можете имитировать медленное соединение и создать задержку.

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

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

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

5. Внесите изменения и улучшения. После анализа результатов и сравнения показателей, устраните проблему. Внесите необходимые изменения в приложение или систему, разверните изменения, а затем проверьте, что изменения устранили проблему, повторив этот процесс. Так вы постепенно повысите устойчивость системы. Это более эффективный подход, чем попытка сразу внести масштабные изменения во всё приложение.

Реализация

В этом разделе описаны четыре эксперимента для тестирования кластера 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 описаны шаги, необходимые для восстановления работы кластера, и этот эксперимент поможет их проверить.

Гипотеза

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

Определение устойчивого состояния от Vault

В этом эксперименте мы проверим, отвечает ли Vault на запросы. Для проверки получим ключ.

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

В Gremlin проводится ещё один эксперимент с «чёрной дырой», на этот раз нацеленный на две ноды кластера.

Наблюдение

Теперь, когда ноды не работают, кластер Vault потерял кворум. Без кворума операции чтения и записи не могут выполняться внутри кластера. При попытке получить тот же ключ возвращается ошибка.

Восстановление и улучшения

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

Долгосрочным решением может стать внедрение развёртывания с несколькими центрами обработки данных, где вы можете реплицировать данные. Это повысит производительность и обеспечит аварийное восстановление (DR). HashiCorp рекомендует использовать кластеры DR, чтобы избежать простоев и соблюдать соглашения об уровне обслуживания (SLA).

Эксперимент 3: тестирование того, как Vault обрабатывает задержку

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

Гипотеза

Введение задержки на лидер ноде кластера не должно вызывать тайм‑аутов приложения или сбоев кластера.

Определение ключевых показателей эффективности (KPI) от инструмента мониторинга

В этом эксперименте используются те же показатели Datadog, что и в первом эксперименте: vault.core.handle_login_request и vault.core.handle_request.

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

На этот раз используйте Gremlin, чтобы добавить задержку. Вместо того чтобы проводить один эксперимент, создайте сценарий, который позволит вам последовательно проводить несколько экспериментов. Постепенно увеличивайте задержку со 100 мс до 200 мс в течение 4 минут с 5-секундными перерывами между экспериментами. (Этот пост в блоге Gremlin объясняет, как работает атака с задержкой.)

Наблюдение

В нашем тесте эксперимент вызвал некоторые задержки времени отклика, особенно на 95-м и 99-м процентилях, но все запросы были успешными. Что ещё более важно, наш кластер стабилен, о чём свидетельствуют ключевые показатели ниже:

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

Чтобы сделать кластер ещё более устойчивым, добавьте в него ноды без права голоса. Нода без права голоса имеет все данные Vault, но не влияет на подсчёт кворума. Это можно использовать с нодами в режиме ожидания, чтобы добавить масштабируемость для чтения кластера. Это может быть полезно в случаях, когда требуется большой объём операций чтения с серверов. Таким образом, если одна или две ноды не справляются, дополнительные ноды в режиме ожидания могут включиться и поддержать производительность.

Эксперимент 4: тестирование того, как Vault обрабатывает нехватку памяти

Этот заключительный эксперимент проверяет способность Vault обрабатывать операции чтения при нехватке памяти.

Гипотеза

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

Определение показателей от инструмента мониторинга

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

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

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

Наблюдение

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

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

Как и в предыдущем эксперименте, вы можете использовать ноды без права голоса и ноды в режиме ожидания, чтобы при необходимости добавить вычислительные мощности в кластер. Эти ноды добавляют дополнительную память, но не влияют на подсчёт кворума.

Как построить культуру использования Chaos engineering

Команды обычно думают о надёжности с точки зрения технологий и систем, но есть и другая сторона — надёжность начинается с людей. Чтобы начать строить культуру надёжности, нужно научить разработчиков приложений, SRE‑инженеров, сотрудников, реагирующих на инциденты, и других членов команд, проактивно думать о надёжности.

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

1. Познакомить другие команды с концепцией Chaos engineering.

2. Показать ценность Chaos engineering в вашей команде (вы можете использовать результаты этих экспериментов в качестве доказательства).

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

4. Создавать в команде культуру поощрения экспериментов и обучения, а не возлагать вину за инциденты.

5. Внедрять новые инструменты и методы Chaos engineering.

6. Использовать Chaos engineering для регулярного тестирования систем и процессов, автоматизации экспериментов и проведения организованных командных мероприятий по надёжности (их часто называют «Игровыми днями»).

Если вы хотите научиться практикам Chaos engineering, приходите в Слёрм на курс Chaos engineering. Вы научитесь формировать гипотезы и самостоятельно проводить эксперименты с помощью ChaosBlade и ChaosMesh, а также познакомитесь с другими инструментами, например Gremlin.