Базовое высокодоступное веб-приложение с высоким уровнем доступности

Эта базовая архитектура основана на архитектуре базовых веб-приложений и расширяет ее, чтобы предоставить подробные рекомендации по проектированию безопасного, избыточного между зонами и высокодоступного веб-приложения в Azure. Архитектура предоставляет общедоступную конечную точку через Шлюз приложений Azure с Брандмауэр веб-приложений. Он направляет запросы к службе приложение Azure через Приватный канал. Приложение Служба приложений использует интеграцию виртуальной сети и Приватный канал для безопасного взаимодействия со службами Azure PaaS, такими как Azure Key Vault и База данных SQL Azure.

Архитектура

Рис. 1. Базовая архитектура службы приложение Azure

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

Компоненты

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

• Шлюз приложений — это подсистема балансировки нагрузки уровня 7 (HTTP/S) и диспетчер веб-трафика. Он использует маршрутизацию на основе URL-адресов для распределения входящего трафика между зонами доступности и разгрузки шифрования для повышения производительности приложения.
• Брандмауэр веб-приложений (WAF) — это облачная служба, которая защищает веб-приложения от распространенных эксплойтов, таких как внедрение SQL и межсайтовые скрипты. WAF обеспечивает видимость трафика в веб-приложение и из нее, что позволяет отслеживать и защищать приложение.
• Azure Key Vault — это служба, которая безопасно хранит секреты, ключи шифрования и сертификаты и управляет ими. Она централизованно обеспечивает управление конфиденциальной информацией.
• Виртуальная сеть Azure — это служба, которая позволяет создавать изолированные и безопасные частные виртуальные сети в Azure. Для веб-приложения на Служба приложений требуется подсеть виртуальной сети для использования частных конечных точек для сетевого безопасного взаимодействия между ресурсами.
• Приватный канал позволяет клиентам получать доступ к службам платформы Azure как услуга (PaaS) непосредственно из частных виртуальных сетей без использования общедоступных IP-адресов.
• Azure DNS — это служба размещения для доменов DNS , которая предоставляет разрешение имен с помощью инфраструктуры Microsoft Azure. Частная зона DNS зонах предоставляют способ сопоставления полного доменного имени службы (FQDN) с IP-адресом частной конечной точки.

Сеть

Безопасность сети находится в основе базовой архитектуры Служба приложений (см. рис. 2). На высоком уровне сетевая архитектура гарантирует следующее:

1. Единая безопасная точка входа для трафика клиента
2. Сетевой трафик фильтруется
3. Данные при передаче шифруются с помощью TLS
4. Утечка данных сводится к минимуму путем сохранения трафика в Azure с помощью Приватный канал
5. Сетевые ресурсы логически группируются и изолированы друг от друга через сегментацию сети

Сетевые потоки

Рис. 2. Сетевая архитектура базового приложения службы приложение Azure

Ниже приведены описания входящего потока входящего трафика к экземпляру Служба приложений и потоку из Служба приложений в службы Azure.

Входящий поток

1. Пользователь выдает запрос на общедоступный IP-адрес Шлюз приложений.
2. Вычисляются правила WAF. Правила WAF положительно влияют на надежность системы путем защиты от различных атак, таких как межсайтовые скрипты (XSS) и внедрение SQL. Шлюз приложений Azure возвращает ошибку запрашивающей стороны, если правило WAF нарушается и обработка останавливается. Если правила WAF не нарушаются, Шлюз приложений направляет запрос в внутренний пул, который в данном случае является доменом Служба приложений по умолчанию.
3. Частная зона privatelink.azurewebsites.net DNS связана с виртуальной сетью. В зоне DNS есть запись A, которая сопоставляет домен по умолчанию Служба приложений с частным IP-адресом частной конечной точки Служба приложений. Связанная частная зона DNS позволяет Azure DNS разрешать домен по умолчанию ip-адресу частной конечной точки.
4. Запрос направляется в экземпляр Служба приложений через частную конечную точку.

поток служб PaaS azure Служба приложений

