Развертывание Azure Spring Apps в нескольких регионах

Эта эталонная архитектура описывает подход к запуску нескольких экземпляров Azure Spring Apps в разных регионах в конфигурации active-active.

Эта конструкция основана на базовой архитектуре Azure Spring Apps. Базовый план развертывает приложение Java Spring Boot в нескольких зонах доступности в одном регионе. Несколько зон распределяют рабочую нагрузку приложения между отдельными расположениями, чтобы рабочая нагрузка может допускать локальные сбои в регионе Azure.

Однако если весь регион испытывает сбой, базовый план становится недоступным пользователю. Цель этого проектирования заключается в создании высокой доступности, которая может выдержать региональный сбой.

Эта архитектура полезна для удовлетворения следующих целей:

• Увеличьте общую цель устойчивости и уровня обслуживания (SLO) приложения.
• Включение глобального охвата для приложения.
• Приблизите рабочую нагрузку к конечному пользователю и сделайте задержку максимально низкой.
• Используйте дополнительный регион в качестве сайта отработки отказа для основного региона и выберите активный пассивный дизайн.

Чтобы повысить устойчивость и надежность приложений, можно развернуть приложение в нескольких регионах. Для этой разработки требуется глобальный маршрутизатор для балансировки нагрузки запросов к приложениям в разных регионах. Глобальный маршрутизатор в этой архитектуре также решает другие цели.

Самая большая проблема с настройкой в нескольких регионах заключается в реплика реплика данных для приложения между несколькими регионами. Эта проблема не связана с настройкой нескольких зон. Зоны доступности Azure подключены высокопроизводительной сетью с задержкой кругового пути менее 2 мс. Этот период задержки достаточно для большинства приложений.

Архитектура

На следующей схеме показана архитектура для этого подхода:

Компоненты

Компоненты этой архитектуры совпадают с базовой архитектурой. В следующем списке выделены только изменения базовой архитектуры. Документация по продуктам о службах Azure см. в разделе "Связанные ресурсы ".

• Azure Front Door выступает в качестве глобальной подсистемы балансировки нагрузки. Эта служба используется из-за ее возможностей для обеспечения более высокой доступности с более низкой задержкой, увеличением масштаба и кэшированием на краю.

Рабочий процесс

Эталонная архитектура реализует следующий рабочий процесс:

1. Пользователь отправляет запрос на имя узла HTTP приложения, например www.contoso.com. Azure DNS разрешает запрос на это имя узла в Azure Front Door.

2. Azure Front Door использует различные конфигурации балансировки нагрузки для пересылки входящих запросов в общедоступную конечную точку Шлюз приложений Azure в каждом регионе. Экземпляры Шлюз приложений настраиваются с тем же именем личного домена и именем сертификата TLS, что и Azure Front Door.

3. Шлюз приложений с интегрированным Брандмауэр веб-приложений Azure проверяет запрос. Брандмауэр веб-приложений разрешает входящие запросы только из указанного профиля Azure Front Door.

4. Шлюз приложений перенаправит разрешенный трафик в IP-адрес подсистемы балансировки нагрузки в подготовленном экземпляре Spring Apps.

5. Внутренняя подсистема балансировки нагрузки направляет трафик только из Шлюз приложений в внутренние службы. Эти службы размещаются в экземпляре Spring Apps в виртуальной сети в каждом регионе.

6. В рамках обработки запроса приложение взаимодействует с другими службами Azure в виртуальной сети. Примеры включают в себя приложение, взаимодействующее с Azure Key Vault для секретов и базы данных для хранения состояния.

Глобальное распределение

Если вы разрабатываете высокий уровень доступности, эту архитектуру можно настроить в активно-активном, активном пассивном режиме с горячим резервным или пассивным с холодным режимом ожидания.

Выбор зависит от требований к доступности приложения. Эта архитектура использует активное развертывание в двух регионах, так как пример организации хочет иметь глобальное присутствие с высоким уровнем обслуживания (соглашение об уровне обслуживания). Если вы работаете критически важные приложения и хотите более высокую доступность, вам потребуется использовать более двух регионов.

Шаблон "активный — активный"

В активном режиме все регионы одновременно обрабатывают запросы. Самая большая проблема с активным и активным режимом заключается в сохранении синхронизации данных между регионами. Этот режим является дорогостоящим подходом, так как вы платите дважды за все компоненты.

