HA и отказоустойчивость: определения и компромиссы

Высокая доступность (HA) и отказоустойчивость (FT) — две разные цели надёжности, которые архитекторы часто путают. Высокая доступность означает, что система испытывает минимальное время простоя: она может пережить сбои, но при восстановлении возможны кратковременные перебои. Отказоустойчивость означает, что система продолжает работать без какого-либо прерывания даже при отказе компонентов, поскольку полностью резервные пути мгновенно принимают нагрузку.

Доступность измеряется как процент времени работы за год. Доступность 99,9% (три девятки) означает примерно 8,7 часа простоя в год, тогда как 99,99% (четыре девятки) допускает только 52,6 минуты. 99,999% (пять девяток) допускает всего 5,26 минуты. Каждая дополнительная девятка обычно требует большей избыточности, автоматизации и затрат. На экзамене SAA-C03 часто проверяется умение определить, какая архитектура соответствует заданной цели доступности.

Высокодоступная архитектура выдерживает отказ одного компонента, автоматически обнаруживая сбой и переключаясь на исправную замену в течение секунд или минут. Примеры: RDS Multi-AZ (автоматическое переключение на резервный экземпляр в другой AZ), Auto Scaling Groups, заменяющие завершённые экземпляры, и Elastic Load Balancers, перенаправляющие трафик от неисправных целевых ресурсов. Возникает кратковременное прерывание, но система восстанавливается без ручного вмешательства.

Отказоустойчивая архитектура использует активную избыточность — несколько одинаковых компонентов одновременно обрабатывают запросы, поэтому при отказе одного из них остальные мгновенно принимают его нагрузку без простоя. Примеры: активно-активный ELB с несколькими экземплярами EC2, DynamoDB Global Tables, одновременно обслуживающие чтение и запись в нескольких регионах, и Aurora с несколькими репликами для чтения. Для отказоустойчивости требуется постоянно работающий дополнительный ресурс.

Отказоустойчивость значительно дороже высокой доступности, поскольку требует постоянно полностью подготовленной резервной ёмкости. Высокодоступный экземпляр RDS Multi-AZ удваивает стоимость базы данных из-за резервного экземпляра, который активируется только при сбое. Отказоустойчивая активно-активная конфигурация Aurora в нескольких регионах может стоить в четыре раза дороже, зато полностью устраняет простой при отказах региона. Архитекторам необходимо сопоставлять стоимость избыточности с бизнес-ценой простоя.

Целевое время восстановления (RTO) — это максимально допустимое время недоступности системы. Архитектуры с высокой доступностью предусматривают низкое RTO — обычно минуты — благодаря автоматическому переключению. Отказоустойчивые архитектуры предусматривают почти нулевое RTO. При проектировании HA необходимо выбирать сервисы и конфигурации, гарантирующие восстановление в пределах заданного бюджета RTO. Например, RDS Multi-AZ обеспечивает RTO примерно 60–120 секунд, что подходит для многих требований высокой доступности.

Единичная точка отказа (SPOF) — это любой компонент, отказ которого приводит к отказу всей системы. К распространённым SPOF относятся один экземпляр EC2 без ASG, база данных RDS в одной AZ, один шлюз NAT или одна зона доступности. Устранение SPOF — первый шаг к обеспечению HA и FT. На экзамене SAA-C03 часто проверяется умение находить и устранять SPOF на заданных архитектурных схемах.

Обеспечить HA или FT гораздо проще для сервисов без состояния (например, веб-серверов или функций Lambda), поскольку любой экземпляр может обработать любой запрос. Сервисы с состоянием (базы данных, кэши, файловые системы) устроены сложнее: необходимо синхронизировать состояние между репликами, учитывать задержку репликации и обеспечивать согласованность при переключении. Такие сервисы AWS, как EFS (общая файловая система), ElastiCache с группами репликации и Aurora (общее хранилище), разработаны для упрощения обеспечения HA сервисов с состоянием.

К распространённым шаблонам HA в AWS относятся: 1) балансировка нагрузки между AZ — распределение экземпляров EC2 по AZ за ALB; 2) реплики для чтения — разгрузка трафика чтения и повышение реплики до основной при DR; 3) S3 для ресурсов без состояния — S3 изначально обеспечивает HA с надёжностью 11 девяток; 4) Global Accelerator — статические IP-адреса Anycast, направляющие трафик к исправным конечным точкам в разных регионах. Каждый шаблон представляет собой компромисс между стоимостью и требуемым уровнем доступности.

Шаблоны отказоустойчивости требуют активной избыточности повсюду. Основные шаблоны FT: DynamoDB изначально отказоустойчив — он реплицирует данные в трёх AZ, поэтому переключение не требуется. S3 имеет встроенную FT. Aurora Multi-Master (теперь многозапись Aurora Serverless v2) позволяет одновременно выполнять запись в нескольких AZ. Kinesis по умолчанию хранит данные в нескольких AZ. Выбор управляемых сервисов со встроенной FT — наиболее экономичный путь к архитектурам без простоев.

Качество проектирования HA или FT определяется качеством тестирования. AWS рекомендует использовать AWS Fault Injection Simulator (FIS) для проведения контролируемых экспериментов: завершать экземпляры, ограничивать пропускную способность API или внедрять сетевые сбои. Необходимо убедиться, что переключение действительно завершается в пределах RTO, что потери данных не превышают RPO и что оповещения срабатывают правильно. Регулярные дни отказов и упражнения по хаос-инжинирингу выявляют пробелы в предположениях об отказоустойчивости до того, как они приведут к инцидентам в рабочей среде.

Проверьте, насколько хорошо Вы усвоили концепции AWS Solutions Architect (SAA-C03) из этого урока.

В этом уроке Вы узнали, что высокая доступность сокращает время простоя благодаря автоматическому восстановлению (RTO в минутах), отказоустойчивость устраняет простой благодаря активной избыточности (нулевое RTO), а стоимость значительно возрастает с каждым уровнем устойчивости. Устранение единичных точек отказа — основа обоих подходов. Далее мы рассмотрим шаблоны Multi-AZ для сервисов с состоянием.