1. Служба приложений отправляет запрос на DNS-имя требуемой службы Azure. Запрос может быть в Azure Key Vault, чтобы получить секрет, служба хранилища Azure получить ZIP-файл публикации, База данных SQL Azure или любую другую службу Azure, которая поддерживает Приватный канал. Функция интеграции виртуальной сети Служба приложений направляет запрос через виртуальную сеть.
2. Как и шаг 3 входящего потока, связанная частная зона DNS содержит запись A, которая сопоставляет домен службы Azure с частным IP-адресом частной конечной точки. Опять же, эта связанная частная зона DNS позволяет Azure DNS разрешать домен в IP-адрес частной конечной точки службы.
3. Запрос направляется в службу через частную конечную точку.

Входящий трафик для Служба приложений

Шлюз приложений — это региональный ресурс, соответствующий требованиям этой базовой архитектуры. Шлюз приложений — это масштабируемая, региональная подсистема балансировки нагрузки уровня 7, которая поддерживает такие функции, как брандмауэр веб-приложения и разгрузка TLS. Рассмотрим следующие моменты при реализации Шлюз приложений для входящего трафика в службы приложение Azure.

• Разверните Шлюз приложений и настройте политику WAF с помощью набора правил, управляемого корпорацией Майкрософт. Используйте режим предотвращения для устранения веб-атак, которые могут привести к недоступности службы происхождения (Служба приложений в архитектуре).
• Реализуйте сквозное шифрование TLS.
• Используйте частные конечные точки для реализации входящего частного доступа к Служба приложений.
• Рекомендуется реализовать автомасштабирование для Шлюз приложений, чтобы легко адаптироваться к динамическим потокам трафика.
• Рекомендуется использовать минимальное число экземпляров масштабирования не менее трех и всегда использовать все зоны доступности, поддерживаемые регионом. Хотя Шлюз приложений развертывается в высокодоступном режиме даже для одного масштабируемого экземпляра, создание нового экземпляра при сбое может занять до семи минут. Развертывание нескольких экземпляров в Зоны доступности помогает обеспечить выполнение экземпляра во время создания нового экземпляра.
• Отключите доступ к общедоступной сети в Служба приложений, чтобы обеспечить сетевую изоляцию. В Bicep это достигается путем задания publicNetworkAccess: 'Disabled' в разделе свойств или siteConfig.

Поток из Служба приложений в службы Azure

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

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

В этой архитектуре База данных SQL Azure, служба хранилища Azure и Key Vault отключены общедоступные конечные точки. Брандмауэры служб Azure используются только для разрешения трафика из других авторизованных служб Azure. Необходимо настроить другие службы Azure с частными конечными точками, такими как Azure Cosmos DB и кэш Redis Azure. В этой архитектуре Azure Monitor не использует частную конечную точку, но она может.

Базовая архитектура реализует частную зону DNS для каждой службы. Частная зона DNS содержит запись A, которая сопоставляется с полным доменным именем службы и частным IP-адресом частной конечной точки. Зоны связаны с виртуальной сетью. Частная зона DNS группы зон гарантируют автоматическое создание и обновление записей DNS приватного канала.

При реализации интеграции виртуальной сети и частных конечных точек следует учитывать следующие моменты.

• Используйте руководство по настройке зоны DNS служб Azure для именования частных зон DNS.
• Настройте брандмауэры служб, чтобы обеспечить частное подключение учетной записи хранения, хранилища ключей, База данных SQL и других служб Azure.
  • Задайте правило доступа к сети учетной записи хранения по умолчанию, чтобы запретить весь трафик.
  • Включите Key Vault для Приватный канал.
  • Запрет доступа к общедоступной сети к SQL Azure.

Сегментация виртуальной сети и безопасность

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

При реализации сегментации и безопасности виртуальной сети следует учитывать следующие моменты.

• Включите защиту от атак DDoS для виртуальной сети с подсетью, которая является частью шлюза приложений с общедоступным IP-адресом.
• Добавьте группу безопасности сети в каждую подсеть, где это возможно. Следует использовать самые строгие правила, которые обеспечивают полную функциональность решения.
• Используйте группы безопасности приложений. Группы безопасности приложений позволяют группировать группы безопасности приложений, что упрощает создание правил для сложных сред.

