Проектирование географически распределенной архитектуры
Azure — это глобальная система. Спроектировав архитектуру, охватывающую несколько регионов Azure, можно создать приложение, которое устойчиво к авариям даже в масштабе всего региона.
Ваш портал отслеживания отправлений является масштабируемым, так как он создан с использованием ряда масштабируемых ресурсов Azure. Он также устойчив к множеству сбоев, так как его компоненты могут иметь несколько экземпляров. Однако ваш совет директоров озабочен тем, что крупномасштабный сбой может привести к перерыву в работе, так как портал полностью находится в регионе Azure "Восточная часть США". Вы хотите предложить модифицированную архитектуру с возможностью отработки отказа в другой регион в случае сбоя в восточной части США.
Здесь мы узнаем, как настроить архитектуру приложения для поддержки географически распределенного приложения. Мы также видим, почему такая архитектура является выгодной для критически важных для бизнеса приложений.
Изначальная архитектура веб-приложения
Давайте посмотрим, как выглядит архитектура портала отслеживания и из каких компонентов она состоит. После того как мы поймем, как используется каждая часть, мы сможем изучить возможности ее поддержки в сценариях геоизбыточности.
Структура портала отслеживания основана на эталонной архитектуре, показанной на приведенной ниже схеме.
Обратите внимание на то, что приложение использует одну группу ресурсов Azure. Она позволяет логически объединить все ресурсы, что упрощает управление. Мы решили развернуть эту группу ресурсов в регионе "Восточная часть США". Хотя ресурсы, входящие в группу ресурсов, не обязательно должны находиться в одном регионе Azure, мы решили развернуть все ресурсы приложения в регионе "Восточная часть США".
В приложении используются три категории ресурсов Azure. Давайте рассмотрим каждую категорию и используемые ресурсы.
Сетевые компоненты
Портал отслеживания использует перечисленные ниже сетевые службы.
| Служба | Description |
|---|---|
| Azure DNS | Мы настроили Azure DNS для размещения записей DNS в Azure. Azure DNS позволяет управлять записями DNS на портале Azure с помощью учетных данных Azure. |
| Шлюз приложений | Мы настроили подсистему балансировки нагрузки Шлюза приложений для распределения трафика между несколькими экземплярами веб-интерфейса. Эта служба находится в одном регионе Azure. |
| Azure CDN | Мы настроили Azure CDN, чтобы повысить эффективность доставки незащищенного статического содержимого, например графики, для веб-сайта. Эта глобальная служба кэширует статическое содержимое в точках присутствия во всем мире. |
Компоненты приложения
Портал отслеживания использует перечисленные ниже службы для поддержки требований к выполнению кода, кэшированию и промежуточному хранению.
| Служба | Description |
|---|---|
| Microsoft Entra ID | Пользователи получают доступ к порталу отслеживания с помощью учетных записей Microsoft Entra. Каталог и учетные записи автоматически реплицируются глобально. |
| Служба приложений Azure | Портал отслеживания использует две службы приложений Azure. Первая служит для выполнения набора динамических веб-страниц, а вторая — для предоставления веб-API. |
| Приложения-функции Azure | Портал отслеживания использует приложения-функции Azure для выполнения всех фоновых задач. Некоторые из этих задач выполняются по расписанию, а другие обрабатывают сообщения в очереди. |
| Очереди службы хранилища Azure | На портале отслеживания используются очереди служба хранилища Azure с приложениями-функциями Azure. Создаваемые порталом сообщения помещаются в очередь, из которой они обрабатываются приложениями-функциями. |
| Кэш Redis | Портал отслеживания использует кэш Redis между интерфейсной службой приложений и системами хранения данных для повышения производительности запросов. |
| Хранилище BLOB-объектов Azure | Статическое содержимое, например файлы графики и видео, хранится в виде больших двоичных объектов (BLOB-объектов) в учетной записи хранения Azure и доставляется через Azure CDN. |
| Поиск Azure | Мы включили Поиск Azure на портале отслеживания. Эта служба позволяет сделать все содержимое доступным для поиска и предоставлять пользователям варианты поиска и результаты нестрогого поиска. |
Компоненты хранилища данных
Портал отслеживания использует перечисленные ниже службы постоянного хранилища.
| Служба | Description |
|---|---|
| База данных SQL Azure | Реляционные данные, например сведения о заказах и клиентах, хранятся в базе данных SQL Azure. |
| Cosmos DB | Частично структурированные данные, включая каталог продуктов, хранятся в Cosmos DB. |
Проблемы исходной архитектуры
Существующая архитектура портала отслеживания разработана для обеспечения масштабируемости и доступности.
Например, когда нагрузка высока и ответы на веб-запросы пользователей происходят с задержкой, в Службе приложений можно добавить дополнительные экземпляры интерфейсного веб-приложения. После этого Шлюз приложений может маршрутизировать запросы к этим новым экземплярам.
Однако есть сценарии, в которых наш архитектурный дизайн имеет проблемы, чтобы преодолеть или даже сбой. Давайте рассмотрим каждый из них, чтобы лучше понять влияние на портал отслеживания.
Региональные сбои
Некоторые серьезные происшествия могут нарушить работу всего региона Azure. Центры обработки данных Azure рассчитаны на высокую устойчивость, но масштабное стихийное бедствие, например ураган или потоп, может вызвать перебои в обслуживании.
Такие события происходят нечасто, и многие компании считают их риск приемлемым. Однако последствия отключения портала отслеживания из-за регионального сбоя настолько велики, что руководство компании решило устранить этот риск.
Соглашения об уровне обслуживания
Для большинства служб Azure предлагается Соглашение об уровне обслуживания или гарантированное время доступности. При проектировании архитектуры приложения, состоящей из нескольких служб Azure, общее соглашение об уровне обслуживания составляется из соглашений отдельных служб.
Чтобы определить итоговое соглашение об уровне обслуживания, необходимо перемножить соглашения служб, составляющих приложение. Например, предположим, что наше приложение состоит из службы приложение Azure (99,95 % соглашения об уровне обслуживания) и идентификатора Microsoft Entra (99,9 % соглашения об уровне обслуживания). Итоговое время доступности будет составлять 99,85 %.
Если этого значения недостаточно для приложения, можно организовать отработку отказа в другой регион.
Глобальные, региональные и настраиваемые компоненты
В нашем проекте некоторые компоненты являются глобальными по умолчанию и не подвержены региональным сбоям.
Другие компоненты, например Шлюз приложений, ограничены одним регионом. Необходимо выбрать альтернативную службу для этих типов компонентов.
Некоторые компоненты можно настроить для поддержки нескольких регионов. Например, для учетной записи хранения Azure, в которой хранится статическое содержимое, можно использовать геоизбыточное хранилище (GRS). GRS реплицирует большие двоичные объекты в другой регион.
В приведенной ниже таблице ниже перечислены глобальные, региональные и настраиваемые компоненты.
| Компонент | Поддержка нескольких регионов | Комментарии |
|---|---|---|
| Azure DNS | Глобальный | Изменения не требуются. |
| Шлюз приложений | Региональный | Каждый экземпляр Шлюза приложений находится в одном регионе. |
| Azure CDN | Глобальный | Изменения не необходимы, содержимое кэшируется глобально по умолчанию. |
| Microsoft Entra ID | Глобальный | Изменения не требуются. |
| Служба приложений Azure | Региональный | Каждый экземпляр приложения находится в одном регионе. |
| Приложения-функции Azure | Региональный | Каждый экземпляр приложения-функции находится в одном регионе. |
| Очереди службы хранилища Azure | Конфигурируемый | Вы можете реплика включить учетную запись служба хранилища Azure в несколько регионов. |
| Кэш Redis для Azure | Региональный | Каждый экземпляр кэша находится в одном регионе. |
| Хранилище 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 поддерживают георепликацию данных в другие регионы. Мы настраиваем эти службы на реплика te east US data to эквивалентные службы в западной части США.
Пары регионов
Регион Azure — это область в пределах одной географической территории, содержащая один или несколько центров обработки данных Azure. Каждый регион образует пару с другим регионом в пределах одной географической территории. Обновление и плановое обслуживание выполняется одновременно только в одном регионе из пары. Если сбой затрагивает несколько регионов, по крайней мере один регион в каждой паре будет приоритетным для восстановления.
Если архитектура охватывает два региона, желательно, чтобы это были регионы, составляющие пару. Примером может служить пара регионов "Восточная часть США" и "Западная часть США". В предлагаемом проекте активным регионом является восточная часть США, а резервным — западная часть США.