Высокодоступное веб-приложение с поддержкой нескольких регионов

Этот пример архитектуры основан на архитектуре примера веб-приложения Basic и расширяет его для отображения:

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

Архитектура

Скачайте файл Visio для этой архитектуры.

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

Этот рабочий процесс решает различные аспекты архитектуры и строится на основе базового веб-приложения.

• Основной и дополнительный регионы. Эта архитектура использует два региона для достижения более высокого уровня доступности. Приложение развертывается в каждом регионе. При обычной работе трафик направляется в основной регион. Если основной регион становится недоступным, трафик направляется в дополнительный.
• Front Door. Azure Front Door — это рекомендуемая подсистема балансировки нагрузки для реализации нескольких регионов. Он интегрируется с брандмауэром веб-приложения (WAF) для защиты от распространенных эксплойтов и использует собственные функции кэширования содержимого Front Door. В этой архитектуре Front Door настроена для маршрутизации приоритета , которая отправляет весь трафик в основной регион, если он не станет недоступным. Если основной регион становится недоступным, Front Door направляет весь трафик в дополнительный регион.
• Георепликация учетных записей хранения, База данных SQL и (или) Azure Cosmos DB.

Компоненты

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

• Идентификатор Microsoft Entra — это облачная служба управления удостоверениями и доступом, которая позволяет сотрудникам получать доступ к облачным приложениям, разработанным для вашей организации.
• Azure DNS — это служба размещения для доменов DNS, которая предоставляет разрешение имен с помощью инфраструктуры Microsoft Azure. Размещая домены в Azure, вы можете управлять своими записями DNS с помощью тех же учетных данных, API и инструментов и оплачивать использование, как и другие службы Azure. Чтобы использовать имя личного домена (например contoso.com), создайте записи DNS, сопоставляющие имя личного домена с IP-адресом. Дополнительные сведения см. в статье Сопоставление существующего настраиваемого DNS-имени с веб-приложениями Azure.
• Azure сеть доставки содержимого — это глобальное решение для доставки содержимого с высокой пропускной способностью путем кэширования его на стратегически размещенных физических узлах по всему миру.
• Azure Front Door — это подсистема балансировки нагрузки уровня 7. В этой архитектуре шлюз перенаправляет HTTP-запросы к внешнему веб-интерфейсу. Front Door также предоставляет брандмауэр веб-приложения (WAF), который защищает приложение от распространенных эксплойтов и уязвимостей. Front Door также используется для решения сеть доставки содержимого (CDN) в этой конструкции.
• приложение Azure Service — это полностью управляемая платформа для создания и развертывания облачных приложений. Он позволяет определить набор вычислительных ресурсов для запуска, развертывания веб-приложений и настройки слотов развертывания.
• Приложения-функции Azure можно использовать для выполнения фоновых задач. Функции вызываются триггером, таким как событие таймера или помещаемое в очередь сообщение. Для длительно выполняемых задач с отслеживанием состояния используйте устойчивые функций.
• служба хранилища Azure — это облачное решение для современных сценариев хранения данных, предлагающее высокодоступное, масштабируемое, устойчивое и безопасное хранилище для различных объектов данных в облаке.
• Кэш Redis Azure — это высокопроизводительная служба кэширования, которая предоставляет хранилище данных в памяти для ускорения извлечения данных на основе кэша Redis с открытым исходным кодом.
• База данных SQL Azure — это реляционная база данных как услуга в облаке. База данных SQL использует свою базу кода совместно с ядром СУБД Microsoft SQL Server.
• Azure Cosmos DB — это глобально распределенная, полностью управляемая, низкая задержка, многоуровневая база данных API для управления данными в большом масштабе.
• Поиск ИИ Azure можно использовать для добавления функций поиска, таких как предложения поиска, нечеткий поиск и поиск по языку. Служба "Поиск Azure" обычно используется в сочетании с другим хранилищем данных, особенно если первичное хранилище данных требует строгой согласованности. При использовании этого подхода храните достоверные данные в другом хранилище данных и используйте другой индекс поиска в службе "Поиск Azure". Служба "Поиск Azure" может также использоваться для консолидации одного индекса поиска из нескольких хранилищ данных.