Примером схемы виртуальной подсети может быть следующее:

Ссылка на Azure-Samples\app-service-baseline-implementation

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

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

Надёжность

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

Базовая архитектура Служба приложений сосредоточена на зональной избыточности для ключевых региональных служб. Зоны доступности физически разделяются в пределах региона. Они обеспечивают зональную избыточность для вспомогательных служб при развертывании двух или более экземпляров в вспомогательных регионах. При простое одной зоны другие зоны по-прежнему могут быть не затронуты.

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

Шлюз приложений

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

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

• Развертывание не менее трех экземпляров Служба приложений с поддержкой зоны доступности.
• Реализуйте конечные точки проверки работоспособности в приложениях и настройте функцию проверки работоспособности Служба приложений для перенаправления запросов из неработоспособных экземпляров. Дополнительные сведения о проверке работоспособности Служба приложений см. в статье "Мониторинг экземпляров Служба приложений с помощью проверки работоспособности". Дополнительные сведения о реализации конечных точек проверки работоспособности в приложениях ASP.NET см. в разделе "Проверка работоспособности" в ASP.NET Core.
• Перепроизбыточная емкость, чтобы иметь возможность обрабатывать сбои зоны.

База данных SQL

• Разверните базу данных SQL Azure "Общего назначения", "Премиум" или критически важный для бизнеса с включенной избыточностью зоны. Уровни "Общего назначения", "Премиум" и критически важный для бизнеса поддерживают избыточность зоны в базе данных SQL Azure.
• Настройте резервные копии базы данных SQL для использования хранилища, избыточного между зонами (ZRS) или геоизбыточного хранилища (GZRS).

Хранилище BLOB-объектов

• Хранилище, избыточное между зонами Azure (ZRS), реплицирует данные синхронно в трех зонах доступности в регионе. Создайте учетные записи хранения GZRS уровня "Стандартный" или "Стандартный" для обеспечения репликации данных в зонах доступности.
• Создайте отдельные учетные записи хранения для развертываний, веб-ресурсов и других данных, чтобы управлять и настраивать учетные записи отдельно.

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

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

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

Шлюз приложений

• Реализуйте автомасштабирование для Шлюз приложений масштабирования в соответствии с требованиями.
• Задайте максимальное число экземпляров, превышающее ожидаемое значение. Плата будет взиматься только за используемые единицы емкости.
• Задайте минимальное число экземпляров, которое может обрабатывать небольшие пики трафика. Вы можете использовать среднее использование единиц вычислений для вычисления минимального количества экземпляров.
• Следуйте инструкциям по размеру подсети Шлюз приложений.

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

• Используйте стандартные или более высокие планы с тремя или более рабочими экземплярами для обеспечения высокой доступности.
• Включите автомасштабирование , чтобы убедиться, что можно увеличить и уменьшить масштаб до удовлетворения спроса.
• Попробуйте открыть запрос в службу поддержки, чтобы увеличить максимальное число рабочих ролей до двух раз, если Служба приложений последовательно использует половину максимального числа экземпляров. Максимальное количество экземпляров по умолчанию составляет до 30 для плана "Премиум" Служба приложений и 10 для стандартного плана.
• Рассмотрите возможность развертывания нескольких меток приложения, когда Служба приложений начинает работать с верхними ограничениями.
• Выберите правильный план обслуживания приложение Azure, соответствующий вашим требованиям к рабочей нагрузке.
• Добавьте Azure CDN в службу приложение Azure для обслуживания статического содержимого.
• Рассмотрите Среда службы приложений, если шумные соседи обеспокоены.

SQL Server

Масштабирование ресурсов базы данных — это сложная тема за пределами этой архитектуры. При масштабировании базы данных рассмотрите следующие ресурсы.

• Динамическое масштабирование ресурсов базы данных с минимальным временем простоя
• Развертывание с помощью Базы данных SQL Azure
• Использование реплик только для чтения для разгрузки рабочих нагрузок запросов только для чтения