Активный пассивный режим с горячим резервным режимом

В активном пассивном режиме с горячим резервным режимом дополнительный регион не получает никаких запросов от Azure Front Door, пока основной регион активен. Убедитесь, что данные приложения реплика из основного в дополнительный регион. Если в основном регионе произошел сбой, необходимо изменить роли внутренних баз данных и выполнить отработку отказа всего трафика через Azure Front Door в дополнительный регион.

В активном пассивном режиме отработка отказа займет некоторое время, что упрощает синхронизацию всех данных. Однако активный пассивный режим с горячим резервным режимом является столь дорогостоящим, как работа с активным и активным режимом.

Активный пассивный с холодным режимом ожидания

В активно-пассивном режиме с холодным резервным режимом основной регион имеет все ресурсы и обслуживает трафик. Дополнительный регион может иметь меньше компонентов или компонентов с меньшими вычислительными ресурсами. Выбор технологии зависит от допустимого времени простоя в соответствии с бизнес-требованиями. Степень настройки дополнительного региона также влияет на затраты. Убедитесь, что в дополнительном регионе присутствуют по крайней мере данные приложения.

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

Если вся настройка решения использует шаблоны, можно легко развернуть холодный резервный дополнительный регион, создав ресурсы по мере необходимости. Вы можете использовать шаблоны Terraform, Bicep или Azure Resource Manager (ARM) и автоматизировать настройку инфраструктуры в конвейере непрерывного интеграции или непрерывного развертывания (CI/CD). Чтобы убедиться, что шаблоны развертываются в чрезвычайных ситуациях, следует регулярно протестировать конфигурацию, повторно выполнив повторную настройку.

Шаблон меток развертывания рекомендуется, так как можно развернуть несколько независимых копий приложения или компонента из одного шаблона в нескольких регионах.

Сравнение режимов

В следующей таблице перечислены усилия, необходимые для синхронизации данных для каждого режима, и сравниваются затраты.

Маршрутизация между регионами

В этой эталонной архитектуре используются географические узлы (геодеса), где любой регион может обслуживать любой запрос.

Azure Front Door настроена с равной маршрутизацией между двумя регионами развертывания. Azure Front Door также предоставляет другие методы маршрутизации трафика в источник. Если вы хотите перенаправить клиентов к ближайшему источнику, маршрутизация на основе задержки имеет наибольшее значение. Если вы разрабатываете активно-пассивное решение, маршрутизация на основе приоритета более правильна.

В примере эталонной архитектуры используется правило балансировки нагрузки с равным весом между двумя регионами. Azure Front Door настроен с помощью:

• Личный домен и сертификат TLS с тем же именем, что и имя узла приложения, например www.contoso.com.

• Один источник для каждого региона, в котором развертывается приложение, где каждый источник является Шлюз приложений Azure экземпляром.

Макет группы ресурсов

Используйте группы ресурсов Azure для управления ресурсами, развернутыми в каждом регионе в виде одной коллекции. Рассмотрите возможность размещения основного региона, дополнительного региона и Azure Front Door в отдельные группы ресурсов, как показано на следующей схеме:

На схеме показана следующая конфигурация групп ресурсов:

• Azure Front Door развертывается в Application-shared группе ресурсов.
• Все ресурсы, размещенные в регионе Западной Европы (weu), развертываются в Application-weu группе ресурсов.
• Ресурсы, размещенные в регионе "Восточная часть США",eus размещаются в Application-eus группе ресурсов.
• Ресурсы, размещенные в восточном регионе Японии (jae), размещаются в Application-jae группе ресурсов.

Ресурсы в одной группе ресурсов используют один и тот же жизненный цикл и могут быть легко созданы и удалены вместе. Каждый регион имеет собственный набор ресурсов в выделенной группе ресурсов, которая соответствует соглашению об именовании на основе имени региона. Azure Front Door находится в собственной группе ресурсов, так как она должна существовать, даже если другие регионы добавляются или удаляются.

Настройка обратного прокси-сервера

Azure Front Door выполняет глобальную балансировку нагрузки между регионами. Этот обратный прокси-сервер помогает распределить трафик при развертывании рабочей нагрузки в нескольких регионах. В качестве альтернативы можно использовать Диспетчер трафика Azure. Диспетчер трафика — это подсистема балансировки нагрузки на основе DNS, которая балансирует нагрузку только на уровне домена.