Подробности сценария

Существует несколько общих подходов к достижению высокой доступности в разных регионах:

• Активный или пассивный с горячим резервным режимом: трафик переходит в один регион, а другой ожидает горячего ожидания. Горячий резервный режим означает, что Служба приложений в дополнительном регионе выделяется и всегда выполняется.

• Активный или пассивный с холодным резервным режимом: трафик переходит в один регион, а другой ожидает холодного ожидания. Холодный резервный режим означает, что Служба приложений в дополнительном регионе не выделяется до тех пор, пока не потребуется для отработки отказа. Этот подход экономичнее, однако при сбое для выхода в динамический режим требуется больше времени.

• Активный или активный: оба региона активны, а запросы распределяются между ними. Если один регион становится недоступным, он выходит из поворота.

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

Потенциальные варианты использования

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

• Разработка плана непрерывности бизнес-процессов и аварийного восстановления для бизнес-приложений.

• Развертывание критически важных приложений, работающих в Windows или Linux.

• Улучшение взаимодействия с пользователем путем сохранения доступности приложений.

Рекомендации

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

Региональные пары

Многие регионы Azure связаны с другим регионом в одном географическом регионе. В некоторых регионах нет парного региона. Дополнительные сведения о парах регионов см. в статье Непрерывность бизнес-процессов и аварийное восстановление в службах BizTalk: пары регионов Azure.

Если основной регион имеет пару, рассмотрите возможность использования парного региона в качестве дополнительного региона (например, восточная часть США 2 и центральная часть США). Преимущества:

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

Если у основного региона нет пары, рассмотрите следующие факторы при выборе дополнительного региона:

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

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

Группы ресурсов

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

Приложения службы приложений

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

Конфигурация Front Door

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

Проверка работоспособности. Front Door использует пробу HTTPS для мониторинга доступности каждой серверной части. Проба предоставляет Front Door тест на переход или сбой для отработки отказа в дополнительный регион. При этом отправляется запрос по указанному пути URL-адреса. Если в течение периода ожидания вернется ответ, отличный от ответа с кодом 200, проверка завершается со сбоем. Можно настроить частоту проверки работоспособности, количество выборок, необходимых для оценки, и количество успешных выборок, необходимых для того, чтобы источник был помечен как работоспособный. Если Front Door помечает источник как пониженный, он отработки отказа в другой источник. Дополнительные сведения см. в разделе "Пробы работоспособности".

Рекомендуется создать путь пробы работоспособности в источнике приложения, который сообщает о общей работоспособности приложения. Эта проба работоспособности должна проверять критические зависимости, такие как приложения Служба приложений, очередь хранилища и База данных SQL. В противном случае проба может сообщить о работоспособном источнике, когда критически важные части приложения фактически завершаются сбоем. С другой стороны, не используйте проверку работоспособности для проверки низкоприоритетных служб. Например, если служба электронной почты отключается, приложение может переключиться на другого поставщика или отправить сообщение электронной почты позже. Дополнительные сведения об этом шаблоне проектирования см. в разделе "Шаблон мониторинга конечных точек работоспособности".

Защита источников из Интернета является важной частью реализации общедоступного приложения. Ознакомьтесь с реализацией безопасного входящего трафика сети, чтобы узнать о рекомендуемых шаблонах проектирования и реализации Майкрософт для защиты связи входящего трафика приложения с Front Door.

CDN. Используйте собственные функции CDN Front Door для кэширования статического содержимого. Основным преимуществом CDN является возможность сократить задержку для пользователей, так как содержимое кэшируется на пограничном сервере, географически близком к пользователю. CDN позволяет сократить нагрузку на приложение, так как такой трафик не обрабатывается приложением. Front Door также предлагает динамическое ускорение сайта, что позволяет обеспечить более широкий общий пользовательский интерфейс для веб-приложения, чем будет доступен только при кэшировании статического содержимого.

База данных SQL

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

Azure Cosmos DB

