Проектирование географически распределенной архитектуры
Azure — это глобальная система. Создав архитектуру, которая присутствует в нескольких регионах Azure, мы можем создать приложение, устойчивое к даже авариям на уровне региона.
Портал отслеживания поставок можно масштабировать, так как он создан с помощью ряда ресурсов Azure, которые могут масштабироваться. Он устойчив ко многим сбоям также и потому, что его компоненты могут иметь несколько резервных экземпляров. Тем не менее, совет директоров выражает обеспокоенность тем, что крупномасштабная катастрофа может привести к сбою, так как портал полностью расположен в регионе Azure Восточная часть США. Вы хотите предложить измененную архитектуру, которая может переключиться на резервный регион, если произойдет сбой в регионе East US.
Здесь мы узнаем, как настроить архитектуру приложения для поддержки географически распределенного приложения. Мы также видим, почему такая архитектура является выгодной для критически важных для бизнеса приложений.
Исходная архитектура веб-приложения
Давайте рассмотрим, как архитектура портала отслеживания и компоненты, используемые в решении. После понимания того, как мы используем все части, мы можем изучить, как поддерживать каждый из этих компонентов в сценариях геоизбыточности.
Дизайн портала отслеживания основан на эталонной архитектуре, показанной на следующей схеме.
Обратите внимание, как наше приложение использует одну группу ресурсов Azure. Эта группа ресурсов позволяет нам группировать и управлять всеми нашими ресурсами логически и упростить управление. Мы решили развернуть эту группу ресурсов в регионе "Восточная часть США". Несмотря на то, что группа ресурсов не ограничивает использование одного региона Azure для включенных ресурсов, мы решили использовать регион "Восточная часть США" для всех ресурсов, развернутых в нашем приложении.
В нашем приложении используются три категории ресурсов Azure. Давайте рассмотрим каждую категорию и посмотрим, какие ресурсы используются.
Сетевые компоненты
На портале отслеживания используются следующие сетевые службы.
| Служба | Описание |
|---|---|
| Azure DNS | Мы настроили Azure DNS для размещения записей DNS в Azure. Azure DNS позволяет управлять записями DNS с помощью учетных данных Azure на портале Azure. |
| шлюз приложений | Мы настроили подсистему балансировки нагрузки шлюза приложений для балансировки трафика между несколькими экземплярами веб-интерфейса. Эта служба локализована в одном регионе Azure. |
| Azure CDN (сеть доставки контента Azure) | Мы настроили Azure CDN, чтобы максимально увеличить доставку незащищенного статического содержимого, например графику для содержимого веб-сайта. Эта глобальная служба кэширует статическое содержимое в точках присутствия по всему миру. |
Компоненты приложения
Портал отслеживания использует следующие службы для поддержки требований к коду, кэшу и промежуточному хранилищу.
| Служба | Описание |
|---|---|
| Microsoft Entra ID | Пользователи получают доступ к порталу отслеживания с помощью учетных записей Microsoft Entra. Каталог и учетная запись автоматически реплицируются глобально. |
| службы приложений Azure | На портале отслеживания используются две службы приложений Azure. Первый запускает набор динамических веб-страниц, а второй — веб-API. |
| приложения функций Azure | Портал отслеживания использует приложения-функции Azure для выполнения всех фоновых задач. Некоторые из этих задач выполняются по регулярному расписанию, а другие задачи работают с сообщениями в очереди. |
| Очереди хранилища Azure | На портале отслеживания используются очереди службы хранилища Azure с приложениями-функциями Azure. Портал отслеживания помещает созданные сообщения в очередь, из которой специальные приложения (функции) обрабатывают эти сообщения. |
| кэш Redis | Портал отслеживания использует кэш Redis между интерфейсной службой приложений и системами хранения данных для повышения производительности запросов. |
| Блоб-хранилище Azure | Статическое содержимое, например графические и видеофайлы, хранятся как двоичные большие объекты (BLOB-объекты) в учетной записи хранения Azure и передаются через Azure CDN. |
| Поиск Azure | Мы включили поиск Azure на портале отслеживания. Поиск Azure позволяет нам сделать все доступные для поиска содержимое и предоставлять предложения по поиску и нечеткие результаты поиска нашим пользователям. |
Компоненты хранилища данных
Портал отслеживания использует следующие службы постоянного хранения.
| Служба | Описание |
|---|---|
| Базе данных SQL Azure | Мы храним реляционные данные, такие как заказы и информация о клиентах в базе данных SQL Azure. |
| Cosmos DB | Мы храним полуструктурированные данные, включая каталог продуктов в Cosmos DB. |
Проблемы с исходной архитектурой
Существующая архитектура портала отслеживания предназначена для обеспечения масштабируемости и доступности.
Например, если спрос высок, а ответы на веб-запросы пользователей медленны, можно добавить дополнительные экземпляры интерфейсного веб-приложения в службу приложений. Здесь шлюз приложений может направлять запросы к вновь созданным экземплярам.
Однако есть сценарии, в которых наш архитектурный дизайн сталкивается с проблемами, которые необходимо преодолеть, или даже может потерпеть неудачу. Давайте рассмотрим каждый сценарий, чтобы лучше понять влияние на портал отслеживания.
Региональные сбои
Некоторые важные события могут прервать весь регион Azure. Центры обработки данных Azure предназначены для обеспечения высокой устойчивости, но массовые погодные события, такие как ураган или наводнение, могут нарушить работу службы из региона.
Эти события являются необычными событиями, и многие компании считают, что они могут поддерживать этот риск. Однако следствие регионального сбоя, отключающего портал отслеживания, является таким высоким риском, что исполнительный отдел компании решил устранить риск.
Соглашения об уровне обслуживания
Большинство служб Azure предлагают соглашение об уровне обслуживания (SLA) или гарантию простоя. При разработке архитектуры приложения, состоящей из нескольких служб Azure, мы вычисляем общее соглашение об уровне обслуживания для приложения как составное из всех других служб обслуживания.
Вы вычисляете данный SLA, умножая SLA составляющих сервисов. Например, предположим, что наше приложение состоит из службы приложений Azure (99,95% SLA) и Microsoft Entra ID (99,9% SLA). Окончательное вычисленное соглашение об уровне обслуживания — 99,85%.
Если этого процента доступности работы приложения недостаточно, мы можем организовать переключение при сбое на другой регион.
Глобальные, региональные и настраиваемые компоненты
В нашей разработке некоторые компоненты по умолчанию являются глобальными и не уязвимы для регионального сбоя.
Некоторые компоненты ограничиваются одним регионом, например шлюз приложений. Необходимо выбрать альтернативную службу для этих типов компонентов.
Некоторые компоненты можно настроить для поддержки нескольких регионов. Например, можно использовать параметр Geo-Redundant хранилища (GRS) в учетной записи хранения Azure, в которой хранится статическое содержимое. GRS реплицирует объекты BLOB в другой регион.
В следующей таблице показано, какие компоненты являются глобальными, региональными и настраиваемыми.
| Компонент | Поддержка нескольких регионов | Комментарии |
|---|---|---|
| Azure DNS | Глобальный | Никаких изменений не требуется. |
| Шлюз приложений | Региональный | Каждый экземпляр шлюза приложений расположен в одном регионе. |
| Azure CDN | Глобальный | Изменения не необходимы, содержимое кэшируется глобально по умолчанию. |
| Microsoft Entra ID | Глобальный | Никаких изменений не требуется. |
| Служба приложений Azure | Региональный | Каждый экземпляр приложения расположен в одном регионе. |
| Приложения-функции Azure | Региональный | Каждый экземпляр приложения-функции расположен в одном регионе. |
| Очереди службы хранилища Azure | Конфигурируемый | Вы можете реплицировать учетную запись хранения Azure в несколько регионов. |
| Кэш Azure Redis | Региональный | Каждый экземпляр кэша расположен в одном регионе. |
| Хранилище BLOB-объектов Azure | Конфигурируемый | Вы можете реплицировать учетную запись хранения Azure в несколько регионов. |
| Поиск Azure | Региональный | Каждый экземпляр службы поиска расположен в одном регионе. |
| База данных SQL Azure | Конфигурируемый | Георепликация позволяет синхронизировать данные с несколькими регионами. |
| Azure Cosmos DB | Конфигурируемый | Георепликация позволяет синхронизировать данные с несколькими регионами. |
Предлагаемая распределенная архитектура
После некоторого исследования вы предлагаете архитектуру, как показано на следующей схеме.
В этом проекте существует активный регион (восточная часть США) и резервный регион (западная часть США). Регион Восток США обрабатывает все запросы от компонентов в обычных обстоятельствах. Если авария приводит к сбою в регионе, приложение переключается на регион "Запад США".
Давайте рассмотрим, на высоком уровне, как вы изменили исходную архитектуру. Мы подробно рассмотрим эти изменения в последующих уроках.
Сети
Azure DNS и Azure CDN по умолчанию являются глобальными системами и уже устойчивы к региональным сбоям. Мы оставим их на месте.
При создании шлюза приложений Azure мы назначаем службу одному региону. Мы удаляем эту уязвимость, заменив эту службу Azure Front Door. Front Door может опрашивать несколько служб приложений и обрабатывать переключение службы приложений из региона "Восток США" в регион "Запад США".
Службы приложений
Идентификатор Microsoft Entra является глобальной системой и не нуждается в изменении.
Учетные записи хранения Azure можно настроить для репликации содержимого в несколько регионов. Для изменения конфигурации мы используем один из вариантов геоизбыточного хранилища.
Другие компоненты, включая службу приложений, приложения-функции, кэш Redis и поиск Azure, являются региональными. Мы создаём дублирующие экземпляры этих компонентов в регионе Запад США в нашей новой архитектуре. В этом дизайне новый регион может взять на себя функции при сбое.
Хранилище данных
База данных SQL Azure и Azure Cosmos DB поддерживают георепликацию данных в другие регионы. Мы настраиваем эти службы для репликации данных восточной части США в эквивалентные службы в западной части США.
Региональные пары
Регион Azure — это область с одним географическим регионом, который содержит один или несколько центров обработки данных Azure. Все регионы связаны с другими регионами в одном географическом регионе. В этих парах обновления и плановое обслуживание выполняются только в одном регионе одновременно. Если возникает сбой, влияющий на несколько регионов, по крайней мере один регион в каждой паре определяется приоритетом для быстрого восстановления.
Рекомендуется разместить архитектуру двух регионов для приложения в двух регионах в региональной паре. Например, восточная часть США связывается с западной частью США. Наш предлагаемый дизайн использует восточную часть США для своего активного региона и западной части США для своего резервного региона.