Мультирегиональный хостинг: как пережить падение дата-центра
Продвинутое4 минРедакция Innovialabs
Коротко
Мультирегиональность — это копия сайта в другом регионе и автоматическое переключение трафика при сбое; проще всего начать с active-passive, а active-active оправдан, только когда простой стоит дороже удвоенной инфраструктуры и сложности с данными.
Коротко: что дает второй регион
Один дата-центр — это единая точка отказа. Пожар, сбой питания, ошибка сети провайдера или проблема всего облачного региона кладут сайт целиком, сколько бы серверов внутри ни стояло. Мультирегиональный хостинг — это работающая копия приложения в географически другом месте плюс механизм, который переводит пользователей туда, когда основная площадка недоступна.
Важно разделять две задачи:
- Высокая доступность внутри региона — несколько серверов и зон доступности (availability zones). Закрывает отказ отдельной машины или стойки.
- Отказоустойчивость между регионами — закрывает отказ целой площадки. Это дороже и сложнее, прежде всего из-за данных.
Перед проектированием зафиксируйте два параметра: RTO (за какое время сервис должен вернуться) и RPO (сколько последних данных допустимо потерять). Именно они определяют архитектуру, а не желание «чтобы никогда не падало».
Active-passive и active-active
| Active-passive | Active-active | |
|---|---|---|
| Трафик | Весь идет в основной регион, резервный ждет | Распределен между регионами постоянно |
| Переключение | При сбое, за минуты | Трафик просто перестает идти в упавший регион |
| Данные | Одна главная БД, реплика в резерве | Запись в нескольких регионах или сложная маршрутизация записей |
| Сложность | Умеренная | Высокая |
| Стоимость | Резерв можно держать уменьшенным | Полная мощность в каждом регионе |
Active-passive подходит большинству проектов. Резервный регион бывает «горячим» (все запущено, нужно только переключить трафик), «теплым» (минимум серверов, масштабируется при аварии) или «холодным» (есть только бэкапы и инфраструктура как код, поднимается вручную).
Active-active дает минимальный простой и бонус в виде низкой задержки для пользователей в разных частях мира. Но каждый регион должен выдерживать нагрузку за двоих, а приложение — корректно работать с данными, которые меняются в нескольких местах.
DNS failover: как переключается трафик
Самый распространенный механизм — DNS с проверками здоровья (health checks). DNS-провайдер регулярно опрашивает эндпоинт приложения в каждом регионе и, если основной перестает отвечать, начинает отдавать IP резервного.
Что важно учесть:
- TTL записи. Резолверы кэшируют ответ на время TTL, поэтому для failover-записей его ставят коротким. Часть клиентов и провайдеров все равно может держать старый адрес дольше.
- Глубина проверки. Эндпоинт
/health, который всегда отвечает200, бесполезен. Он должен проверять то, без чего сервис не работает: базу, кэш, критичные зависимости, — но не падать из-за второстепенных. - Порог срабатывания. Переключение по одной неудачной проверке приводит к «дребезгу». Нужно несколько подряд неудачных проверок из разных точек.
- Альтернативы. Глобальные балансировщики и anycast (например, у CDN-провайдеров) переключают трафик быстрее DNS, потому что не зависят от кэша резолверов.
Данные: главный компромисс
Статику и код скопировать легко. Сложность всегда в базе данных.
- Асинхронная репликация. Основная БД подтверждает запись сразу, реплика догоняет с задержкой. Быстро, но при аварии последние транзакции могут не успеть доехать — это и есть ваш RPO.
- Синхронная репликация. Запись подтверждается только после сохранения в обоих регионах. Потерь нет, но каждая запись ждет межрегиональную задержку, и при обрыве связи запись может остановиться.
- Мультимастер. Запись в любом регионе. Требует стратегии разрешения конфликтов, и не каждая модель данных это допускает.
Отдельно продумайте обратное переключение: после восстановления основного региона его данные устарели, и вернуть трафик без потерь — отдельная процедура.
Частые ошибки
- Резервный регион ни разу не проверялся под реальной нагрузкой — в момент аварии выясняется, что он не поднимается.
- Секреты, сертификаты, DNS-записи сторонних сервисов или очереди существуют только в основном регионе.
- Файлы пользователей лежат на диске сервера, а не в объектном хранилище с репликацией.
- Вспомогательные сервисы (авторизация, платежи, почта) привязаны к одному региону и становятся новой единой точкой отказа.
- Нет runbook: кто принимает решение о переключении и какие шаги выполняет.
Когда второй регион оправдан
Мультирегиональность стоит денег дважды: за инфраструктуру и за инженерное время на поддержку. Она оправдана, если:
- час простоя обходится дороже, чем содержание резерва;
- есть договорные обязательства по доступности (SLA) перед клиентами;
- требования регулятора обязывают иметь резервную площадку;
- пользователи распределены по миру, и задержка сама по себе влияет на бизнес.
Если ничего из этого нет, разумная ступень — несколько зон доступности в одном регионе, плюс регулярные бэкапы в другой регион и инфраструктура как код, чтобы поднять все заново за предсказуемое время.