Azure Cosmos DB поддерживает георепликацию между регионами в активно-активном шаблоне с несколькими регионами записи. Кроме того, можно назначить один регион как регион для записи, а остальные — как реплики только для чтения. При возникновении регионального сбоя можно выполнить отработку отказа, выбрав другой регион для записи. Пакет SDK клиента автоматически отправляет запросы на запись в текущий регион записи, поэтому вам не нужно обновлять конфигурацию клиента после отработки отказа. См. ведения о глобальном распределении данных с помощью Azure Cosmos DB.

Хранилище

Используйте геоизбыточное хранилище с доступом для чтения для службы хранилища Azure. С геоизбыточным хранилищем с доступом на чтение данные реплицируются в дополнительный регион. У вас есть доступ только для чтения к данным во вторичном регионе через отдельную конечную точку. Отработка отказа , инициированная пользователем, в дополнительный регион поддерживается для геореплицированных учетных записей хранения. Запуск отработки отказа учетной записи хранения автоматически обновляет записи DNS, чтобы сделать учетную запись вторичного хранения новой основной учетной записью хранения. Отработка отказа должна выполняться только при необходимости. Это требование определяется планом аварийного восстановления вашей организации, и следует учитывать последствия, как описано в разделе "Рекомендации".

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

В некоторых случаях репликация объектов для блочных BLOB-объектов будет достаточным решением для репликации рабочей нагрузки. Эта функция репликации позволяет копировать отдельные BLOB-объекты из основной учетной записи хранения в учетную запись хранения в дополнительном регионе. Преимущества этого подхода — это детальный контроль над реплицируемыми данными. Политику репликации можно определить для более детального управления типами блочных BLOB-объектов, которые реплицируются. Примеры определений политик включают в себя, но не ограничиваются:

• Реплицируются только блочные BLOB-объекты, добавленные после создания политики.
• Реплицируются только блочные BLOB-объекты, добавленные после заданной даты и времени.
• Реплицируются только блочные BLOB-объекты, соответствующие заданному префиксу.

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

Служебная шина Azure

Чтобы воспользоваться максимальной устойчивостью, предлагаемой для Служебная шина Azure, используйте уровень "Премиум" для пространств имен. Уровень "Премиум" использует зоны доступности, что делает пространства имен устойчивыми к сбоям центра обработки данных. Если существует широко распространенная катастрофа, влияющая на несколько центров обработки данных, функция геокатастирного восстановления, включенная в уровень "Премиум", может помочь вам восстановиться. Функция геозабойного восстановления обеспечивает непрерывную репликацию всей конфигурации пространства имен (очередей, разделов, подписок и фильтров) из основного пространства имен в дополнительное пространство имен при связывании. Он позволяет инициировать однократный переход отработки отказа с первичного на дополнительный в любое время. При перемещении для отработки отказа выбранное имя псевдонима для пространства имен будет назначено дополнительному пространству имен, после чего сопряжение будет разорвано. После инициации отработка отказа происходит почти мгновенно.

Поиск с использованием ИИ Azure

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

В поиске ИИ реплики являются копиями индекса. Наличие нескольких реплик позволяет службе "Поиск ИИ Azure" выполнять перезагрузки и обслуживание на одной реплике, а выполнение запросов продолжается на других репликах. Дополнительные сведения о добавлении реплик см. в разделе Добавление и уменьшение реплик и разделов.

Вы можете использовать Зоны доступности с поиском ИИ Azure, добавив две или более реплики в службу поиска. Каждая реплика будет помещаться в другую зону доступности в пределах региона.

Рекомендации по BCDR см . в документации по нескольким географическим регионам .

Кэш Azure для Redis

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

Рекомендации

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

Надежность

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

Azure Front Door

Azure Front Door автоматически выполняет отработку отказа, если основной регион становится недоступным. При отработки отказа Front Door существует период времени (обычно около 20–60 секунд), когда клиенты не могут добраться до приложения. Этот период зависит от следующих факторов:

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

