AWS Fault Injection Simulator – используйте контролируемые эксперименты для улучшения отказоустойчивости

AWS предоставляет компоненты необходимые для построения высоконадёжных систем: множество регионов (каждый с несколькими зонами доступности AZ), Amazon CloudWatch (метрики, мониторинг и нотификации), Auto Scaling, Load Balancing, несколько вариантов репликации между регионами, и многое другое. Когда вы настраиваете это всё в соответствии с рекомендуемыми подходами, описанными в Well-Architected Framework, ваши системы должны продолжать работать, даже при отказах какого-либо компонента вышей системы.

Тем не менее, вы не можете быть в этом уверены, пока не проведёте соответствующего тестирования. Достаточно новая область Chaos Engineering (основанная на новаторской работе “Мастера Катастроф” Jesse Robbins в первые дни Amazon.com, и затем поднятая на новый уровень Netflix Chaos Monkey) фокусируется на добавлении стресса в приложение путем создания «разрушительных» событий, наблюдением за поведением в этот момент, и последующего внесения улучшений в систему. Помимо подсвечивания проблемных областей, требующих улучшения, Chaos Engineering помогает обнаружить «слепые зоны» в системе, которым необходим дополнительный мониторинг и нотификации в случае проблем. Также, такой подход выявляет скрытые проблемы уровня разработки в коде программного обеспечения, и позволяет отточить навыки управления системой с фокусом на улучшение времени восстановления приложения. Чтобы узнать об этом побольше, начните с Chaos Engineering – Part 1 от моего коллеги Adrian Hornsby.

Введение в AWS Fault Injection Simulator (FIS)

Сегодня мы представляем AWS Fault Injection Simulator (FIS) – новый сервис, который позволяет проводить контролируемые эксперименты с вашими рабочими нагрузками AWS путём внедрения ошибок и возможности наблюдать за последствиями.  Вы узнаете как система реагирует на различные типы ошибок и получите дополнительное понимание об отказах в вашей системе. Для начала можно запустить эксперименты в рамках тестового окружения, затем сделать их частью процессов CI/CD, а уже после – запускать в производственной среде.

Каждый AWS Fault Injection Simulator (FIS) эксперимент нацелен на определённй набор ресурсов AWS, и производит над ними набор действий. Мы запустили сервис со встроенной поддержкой для Amazon Elastic Compute Cloud (EC2), Amazon Elastic Container Service (ECS), Amazon Elastic Kubernetes Service (EKS), и Amazon Relational Database Service (RDS), поддержка дополнительных ресурсов и действий запланирована на 2021. Вы можете выбрать необходимые ресурсы по их типу, тэгам, ARN, или по указанным в выборке параметрам. Есть возможность остановить эксперимент, если сработал один или более условий для остановки эксперимента (определённых посредством CloudWatch Alarms). Это позволяет быстро прервать эксперимент, если было обнаружено неожиданное влияние на критичную бизнес или операционную метрику.

Использование AWS Fault Injection Simulator (FIS)
Давайте создадим шаблон эксперимента и запустим сам эксперимент! Я буду использовать четыре EC2 инстанса, имеющих тэги Mode = Test:

Откроем FIS консоль и нажмём Create experiment template, чтобы начать процесс:

Введём описание (Description) и выберем IAM роль. Роль определяет права доступа, необходимые для FIS для проведения действий на выбранных ресурсах в рамках экспериментов:

Далее, я определяю одно или несколько действий, из которых состоит эксперимент. Я нажимаю Add action:

Затем, я определяю моё первое действие – я хочу остановить некоторые из моих EC2 инстансов (имеющих тэг Mode=Test) на пять минут, и убедиться, что система сохранит работоспособность. После окончания конфигурации, я нажимаю Save:

Далее, я выбираю необходимые целевые ресурсы (EC2 инстансы в нашем случае) для эксперимента. Я нажимаю Add target, задаю имя группы целевых ресурсов, и определяю, что они включают все мои EC2 инстансы в текущем регионе, имеющие тэг Mode со значением Test. Я также могу выбрать случайный инстанс, или процентное значение всех инстансов, имеющих тэг, или фильтр по Ресурсу. После выбора нужных опций, я нажимаю Save:

Я могу выбрать одно или несколько условий остановки (CloudWatch Alarms) эксперимента. Если условие срабатывает, то эксперимент будет остановлен. Этот контролируемый механизм позволяет создать безопасную среду для экспериментов, где локальная ошибка не приведёт к масштабной деградации системы или приложения.

И последнее, я тэгирую мой шаблон эксперимента, и нажимаю Create experiment template:

Мой шаблон готов к использованию для эксперимента:

Для запуска эксперимента, я выбираю нужный шаблон и, после этого выбираю опцию Start experiment из Actions меню:

Затем, я нажимаю Start experiment (я решил добавить тэг):

Я подтверждаю свои намерения, потому что это может повлияет на мои AWS ресурсы:

Мой эксперимент начинает работу, и я могу наблюдать за происходящими действиями:

Как и ожидалось, целевые инстансы останавливаются:

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

Я могу создавать, запускать и отслеживать эксперименты, используя FIS API и FIS CLI. Также вы можете, например, запускать несколько разных экспериментов на одних и тех же целевых ресурсах, или запускать один и тот же эксперимент на разных целевых ресурсах.

Начните использование уже сегодня
AWS Fault Injection Simulator (FIS) доступен для использования, и вы можете запускать контролируемые эксперименты с его помощью уже сегодня. Он доступен во всех AWS регионах, за исключением Asia Pacific (Osaka) и двух регионов в Китае. Эти три региона включены в план дальнейшего развития сервиса FIS.

Ценообразование основано на времени, в течении которого исполнялись ваши действия в рамках экспериментов; ознакомьтесь с FIS ценообразованием, чтобы узнать подробнее.

Мы планируем добавлять дополнительные поддерживаемые сервисы и действия в течении 2021, поэтому следите за обновлениями!

— Jeff;