Azure Front Door имеет интегрированные сети доставки содержимого (CDN), которые доставляют содержимое из глобальной пограничной сети Майкрософт с точками присутствия (PoPs) по всему миру.

Текущее решение использует два обратных прокси для обеспечения согласованности с базовой архитектурой. Azure Front Door — это глобальный маршрутизатор. Шлюз приложений выступает в качестве подсистемы балансировки нагрузки для каждого региона. В большинстве случаев эта настройка не требуется. При устранении следующих требований можно удалить Шлюз приложений.

• Так как azure Брандмауэр веб-приложений присоединена к Шлюз приложений, вместо этого необходимо подключить Брандмауэр веб-приложений к службе Azure Front Door.
• Необходимо убедиться, что входящие вызовы происходят только из экземпляра Azure Front Door. Вы можете добавить X-Azure-FDID header проверка и диапазоны IP-адресов Azure Front Door проверка в приложении Spring Cloud Gateway. Дополнительные сведения см. в статье Об использовании Azure Front Door в качестве обратного прокси-сервера с помощью Spring Cloud Gateway.

Сведения о различных сценариях обратного прокси-сервера, настройке и их безопасности см. в статье "Предоставление Azure Spring Apps через обратный прокси-сервер".

Серверная база данных

Для развертывания с несколькими регионами необходимо иметь стратегию реплика обработки данных. Когда приложение доступно в разных регионах, данные должны быть синхронизированы, чтобы пользователи не видели устаревшие данные.

Текущая архитектура использует базу данных MySQL для серверной базы данных, но эта конфигурация не касается синхронизации данных. При выборе технологии базы данных проверка, как лучше реплика и синхронизировать данные между регионами. Одним из вариантов является База данных SQL Azure, которая имеет активную функцию гео-реплика, которая предоставляет непрерывно синхронизированную и читаемую базу данных-получатель для базы данных-источника.

Эту функцию можно использовать в следующих сценариях:

• Если дополнительный регион является холодным резервным, который не получает активные запросы
• Отработка отказа при сбое основного региона
• Чтобы настроить базы данных-источник и получатель с приватным подключением к соответствующим регионам через пиринг между двумя регионами.

Другой подход — использовать Azure Cosmos DB. Эта служба может глобально распространять данные, прозрачно реплика реплика для всех регионов в учетной записи Azure Cosmos DB. Вы также можете настроить Azure Cosmos DB с несколькими регионами записи. Дополнительные сведения см . в шаблоне Geode.

Автоматизированное развертывание

Автоматизируйте развертывание инфраструктуры и развертывание кода приложения как можно больше.

Автоматизация развертываний инфраструктуры гарантирует, что инфраструктура настроена одинаково, что помогает избежать смещения конфигурации, например между регионами. Автоматизация инфраструктуры также может тестировать операции отработки отказа.

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

Производительность и масштабируемость   

Эта архитектура лучше подходит, чем базовая архитектура для удовлетворения требований приложения, так как она распределяет нагрузку по регионам. Если вы настраиваете Azure Front Door для маршрутизации запросов на основе задержки, пользователи получают лучшее время отклика, так как запросы направляются в ближайшие к ним регионы.

В зависимости от настройки базы данных может возникнуть дополнительная задержка при синхронизации данных между регионами. Эту задержку можно преодолеть с помощью Azure Cosmos DB с более расслабленным уровнем согласованности.

Эта эталонная архитектура имеет несколько компонентов, которые могут автомасштабирование на основе метрик:

• Azure Front Door может автомасштабирование на основе спроса. Вы можете использовать другие функции Azure Front Door, такие как ускорение трафика и кэширование, чтобы приблизить ресурсы к конечным пользователям.
• Шлюз приложений поддерживает автомасштабирование. Дополнительные сведения см. в разделе "Масштабирование" Шлюз приложений версии 2 и Брандмауэр веб-приложений версии 2.
• Azure Spring Apps также поддерживает автомасштабирование. Дополнительные сведения см. в разделе Настройка автомасштабирования для приложений.

Рекомендации по затратам

Это решение эффективно удвоит оценку затрат базовой архитектуры.

Основными драйверами затрат, связанными с решением для нескольких регионов, являются следующие:

• Базы данных-источник и вторичные базы данных должны использовать один и тот же уровень служб; В противном случае база данных-получатель может не соответствовать реплика изменениям.
• Значительный трафик между регионами увеличивает затраты. За сетевой трафик между регионами Azure взимается плата.