Front Door — это точка возможного сбоя в системе. Если служба завершается ошибкой, клиенты не могут получить доступ к приложению во время простоя. Просмотрите соглашение об уровне обслуживания Front Door и определите, достаточно ли использовать только Front Door, чтобы обеспечить соответствие корпоративным требованиям к высокой доступности. Если это не так, рекомендуем добавить резервное решение для управления трафиком. Если в службе Front Door произошел сбой, измените записи CNAME в службе доменных имен, чтобы они указывали на резервную службу управления трафиком. (Этот шаг нужно выполнить вручную, приложение будет отключено, пока изменения DNS не распространятся.)

Уровень Azure Front Door уровня "Стандартный" и "Премиум" объединяет возможности Azure Front Door (классический), Azure CDN уровня "Стандартный" от Майкрософт (классической) и Azure WAF на одной платформе. Использование Azure Front Door уровня "Стандартный" или "Премиум" уменьшает точки сбоя и обеспечивает расширенный контроль, мониторинг и безопасность. Дополнительные сведения см. в разделе "Обзор уровня Azure Front Door".

База данных SQL

Цель точки восстановления (RPO) и оценочная цель времени восстановления (RTO) для База данных SQL описаны в обзоре непрерывности бизнес-процессов с База данных SQL Azure.

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

Azure Cosmos DB

Цель времени восстановления (RTO) для Azure Cosmos DB настраиваются с помощью используемых уровней согласованности, которые обеспечивают компромиссы между доступностью, устойчивостью данных и пропускной способностью. Azure Cosmos DB предоставляет минимальное значение RTO 0 для расслабленного уровня согласованности с несколькими узлами или RPO 0 для обеспечения строгой согласованности с одним главными узлами. Дополнительные сведения о уровнях согласованности Azure Cosmos DB см. в статье "Уровни согласованности" и "Устойчивость данных" в Azure Cosmos DB.

Хранилище

Хранилище RA-GRS обеспечивает устойчивое хранилище, но важно учитывать следующие факторы при выполнении отработки отказа:

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

• Запланируйте целевую цель восстановления (RTO) соответствующим образом: отработка отказа в дополнительный регион обычно занимает около одного часа, поэтому план аварийного восстановления должен учитывать эти сведения при расчете параметров RTO.

• Тщательно спланируйте отработку отказа: важно понимать, что при отработке отказа учетной записи хранения данные в исходной основной учетной записи теряются. Попытка вернуться к основному региону без тщательного планирования рискованно. После завершения отработки отказа новый основной объект в регионе отработки отказа будет настроен для локально избыточного хранилища (LRS). Необходимо вручную перенастроить его как геореплицированное хранилище, чтобы инициировать репликацию в основной регион, а затем предоставить достаточно времени, чтобы позволить учетным записям синхронизироваться.

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

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

Дополнительные сведения см. в разделе Что делать в случае сбоя службы хранилища Azure.

Сведения о предварительных требованиях и предупреждениях по репликации объектов см. в документации по репликации объектов при использовании репликации объектов для блочных BLOB-объектов.

Служебная шина Azure

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

Безопасность

Безопасность обеспечивает гарантии от преднамеренного нападения и злоупотребления ценными данными и системами. Дополнительные сведения см. в разделе "Общие сведения о компоненте безопасности".

Ограничить входящий трафик , чтобы приложение принимало трафик только из Front Door. Это гарантирует, что весь трафик проходит через WAF перед достижением приложения. Дополнительные сведения см. в статье Разделы справки блокировка доступа к серверной части только Azure Front Door?

Если вы создаете веб-сайт и веб-API в качестве отдельных приложений, веб-сайт не может выполнять вызовы AJAX на стороне клиента, если вы не включите CORS .

В службах приложений реализована встроенная поддержка CORS без необходимости написания кода приложения. Дополнительные сведения см. в статье Создание API RESTful Node.js и его развертывание в приложении API в Azure. Добавьте веб-сайт в список разрешенных источников для API-интерфейса.

