Проектирование географически распределенной архитектуры приложения
Если сетевые компоненты маршрутизируют запросы в несколько регионов для снижения последствий регионального сбоя, необходимо спроектировать службы приложений, которые смогут отвечать на эти запросы как в основном, так и в резервном регионах.
Напомним, что ранее мы планируем настроить Azure Front Door с приоритетом внутреннего назначения. Мы назначаем регион "Восточная часть США" в качестве основного региона и западного региона США в качестве резервного региона. При возникновении регионального сбоя запросы направляются в Служба приложений в неуправляемом регионе. В каждом регионе необходимо настроить ресурсы для поддержки отработки отказа доступа пользователей, реплицированного хранилища и кода приложения.
Здесь мы рассмотрим службы приложений в нашем решении и определяем необходимость их изменения в архитектуре с несколькими регионами. В частности, мы рассмотрим Active Directory, статическое хранилище содержимого, веб-приложения, веб-API, очереди, функции Azure и кэши данных.
Microsoft Entra ID
На нашем портале отслеживания отправлений пользователи могут отслеживать доставку своих покупок, вводя номера для отслеживания. Однако обычные пользователи могут зарегистрироваться, чтобы получить доступ к дополнительным функциям, таким как сведения о скорости доставки и другие статистические данные. Мы разработали портал отслеживания для хранения учетных записей пользователей в идентификаторе Microsoft Entra.
Идентификатор Microsoft Entra разработан как глобальная система по умолчанию. Поэтому она устойчива к региональным сбоям, и изменять этот компонент системы не нужно.
Хранилище BLOB-объектов Azure
Статическое содержимое, например изображения и видео, хранится в учетных записях хранения Azure в виде больших двоичных объектов (BLOB) и доставляется пользователям через Azure CDN.
В изначальной архитектуре учетная запись хранения находится в одном регионе, так как мы решили использовать локально избыточное хранилище (LRS). С помощью LRS данные реплицируются только в пределах одного центра обработки данных. Поэтому в такой конфигурации учетная запись хранения становится недоступна в случае регионального сбоя. Любое статическое содержимое, уже кэшированное CDN, остается доступным для пользователей.
То же самое верно и в отношении хранилища, избыточного между зонами (ZRS). Несмотря на то, что в этой конфигурации данные реплицируются в разные центры обработки данных, все эти центры находятся в одном регионе. Региональный сбой также влияет на учетную запись хранения в этой конфигурации.
В нашем проекте мы активно используем CDN для кэширования статического содержимого. Существует вероятность того, что во время сбоя пользователь может запросить статический файл, которого еще нет в кэше CDN. В результате изображение или видео не удастся отобразить.
Возможности такого события можно избежать, выбрав геоизбыточное хранилище для репликации учетной записи хранения в несколько регионов. Кроме того, доступен параметр репликации только для чтения, предотвращающий добавление статического содержимого во время регионального сбоя.
На выбор доступно два варианта геоизбыточности: геоизбыточное хранилище с доступом на чтение (RA-GRS) и хранилище, геоизбыточное между зонами, с доступом на чтение (RA-GZRS). Выбор, который мы делаем, зависит от нашего бюджета и процента времени, которое нам нужно.
Служба приложений Azure и приложения-функции Azure
Портал отслеживания отправлений реализует две Службы приложений Azure. Первый Служба приложений размещает веб-приложение, реализующее пользовательский веб-интерфейс, а второй — веб-API, используемый мобильными приложениями для отслеживания данных о доставке. Все фоновые задачи выполняются как приложения-функции Azure.
В изначальной архитектуре каждая Служба приложений Azure находится в одном регионе Azure. Мы создадим второй Служба приложений в дополнительном регионе (западная часть США) и развернем веб-проект там для поддержки новой архитектуры с несколькими регионами. Мы настраиваем режим маршрутизации приоритета Azure Front Door для отправки запросов в дополнительный регион, когда основной регион недоступен.
Чтобы отработка отказа происходила максимально гладко, веб-приложение не должно сохранять сведения о состоянии сеанса в памяти. Мы изменим наш веб-сайт, чтобы убедиться, что мы не в конечном итоге потеря данных. Например, если код сохраняет список отправлений пользователей в памяти, при отработке отказа этот список будет потерян.
Когда состояние сеанса не сохраняется, каждый веб-запрос обрабатывается независимо от других. Если отработка отказа происходит во время сеанса пользователя, она должна быть прозрачной для пользователя.
Мы внося аналогичные изменения в наши приложения-функции Azure. Мы создадим отдельный экземпляр функции Azure в дополнительном регионе и развернем в нем тот же пользовательский код, что и в основном регионе.
Важно!
При развертывании обновления для пользовательского кода в Службе приложений или службе приложений-функций не забудьте передать его во все экземпляры службы. Если вы хотите автоматизировать этот процесс, в Azure DevOps есть средства, которые могут помочь в этом.
Очереди службы хранилища Azure
В изначальной архитектуре с одним регионом мы использовали очередь в учетной записи хранения Azure для управления взаимодействием между Службой приложений и приложением-функцией. Когда веб-приложению или веб-API требуется выполнить фоновую задачу, они помещают в очередь сообщение со всеми необходимыми сведениями. Приложение-функция проверяет наличие новых сообщений в очереди и выполняет фоновую задачу, выполняя необходимые запросы к хранилищам данных.
Такое использование очереди позволяет организовать надлежащую обработку большого объема веб-запросов. При выполнении многих фоновых задач очередь может создаваться, но задачи не удаляются. Они остаются в очереди, пока не будут обработаны. При снижении нагрузки приложения-функции обращаются к очереди и уменьшают ее размер. Если спрос сохраняется, мы увеличиваем количество экземпляров приложения-функции.
Для версии портала отслеживания отправлений в нескольких регионах необходимо гарантировать, что при отработке отказа элементы в очереди не будут теряться. Наша очередь определена в службе хранилища Azure, и мы можем использовать один из вариантов избыточности для георепликации.
Помните, что мы не можем использовать параметр избыточности с доступом для чтения, так как наша очередь поддерживает операции чтения и записи. Служба приложений должна добавлять элементы в очередь, а приложение-функция должно удалять завершенные элементы из нее. Поэтому используйте геоизбыточное хранилище (GRS) или хранилище, геоизбыточное между зонами (GZRS).
Кэш Redis для Azure
Мы используем Кэш Azure для Redis, чтобы максимально повысить производительность хранилища данных. Redis кэширует все результаты запросов, полученные при запросе приложениями данных из базы данных. Любые дополнительные запросы для аналогичных данных не требуют запроса базы данных и извлекаются из кэша Redis.
Для архитектуры с несколькими регионами мы создадим экземпляр кэша Redis как в основных, так и в резервных регионах. Учтите, что при отработке отказа Кэш Redis в резервном регионе, скорее всего, будет пустым. Этот пустой кэш не приводит к ошибкам, но производительность может временно удалиться, так как данные заполняют новый кэш.