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

Главная идея простая: решение «что делать при отказе» принимается заранее, на бумаге и в архитектуре, а не в панике в три часа ночи во время инцидента. Disaster recovery (DR, аварийное восстановление) — это ваш план на случай, когда обычной защиты не хватило и нужно восстанавливать систему. В этой статье разберём базовые понятия по шагам: где размещать копии, как измерять требования к восстановлению и какие бывают стратегии.

Зоны доступности и регионы

Сначала про географию AWS, без неё дальше не разобраться.

  • Регион (region) — большая географическая область, например Франкфурт или Северная Вирджиния. Внутри региона ваши данные не покидают его пределов.
  • Зона доступности (Availability Zone, AZ) — отдельный физический датацентр (или группа близких датацентров) внутри региона. В каждом регионе их обычно три и больше. Зоны соединены быстрыми каналами, но физически разнесены: пожар или сбой питания в одной зоне не задевает другие.

Аналогия: регион — это город, а зоны доступности — разные здания в этом городе. Если в одном здании отключилось электричество, работа продолжается в соседнем.

Multi-AZ против multi-region

Есть два уровня защиты, и они стоят очень по-разному.

Multi-AZ — это когда ваши ресурсы продублированы в нескольких зонах доступности одного региона. Защищает от отказа целой зоны (того самого «здания»). Это дёшево, задержка между зонами крошечная, и в большинстве сервисов AWS такая защита встраивается почти автоматически. Например, группа автомасштабирования (Auto Scaling Group) раскидывает серверы по разным зонам, а у базы данных RDS есть режим Multi-AZ, который держит горячую копию в другой зоне. Подробнее про эту базовую защиту — в статье про масштабирование и доступность. Multi-AZ делают практически всегда — это разумный минимум.

Multi-region — это полная копия системы в другом регионе (другом «городе»). Защищает от отказа целого региона. Такое случается очень редко, но если случается — это катастрофа. Расплата за защиту высокая: данные нужно реплицировать через сотни и тысячи километров, следить за их согласованностью и уметь переключать трафик между регионами. Это делают только для по-настоящему критичных систем, где недоступность региона недопустима — например, в финансах.

Простое правило: multi-AZ — почти всем, multi-region — только когда требования к доступности это реально оправдывают, потому что стоимость и сложность вырастают резко.

Ещё один важный нюанс: multi-AZ и multi-region решают разные проблемы и не взаимозаменяемы. Multi-AZ спасает от технического сбоя оборудования. Multi-region вдобавок спасает от региональной катастрофы. Но ни то, ни другое не спасает от логической ошибки — если вы случайно удалили таблицу или выкатили багованный код, копия в другой зоне или регионе аккуратно повторит за вами и удаление, и баг. От таких ситуаций защищают только бэкапы, о которых ниже.

RPO и RTO

Прежде чем выбирать стратегию восстановления, нужно ответить на два вопроса. Их формулируют двумя метриками, и именно их спросят в первую очередь, когда зайдёт речь о DR.

  • RPO (Recovery Point Objective) — сколько данных вы готовы потерять, измеряется во времени. RPO = 5 минут означает: «если случится катастрофа, мы согласны потерять последние 5 минут данных, не больше». Эта метрика определяет, как часто делать бэкапы и репликацию. Хотите RPO поменьше — копируйте данные чаще.
  • RTO (Recovery Time Objective) — за какое время система должна снова заработать. RTO = 1 час означает: «через час после аварии сервис снова доступен». Эта метрика определяет, какую стратегию восстановления выбрать.

Аналогия для RPO и RTO: представьте, что вы пишете документ. RPO — как часто вы нажимаете «Сохранить» (сколько работы потеряете при сбое). RTO — как быстро вы откроете компьютер заново и продолжите работать после того, как он завис.

Чем меньше оба числа, тем дороже решение. Важный момент: RPO и RTO задаёт бизнес, а не инженер. Бизнес решает, во что обходится час простоя и потеря данных, а инженер уже подбирает под эти цифры подходящую архитектуру.

Маленький пример. Интернет-магазин говорит: «терять заказы нельзя совсем, но магазин может полежать полчаса без катастрофы». Это значит RPO близок к нулю (данные дублируем непрерывно), а RTO порядка тридцати минут (восстановиться можно не мгновенно). Другой случай — внутренний отчётный сервис: «потерять данные за сутки не страшно, но к утру всё должно работать». Тут RPO в сутки и RTO в несколько часов — и решение будет в разы дешевле. Одни и те же технологии, но разные цифры дают совершенно разную архитектуру и стоимость.

Четыре стратегии аварийного восстановления