шифрование База данных SQL Используйте прозрачное шифрование данных, если необходимо шифровать неактивные данные в базе данных. Эта функция выполняет шифрование и расшифровку всей базы данных в режиме реального времени (включая резервные копии и файлы журнала транзакций) и не требует изменений в приложении. Шифрование вызывает небольшую задержку, поэтому рекомендуется разбить данные. Они должны быть безопасными в собственной базе данных, и шифрование необходимо выполнять только для этой базы данных.

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

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

Оптимизация затрат

Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".

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

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

Приложения без отслеживания состояния , настроенные для автомасштабирования, являются более экономичными, чем приложения с отслеживанием состояния. Для приложения ASP.NET, использующего состояние сеанса, сохраните его в памяти с Кэш Azure для Redis. Дополнительные сведения см. в разделе ASP.NET Поставщик состояния сеанса для Кэш Azure для Redis. Другим вариантом является использование Azure Cosmos DB в качестве внутреннего хранилища состояний через поставщика состояний сеанса. См. статью "Использование Azure Cosmos DB в качестве ASP.NET состояния сеанса и поставщика кэширования".

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

Дополнительные сведения см. в разделе затрат в Microsoft Azure Well-Architected Framework.

Используйте калькулятор цен для оценки затрат. Эти рекомендации в этом разделе помогут сократить затраты.

Azure Front Door

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

Azure Cosmos DB

Существуют два фактора, определяющие цены На Azure Cosmos DB:

• Подготовленная пропускная способность или единицы запросов в секунду (ЕЗ/с).

  Существует два типа пропускной способности, которые можно подготовить в Azure Cosmos DB, стандартная и автомасштабирование. Стандартная пропускная способность выделяет ресурсы, необходимые для гарантии заданных единиц запросов в секунду. Для автомасштабирования вы подготавливаете максимальную пропускную способность, а Azure Cosmos DB мгновенно масштабируется вверх или вниз в зависимости от нагрузки с максимальной пропускной способностью автомасштабирования не менее 10 %. Плата за стандартную пропускную способность взимается за подготовленную почасовую пропускную способность. Плата за автомасштабирование взимается за максимальную пропускную способность, потребляемую почасовую.

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

См. сведения о затратах на платформу Microsoft Azure с продуманной архитектурой.

Оптимизация производительности

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

Приложение Службы приложений

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

База данных SQL

Увеличьте уровень масштабируемости базы данных SQL путем сегментирования базы данных. Сегментирование означает горизонтальное секционирование базы данных. Сегментирование позволяет горизонтально увеличить масштаб базы данных с помощью инструментов для работы с эластичными базами данных. Потенциальные преимущества сегментирования:

• повышение пропускной способности транзакций;
• быстрое выполнение запросов к подмножеству данных.

Azure Front Door

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

Поиск Azure

Служба "Поиск Azure" устраняет затраты на сложный поиск данных из первичного хранилища данных и может масштабироваться для обработки нагрузки. Дополнительные сведения см. в статье Масштабирование уровней ресурсов для рабочих нагрузок запросов и индексирования в Поиске Azure.

Эффективность работы

Операционное превосходство относится к операциям, которые развертывают приложение и продолжают работать в рабочей среде и являются расширением руководства по надежности платформы Well-Architected Framework. В этом руководстве представлен подробный обзор устойчивости архитектуры в платформе приложений, чтобы обеспечить доступность рабочих нагрузок и восстановление после сбоев в любом масштабе. Основной принцип этого подхода заключается в разработке инфраструктуры приложений для обеспечения высокой доступности, оптимальной для нескольких географических регионов, как показано в этом проекте.

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

• Подробное руководство по Azure Front Door — методы маршрутизации трафика

• Создание проб работоспособности, сообщающих о общей работоспособности приложения на основе шаблонов мониторинга конечных точек

• Включение групп автоматической отработки отказа SQL Azure

• Обеспечение непрерывности бизнес-процессов и аварийного восстановления с помощью парных регионов Azure

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

• Многорегионное N-уровневое приложение является аналогичным сценарием. В нем показано приложение уровня N, работающее в нескольких регионах Azure.

• Принципы проектирования приложений Azure