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