Активный режим в нескольких площадках с Global Tables и Route 53

Multi-Site Active-Active — это высший уровень аварийного восстановления, при котором приложение одновременно работает с полной производственной нагрузкой в двух или более регионах AWS. В отличие от active-passive, где резервная среда ожидает передачи управления, в режиме active-active оба региона постоянно обслуживают реальный пользовательский трафик. При отказе одного региона другой немедленно принимает на себя 100% трафика без задержки перехода в резервный режим. Этот шаблон также уменьшает задержку для пользователей по всему миру, обслуживая их из ближайшего региона.

DynamoDB Global Tables — основа данных для архитектур active-active. Global Tables поддерживает репликацию с несколькими ведущими узлами между несколькими регионами: приложения в любом регионе могут локально читать и write в таблицу DynamoDB, а изменения примерно за 1 секунду реплицируются во все остальные регионы. Чтобы включить Global Tables, укажите регионы, в которых должна существовать таблица. AWS автоматически выполняет всю репликацию, разрешение конфликтов (побеждает последняя запись) и переход в резервный режим.

Aurora Global Database поддерживает активное чтение, но пассивную запись. Все вторичные регионы обслуживают чтение с задержкой репликации менее 1 секунды, тогда как записи принимает только основной регион. Это идеальный вариант для приложений с преобладанием чтения, которым нужны чтения с низкой задержкой по всему миру и чётко определённый основной регион для записи. При региональном отказе основного региона можно повысить вторичный регион до основного менее чем за 1 минуту, обеспечив низкий RTO для уровня записи. Сравните это с DynamoDB Global Tables, которая поддерживает активную запись во всех регионах.

Route 53 — диспетчер трафика для архитектур active-active на нескольких площадках. Используйте маршрутизацию на основе задержки, чтобы направлять каждого пользователя в регион с наименьшей сетевой задержкой от его местоположения. Добавьте проверки работоспособности к записи каждого региона: когда регион не проходит проверку, Route 53 автоматически удаляет его из ответов DNS и направляет весь трафик в оставшиеся работоспособные регионы. Установите для DNS TTL 60 секунд или меньше, чтобы минимизировать время перехода пользователей в работоспособный регион.

Когда один регион выходит из строя в конфигурации active-active, выживший регион должен обрабатывать вдвое больший (или ещё больший) обычный трафик. Ваша Auto Scaling Group должна иметь достаточную максимальную ёмкость и политики масштабирования, которые быстро реагируют на нагрузку. Настройте масштабирование с отслеживанием целевого показателя на основе количества запросов ALB на целевой объект, чтобы ASG автоматически добавляла экземпляры при удвоении трафика. Также рассмотрите предварительный прогрев: во время тренировочных переходов в резервный режим наблюдайте, как быстро масштабируется ASG, и убедитесь, что она может достичь требуемой ёмкости в пределах целевого RTO.

В одно-региональной архитектуре пользовательские сеансы можно хранить локально на серверах приложений. В многорегиональной конфигурации active-active пользователи при последующих запросах могут переключаться между регионами, из-за чего серверные сеансы перестают работать. Возможные решения: 1) сеансы без состояния — хранить данные сеанса в подписанном JWT или файле cookie, который может проверить любой сервер в любом регионе. 2) DynamoDB Global Tables для сеансов — централизованно хранить сеансы с доступом из любого региона за миллисекунды. 3) ElastiCache с Global Datastore — репликация Redis между регионами для хранения сеансов.

Главная проблема active-active с записью из нескольких ведущих узлов — это конфликты записей. Если два пользователя в разных регионах одновременно обновляют одну запись, какое обновление победит? DynamoDB Global Tables использует побеждает последняя запись, ориентируясь на время записи. Для большинства сценариев это работает хорошо, но может привести к потере данных при конкурирующих обновлениях (например, когда два пользователя одновременно увеличивают счётчик). Проектируйте модель данных так, чтобы избегать одновременных записей в один элемент из разных регионов: используйте условные записи или распределяйте владение данными между регионами.

Для объектного хранилища в конфигурации active-active используйте межрегиональную репликацию S3 с двунаправленной репликацией (доступна для корзин с включённым версионированием). В отличие от однонаправленной CRR, двунаправленная репликация поддерживает синхронность корзин обоих регионов: объекты, записанные в любом регионе, автоматически реплицируются в другой. Это критически важно для приложений, которые записывают загруженные пользователями файлы в локальную корзину S3, но должны обеспечить глобальный доступ к этим файлам. Включите Replication Time Control (RTC) S3, чтобы гарантировать репликацию 99,99% объектов в течение 15 минут.

Используйте CloudFront с группами источников, чтобы создать CDN active-active с автоматическим переходом в резервный режим. Настройте основной источник (ALB в us-east-1) и вторичный источник (ALB в eu-west-1). CloudFront автоматически переключается на вторичный источник, когда основной возвращает ошибки 5xx. Для статических ресурсов, предоставляемых из S3, настройте группы источников, указывающие на корзины S3 в нескольких регионах с двунаправленной репликацией. Это добавляет уровень устойчивости на уровне CDN поверх маршрутизации active-active в Route 53.

Архитектуры active-active требуют надёжного мониторинга, чтобы оба региона оставались работоспособными, а трафик распределялся ожидаемым образом. Ключевые метрики: Route 53 HealthCheckPercentageHealthy для каждого региона, DynamoDB ReplicationLatency для задержки Global Tables, ALB RequestCount для каждого региона — для проверки распределения трафика — и панели CloudWatch между аккаунтами и регионами для единого представления. Настройте оповещения, когда задержка репликации превышает порог RPO или распределение трафика становится существенно неравномерным.

Active-active подходит, когда пользователи распределены по всему миру, а задержка при обращении к одному региону неприемлема; RTO должен быть близок к нулю и бизнес не может допустить даже нескольких минут простоя; высокая пропускная способность записи требует распределения записей между регионами; нормативные требования предписывают обрабатывать данные внутри страны. Стоимость существенно выше, чем у других уровней DR, поэтому выбирайте active-active только тогда, когда бизнес-требования и экономика явно это оправдывают. Для многих нагрузок достаточно Warm Standby, который обходится значительно дешевле.

В этом уроке Вы узнали, что DynamoDB Global Tables поддерживает запись с несколькими ведущими узлами между регионами для настоящей конфигурации active-active, маршрутизация Route 53 на основе задержки с проверками работоспособности направляет пользователей в ближайший работоспособный регион, а управление сеансами в active-active должно быть без состояния или использовать глобально реплицируемое хранилище. Active-active обеспечивает почти нулевые RTO и RPO, но требует значительно больших затрат. Далее мы рассмотрим Operational Excellence и Security — принципы Well-Architected Framework.