AWS выделяет четыре основные стратегии DR. Они выстроены по возрастанию: чем выше в списке, тем дешевле и тем медленнее восстановление; чем ниже — тем дороже и быстрее.

  1. Backup & restore (бэкап и восстановление) — вы только храните резервные копии. Случилась катастрофа — разворачиваете инфраструктуру заново и заливаете данные из бэкапа. Самый дешёвый вариант, но RTO и RPO большие (часы). Подходит для систем, которые могут позволить себе подождать.

  2. Pilot light («дежурная лампочка») — постоянно работает только самое ядро, обычно реплика базы данных, которая всё время получает свежие данные. Остальное (серверы приложения, балансировщики) выключено и поднимается только при аварии. Название — отсылка к маленькому огоньку в газовой колонке, от которого мгновенно зажигается основное пламя. RTO заметно меньше, цена умеренная.

  3. Warm standby («тёплый резерв») — в запасном регионе работает уменьшенная, но полностью живая копия всей системы. Она реально обслуживает что-то (или просто готова), а при аварии масштабируется до полного размера и принимает весь трафик. RTO маленький, но и платить приходится постоянно за работающую копию.

  4. Multi-site active-active («активный-активный») — полноценные копии системы работают одновременно в нескольких регионах и обе обслуживают пользователей. Если один регион падает, трафик просто идёт во второй, почти без паузы. RTO близок к нулю, но это самый дорогой и сложный вариант: нужно синхронизировать данные между регионами в обе стороны.

Чтобы было нагляднее, представьте резервный автомобиль на случай поломки основного. Backup & restore — это запчасти в гараже: дёшево, но собирать машину придётся долго. Pilot light — машина без колёс, колёса докупаются при поломке. Warm standby — заведённая, но стоящая в гараже малолитражка, на которую можно быстро пересесть. Active-active — две одинаковые машины едут параллельно, и если одна заглохла, вы просто продолжаете во второй.

Выбор стратегии — это компромисс между требованиями (RPO/RTO) и бюджетом. Частая дорогая ошибка — строить active-active там, где задачам с запасом хватило бы pilot light.

Бэкапы и их проверка

Бэкап, который ни разу не восстанавливали, — это не бэкап, а надежда. Самый частый провал в DR звучит так: «бэкапы вроде были, а восстановиться не смогли» — файл оказался битым, не хватило прав, скрипт устарел или процесс занял в десять раз больше времени, чем рассчитывали.

Поэтому хорошая практика складывается из двух частей. Первая — регулярные автоматические бэкапы: с частотой, которая укладывается в ваш RPO, и со сроком хранения, который вам нужен. AWS Backup умеет настраивать такие политики централизованно. Вот как выглядит запуск разовой резервной копии через командную строку (AWS CLI):

aws backup start-backup-job \
  --backup-vault-name production-vault \
  --resource-arn arn:aws:rds:eu-central-1:111122223333:db:orders-db \
  --iam-role-arn arn:aws:iam::111122223333:role/AWSBackupDefaultServiceRole

Вторая, не менее важная часть — учения по восстановлению. Периодически нужно реально поднимать систему из бэкапа в изолированной среде и проверять две вещи: что данные целы и что вы укладываетесь в свой RTO. Только пройденное «учение» превращает бэкап из строчки в отчёте в настоящую страховку.

Где это применяется

Отказоустойчивость и DR — это не отдельная экзотическая тема, а часть определения «готового к продакшену» сервиса наравне с масштабированием и наблюдаемостью. Когда инженера спрашивают «что будет, если упадёт зона или регион, и как мы восстановимся», честный ответ опирается ровно на эти понятия: multi-AZ как база, multi-region по необходимости, стратегия DR под заданные RPO/RTO и проверенные бэкапы. Надёжность (reliability) — один из столпов методики проектирования Well-Architected, так что понимать DR полезно при любой работе с облаком.

Типичные ошибки новичков:

  • Считать, что AWS «и так всё сохранит». Облако даёт инструменты, но политику бэкапов и стратегию DR настраиваете вы. По умолчанию никто за вас данные на случай катастрофы не дублирует.
  • Путать высокую доступность и аварийное восстановление. Multi-AZ держит сервис живым при мелких сбоях, но это не замена бэкапам: если кто-то по ошибке удалил данные, реплика в другой зоне честно повторит это удаление.
  • Строить самый дорогой вариант «на всякий случай». Active-active без реального требования к нулевому RTO — это сожжённый бюджет. Сначала RPO/RTO от бизнеса, потом стратегия. Тему денег стоит изучить отдельно — см. оптимизацию затрат.
  • Ни разу не проверять бэкап. Самая обидная ошибка: план есть, копии есть, а в момент аварии всё рассыпается.

Что учить дальше: разберитесь, как вообще устроена доступность приложения в облаке — масштабирование и доступность и базовые основы AWS. DR тесно связан с автоматизацией развёртывания: всю инфраструктуру для восстановления удобно описывать кодом, чтобы поднимать её одной командой — загляните в основы infrastructure as code и инструменты Terraform, CloudFormation, CDK. Полезно понимать и хранилище для самих бэкапов — про него отдельно в объектном хранилище. А если деплоите в Kubernetes, посмотрите, как восстановление и переключение нагрузки решаются там — в разделе Kubernetes: эксплуатация.