Другие рекомендации по масштабируемости

• Просмотрите ограничения и квоты подписки, чтобы обеспечить масштабирование служб по требованию.
• Рекомендуется кэширование для следующих типов данных для повышения производительности и масштабируемости:
  • полустатических данных транзакции;
  • ASP.NET Core.
  • выходных данных в формате HTML. Это может быть полезно в приложениях, которые отображают сложные выходные данные в формате HTML.

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

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

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

• Отключение локальных методов проверки подлинности для развертываний сайтов FTP и SCM
• Отключите удаленную отладку.
• Используйте последнюю версию TLS.
• Включите Microsoft Defender для Служба приложений.
• Используйте последние версии поддерживаемых платформ, языков программирования, протоколов и фреймворков.
• Рассмотрите Среда службы приложений, если требуется более высокий уровень изоляции или безопасный сетевой доступ.

Шифрование

Производственное веб-приложение должно шифровать данные при передаче с помощью HTTPS. Протокол HTTPS использует протокол TLS и использует открытые и закрытые ключи для шифрования. Необходимо сохранить сертификат (X.509) в Key Vault и разрешить Шлюз приложений получить закрытый ключ. Для неактивных данных некоторые службы автоматически шифруют данные, а другие позволяют настраивать.

Передаваемые данные

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

1. Пользователь отправляет HTTPS-запрос в веб-приложение.
2. HttpS-запрос достигает шлюза приложений.
3. Шлюз приложений использует сертификат (X.509) в Key Vault для создания безопасного tls-подключения с веб-браузером пользователя. Шлюз приложений расшифровывает HTTPS-запрос, чтобы брандмауэр веб-приложения смог проверить его.
4. Шлюз приложений создает подключение TLS с Служба приложений для повторного шифрования запроса пользователя. Служба приложений предоставляет встроенную поддержку HTTPS, поэтому вам не нужно добавлять сертификат в Служба приложений. Шлюз приложений отправляет зашифрованный трафик в Служба приложений. Служба приложений расшифровывает трафик, а веб-приложение обрабатывает запрос.

При настройке шифрования данных во время передачи данных рекомендуется учитывать следующие рекомендации.

• Создайте или отправьте сертификат в Key Vault. Для шифрования HTTPS требуется сертификат (X.509). Вам нужен сертификат из доверенного центра сертификации для личного домена.
• Сохраните закрытый ключ в сертификате в Key Vault.
• Следуйте указаниям, приведенным в статье "Предоставление разрешения приложениям для доступа к хранилищу ключей Azure" с помощью Azure RBAC и управляемых удостоверений для ресурсов Azure, чтобы предоставить Шлюз приложений доступ к закрытому ключу сертификата. Не используйте политики доступа Key Vault для предоставления доступа. Политики доступа позволяют предоставлять широкие разрешения не только определенным значениям.
• Включите сквозное шифрование. Служба приложений — это внутренний пул для шлюза приложений. При настройке параметра серверной части для внутреннего пула используйте протокол HTTPS через внутренний порт 443.

Неактивные данные

• Шифрование конфиденциальных данных в База данных SQL Azure с помощью прозрачного шифрования данных. Прозрачные данные шифруют всю базу данных, резервные копии и файлы журнала транзакций и не требуют изменений в веб-приложении.
• Свести к минимуму задержку шифрования базы данных. Чтобы свести к минимуму задержку шифрования, поместите данные, необходимые для собственной базы данных, и включите шифрование только для этой базы данных.
• Сведения о встроенной поддержке шифрования. служба хранилища Azure автоматически шифрует неактивных данных с помощью шифрования на стороне сервера (256-разрядная версия AES). Azure Monitor автоматически шифрует неактивных данных с помощью ключей, управляемых Корпорацией Майкрософт (MMKs).

Управление идентификацией и доступом

Базовый Служба приложений настраивает проверку подлинности и авторизацию для удостоверений пользователей (пользователей) и удостоверений рабочей нагрузки (ресурсов Azure) и реализует принцип наименьших привилегий.

