Перспектива Azure Well-Architected Framework в службе приложений Azure (веб-приложения)
Служба приложений Azure — это платформа как услуга (PaaS), которая предоставляет полностью управляемую среду размещения для создания, развертывания и масштабирования веб-приложений. В качестве решения PaaS служба приложений абстрагирует базовую инфраструктуру, что позволяет сосредоточиться на разработке приложений. Служба приложений (веб-приложение) запускает приложения в контексте плана службы приложений, который определяет ресурсы, операционную систему, регион и модель цен (SKU), используемую для размещения приложения.
В этой статье предполагается, что в качестве архитектора вы рассмотрели дерево решений вычислений и выбрали службу приложений в качестве вычислительных ресурсов для рабочей нагрузки. Рекомендации по архитектуре, представленные в этой статье, связаны с принципами столпов платформы Azure Well-Architected.
Важный
Как использовать это руководство
Каждый раздел содержит контрольный список проектирования выделение архитектурных рекомендаций и стратегий для службы приложений Azure. рекомендации предлагают конкретные указания для реализации этих стратегий.
Рекомендации не представляют исчерпывающий список всех конфигураций, доступных для функции веб-приложений Службы приложений Azure и их зависимостей. Вместо этого они перечисляют ключевые рекомендации, сопоставленные с перспективами проектирования. Используйте рекомендации для создания подтверждения концепции или оптимизации существующих сред.
Базовая архитектура, демонстрирующая основные рекомендации: базовая архитектура службы приложений.
область технологий
В этом обзоре рассматриваются взаимосвязанные решения для следующих ресурсов Azure:
- Планы службы приложений
- Веб-приложения
Другие предложения Azure связаны с службой приложений, такими как Функции Azure, Azure Logic Apps и среда службы приложений. Эти возможности выходят за рамки данной статьи. Среда App Service упоминается время от времени для пояснения функций или возможностей основных предложений службы приложений.
Надёжность
Цель компонента надежности заключается в обеспечении непрерывной функциональности путем создания достаточной устойчивости и возможности быстрого восстановления после сбоев.
Принципы проектирования надежности обеспечивают высокоуровневую стратегию проектирования, применяемую для отдельных компонентов, системных потоков и системы в целом.
Контрольный список дизайна
Начните стратегию проектирования на основе контрольного списка проверки проектирования для надежности. Определите, насколько это соответствует вашим бизнес-требованиям, принимая во внимание уровни и функции Службы приложений и ее зависимости. Расширьте стратегию, чтобы включить дополнительные подходы по мере необходимости.
Приоритет потоков пользователей: не все потоки одинаково важны. Определите критически важные пути в приложении и назначьте приоритеты каждому потоку, чтобы управлять решениями по проектированию. Проектирование потока пользователей может повлиять на уровни служб и количество экземпляров, которые вы выбираете для плана и конфигурации службы приложений.
Например, приложение может включать интерфейсные и внутренние уровни, которые взаимодействуют через брокер сообщений. Вы можете сегментировать уровни в нескольких веб-приложениях, чтобы обеспечить независимое масштабирование, управление жизненным циклом и обслуживание. Размещение большого приложения в одном плане может привести к проблемам с памятью или ЦП и повлиять на надежность.
Для оптимальной производительности на стороне пользовательского интерфейса может потребоваться больше экземпляров на фронтэнде. Однако серверная часть может не требовать того же количества экземпляров.
предвидеть потенциальные сбои: планирование стратегий устранения возможных сбоев. В следующей таблице показаны примеры анализа режима сбоя.
Неудача Смягчение Сбой базовых или абстрактных компонентов службы приложений Имейте избыточность компонентов в инстанциях и зависимостях. Мониторинг работоспособности экземпляров, производительности сети и производительности хранилища. Сбой внешних зависимостей Используйте такие шаблоны конструктора, как шаблон повторных попыток и шаблонразбиения цепи. Отслеживайте внешние зависимости и задайте соответствующие тайм-ауты. Сбой из-за перенаправления трафика в неработоспособные экземпляры Мониторинг работоспособности экземпляра. Учтите скорость отклика и избегайте отправки запросов в недоступные экземпляры. Дополнительные сведения см. в статье Анализ режима сбоя для приложений Azure.
создание резервирования: создание резервирования в приложении и вспомогательной инфраструктуре. Распределите экземпляры между зонами доступности, чтобы повысить отказоустойчивость. Трафик направляется в другие зоны, если одна из зон выходит из строя. Разверните приложение в нескольких регионах, чтобы убедиться, что ваше приложение остается доступным, даже если весь регион испытывает сбой.
Создайте аналогичные уровни избыточности в зависимых службах. Например, экземпляры приложений привязываются к объектному хранилищу. Рассмотрите возможность настройки связанной учетной записи хранилища с зонально-избыточным хранилищем (ZRS), если приложение использует зонально-избыточное развертывание.
использовать несколько экземпляров. Запуск приложения только на одном экземпляре является немедленной точкой сбоя. Выделите несколько экземпляров для вашего приложения для обеспечения высокой доступности. Если один экземпляр выйдет из строя, другие экземпляры по-прежнему могут обрабатывать входящие запросы. Помните, что код приложения должен иметь возможность обрабатывать несколько экземпляров без проблем синхронизации при чтении из источников данных или записи в нее.
Избыточность в сетевых компонентах. Например, используйте зонально-избыточные IP-адреса и балансировщики нагрузки.
Иметь надежную стратегию масштабирования: непредвиденная нагрузка на приложение может сделать его ненадежным. Рассмотрите правильный подход к масштабированию на основе характеристик рабочей нагрузки. Горизонтальное масштабирование (scaling out) позволяет добавлять дополнительные экземпляры для распределения нагрузки, а вертикальное масштабирование (scaling up) включает увеличение емкости существующего экземпляра (процессора, памяти). Остерегайтесь чрезмерной подготовки, так как добавление ненужных экземпляров увеличивает затраты без существенных преимуществ производительности.
Иногда можно увеличивать масштаб, чтобы справиться с нагрузкой. Однако если нагрузка продолжает увеличиваться, масштабируйте их до новых экземпляров. Предпочитайте автоматическое или автоматическое масштабирование по сравнению с подходами вручную. Всегда сохраняйте буфер дополнительной емкости во время операций масштабирования, чтобы предотвратить снижение производительности[Выбор параметра масштабирования службы приложений](Автоматическое масштабирование в Службе приложений Azure)
Уровень плана службы приложений , который вы выбираете, влияет на масштабирование с точки зрения количества экземпляров и единиц вычислений.
Убедитесь в правильной инициализации приложений, чтобы новые экземпляры быстро прогрелись и могут получать запросы.
По возможности старайтесь использовать приложения без отслеживания состояния. Надежное масштабирование состояния с новыми экземплярами может повысить сложность. Рассмотрим внешнее хранилище данных, которое можно масштабировать независимо, если необходимо сохранить состояние приложения. Хранение состояния сеанса в памяти может привести к потере состояния сеанса при возникновении проблемы с приложением или службой приложений. Она также ограничивает возможность распространения нагрузки по другим инстанциям.
Регулярно тестируйте правила автомасштабирования. Имитируйте сценарии загрузки, чтобы убедиться, что приложение масштабируется должным образом. Вы должны регистрировать события масштабирования, чтобы устранить проблемы, которые могут возникнуть и оптимизировать стратегию масштабирования с течением времени.
Служба приложений имеет ограничение на количество экземпляров в рамках плана, что может повлиять на возможность надежного масштабирования. Одна из стратегий — использовать идентичные метки развертывания, при этом каждый экземпляр плана службы приложений работает с собственной конечной точкой. Важно, чтобы все серверы подключались к внешнему балансировщику нагрузки для распределения трафика между ними. Используйте Шлюз приложений Azure для развертываний в одной зоне и Azure Front Door для развертывания с несколькими регионами. Этот подход идеально подходит для критически важных приложений, где надежность имеет решающее значение. Для получения дополнительной информации см. раздел Базовый уровень критически важных задач в службе приложений.
Планирование возможности восстановления. Избыточность имеет решающее значение для непрерывности бизнес-процессов. Переключитесь на другой экземпляр, если один из экземпляров становится недоступным. Изучите возможности автоматического восстановления в службе приложений, например автоматическое восстановление экземпляров.
Реализуйте шаблоны проектирования для обеспечения плавной деградации в случае временных сбоев, таких как проблемы с сетевым подключением, а также крупных событий, например, региональных сбоев. Рассмотрим следующие шаблоны проектирования:
Шаблон типа Bulkhead сегментирует ваше приложение на изолированные группы, чтобы предотвратить распространение сбоя на всю систему.
Шаблон выравнивания нагрузки Queue-Based ставит в очередь рабочие элементы, которые служат буфером для сглаживания пиков трафика.
Паттерн повторных попыток обрабатывает временные сбои из-за глюков в сети, разорванных подключений к базе данных или перегруженных услуг.
шаблон разбиения цепи запрещает приложению многократно пытаться выполнить операцию, которая, скорее всего, завершится ошибкой.
С помощью веб-заданий можно выполнять фоновые задачи в веб-приложении. Для надежного выполнения этих задач убедитесь, что приложение, на котором размещено задание, выполняется непрерывно по расписанию или на основе триггеров, управляемых событиями.
Дополнительные сведения см. в шаблонах надежности.
Проводить тестирование надежности. Проводите нагрузочное тестирование для оценки надежности и производительности приложения под нагрузкой. Планы тестирования должны включать сценарии, которые проверяют автоматические операции восстановления.
Используйте инъекцию ошибок, чтобы намеренно вводить сбои и проверить механизмы самовосстановления и самосохранения. Изучите библиотеку ошибок , предоставляемую Azure Chaos Studio.
Служба приложений накладывает ограничения ресурсов на размещенные приложения. План службы приложений определяет эти ограничения. Убедитесь, что тесты подтверждают, что приложение выполняется в пределах этих ограничений ресурсов. Дополнительные сведения см. в разделе ограничения подписки и службы Azure, квоты и ограничения.
использовать функцию проверки работоспособности для выявления неответственных работников: служба приложений имеет встроенные возможности, которые периодически проверяют определенный путь веб-приложения. Платформа проверяет этот путь, чтобы определить, работает ли приложение и отвечает на запросы. Если сайт масштабируется до нескольких экземпляров, служба приложений исключит любые неработоспособные экземпляры при обработке запросов, повышая общую доступность. Путь проверки состояния приложения должен опрашивать критически важные компоненты вашего приложения, такие как база данных, кэш или служба обмена сообщениями. Это гарантирует, что статус, возвращаемый маршрутом проверки состояния, является точным отражением общего состояния вашего приложения. Установите путь проверки состояния
Использовать функцию автоматического восстановления. Иногда приложение может столкнуться с непредвиденным поведением, которые можно решить простым перезапуском. Функции Автоисцеления позволяют определить "условие," которое активирует Автоисцеление, а также "действие," которое будет выполнено, когда условие выполнено. средства диагностики службы приложений и функции автоматического лечения
Отчет об оценке устойчивости службы приложений: Чтобы просмотреть рекомендации по лучшим практикам, ознакомьтесь с отчетом об оценке устойчивости.Отчет об оценке устойчивости службы приложений
Рекомендации
| Рекомендация | Выгода |
|---|---|
| (Служба приложений) Выберите уровень "Премиум" версии 3 плана службы приложений для рабочих нагрузок. Установите максимальное и минимальное количество работников в соответствии с планированием мощности. Для получения дополнительной информации см. обзор службы приложений. |
План службы приложений premium версии 3 предлагает расширенные функции масштабирования и гарантирует избыточность при возникновении сбоев. |
| (Служба приложений) активировать избыточность зоны. Рассмотрите возможность подготовки более трех экземпляров для повышения отказоустойчивости. Проверьте региональную поддержку избыточности зон, так как не все регионы предлагают эту функцию. |
Ваше приложение может противостоять сбоям в одной зоне, если вы распределите несколько экземпляров по различным зонам. Трафик автоматически перемещается на исправные экземпляры в других зонах и поддерживает надежность приложения, если одна зона недоступна. |
| (Веб-приложение) Рассмотрите возможность отключения функции маршрутизации запросов приложений (ARR). Сопоставление ARR создает липкие сеансы, которые перенаправляют пользователей на узел, обрабатывающий предыдущие запросы. | Входящие запросы равномерно распределяются по всем доступным узлам при отключении привязки ARR. Равномерно распределенные запросы предотвращают перегрузку трафика любого одного узла. Запросы можно легко перенаправлять на другие здоровые узлы, если узел недоступен. Избегайте привязки к сеансу, чтобы убедиться, что экземпляр службы приложений остается независимым от состояния. Служба приложений без отслеживания состояния снижает сложность и обеспечивает согласованное поведение между узлами. Удалите липкие сеансы, чтобы App Service могла добавлять или удалять экземпляры для горизонтального масштабирования. |
| (Веб-приложение) определите правила автоматического восстановления на основе количества запросов, медленных запросов, ограничений памяти и других индикаторов, которые являются частью основной метрики производительности. Рассмотрим эту конфигурацию как часть стратегии масштабирования. | Правила автоматического восстановления помогают приложению автоматически восстанавливаться после непредвиденных проблем. Настроенные правила активируют действия восстановления при нарушении пороговых значений. Автоматическое восстановление обеспечивает автоматическое упреждающее обслуживание. |
| (Веб-приложение) включить функцию проверки работоспособности и предоставить путь, который отвечает на запросы проверки работоспособности. | Медицинские осмотры могут выявлять проблемы на ранней стадии. Затем система может автоматически выполнять корректирующие действия при сбое запроса проверки работоспособности. Подсистема балансировки нагрузки перенаправляет трафик от неработоспособных экземпляров, направляя пользователей на здоровые узлы. |
Безопасность
Цель компонента "Безопасность" — обеспечить конфиденциальности, целостности и доступности гарантии рабочей нагрузки.
Принципы проектирования безопасности обеспечивают высокоуровневую стратегию проектирования для достижения этих целей, применяя подходы к техническому проектированию в контексте хостинга на платформе App Service.
Контрольный список для проектирования
Начните стратегию разработки на основе контрольного списка проверки проектирования для обеспечения безопасности и выявления уязвимостей и контроля для улучшения уровня безопасности. Расширьте стратегию, чтобы включить дополнительные подходы по мере необходимости.
просмотрите базовые показатели безопасности. Чтобы повысить уровень безопасности приложения, размещенного в плане службы приложений, просмотрите базовые показатели безопасности для службы приложений.
Использовать последнюю версию среды выполнения и библиотек. Тщательно протестируйте сборки приложения, прежде чем выполнять обновления, чтобы устранить проблемы рано и обеспечить плавное переход на новую версию. Служба приложений поддерживает политику поддержки среды выполнения языка для обновления существующих стеков и завершения поддержки стека.
Создание сегментации через границы изоляции для сдерживания нарушения: применение сегментации по удостоверению личности. Например, реализуйте управление доступом на основе ролей (RBAC) для назначения определенных разрешений на основе ролей. Следуйте принципу наименьших привилегий, чтобы ограничить права доступа только тем, что необходимо. Кроме того, создайте сегментацию на уровне сети. развертывание приложений службы App Service в виртуальную сеть Azure для изоляции и определения сетевых групп безопасности (NSG) для фильтрации трафика.
Планы службы приложений предлагают уровень среды службы приложений, обеспечивающий высокую степень изоляции. В среде службы приложений вы получаете выделенные вычислительные ресурсы и сети.
Применить контроль доступа к идентификаторам. Ограничить как входящий доступ к веб-приложению, так и исходящий доступ из веб-приложения к другим ресурсам. Эта конфигурация применяет контроль доступа к идентичностям и помогает поддерживать общую защиту рабочей нагрузки.
Используйте идентификатор Microsoft Entra для всех потребностей проверки подлинности и авторизации. Используйте встроенные роли, такие как участник веб-плана, участник веб-сайта, а также универсальный участник, читатель и владелец.
Применить элементы управления безопасностью сети. Интеграция службы приложений с виртуальной сетью для управления исходящим трафиком. Используйте частные конечные точки для контроля входящего трафика и ограничения доступа к службе приложений из виртуальной сети и отключения общедоступного доступа к Интернету. Защитить сеть, контролировать входящий и исходящий трафик
Разверните брандмауэр веб-приложения (WAF) для защиты от распространенных уязвимостей. Шлюз приложений и Azure Front Door интегрируют возможности WAF.
Настройте правила обратного прокси-сервера и параметры сети соответствующим образом, чтобы обеспечить требуемый уровень безопасности и контроля. Например, добавьте правила NSG в подсеть частной конечной точки, чтобы принимать трафик только из обратного прокси-сервера.
Исходящий трафик из приложения в другие службы PaaS должен выполняться через частные конечные точки. Рассмотрите возможность размещения компонента брандмауэра для ограничения исходящего трафика в общедоступный Интернет. Оба подхода предотвращают кражу данных.
Для всестороннего обзора см. сетевые возможности службы приложений.
Шифрование данных: защита передаваемых данных с помощью сквозного протокола TLS. Используйте ключи, управляемые клиентом, для полного шифрования неактивных данных. Дополнительные сведения см. в статье Шифрование неактивных данных с помощью ключей, управляемых клиентом,.
Не используйте устаревшие протоколы, такие как TLS 1.0 и 1.1. Убедитесь, что все веб-приложения используют только HTTPS и применяют TLS 1.2 или более поздней версии. Минимальная версия TLS по умолчанию — 1.2. Дополнительные сведения см. в обзоре TLS службы приложений .
Все экземпляры службы приложений имеют доменное имя по умолчанию. Используйте личный домен и защитите этот домен с помощью сертификатов.
сквозное шифрование TLS: сквозное шифрование TLS доступно в планах службы приложений уровня "Премиум". Эта функция шифрует трафик по всей транзакции, минимизируя риск перехвата трафика.
Уменьшение поверхности атаки: Удалите ненужные конфигурации по умолчанию. Например, отключите удаленную отладку, локальную проверку подлинности для сайтов диспетчера управления версиями (SCM) и обычную проверку подлинности. Отключите небезопасные протоколы, такие как ПРОТОКОЛ HTTP и протокол передачи файлов (FTP). Принудительное применение конфигураций с помощью политик Azure. Дополнительные сведения см. в политиках Azure.
Реализация ограничивающих политик общего доступа к ресурсам (CORS). Используйте ограничивающие политики CORS в веб-приложении, чтобы принимать только запросы из разрешенных доменов, заголовков и других критериев. Применяйте политики CORS с помощью встроенных определений политик Azure.
Использование управляемых удостоверений. Включение управляемых удостоверений для службы приложений для безопасного доступа к другим службам Azure без необходимости управлять учетными данными. Сведения об управляемых удостоверениях.
защищать секреты приложений: необходимо обрабатывать конфиденциальную информацию, например ключи API или маркеры проверки подлинности. Вместо жесткого написания этих секретов непосредственно в коде приложения или файлах конфигурации можно использовать ссылки Azure Key Vault в параметрах приложения. При запуске приложения служба приложений автоматически извлекает значения секретов из Key Vault с помощью управляемого удостоверения приложения.
Включить журналы ресурсов для приложения. Включите журналы ресурсов для приложения для создания комплексных следов действий, которые предоставляют ценные данные во время расследований, которые следуют инцидентам безопасности. Подробные инструкции см. в руководстве по мониторингу журналов .
При оценке угроз рассмотрите возможность ведения журнала в рамках процесса моделирования угроз.
Рекомендации
| Рекомендация | Выгода |
|---|---|
| (Веб-приложение) Назначить управляемые удостоверения веб-приложению. Чтобы поддерживать границы изоляции, не передавайте и не повторно используйте учетные записи в приложениях. Убедитесь, что вы безопасно подключаетесь к реестру контейнеров, если вы используете контейнеры для развертывания. |
Приложение извлекает секреты из Key Vault для проверки подлинности исходящего взаимодействия из приложения. Azure управляет удостоверением и не требует настройки или скрытия секретов. У вас есть отдельные идентификации для гранулярного управления. Различные идентичности упрощают отзыв, если одна из них скомпрометирована. |
| (Веб-приложение) Настройте настраиваемых доменов для приложений. Отключите HTTP и примите только HTTP-запросы. |
Пользовательские домены обеспечивают безопасную связь через ПРОТОКОЛ HTTPS с помощью протокола TLS, который обеспечивает защиту конфиденциальных данных и создает доверие пользователей. |
| (Веб-приложение) проверяет, является ли встроенной проверки подлинности службы приложений правильным механизмом проверки подлинности пользователей, обращаюющихся к приложению. Встроенная проверка подлинности службы приложений интегрируется с идентификатором Microsoft Entra. Эта функция обрабатывает валидацию токенов и управление идентификацией пользователей для нескольких поставщиков аутентификации и поддерживает OpenID Connect. С помощью этой функции у вас нет авторизации на детальном уровне, и у вас нет механизма проверки подлинности. | При использовании этой функции не требуется использовать библиотеки проверки подлинности в коде приложения, что снижает сложность. Пользователь уже проходит проверку подлинности, когда запрос достигает приложения. |
| (Веб-приложение) Настройте приложение для интеграции с виртуальной сетью . Используйте частные конечные точки для приложений App Service. Блокировать весь общедоступный трафик. Направьте загрузку образа контейнера через интеграцию виртуальной сети. Весь исходящий трафик из приложения передается через виртуальную сеть. |
Получите преимущества безопасности для использования виртуальной сети Azure. Например, приложение может безопасно получить доступ к ресурсам в сети. Добавьте частную конечную точку для защиты приложения. Частные конечные точки ограничивают прямой доступ к общедоступной сети и разрешают контролируемый доступ через обратный прокси-сервер. |
| (Веб-приложение) Для реализации укрепления: - Отключить базовую проверку подлинности, которая использует имя пользователя и пароль в пользу проверки подлинности на основе идентификатора Microsoft Entra. — отключите удаленную отладку, чтобы не открывались входящие порты. — включите политики CORS для ужесточения входящих запросов. — Отключите протоколы, такие как FTP. |
Мы не рекомендуем обычную проверку подлинности в качестве безопасного метода развертывания. Идентификатор Microsoft Entra использует проверку подлинности на основе маркеров OAuth 2.0, которая предлагает множество преимуществ и улучшений, которые устраняют ограничения, связанные с базовой проверкой подлинности. Политики ограничивают доступ к ресурсам приложения, разрешают только запросы из определенных доменов и безопасные запросы между регионами. |
| (Веб-приложение) Всегда используйте ссылки Key Vault в качестве параметров приложения. |
Секреты хранятся отдельно от конфигурации приложения. Параметры приложения шифруются при хранении. Служба приложений также управляет сменами секретов. |
| (Служба приложений) включитьMicrosoft Defender для облачной службы приложений. | Получите защиту в режиме реального времени для ресурсов, работающих в плане службы приложений. Защита от угроз и повышение общего уровня безопасности. |
| (Служба приложений) включить ведение журнала диагностики и добавить инструментирование в приложение. Журналы отправляются в учетные записи хранения Azure, Центры событий Azure и Log Analytics. Дополнительные сведения о типах журналов аудита см. в разделе Поддерживаемые типы журналов. | Ведение журнала записывает шаблоны доступа. Он записывает соответствующие события, которые предоставляют ценные сведения о взаимодействии пользователей с приложением или платформой. Эта информация имеет решающее значение для обеспечения подотчетности, соответствия требованиям и безопасности. |
Оптимизация затрат
Оптимизация затрат фокусируется на обнаружении шаблонов расходов, приоритете инвестиций в критически важные области и оптимизации в других в соответствии с бюджетом организации при выполнении бизнес-требований.
Принципы проектирования оптимизации затрат обеспечивают высокоуровневую стратегию проектирования для достижения этих целей и обеспечения компромиссов в техническом проектировании, связанном с веб-приложениями и средой, в которой они работают.
Контрольный список дизайна
Начните разработку стратегии на основе контрольного списка для оптимизации затрат для инвестиций. Тонко настройте дизайн, чтобы рабочая нагрузка соответствовала выделенному бюджету. Проект должен использовать правильные возможности Azure, отслеживать инвестиции и находить возможности для оптимизации с течением времени.
Оценить начальные затраты. В рамках упражнения по моделированию затрат используйте калькулятор цен Azure, чтобы оценить приблизительные затраты, связанные с различными уровнями на основе количества экземпляров, которые планируется запустить. Каждый уровень службы приложений предлагает различные варианты вычислений.
Непрерывно отслеживайте модель затрат для отслеживания расходов.
оценить скидки. Более высокие уровни включают выделенные вычислительные экземпляры. Вы можете применить скидку на резервирование, если рабочая нагрузка имеет прогнозируемый и согласованный шаблон использования. Убедитесь, что вы анализируете данные об использовании, чтобы определить тип резервирования, соответствующий рабочей нагрузке. Дополнительные сведения см. в разделе Экономия затрат на зарезервированные экземпляры службы приложений.
Понимание счетчиков использования: Плата Azure взимается по почасовой ставке, пропорционально секунде, в зависимости от тарифного плана службы приложений. Взимается плата за каждый экземпляр горизонтального масштабирования в вашем плане, в зависимости от времени, на которое выделяется экземпляр виртуальной машины. Обратите внимание на неиспользуемые вычислительные ресурсы, которые могут увеличить затраты в результате перемещений из-за неоптимального выбора номера SKU или плохо настроенной конфигурации масштабирования.
Дополнительные функции службы приложений, такие как регистрация личного домена и пользовательские сертификаты, могут добавить затраты. Другие ресурсы, такие как виртуальные сети, чтобы изолировать решение или хранилища ключей для защиты секретов рабочей нагрузки, которые интегрируются с ресурсами службы приложений, также могут добавлять затраты. Дополнительные сведения см. в модели выставления счетов служб приложений.
Рассмотрим компромисс между плотностью и изоляцией. Вы можете использовать планы службы приложений для размещения нескольких приложений на одном вычислительном ресурсе, что экономит затраты на общие среды. Дополнительные сведения см. в разделе Компромисс.
оценить влияние стратегии масштабирования назатрат: необходимо правильно разработать, проверить и настроить масштабирование при реализации автомасштабирования. Установите точные и минимальные ограничения для автомасштабирования.
Упреждающая инициализация приложения для надежного масштабирования. Например, не подождите, пока ЦП достигнет 95% использования. Вместо этого запустите масштабирование при примерно 65%, чтобы дать достаточно времени для выделения и инициализации новых экземпляров в процессе масштабирования. Однако эта стратегия может привести к неиспользуемой емкости.
Рекомендуется объединить и сбалансировать механизмы вертикального и горизонтального масштабирования. Например, приложение может сначала масштабироваться вертикально, а затем по мере необходимости масштабироваться горизонтально. Ознакомьтесь с высокими уровнями, которые предлагают большую емкость и эффективное использование ресурсов. В зависимости от шаблонов использования более высокие категории "Премиум" часто являются более экономичными, так как они более способны.
Оптимизировать затраты на эксплуатацию среды. Рассмотрите базовый или бесплатный уровень для развертывания предварительных сред. Эти уровни отличаются низкой производительностью и низкими затратами. Если вы используете уровень "Базовый" или "Бесплатный", используйте управление для принудительного применения уровня, ограничения количества экземпляров и центральных процессоров, ограничения масштабирования и сокращения хранения журналов.
реализация шаблонов проектирования. Эта стратегия уменьшает объем запросов, создаваемых рабочей нагрузкой. Рассмотрите возможность использования таких шаблонов, как шаблон "Backends for Frontends" и шаблон "Gateway Aggregation", которые могут свести к минимуму количество запросов и сократить затраты.
регулярно проверять затраты, связанные с данными,: длительные периоды хранения данных или дорогие уровни хранения могут привести к высоким затратам на хранение. Дополнительные расходы могут накапливаться из-за использования пропускной способности и длительного хранения данных ведения журнала.
Рекомендуется реализовать кэширование для минимизации затрат на передачу данных. Начните с кэширования локальной памяти, а затем изучите параметры распределенного кэширования, чтобы уменьшить количество запросов к серверной базе данных. Учитывайте затраты на трафик пропускной способности, связанные с обменом данными между регионами, если база данных находится в другом регионе.
Оптимизация затрат на развертывание. Воспользуйтесь преимуществами слотов развертывания для оптимизации затрат. Слот выполняется в той же вычислительной среде, что и рабочий экземпляр. Используйте их стратегически для таких сценариев, как сине-зеленые развертывания для переключения между слотами. Этот подход сокращает время простоя и обеспечивает плавные переходы.
Используйте слоты развертывания с осторожностью. Вы можете столкнуться с проблемами, такими как исключения или утечки памяти, которые могут повлиять как на существующие экземпляры, так и на новые экземпляры. Убедитесь, что вы тщательно тестируете изменения. Для получения руководства по эксплуатации см. Операционное превосходство.
Рекомендации
| Рекомендация | Выгода |
|---|---|
| (Служба приложений) выбрать бесплатные или базовые уровни для более низких сред. Мы рекомендуем использовать эти уровни для экспериментального использования. Удалите уровни, когда они больше не нужны. | Уровни "Бесплатный" и "Базовый" являются бюджетными по сравнению с более высокими уровнями. Они предоставляют экономичное решение для непроизводственных сред, которые не нуждаются в полных функциях и производительности планов premium. |
| (Служба приложений) Воспользуйтесь преимуществами скидок и изучите предпочтительную цену для: — нижние среды с планами разработки и тестирования под тегами и. - резервирования Azure и планов экономии Azure для выделенных вычислений, которые вы готовите на уровне "Премиум V3" и в среде службы приложений. Используйте зарезервированные экземпляры для стабильных рабочих нагрузок, имеющих прогнозируемые шаблоны использования. |
Планы разработки и тестирования предоставляют сниженные ставки для служб Azure, что делает их экономически эффективными для непроизводственных сред. Используйте зарезервированные экземпляры для предоплаты вычислительных ресурсов и получения значительных скидок. |
| (Веб-приложение) Мониторинг затрат, которые несут ресурсы службы приложений. Запустите средство анализа затрат на портале Azure. создание бюджетов и оповещений для уведомления заинтересованных лиц. |
Вы можете определить пики затрат, неэффективные или непредвиденные расходы на ранних этапах. Этот упреждающий подход помогает обеспечить бюджетные средства контроля, чтобы предотвратить перерасход. |
| (Служба приложений) Уменьшайте масштаб, когда спрос снижается. Чтобы масштабироваться, определите правила масштабирования, чтобы уменьшить количество экземпляров вAzure Monitor. | Предотвращение потерь и сокращение ненужных расходов. |
Операционное превосходство
Операционное совершенство в основном фокусируется на процессах разработки, наблюдаемости и управления выпусками.
Принципы проектирования операционного превосходства обеспечивают высокоуровневую стратегию разработки для достижения этих целей в отношении операционных требований рабочей нагрузки.
Контрольный список по проектированию
Начните разработку стратегии проектирования на основе контрольного списка для проверки разработки в рамках для определения процессов обозримости, тестирования и развертывания, относящихся к веб-приложениям.
Управление выпусками. Использование слотов развертывания для эффективного управления выпусками. Вы можете развернуть приложение в слоте, выполнить тестирование и проверить его функциональные возможности. После проверки вы можете легко переместить приложение в рабочую среду. Этот процесс не несет дополнительных затрат, так как слот выполняется в той же среде виртуальной машины, что и рабочий экземпляр.
Используйте подмену с предварительным просмотром (многофазная подмена). Переключение с предварительным просмотром позволяет протестировать приложение в промежуточных слотах с параметрами рабочей среды, а также разогреть приложение. После выполнения тестов и прогревания всех необходимых путей можно завершить переключение, а приложение начнет получать рабочий трафик без перезапуска.
запускать автоматизированные тесты. Прежде чем продвигать выпуск веб-приложения, тщательно протестируйте его производительность, функциональные возможности и интеграцию с другими компонентами. Используйте Azure Load Testing, которое интегрируется с Apache JMeter, популярным средством для тестирования производительности. Изучите автоматизированные средства для других типов тестирования, таких как Фантом для функционального тестирования.
Автоматизация развертываний. Использование конвейеров CI/CD с помощью Azure DevOps или GitHub Actions для автоматизации развертываний и уменьшения усилий вручную непрерывного развертывания в Службе приложений Azure.
Развертывание неизменяемых единиц. Реализация шаблона штампов развертывания для разделения службы приложений в неизменяемый штамп. Служба приложений поддерживает использование контейнеров, которые по сути неизменяемы. Рассмотрите возможность использования пользовательских контейнеров для веб-приложения App Service.
Каждый штамп представляет собой автономную единицу, которую можно быстро масштабировать вверх или вниз. Единицы, основанные на этом штампе, являются временными и не имеющими состояния. Проектирование без отслеживания состояния упрощает операции и обслуживание. Этот подход идеально подходит для критически важных приложений. Пример см. в разделе критически важные базовые показатели службы приложений.
Используйте технологию "инфраструктура как код" (IaC), такую как Bicep, чтобы создавать единицы с повторяемостью и согласованностью.
Поддерживайте безопасность производственных сред: Создайте отдельные планы службы приложений Azure для запуска производственных и предварительных сред. Не вносите изменения непосредственно в рабочую среду, чтобы обеспечить стабильность и надежность. Отдельные инстанции позволяют гибко разрабатывать и тестировать, прежде чем вносить изменения в продакшн.
Используйте низкие среды для изучения новых функций и конфигураций изолированным образом. Сохраняйте временные среды разработки и тестирования.
управление сертификатами. Для пользовательских доменов необходимо управлять сертификатами TLS.
Имеются процессы для приобретения, продления и проверки сертификатов. Если это возможно, выгрузите эти процессы в службу приложений. Если вы используете собственный сертификат, необходимо управлять его продлением. Выберите подход, который лучше всего соответствует вашим требованиям безопасности.
| Рекомендация | Выгода |
|---|---|
| (Веб-приложение) отслеживать работоспособность экземпляров и активировать пробы работоспособности экземпляров. Настройте конкретный путь для обработки запросов проверки работоспособности. |
Вы можете быстро обнаруживать проблемы и выполнять необходимые действия для поддержания доступности и производительности. |
| (Веб-приложение) Активировать журналы диагностики для приложения и экземпляра. Частое ведение журнала может замедлить производительность системы, добавить затраты на хранение и привести к риску, если у вас нет небезопасного доступа к журналам. Следуйте приведенным ниже рекомендациям. — Регистрируйте правильный объем информации. — задайте политики хранения. — ведите журнал авторизованного доступа и несанкционированных попыток доступа. — обрабатывает журналы как данные и применяет элементы управления защитой данных. |
Журналы диагностики предоставляют ценные сведения о поведении приложения. Отслеживайте шаблоны трафика и выявляйте аномалии. |
| (Веб-приложение) Воспользуйтесь преимуществами управляемых сертификатов службы приложений для разгрузки управления сертификацией в Azure. | Служба приложений автоматически обрабатывает такие процессы, как закупки сертификатов, проверка сертификатов, продление сертификата и импорт сертификатов из Key Vault. Кроме того, отправьте сертификат в Key Vault и авторизуйте поставщик ресурсов службы приложений для доступа к нему. |
| (Служба приложений) проверить изменения приложения в промежуточном слоте перед переключением на рабочий слот. | Избегайте простоя и ошибок. Быстро вернитесь к последнему известному хорошему состоянию, если вы обнаружите проблему после переключения. |
Эффективность производительности
Эффективность производительности заключается в поддержании пользовательского опыта даже при увеличении нагрузки путем управления мощностями. Стратегия включает масштабирование ресурсов, определение и оптимизацию потенциальных узких мест, а также оптимизацию для пиковой производительности.
Принципы проектирования производственной эффективности обеспечивают общую стратегию проектирования для достижения этих целевых показателей пропускной способности с учетом предполагаемой нагрузки.
Контрольный список для проектирования
Запустите стратегию разработки дизайна на основе контрольного списка проверки эффективности производительности для определения исходного уровня на основе ключевых показателей производительности для веб-приложений.
Определение и мониторинг показателей производительности. Задайте целевые показатели для приложения, такие как объем входящих запросов, время, которое приложение принимает для реагирования на запросы, ожидающие запросы и ошибки в HTTP-ответах. Рассмотрим ключевые показатели в рамках базовых показателей производительности рабочей нагрузки.
Сбор метрик службы приложений, которые составляют основу индикаторов производительности. Сбор журналов для получения аналитических сведений об использовании ресурсов и действиях. Используйте средства мониторинга производительности приложений (APM), такие как Application Insights, для сбора и анализа данных о производительности из приложения. Дополнительные сведения см. в справочнике по данным мониторинга службы приложений.
Включите инструментирование на уровне кода, трассировку транзакций и профилирование производительности.
Определение емкости: Имитация различных пользовательских сценариев для определения оптимальной емкости, необходимой для обработки ожидаемого трафика. Используйте нагрузочное тестирование, чтобы понять, как работает приложение под разными уровнями нагрузки.
Выберите нужный уровень. Используйте выделенные вычислительные ресурсы для рабочих нагрузок. Уровни Premium V3 предлагают более крупные SKU с увеличенным объемом памяти и центрального процессора, большим количеством экземпляров и дополнительными функциями, такими как зональная избыточность. Дополнительные сведения см. в ценовой категории "Premium V3 ".
Оптимизировать стратегию масштабирования. По возможности используйте автомасштабирование вместо того, чтобы вручную настроить количество экземпляров при изменении нагрузки приложения. При автомасштабировании служба приложений настраивает емкость сервера на основе предопределенных правил или триггеров. Убедитесь, что вы выполняете достаточное тестирование производительности и задаете правильные правила для правильных триггеров.
Если во время начальной установки вы определяете простоту, используйте параметр автомасштабирования, который не требует определения правил, и необходимо задать только ограничения.
Иметь доступные ресурсы, чтобы гарантировать оптимальную производительность. Выделите ресурсы соответствующим образом для поддержания целевых показателей производительности, таких как время отклика или пропускная способность. При необходимости рассмотрите возможность перемещений ресурсов.
При определении правил автомасштабирования следует учитывать время, необходимое для инициализации приложения. Учитывайте эти издержки при принятии всех решений по масштабированию.
Использование кэширования. Получение сведений из ресурса, который редко изменяется и доступ к которому обходится дорого, влияет на производительность. Сложные запросы, включая соединения и несколько подстановок, влияют на время выполнения. Выполните кэширование, чтобы свести к минимуму время обработки и задержку. Результаты запроса кэшируются, чтобы избежать повторяющихся обходов в базу данных или серверную часть и сократить время обработки для последующих запросов.
Дополнительные сведения об использовании локального и распределенного кэширования в рабочей нагрузке см. в Кэширование.
Просмотрите антипаттерны производительности. Чтобы убедиться, что веб-приложение работает и масштабируется в соответствии с вашими бизнес-требованиями, избегайте типичных антипаттернов. Ниже приведены некоторые антипаттерны, которые служба приложений исправляет.
Антипаттерн Описание занятый пользовательский интерфейс Ресурсоемкие задачи могут увеличить время отклика для запросов пользователей и вызвать высокую задержку.
Перенесите процессы, потребляющие значительные ресурсы, в отдельный бэкэнд. Используйте брокер сообщений для постановки в очередь ресурсоемких задач, которые серверная часть подхватывает для асинхронной обработки.без кэширования Обслуживайте запросы из промежуточного кэша перед серверной базой данных, чтобы уменьшить задержку. Шумный сосед Многоарендные системы совместно используют ресурсы между арендаторами. Активность одного клиента может негативно повлиять на использование системы другого клиента. Среда службы приложений предоставляет полностью изолированную и выделенную среду для запуска приложений.
Рекомендации
| Рекомендация | Выгода |
|---|---|
| (Служба приложений) Включить параметр AlwaysOn, если приложения совместно используют один план службы приложений. Приложения службы App Service автоматически выгружаются при простое, чтобы экономить ресурсы. Следующий запрос запускает холодный запуск, который может вызвать время ожидания запроса. | Приложение никогда не выгружается с включенной функцией Always On. |
| (Веб-приложения) рекомендуется использовать протокол HTTP/2 для приложений для повышения эффективности протокола. | Выберите HTTP/2 по протоколу HTTP/1.1, так как HTTP/2 полностью мультиплексирует подключения, повторно использует подключения для снижения затрат и сжимает заголовки, чтобы свести к минимуму передачу данных. |
Компромиссы
Если вы используете подходы в контрольных списках столпов, вам может потребоваться сделать компромиссы по проектированию. Ниже приведены некоторые примеры преимуществ и недостатков.
плотности и изоляции
Более высокая плотность: Размещать несколько приложений в одном плане службы приложений для оптимизации использования ресурсов. Все приложения совместно используют ресурсы, такие как ЦП и память, что позволяет сэкономить деньги и снизить операционную сложность. Этот подход также оптимизирует использование ресурсов. Приложения могут использовать неактивные ресурсы из другого приложения, если с течением времени шаблоны загрузки изменяются.
Кроме того, учитывайте недостатки, такие как состязание по ресурсам. Например, пики использования или нестабильности приложения могут повлиять на производительность других приложений. Инциденты в одном приложении также могут проникать в другие приложения в общей среде, что может повлиять на безопасность. Для критически важных приложений, требующих высокой доступности и производительности, изолированные среды, такие как среда службы приложений версии 3 (ASE) предоставляют выделенные ресурсы, но при более высокой стоимости. Рекомендуется использовать общие среды для некритических рабочих нагрузок и изолированных сред для критически важных приложений.
более высокий уровень изоляции: изоляция помогает избежать вмешательства. Эта стратегия применяется к безопасности, производительности и даже сегрегации сред разработки, тестирования и рабочей среды.
Среда службы приложений обеспечивает более эффективное управление безопасностью и защитой данных, так как каждое приложение может иметь собственные параметры безопасности. Ваша среда может содержать нарушения, так как изоляция ограничивает радиус взрыва. Минимизация конкуренции за ресурсы с точки зрения производительности. Изоляция позволяет независимо масштабироваться на основе конкретного спроса и планирования отдельных ресурсов.
В качестве недостатка этот подход является более дорогим и требует операционной строгости.
стратегия надежного масштабирования
Хорошо определенная стратегия масштабирования гарантирует, что приложение может обрабатывать различные нагрузки без ущерба для производительности. Однако есть компромиссы по затратам. Выполнение операций масштабирования занимает время. При выделении новых ресурсов приложение должно быть правильно инициализировано, прежде чем он сможет эффективно обрабатывать запросы. Вы можете избыточно выделить ресурсы (предварительно подготовленные экземпляры), чтобы обеспечить подстраховку. Без этой дополнительной емкости во время этапа инициализации может возникнуть задержка в обслуживании запросов, что влияет на взаимодействие с пользователем. Операции автомасштабирования могут запускаться достаточно рано, чтобы обеспечить правильную инициализацию ресурсов к моменту, когда клиенты начинают их использовать.
В качестве недостатка избыточные ресурсы стоят больше. Плата взимается в секунду для каждого экземпляра, включая предварительно подготовленные экземпляры. Более высокие уровни включают предварительно подготовленные экземпляры. Определите, стоят ли возможности с более дорогими уровнями стоит инвестиций.
построение избыточности
Избыточность обеспечивает устойчивость, но также несет затраты. Целевые показатели уровня обслуживания для рабочей нагрузки определяют допустимые пороги производительности. Это становится расточительным, если избыточность превышает требования SLO. Оцените, улучшает ли избыточная избыточность целевые показатели обслуживания (SLOs) или добавляет ненужную сложность.
Кроме того, учитывайте недостатки. Например, избыточность в нескольких регионах обеспечивает высокий уровень доступности, но повышает сложность и затраты из-за синхронизации данных, механизмов отработки отказа и обмена данными между регионами. Определите, может ли зональная избыточность соответствовать вашим уровням обслуживания.
Политики Azure
Azure предоставляет широкий набор встроенных политик, связанных со службой приложений и его зависимостями. Набор политик Azure может проверять некоторые из предыдущих рекомендаций. Например, можно проверить, можно ли:
Надлежащие механизмы управления сетью установлены. Например, можно включить сегментацию сети, разместив службу приложений в виртуальной сети Azure с помощью внедрения виртуальной сети, чтобы обеспечить более широкий контроль над конфигурацией сети. Приложение не имеет общедоступных конечных точек и подключается к службам Azure через частные конечные точки.
Элементы управления удостоверениями функционируют. Например, приложение использует управляемые удостоверения для проверки подлинности в других ресурсах. Встроенная проверка подлинности службы приложений (Простая проверка подлинности) проверяет входящие запросы.
Такие функции, как удаленная отладка и обычная проверка подлинности, отключены, чтобы уменьшить область атаки.
Для комплексного управления ознакомьтесь со встроенными определениями политики Azure и другими политиками, которые могут повлиять на безопасность вычислительного слоя.
Рекомендации помощника по Azure
Помощник по Azure — это персонализированный облачный консультант, который поможет вам следовать рекомендациям по оптимизации развертываний Azure. Ниже приведены некоторые рекомендации, которые помогут повысить надежность, безопасность, эффективность затрат, производительность и эффективность работы экземпляров веб-приложения.
Дальнейшие действия
Рассмотрим следующие статьи как ресурсы, демонстрирующие рекомендации, выделенные в этой статье.
Используйте эти эталонные архитектуры в качестве примеров применения этих рекомендаций к рабочей нагрузке.
Если вы еще ни разу не развернули веб-приложение, ознакомьтесь с разделом базовое веб-приложение.
Исходная архитектура для развертывания в рабочей среде указана в базовая архитектура высокодоступного зонально-резервируемого веб-приложения.
Используйте следующую документацию по продукту для создания опыта реализации: