Проектируем DR-инфраструктуру для веб-приложений
Представьте: в 3 часа ночи отказывает основной регион AWS, ваш сервис недоступен, а каждый час простоя обходится в тысячи долларов. Без резервного дата-центра (DR Site) восстановление может занять часы. Мы проектируем и внедряем решения Disaster Recovery, которые минимизируют простой. За 5 лет мы реализовали более 20 проектов для e-commerce и fintech, и знаем, как обеспечить RTO от 5 минут.
Клиенты часто удивляются, что cold standby обходится всего в 10% от production (от 20 000 до 50 000 рублей в месяц для среднего проекта), но при сбое восстановление длится до 8 часов. Warm standby — золотая середина: при RTO 30–60 минут стоимость составляет 30–50% от production (от 60 000 до 150 000 рублей ежемесячно). Свяжитесь с нами — подберём оптимальный вариант под ваш бюджет и требования по RTO и RPO.
Как выбрать тип DR-готовности?
Для cold standby инфраструктура не запущена, данные реплицируются, конфигурация хранится в IaC. При сбое: поднять окружение из Terraform → восстановить данные из резервной копии → запустить приложение. RTO: 2–8 часов.
Warm standby подразумевает базовую инфраструктуру, запущенную в уменьшенном размере (1 инстанс вместо 10). Данные актуальны через репликацию. При сбое: масштабировать до production-размера → переключить DNS. RTO: 15–60 минут.
Hot standby — полная копия инфраструктуры работает постоянно, данные синхронизированы с лагом менее минуты. При сбое: переключить DNS/балансировщик. RTO: 1–5 минут.
Warm standby дешевле hot standby в 3–5 раз при RTO до 60 минут, что делает его оптимальным выбором для большинства веб-приложений.
| Тип готовности | RTO | RPO | Относительная стоимость |
|---|---|---|---|
| Cold Standby | 2–8 часов | часы | Низкая (10% от prod) |
| Warm Standby | 15–60 минут | минуты | Средняя (30–50% от prod) |
| Hot Standby | 1–5 минут | секунды | Высокая (80–100% от prod) |
Выбор местоположения DR Site
Ключевые требования:
- Физически независимая электросеть и интернет-каналы
- Минимум 100 км от основной площадки (защита от региональных катастроф)
- Соответствие законодательству (данные пользователей из РФ — в РФ, GDPR для Европы)
Варианты:
- Второй AWS/GCP/Azure регион (самое простое)
- Другой облачный провайдер (защита от vendor outage)
- Собственный или арендованный co-location (для regulated industries)
Почему Infrastructure as Code — основа DR Site?
Весь DR Site описывается в Terraform. Основное и резервное окружение — разные workspace или отдельные директории конфигурации, параметризованные через переменные:
module "app_cluster" { source = "./modules/app" region = var.region instance_type = var.dr_mode ? "t3.medium" : "c6i.2xlarge" replica_count = var.dr_mode ? 1 : 5 } Cold standby: terraform apply только при активации DR. Warm standby: terraform apply сразу с dr_mode = true. IaC гарантирует идентичность окружений и исключает дрейф конфигурации.
Репликация данных
PostgreSQL → DR Site: Streaming replication с асинхронным standby в DR. Для критических данных — synchronous_commit = remote_apply (гарантирует, что при сбое primary данные есть на standby, но увеличивает латентность записи).
Мониторинг лага репликации:
SELECT now() - pg_last_xact_replay_timestamp() AS replication_lag; Алерт при лаге > 30 секунд.
Файловые хранилища: S3 Cross-Region Replication (AWS) — автоматически, RPO < 15 минут; Rclone sync по расписанию — для объектов, которые редко меняются; Lsyncd для realtime синхронизации файловой системы между серверами.
Redis: Redis Sentinel с репликой в DR или Redis Cluster с geo-distribution.
Сетевая связность
Между основной площадкой и DR Site нужен выделенный канал для репликации данных: AWS VPC Peering или Transit Gateway (внутри AWS), AWS Direct Connect / GCP Interconnect (из on-premise в облако), Site-to-site VPN (бюджетный вариант, менее надёжный).
Канал репликации должен быть изолирован от пользовательского трафика — пиковая нагрузка приложения не должна влиять на репликацию.
Как обеспечить минимальный RTO?
Чтобы сократить RTO до минут, используйте hot или warm standby с автоматическим переключением DNS. Дополнительно: настройте health checks, которые запускают процедуру восстановления, и храните Terraform state в удалённом бэкенде, доступном из обоих ЦОДов.
Процедура активации DR Site
Документированный runbook с точными командами — не общими словами, а конкретными шагами:
- Подтвердить сбой основной площадки (не ложная тревога)
- Объявить DR-инцидент, назначить инцидент-менеджера
- Проверить лаг репликации БД перед переключением
- Если warm/hot: выполнить promote БД-реплики (
pg_promote()) - Обновить DNS (Route 53 / Cloudflare) на DR-адреса
- Проверить работоспособность через DR Site
- Уведомить команду и, при необходимости, пользователей
- Зафиксировать время RTO
Что входит в настройку DR Site
| Этап | Результат | Срок |
|---|---|---|
| Аудит инфраструктуры | Отчёт с рекомендациями | 2–3 дня |
| Проектирование DR-архитектуры | Схема, выбор стратегии | 1–2 дня |
| Настройка репликации данных | Репликация БД, файлов, Redis | 3–7 дней |
| Развёртывание IaC для DR | Terraform-конфигурации | 5–10 дней |
| Написание runbook и тестирование | Документация, тестовое переключение | 3–5 дней |
| Обучение команды | Вебинар/документация | 1 день |
Сроки реализации
- Анализ текущей инфраструктуры и выбор стратегии — 2–3 дня
- Настройка репликации данных — 3–7 дней
- Развёртывание DR-инфраструктуры в IaC — 5–10 дней
- Сетевая связность и безопасность — 2–5 дней
- Процедуры, runbook, тестирование — 3–5 дней
Итого: 2–5 недель в зависимости от сложности инфраструктуры и типа DR.
Ориентировочная стоимость
Стоимость рассчитывается индивидуально и зависит от выбранного типа standby, объёма данных и сложности инфраструктуры. Мы подберём оптимальный баланс между бюджетом и временем восстановления.
Закажите консультацию — оценим ваш проект и предложим решение с нужным RTO и RPO. Disaster Recovery — это не роскошь, а необходимость для любого серьёзного сервиса.