Удостоверения пользователей

• Используйте интегрированный механизм проверки подлинности для Служба приложений ("EasyAuth"). EasyAuth упрощает процесс интеграции поставщиков удостоверений в веб-приложение. Он обрабатывает проверку подлинности за пределами веб-приложения, поэтому вам не нужно вносить существенные изменения кода.
• Настройте URL-адрес ответа для личного домена. Необходимо перенаправить веб-приложение в https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Замените <application-gateway-endpoint> общедоступный IP-адрес или имя личного домена, связанное с шлюзом приложений. Замените <provider> поставщиком проверки подлинности, который вы используете, например "aad" для идентификатора Microsoft Entra. Документацию Azure Front можно использовать для настройки этого потока с помощью Шлюз приложений или настройки Шлюз приложений.

Удостоверения рабочей нагрузки

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

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

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

Развертывание для базового приложения Служба приложений следует руководству по CI/CD для Azure веб-приложения с помощью Azure Pipelines. Помимо этого руководства, базовая архитектура Служба приложений учитывает, что приложение и учетная запись хранения развертывания защищены сетью. Архитектура запрещает общедоступный доступ к Служба приложений. Это означает, что вы не можете развернуть извне виртуальной сети. В базовом плане показано, как развернуть код приложения в виртуальной сети с помощью локальных агентов развертывания. В следующем руководстве по развертыванию основное внимание уделяется развертыванию кода приложения, а не развертыванию изменений инфраструктуры или базы данных.

Рис. 3. Развертывание приложений службы приложение Azure

Рабочий поток развертывания

1. В рамках конвейера выпуска конвейер отправляет запрос задания для локальных агентов в очереди заданий. Запрос задания предназначен для отправки артефакта сборки ZIP-файла публикации в учетную запись служба хранилища Azure.

2. Агент локального развертывания выбирает новый запрос задания с помощью опроса. Он скачивает задание и артефакт сборки.

3. Агент локального развертывания отправляет ZIP-файл в учетную запись хранения через частную конечную точку учетной записи хранения.

4. Конвейер продолжается, и управляемый агент выбирает последующее задание. Управляемый агент вызывает ИНТЕРФЕЙС командной строки для обновления WEBSITE_RUN_FROM_PACKAGE appSetting до имени нового ZIP-файла публикации для промежуточного слота.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. служба приложение Azure извлекает новый ZIP-файл публикации из хранилища через частную конечную точку учетной записи хранения. Промежуточный экземпляр перезапускается с новым пакетом, так как WEBSITE_RUN_FROM_PACKAGE задано другое имя файла.

6. Конвейер возобновляется и выполняет все тесты дыма или ожидает утверждения. Если тесты передаются или утверждены, конвейер переключает промежуточные и рабочие слоты.

Руководства по развертыванию

Ниже приведены основные рекомендации по развертыванию базовой архитектуры.

• Используйте запуск из пакета , чтобы избежать конфликтов развертывания. При запуске приложения непосредственно из пакета в службе приложение Azure файлы в пакете не копируются в каталог wwwroot. Вместо этого сам ZIP-пакет монтируется непосредственно в каталог wwwroot только для чтения. Это устраняет конфликты блокировки файлов между развертыванием и средой выполнения и гарантирует, что в любое время выполняются только полностью развернутые приложения.
• Включите номера версий в развернутые ZIP-файлы пакета. WEBSITE_RUN_FROM_PACKAGE Обновление appSetting до пакета развертывания с другим именем файла приводит к автоматическому сбору новой версии и перезапуску службы Служба приложений.
• Используйте слоты развертывания для развертывания отказоустойчивого кода.
• Рекомендуется использовать сочетание управляемых и локальных агентов.
  • Используйте локальные агенты для отправки ZIP-файла пакета в учетную запись хранения через частную конечную точку. Агент инициирует обмен данными с конвейером с помощью опроса , поэтому не требуется открывать сеть для входящего вызова.
  • Используйте управляемые агенты для других заданий в конвейере.
