Як обрати тип standby для вашого веб-застосунку

Уявіть: о 3 годині ночі відмовляє основний регіон AWS, ваш сервіс недоступний, а кожна година простою коштує тисячі доларів. Без резервного дата-центру (DR Site) відновлення може зайняти години. Ми проєктуємо та впроваджуємо рішення Disaster Recovery, які мінімізують простій. Наша команда має 5+ років досвіду в DR та реалізувала 20+ проєктів для e-commerce і fintech.

Клієнти часто дивуються, що cold standby обходиться всього в 10% від production (наприклад, близько $500/міс для невеликого застосунку), але при збої відновлення триває до 8 годин. Warm standby — золота середина: при RTO 30–60 хвилин вартість становить 30–50% від production (близько $1500–2500/міс). Наприклад, перехід з hot на warm standby зменшує щомісячну вартість з $5000 до $2000, економлячи $3000 на місяць.

Як ми це робимо (доказ експертності)

На одному з проєктів для фінтех-компанії ми реалізували warm standby з RTO 15 хвилин замість початкових 4 годин. Використовували Terraform для IaC, PostgreSQL streaming replication та автоматичне перемикання DNS через Route 53. Результат: час відновлення скоротився в 16 разів, а вартість резервної інфраструктури склала лише 40% від production.

Який тип 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 хвилин, що робить його оптимальним вибором для більшості веб-застосунків. Hot standby забезпечує RTO в 60 разів краще, ніж cold standby. Крім того, warm standby у 3–5 разів кращий за cold standby за співвідношенням вартості та швидкості відновлення.

Архітектура DR Site

Вибір місця розташування 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 з точними командами — не загальними словами, а конкретними кроками:

1. Підтвердити збій основної площадки (не хибна тривога)
2. Оголосити DR-інцидент, призначити інцидент-менеджера
3. Перевірити лаг реплікації БД перед перемиканням
4. Якщо warm/hot: виконати promote БД-репліки (pg_promote())
5. Оновити DNS (Route 53 / Cloudflare) на DR-адреси
6. Перевірити працездатність через DR Site
7. Повідомити команду та, при необхідності, користувачів
8. Зафіксувати час RTO

Що входить у налаштування DR Site

Терміни реалізації

• Аналіз поточної інфраструктури та вибір стратегії — 2–3 дні
• Налаштування реплікації даних — 3–7 днів
• Розгортання DR-інфраструктури в IaC — 5–10 днів
• Мережева зв'язність та безпека — 2–5 днів
• Процедури, runbook, тестування — 3–5 днів

Разом: 2–5 тижнів залежно від складності інфраструктури та типу DR.

Орієнтовна вартість

Вартість розраховується індивідуально і залежить від обраного типу standby, об'єму даних та складності інфраструктури. Наприклад, hot standby для середнього застосунку може коштувати близько $5000/міс. Ми підберемо оптимальний баланс між бюджетом та часом відновлення.

Замовте консультацію — оцінимо ваш проєкт і запропонуємо рішення з потрібним RTO і RPO. Disaster Recovery — це не розкіш, а необхідність для будь-якого серйозного сервісу.