Телеграм канал «»

Три зоны доступности. Почему сервис всё равно упал?

Один из стандартных способов повысить отказоустойчивость — распределить инфраструктуру между несколькими Availability Zones.

Если одна зона перестанет работать, нагрузку примут оставшиеся.

По крайней мере, так выглядит архитектурная схема.

Представим сервис, работающий в трёх зонах. В каждой размещена треть вычислительных мощностей.

В обычном режиме система обрабатывает 9000 запросов в секунду — примерно по 3000 на зону.

Теперь одна зона становится недоступна.

Трафик никуда не исчезает, поэтому двум оставшимся зонам приходится обрабатывать уже по 4500 запросов в секунду.

Но каждая из них рассчитана максимум на 3500.

Формально резервирование есть. Фактически резервной ёмкости нет.

Начинают расти очереди и latency. Появляются тайм-ауты, клиенты повторяют запросы, а повторы ещё сильнее нагружают систему.

Локальный отказ превращается в каскадный.

Это проблема capacity planning: при проектировании нужно учитывать не только нормальную нагрузку, но и то, сколько ресурсов останется после отказа части инфраструктуры.

Но нехватка мощности — не единственная причина, по которой Multi-AZ может не спасти.

1. Общие зависимости

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

Отказ такой зависимости затронет сразу все зоны. Три независимых ряда серверов не помогут, если за ними стоит одна общая точка отказа.

2. Недостаточная изоляция

Компоненты могут делить пулы соединений, лимиты, очереди или другие ресурсы.

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

3. Неудачный failover

Переключение на резервную инфраструктуру само создаёт дополнительную нагрузку.

Например, тысячи клиентов одновременно восстанавливают соединения с базой данных. Добавим сюда повторные запросы, прогрев кешей и перераспределение трафика.

Резервная система должна выдерживать не только обычный поток запросов, но и поведение клиентов во время восстановления.

4. Непроверенный сценарий отказа

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

Но пока команда не отключила зону в тестовом окружении или контролируемом эксперименте, она не знает, что произойдёт на практике.

Поэтому я бы спрашивал не только:

«В скольких зонах работает сервис?»

Полезнее проверить другое:

— Хватит ли оставшейся мощности при отказе одной зоны?

— Какие зависимости остаются общими?

— Действительно ли зоны изолированы друг от друга?

— Как поведут себя клиенты во время переключения?

— Не вызовут ли тайм-ауты и retry дополнительную перегрузку?

— Сколько времени займёт восстановление?

— Проверяли ли мы этот сценарий на практике?

Multi-AZ снижает риск инфраструктурного отказа, но не гарантирует устойчивость всей системы.

Отказоустойчивость появляется не тогда, когда мы добавили ещё одну зону на схему.

А когда проверили, что после потери части ресурсов система продолжает работать с приемлемым качеством — а не просто остаётся формально доступной.