• Автоматизация развертываний инфраструктуры с помощью кода (IaC).
• Непрерывно проверяйте рабочую нагрузку, чтобы проверить производительность и устойчивость всего решения с помощью таких служб, как Нагрузочное тестирование Azure и Azure Chaos Studio.

Настройка

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

• Никогда не проверяйте секреты, такие как пароли или ключи доступа, в системе управления версиями.
• Используйте Azure Key Vault для хранения секретов.
• Используйте конфигурацию Служба приложений для конфигурации приложения. Если необходимо выполнить внешнюю настройку из конфигурации приложения или требовать поддержку флага компонентов, рассмотрите возможность использования Конфигурация приложений Azure.
• Используйте ссылки Key Vault в Служба приложений конфигурации для безопасного предоставления секретов в приложении.
• Создайте параметры приложения, которые соответствуют слоту и не переключятся, если вам нужны разные рабочие и промежуточные параметры. При переключении слотов развертывания по умолчанию заменяются и параметры приложения.
• Задайте переменные локальной среды для локальной разработки или преимущества функций платформы приложений. конфигурация Служба приложений предоставляет параметры приложения в виде переменных среды. Например, Visual Studio позволяет задать переменные среды в профилях запуска. Он также позволяет использовать параметры приложения и секреты пользователя для хранения параметров и секретов локального приложения.

Наблюдение

Мониторинг — это сбор и анализ данных из ИТ-систем. Цель мониторинга — это наблюдаемость на нескольких уровнях для отслеживания работоспособности и безопасности веб-приложения. Наблюдаемость — это ключевой аспект базовой архитектуры Служба приложений.

Чтобы отслеживать веб-приложение, необходимо собирать и анализировать метрики и журналы из кода приложения, инфраструктуры (среды выполнения) и платформы (ресурсы Azure). Дополнительные сведения см. в журнале действий Azure, журналах ресурсов Azure и журналах приложений.

Мониторинг платформы

Мониторинг платформы — это сбор данных из служб Azure в архитектуре. Рассмотрим следующее руководство по мониторингу платформы.

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

  Ресурс Azure	Описания метрик и журналов
  Шлюз приложений	Шлюз приложений описания метрик и журналов
  Брандмауэр веб-приложения	Метрики и описания журналов брандмауэра веб-приложения
  Служба приложений	Служба приложений описания метрик и журналов
  База данных SQL Azure	описание метрик и журналов База данных SQL Azure
  Cosmos DB	Описания метрик и журналов Azure Cosmos DB
  Key Vault	Описания метрик и журналов Key Vault
  Хранилище BLOB-объектов	Хранилище BLOB-объектов Azure описания метрик и журналов
  Application Insights	Описания метрик и журналов Application Insights
  Общедоступный IP-адрес	Метрики и описания общедоступных IP-адресов

• Общие сведения о затратах на сбор метрик и журналов. Как правило, чем больше метрик и журналов вы собираете, тем больше он стоит. Дополнительные сведения см. в разделе "Вычисления затрат Log Analytics" и параметры и цены на рабочую область Log Analytics.

• создавать оповещения; Необходимо создать оповещения для всех ресурсов Azure в архитектуре и настроить действия для устранения проблем. Выберите распространенные и рекомендуемые правила генерации оповещений, чтобы начать работу и изменить их по мере необходимости. Дополнительные сведения см. в разделе:

  • Обзор оповещений Azure Monitor
  • оповещения Шлюз приложений
  • оповещения Служба приложений
  • оповещения База данных SQL Azure
  • Оповещения хранилища BLOB-объектов
  • Оповещения хранилища ключей

Шлюз приложений

Шлюз приложений отслеживает работоспособность ресурсов в серверном пуле. Используйте журналы Шлюз приложений Access для сбора таких сведений, как метка времени, код ответа HTTP и путь URL-адреса. Дополнительные сведения см. в разделе Шлюз приложений пробы работоспособности по умолчанию и журналов работоспособности серверной части и журналов диагностики.

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