Чтобы управлять этими затратами, рассмотрите следующие рекомендации для реализации:

• Используйте масштабируемые версии ресурсов, таких как Azure Spring Apps и Шлюз приложений в резервном регионе, и масштабируйте ресурсы только в том случае, если резервный режим станет активным.
• Если бизнес-сценарии позволяют, создайте активную-пассивные настройки, чтобы сэкономить на затратах.
• Реализуйте настройку с несколькими зонами в одном регионе для обеспечения доступности и устойчивости бизнес-потребностей. Этот вариант может быть более экономичным, так как вы платите только за большинство ресурсов один раз.
• Выберите альтернативную настройку, которая использует только один обратный прокси-сервер, чтобы сэкономить на затратах. Помните, что необходимо применить дополнительную конфигурацию для обеспечения безопасности этой альтернативы.

Мы оценили стоимость служб в этой архитектуре с калькулятором цен Azure с помощью разумных значений по умолчанию для небольшого масштабируемого приложения. Эту оценку можно обновить на основе ожидаемых значений пропускной способности для приложения.

Другие вопросы

Рекомендации по проектированию архитектуры базовых показателей с несколькими зонами также применяются к решению с несколькими регионами, описанным в этой статье. Просмотрите следующие моменты в контексте архитектуры с несколькими регионами:

• Безопасность сети. Важно контролировать обмен данными через сеть. Это решение разрешает входящие вызовы только из Azure Front Door, где вызовы направляются в Шлюз приложений в каждом регионе. Из Шлюз приложений вызовы направляются в службу Azure Spring Apps внутреннего плана. Взаимодействие с Azure Spring Apps с поддержкой таких служб, как Key Vault, также контролируется с помощью частных конечных точек. Дополнительные сведения см. в разделе "Базовая архитектура: безопасность сети".

• Управление удостоверениями и доступом. Реализуйте более безопасный доступ с помощью управляемых удостоверений для подключения между различными компонентами. Примером является использование управляемого удостоверения Azure Spring Apps для подключения к Key Vault. Дополнительные сведения см. в разделе "Базовая архитектура: управление удостоверениями и доступом".

• Мониторинг. Вы можете добавить инструментирование и включить распределенную трассировку для сбора данных из приложения. Объедините этот источник данных с платформой диагностика для получения комплексной информации о приложении. Дополнительные сведения см. в разделе "Базовая архитектура: мониторинг".

• Управление секретами. Решение с несколькими регионами хранит секреты и сертификаты приложения в одном хранилище ключей. Дополнительные сведения см. в разделе "Базовая архитектура: управление секретами".

Развертывание сценария

Развертывание для этой эталонной архитектуры доступно в эталонной архитектуре Azure Spring Apps с несколькими регионами на GitHub. В развертывании используются шаблоны Terraform.

Чтобы развернуть архитектуру, выполните пошаговые инструкции.

Соавторы

Корпорация Майкрософт поддерживает это содержимое. Следующий участник разработал исходное содержимое.

Автор субъекта:

• Gitte Vermeiren | FastTrack для инженера Azure

Чтобы просмотреть неопубликованные профили LinkedIn, войдите в LinkedIn.

Следующие шаги

Чтобы интегрировать эту рабочую нагрузку с общими службами, управляемыми центральными командами в организации, разверните ее в целевой зоне приложения Azure.

Связанные ресурсы

Документация по службам и функциям Azure, используемым в этой архитектуре, см. в следующих статьях:

• Azure Spring Apps
• Azure Front Door
• Шлюз приложений Azure версии 2
• База данных Azure для MySQL
• Azure Key Vault
• Azure DNS
• Azure Брандмауэр веб-приложений
• Приватный канал Azure
• Управляемые удостоверения Microsoft Entra для ресурсов Azure

Для более глубокого понимания вариантов конфигурации, связанных с этой архитектурой, рекомендуется ознакомиться со следующими руководствами.

• Предоставление доступа к Azure Spring Apps через обратный прокси-сервер
• Высокодоступное сине-зеленое развертывание для приложений
• Сохранение исходного имени узла HTTP между обратным прокси-сервером и серверным веб-приложением

Эта архитектура разработана в соответствии с основами платформы Microsoft Azure Well-Architected Framework. Мы рекомендуем ознакомиться с принципами проектирования для каждого из них.