Служба приложений имеет встроенные и интегрированные средства мониторинга, которые необходимо включить для улучшения наблюдаемости. Если веб-приложение уже имеет функции телеметрии и мониторинга ("инструментирование в процессе"), оно должно продолжать работать над Служба приложений.

• Включите автоматическое инструментирование. Служба приложений имеет расширение инструментирования, которое можно включить без изменений кода. Вы получаете видимость мониторинга производительности приложений (APM). Дополнительные сведения см. в статье "Мониторинг производительности службы приложение Azure".
• Включите распределенную трассировку. Автоматическое инструментирование позволяет отслеживать распределенные облачные системы с помощью распределенной трассировки и профилировщика производительности.
• Используйте инструментирование на основе кода для пользовательской телеметрии. приложение Azure Insights также поддерживает инструментирование на основе кода для телеметрии пользовательских приложений. Добавьте пакет SDK Application Insights в код и используйте API Application Insights.
• Включите журналы Служба приложений. Платформа Служба приложений поддерживает четыре дополнительных журнала, которые следует включить для поддержки устранения неполадок. Эти журналы — это журналы приложений, журналы веб-сервера, подробные сообщения об ошибках и трассировка неудачных запросов.
• Используйте структурированное ведение журнала. Добавьте структурированную библиотеку ведения журнала в код приложения. Обновите код, чтобы использовать пары "ключ-значение" и включить журналы приложений в Служба приложений для хранения этих журналов в рабочей области Log Analytics.
• Включите проверку работоспособности Служба приложений. Проверка работоспособности перенаправляет запросы от неработоспособных экземпляров и заменяет неработоспособные экземпляры. План Служба приложений должен использовать два или более экземпляров для проверки работоспособности.

База данных

• Аналитика пользовательской базы данных. Для баз данных SQL Azure необходимо настроить SQL Insights в Azure Monitor. Database Insights использует динамические административные представления для предоставления данных, необходимых для мониторинга работоспособности, диагностики проблем и настройки производительности. Дополнительные сведения см. в статье "Мониторинг База данных SQL Azure с помощью Azure Monitor".
• Если архитектура включает Cosmos DB, вам не нужно включать или настраивать что-либо для использования аналитики Cosmos DB.

Система управления

Веб-приложения получают преимущества от Политика Azure путем применения решений по архитектуре и безопасности. Политика Azure может сделать его (1) невозможным для развертывания (запрета) или (2) простого обнаружения (аудита) смещения конфигурации от предпочтительного требуемого состояния. Это помогает перехватывать развертывания инфраструктуры как код (IaC) или портал Azure изменения, которые отклоняются от согласованной архитектуры. Все ресурсы должны размещаться в архитектуре в Политика Azure управлении. Используйте встроенные политики или инициативы политики, если это возможно для применения основных сетевых топологий, функций служб, безопасности и мониторинга, например:

• Для Службы приложений должен быть отключен доступ из общедоступной сети
• Служба приложений должна использовать интеграцию виртуальной сети
• Служба приложений следует использовать Приватный канал Azure для подключения к службам PaaS
• Служба приложений должны иметь локальные методы проверки подлинности, отключенные для развертываний сайтов FTP и SCM
• Служба приложений должна быть отключена удаленная отладка
• Приложения Службы приложений должны использовать последнюю версию TLS
• Необходимо включить Microsoft Defender для Службы приложений
• Для Шлюза приложений должен быть включен Брандмауэр веб-приложения (WAF)

Дополнительные встроенные политики для ключевых служб, таких как Шлюз приложений и сетевые компоненты, Служба приложений, Key Vault и мониторинг. Можно создать пользовательские политики или использовать политики сообщества (например, из целевых зон Azure), если встроенные политики не полностью охватывают ваши потребности. Предпочитайте встроенные политики, если они доступны.

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

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

• Руководство по Приватный канал в Виртуальная глобальная сеть
• Увеличение масштаба приложения в службе приложение Azure
• Перенос Служба приложений в поддержку зоны доступности
• Масштабирование Шлюз приложений версии 2 и WAF версии 2