Перспектива azure Well-Architected Framework для службы приложение Azure (веб-приложения)
приложение Azure служба — это решение вычислений как услуга (PaaS), которое можно использовать для размещения рабочей нагрузки на платформе Azure. Это полностью управляемая служба, которая абстрагирует базовые вычислительные ресурсы и загружает ответственность за создание, развертывание и масштабирование на платформу. Служба приложений всегда работает в рамках плана службы приложений. План службы, который вы выбираете, определяет регион, в котором выполняется рабочая нагрузка, конфигурации вычислений и операционная система. Для Служба приложений доступны несколько моделей выставления счетов.
В этой статье предполагается, что в качестве архитектора вы рассмотрели дерево принятия решений вычислений и выбрали Служба приложений в качестве вычислительных ресурсов для рабочей нагрузки. В этом руководстве приведены рекомендации по архитектуре, сопоставленные с принципами основных принципов платформы Azure Well-Architected Framework.
Внимание
Как использовать это руководство
Каждый раздел содержит список проверка проектирования, который представляет архитектурные области, связанные с стратегиями проектирования, локализованными в технологии область.
Также включены рекомендации по возможностям технологий, которые помогут материализовать эти стратегии. Рекомендации не представляют исчерпывающий список всех конфигураций, доступных для функции веб-приложения службы приложение Azure и их зависимостей. Вместо этого они перечисляют ключевые рекомендации, сопоставленные с перспективами проектирования. Используйте рекомендации для создания подтверждения концепции или оптимизации существующих сред.
Базовая архитектура, демонстрирующая основные рекомендации: Служба приложений базовую архитектуру.
Технология область
В этом обзоре рассматриваются взаимосвязанные решения для следующих ресурсов Azure:
- Планы службы приложений
- Веб-приложения
Другие предложения Azure связаны с Служба приложений, такими как Функции Azure, Azure Logic Apps и Среда службы приложений. Эти предложения не область для этой статьи. Среда службы приложений иногда ссылаются на функции или варианты основных предложений Служба приложений.
Надежность
Цель компонента "Надежность" — обеспечить непрерывную функциональность путем создания достаточной устойчивости и возможности быстрого восстановления после сбоев.
Принципы проектирования надежности обеспечивают высокоуровневую стратегию проектирования, применяемую для отдельных компонентов, системных потоков и системы в целом.
Контрольный список проектирования
Запустите стратегию проектирования на основе списка проверка проверки дизайна для надежности. Определите свою релевантность бизнес-требований, учитывая уровни и функции Служба приложений и его зависимостей. Расширьте стратегию, чтобы включить дополнительные подходы по мере необходимости.
Приоритеты потоков пользователей: не все потоки одинаково важны. Назначьте приоритеты каждому потоку, чтобы управлять решениями по проектированию. Проектирование пользовательского потока может влиять на уровни служб и количество экземпляров, которые вы выбираете для плана и конфигурации Служба приложений.
Например, приложение может включать интерфейсные и внутренние уровни, которые взаимодействуют через брокер сообщений. Вы можете сегментировать уровни в нескольких веб-приложениях, чтобы обеспечить независимое масштабирование, управление жизненным циклом и обслуживание. Размещение большого приложения в одном плане может привести к проблемам с памятью или ЦП и повлиять на надежность.
Для оптимальной производительности на стороне пользовательского интерфейса может потребоваться больше экземпляров. Однако серверная часть может не требовать того же количества экземпляров.
Предвидеть потенциальные сбои: планирование стратегий устранения рисков для потенциальных сбоев. В следующей таблице показаны примеры анализа режима сбоя.
Сбой Исправление Сбой базовых или абстрактных компонентов Служба приложений Избыточность компонентов в экземплярах и зависимостях. Мониторинг работоспособности экземпляров, производительности сети и производительности хранилища. Сбой внешних зависимостей Используйте такие шаблоны конструктора, как шаблон повторных попыток и шаблон разбиения цепи. Отслеживайте внешние зависимости и задайте соответствующие тайм-ауты. Сбой из-за перенаправления трафика в неработоспособные экземпляры Мониторинг работоспособности экземпляра. Рассмотрите возможность реагирования и избегайте отправки запросов в неработоспособные экземпляры. Дополнительные сведения см. в разделе "Анализ режима сбоя" для приложений Azure.
Избыточность сборки: создание избыточности в приложении и вспомогательной инфраструктуре. Распространение экземпляров между зонами доступности для повышения отказоустойчивости. Трафик направляется в другие зоны, если одна зона завершается сбоем. Разверните приложение в нескольких регионах, чтобы убедиться, что ваше приложение остается доступным, даже если весь регион испытывает сбой.
Создайте аналогичные уровни избыточности в зависимых службах. Например, экземпляры приложений привязываются к хранилищу BLOB-объектов. Рассмотрите возможность настройки связанной учетной записи хранения с хранилищем, избыточным между зонами (ZRS), если приложение использует избыточное между зонами развертывание.
Избыточность в сетевых компонентах. Например, используйте ip-адреса, избыточные между зонами, и подсистемы балансировки нагрузки.
У вас есть надежная стратегия масштабирования: непредвиденная нагрузка на приложение может сделать его ненадежным. Рассмотрите правильный подход к масштабированию на основе характеристик рабочей нагрузки. Иногда можно масштабировать до обработки нагрузки. Однако если нагрузка продолжает увеличиваться, масштабируйте их до новых экземпляров. Предпочитайте автоматическое масштабирование по сравнению с подходами вручную. Всегда сохраняйте буфер дополнительной емкости во время операций масштабирования, чтобы предотвратить снижение производительности.
Уровень плана Служба приложений, который вы выбираете, влияет на масштабирование с точки зрения количества экземпляров и вычислительных единиц.
Убедитесь в правильной инициализации приложений, чтобы новые экземпляры быстро прогрелись и могут получать запросы.
По возможности старайтесь использовать приложения без отслеживания состояния. Надежное масштабирование состояния с новыми экземплярами может повысить сложность. Рассмотрим внешнее хранилище данных, которое можно масштабировать независимо, если необходимо сохранить состояние приложения. Сохранение состояния сеанса в памяти может привести к потере состояния сеанса при возникновении проблемы с приложением или Службой приложений. Она также ограничивает возможность распространения нагрузки по другим экземплярам.
Регулярно тестируйте правила автомасштабирования. Имитируйте сценарии загрузки, чтобы убедиться, что приложение масштабируется должным образом. Вы должны регистрировать события масштабирования, чтобы устранить проблемы, которые могут возникнуть и оптимизировать стратегию масштабирования с течением времени.
Служба приложений имеет ограничение на количество экземпляров в плане, что может повлиять на надежность масштабирования. Одна из стратегий — использовать идентичные метки развертывания, каждый запущенный экземпляр плана Служба приложений с собственной конечной точкой. Важно, чтобы все метки с внешней подсистемой балансировки нагрузки распределяли трафик между ними. Используйте Шлюз приложений Azure для развертываний в одной зоне и Azure Front Door для развертывания с несколькими регионами. Этот подход идеально подходит для критически важных приложений, где надежность имеет решающее значение. Дополнительные сведения см. в разделе "Критически важные для миссии" базовые показатели с Служба приложений.
План Служба приложений распределяет трафик между экземплярами и отслеживает их работоспособность. Обратите внимание, что внешний подсистема балансировки нагрузки может не сразу определить, завершается ли сбой одного экземпляра.
Планирование возможности восстановления: избыточность имеет решающее значение для непрерывности бизнес-процессов. Отработка отказа в другой экземпляр, если один экземпляр недоступен. Изучите возможности автоматического восстановления в Служба приложений, например автоматическое восстановление экземпляров.
Реализуйте шаблоны проектирования для обработки корректной деградации как временных сбоев, таких как проблемы с сетевым подключением, так и крупномасштабные события, такие как региональные сбои. Рассмотрим следующие шаблоны проектирования:
Шаблон bulkhead сегментирует приложение в изолированные группы, чтобы предотвратить сбой, влияющий на всю систему.
Шаблон выравнивания нагрузки на основе очередей помещает рабочие элементы, которые служат буфером для сглаживания пиков трафика.
Шаблон повторных попыток обрабатывает временные сбои из-за сбоя сети, удаления подключения к базе данных или занятых служб.
Шаблон разбиения цепи запрещает приложению многократно пытаться выполнить операцию, которая, скорее всего, завершится ошибкой.
С помощью веб-заданий можно выполнять фоновые задачи в веб-приложении. Для надежного выполнения этих задач убедитесь, что приложение, на котором размещено задание, выполняется непрерывно по расписанию или на основе триггеров, управляемых событиями.
Дополнительные сведения см. в разделе "Шаблоны надежности".
Проводите тестирование надежности: проводите нагрузочное тестирование, чтобы оценить надежность и производительность приложения под нагрузкой. Планы тестирования должны включать сценарии, которые проверяют автоматические операции восстановления.
Используйте внедрение ошибок, чтобы намеренно вводить сбои и проверять механизмы самовосстановления и самосохранения. Изучите библиотеку ошибок, предоставляемую Azure Chaos Studio.
Служба приложений накладывает ограничения ресурсов на размещенные приложения. План Служба приложений определяет эти ограничения. Убедитесь, что тесты подтверждают, что приложение выполняется в пределах этих ограничений ресурсов. Дополнительные сведения см. в статье Подписка Azure, границы, квоты и ограничения службы.
Используйте пробы работоспособности для выявления неответственных рабочих ролей: Служба приложений имеет встроенные возможности, которые периодически ping определенный путь веб-приложения. Неответственные экземпляры удаляются из подсистемы балансировки нагрузки и заменяются новым экземпляром.
Рекомендации
| Рекомендация | Преимущества |
|---|---|
| (Служба приложений план) Выберите уровень "Премиум" Служба приложений плана для рабочих нагрузок. Задайте максимальное и минимальное количество рабочих ролей в соответствии с планированием емкости. Дополнительные сведения см. в Служба приложений обзоре плана. |
План Служба приложений уровня "Премиум" предлагает расширенные функции масштабирования и гарантирует избыточность при возникновении сбоев. |
| (план Служба приложений) Включите избыточность зоны. Рассмотрите возможность подготовки более трех экземпляров для повышения отказоустойчивости. Проверьте региональную поддержку избыточности зон, так как не все регионы предлагают эту функцию. |
Приложение может противостоять сбоям в одной зоне, если несколько экземпляров распределяются по зонам. Трафик автоматически перемещается на здоровые экземпляры в других зонах и обеспечивает надежность приложения, если одна зона недоступна. |
| (Служба приложений) Рассмотрите возможность отключения функции маршрутизации запросов приложений (ARR). Сопоставление ARR создает липкие сеансы, которые перенаправляют пользователей на узел, обрабатывающий предыдущие запросы. | Входящие запросы равномерно распределяются по всем доступным узлам при отключении сопоставления ARR. Равномерно распределенные запросы предотвращают перегрузку трафика любого одного узла. Запросы можно легко перенаправлять на другие здоровые узлы, если узел недоступен. Избегайте сопоставления сеансов, чтобы убедиться, что экземпляр Служба приложений остается без отслеживания состояния. Без отслеживания состояния Служба приложений снижает сложность и обеспечивает согласованное поведение между узлами. Удалите липкие сеансы, чтобы Служба приложений могли добавлять или удалять экземпляры для горизонтального масштабирования. |
| (Служба приложений) Определите правила автоматического восстановления на основе количества запросов, медленных запросов, ограничений памяти и других индикаторов, которые являются частью базового показателя производительности. Рассмотрим эту конфигурацию как часть стратегии масштабирования. | Правила автоматического восстановления помогают приложению автоматически восстанавливаться после непредвиденных проблем. Настроенные правила активируют действия восстановления при нарушении пороговых значений. Автоматическое восстановление обеспечивает автоматическое упреждающее обслуживание. |
| (Служба приложений) Включите функцию проверка работоспособности и укажите путь, который отвечает на запросы проверка работоспособности. | Работоспособности проверка могут обнаруживать проблемы рано. Затем система может автоматически выполнять корректирующие действия при сбое запроса работоспособности проверка. Подсистема балансировки нагрузки направляет трафик из неработоспособных экземпляров, который направляет пользователей на здоровые узлы. |
Безопасность
Цель компонента "Безопасность" заключается в обеспечении конфиденциальности, целостности и доступности для рабочей нагрузки .
Принципы проектирования безопасности обеспечивают высокоуровневую стратегию проектирования для достижения этих целей, применяя подходы к техническому проектированию вокруг размещения на Служба приложений.
Контрольный список проектирования
Запустите стратегию проектирования с учетом проверка списка проверка для безопасности и выявления уязвимостей и элементов управления, чтобы повысить уровень безопасности. Расширьте стратегию, чтобы включить дополнительные подходы по мере необходимости.
Просмотрите базовые показатели безопасности. Чтобы повысить уровень безопасности приложения, размещенного в плане Служба приложений, просмотрите базовые показатели безопасности для Служба приложений.
Используйте последнюю среду выполнения и библиотеки: тщательно протестируйте сборки приложения, прежде чем выполнять обновления для раннего перехвата проблем и обеспечить плавный переход на новую версию. Служба приложений поддерживает политику поддержки среды выполнения языка для обновления существующих стеков и выхода из эксплуатации стеков завершения поддержки.
Создайте сегментацию через границы изоляции, чтобы содержать нарушение: применение сегментации удостоверений. Например, реализуйте управление доступом на основе ролей (RBAC) для назначения определенных разрешений на основе ролей. Следуйте принципу наименьших привилегий, чтобы ограничить права доступа только тем, что необходимо. Кроме того, создайте сегментацию на уровне сети. Внедрение приложений Служба приложений в виртуальную сеть Azure для изоляции и определение групп безопасности сети (NSG) для фильтрации трафика.
Служба приложений планы предлагают уровень Среда службы приложений, обеспечивающий высокую степень изоляции. С помощью Среда службы приложений вы получаете выделенные вычислительные ресурсы и сети.
Применение элементов управления доступом к удостоверениям: ограничение доступа к веб-приложению и внешнему доступу из веб-приложения к другим ресурсам. Эта конфигурация применяет элементы управления доступом к удостоверениям и помогает поддерживать общую безопасность рабочей нагрузки.
Используйте идентификатор Microsoft Entra для всех потребностей проверки подлинности и авторизации. Используйте встроенные роли, такие как участник веб-плана, участник веб-сайта и универсальный участник, читатель и владелец.
Управление сетевым трафиком в приложение и из нее: не предоставляйте конечные точки приложений общедоступному Интернету. Вместо этого добавьте частную конечную точку в веб-приложение, размещенное в выделенной подсети. Перед приложением с обратным прокси-сервером, который взаимодействует с этой частной конечной точкой. Рекомендуется использовать Шлюз приложений или Azure Front Door для этой цели.
Разверните брандмауэр веб-приложения (WAF) для защиты от распространенных уязвимостей. Как Шлюз приложений, так и Azure Front Door имеют интегрированные возможности WAF.
Настройте правила обратного прокси-сервера и параметры сети соответствующим образом, чтобы обеспечить требуемый уровень безопасности и контроля. Например, добавьте правила NSG в подсеть частной конечной точки, чтобы принимать трафик только из обратного прокси-сервера.
Исходящий трафик из приложения в другие службы PaaS должен выполняться через частные конечные точки. Рассмотрите возможность размещения компонента брандмауэра для ограничения исходящего трафика в общедоступный Интернет. Оба подхода предотвращают кражу данных.
Подробные сведения см. в разделе Служба приложений сетевых функций.
Шифрование данных: защита передаваемых данных с помощью сквозного протокола TLS. Используйте ключи, управляемые клиентом, для полного шифрования неактивных данных. Дополнительные сведения см. в разделе "Шифрование неактивных" с помощью ключей, управляемых клиентом.
Не используйте устаревшие протоколы, такие как TLS 1.0 и 1.1. Служба приложений включает 1.2 по умолчанию. Дополнительные сведения см. в Служба приложений обзоре TLS.
Все экземпляры Служба приложений имеют доменное имя по умолчанию. Используйте личный домен и защитите этот домен с помощью сертификатов.
Уменьшите область атаки: удалите конфигурации по умолчанию, которые вам не нужны. Например, отключите удаленную отладку, локальную проверку подлинности для сайтов диспетчера управления версиями (SCM) и обычную проверку подлинности. Отключите небезопасные протоколы, такие как ПРОТОКОЛ HTTP и протокол передачи файлов (FTP). Принудительное применение конфигураций с помощью политик Azure. Дополнительные сведения см. в политиках Azure.
Реализуйте ограничивающие политики совместного использования ресурсов (CORS): используйте ограничивающие политики CORS в веб-приложении, чтобы принимать только запросы из разрешенных доменов, заголовков и других критериев. Применение политик CORS со встроенными определениями политик Azure.
Защита секретов приложения: необходимо обрабатывать конфиденциальную информацию, например ключи API или маркеры проверки подлинности. Вместо жесткого написания этих секретов непосредственно в коде приложения или файлах конфигурации можно использовать ссылки Azure Key Vault в параметрах приложения. При запуске приложения Служба приложений автоматически извлекает значения секретов из Key Vault с помощью управляемого удостоверения приложения.
Включите журналы ресурсов для приложения: включите журналы ресурсов для приложения для создания комплексных следов действий, которые предоставляют ценные данные во время расследований, которые следуют инцидентам безопасности.
При оценке угроз рассмотрите возможность ведения журнала в рамках процесса моделирования угроз.
Рекомендации
| Рекомендация | Преимущества |
|---|---|
| (Служба приложений) Назначение управляемых удостоверений веб-приложению. Чтобы поддерживать границы изоляции, не делитесь удостоверениями или повторно используйте их в приложениях. Убедитесь, что вы безопасно подключаетесь к реестру контейнеров, если используете контейнеры для развертывания. |
Приложение извлекает секреты из Key Vault для проверки подлинности исходящего взаимодействия из приложения. Azure управляет удостоверением и не требует подготовки или смены секретов. У вас есть уникальные удостоверения для детализации элемента управления. Отдельные удостоверения упрощают отзыв, если удостоверение скомпрометировано. |
| (Служба приложений) Настройка пользовательских доменов для приложений. Отключите HTTP и примите только HTTP-запросы. |
Пользовательские домены обеспечивают безопасную связь через ПРОТОКОЛ HTTPS с помощью протокола TLS, который обеспечивает защиту конфиденциальных данных и создает доверие пользователей. |
| (Служба приложений) оценить, следует ли Служба приложений встроенная проверка подлинности — это правильный механизм проверки подлинности пользователей, обращаюющихся к приложению. Служба приложений встроенная проверка подлинности интегрируется с идентификатором Microsoft Entra. Эта функция обрабатывает проверку маркеров и управление удостоверениями пользователей в нескольких поставщиках входа и поддерживает Подключение OpenID. С помощью этой функции у вас нет авторизации на детальном уровне, и у вас нет механизма проверки подлинности. | При использовании этой функции не требуется использовать библиотеки проверки подлинности в коде приложения, что снижает сложность. Пользователь уже проходит проверку подлинности, когда запрос достигает приложения. |
| (Служба приложений) Настройте приложение для интеграции виртуальной сети. Используйте частные конечные точки для приложений Служба приложений. Блокировать весь общедоступный трафик. Перенаправите образ контейнера через интеграцию виртуальной сети. Весь исходящий трафик из приложения проходит через виртуальную сеть. |
Получите преимущества безопасности для использования виртуальной сети Azure. Например, приложение может безопасно получить доступ к ресурсам в сети. Добавьте частную конечную точку для защиты приложения. Частные конечные точки ограничивают прямой доступ к общедоступной сети и разрешают контролируемый доступ через обратный прокси-сервер. |
| (Служба приложений) Для реализации защиты: - Отключите базовую проверку подлинности, которая использует имя пользователя и пароль в пользу проверки подлинности на основе идентификаторов Майкрософт. — отключите удаленную отладку, чтобы не открывались входящие порты. — включение политик CORS для ужесточения входящих запросов. — отключите протоколы, такие как FTP. |
Мы не рекомендуем обычную проверку подлинности в качестве безопасного метода развертывания. Идентификатор Microsoft Entra использует проверку подлинности на основе маркеров OAuth 2.0, которая предлагает множество преимуществ и улучшений, которые устраняют ограничения, связанные с базовой проверкой подлинности. Политики ограничивают доступ к ресурсам приложения, разрешают только запросы из определенных доменов и безопасные запросы между регионами. |
| (Служба приложений) Всегда используйте ссылки Key Vault в качестве параметров приложения. |
Секреты хранятся отдельно от конфигурации приложения. Параметры приложения шифруются неактивных данных. Служба приложений также управляет сменами секретов. |
| (план Служба приложений) Включите Microsoft Defender для облака для Служба приложений. | Получите защиту в режиме реального времени для ресурсов, выполняемых в плане Служба приложений. Защита от угроз и повышение общего уровня безопасности. |
| (план Служба приложений) Включите ведение журнала диагностики и добавьте инструментирование в приложение. Журналы отправляются в учетные записи служба хранилища Azure, Центры событий Azure и Log Analytics. Дополнительные сведения о типах журналов аудита см. в разделе "Поддерживаемые типы журналов". | Ведение журнала записывает шаблоны доступа. Он записывает соответствующие события, которые предоставляют ценные сведения о взаимодействии пользователей с приложением или платформой. Эта информация имеет решающее значение для обеспечения подотчетности, соответствия требованиям и безопасности. |
Оптимизация затрат
Оптимизация затрат фокусируется на обнаружении шаблонов расходов, приоритете инвестиций в критически важные области и оптимизации в других целях в соответствии с бюджетом организации при выполнении бизнес-требований.
Принципы проектирования оптимизации затрат предоставляют высокоуровневую стратегию проектирования для достижения этих целей и достижения компромиссов в соответствии с техническим дизайном, связанными с веб-приложениями и средой, в которой они работают.
Контрольный список проектирования
Запустите стратегию проектирования на основе списка проверка обзора проектирования для оптимизации затрат для инвестиций и точной настройки проектирования, чтобы рабочая нагрузка была согласована с бюджетом, выделенным для рабочей нагрузки. Проект должен использовать правильные возможности Azure, отслеживать инвестиции и находить возможности для оптимизации с течением времени.
Оценка начальной стоимости. В рамках упражнения по моделированию затрат используйте калькулятор цен Azure, чтобы оценить приблизительные затраты, связанные с различными уровнями на основе количества экземпляров, которые планируется запустить. Каждый уровень Служба приложений предлагает различные варианты вычислений.
Непрерывно отслеживайте модель затрат для отслеживания расходов.
Оцените скидки: более высокие уровни включают выделенные вычислительные экземпляры. Вы можете применить скидку на резервирование, если рабочая нагрузка имеет прогнозируемый и согласованный шаблон использования. Убедитесь, что вы анализируете данные об использовании, чтобы определить тип резервирования, соответствующий рабочей нагрузке. Дополнительные сведения см. в разделе "Экономия затрат с помощью Служба приложений зарезервированных экземпляров".
Общие сведения об измерениях использования: Плата За почасовую ставку Azure, пропорциональной второй, на основе ценовой категории Служба приложений плана. Плата применяется к каждому экземпляру горизонтального масштабирования в плане в зависимости от времени выделения экземпляра виртуальной машины. Обратите внимание на неиспользуемые вычислительные ресурсы, которые могут увеличить затраты в результате перемещений из-за неоптимального выбора номера SKU или плохо настроенной конфигурации масштабирования.
Дополнительные Служба приложений функции, такие как регистрация личного домена и пользовательские сертификаты, могут добавить затраты. Другие ресурсы, такие как виртуальные сети, чтобы изолировать решение или хранилища ключей для защиты секретов рабочей нагрузки, которые интегрируются с вашими Служба приложений ресурсами, также могут добавлять затраты. Дополнительные сведения см. в разделе Служба приложений модели выставления счетов.
Рассмотрим компромисс между плотностью и изоляцией: вы можете использовать Служба приложений планы размещения нескольких приложений на одном вычислительном ресурсе, что экономит затраты на общие среды. Дополнительные сведения см. в разделе "Компромиссы".
Оцените эффект стратегии масштабирования по затратам: необходимо правильно разработать, проверить и настроить масштабирование и масштабирование при реализации автомасштабирования. Установите точные и минимальные ограничения для автомасштабирования.
Упреждающая инициализация приложения для надежного масштабирования. Например, не подождите, пока ЦП не достигнет 95 % использования. Вместо этого активируйте масштабирование примерно на 65 %, чтобы обеспечить достаточное время для выделения и инициализации новых экземпляров во время масштабирования. Однако эта стратегия может привести к неиспользуемой емкости.
Рекомендуется объединить и сбалансировать механизмы масштабирования и масштабирования. Например, приложение может масштабироваться в течение некоторого времени, а затем масштабироваться по мере необходимости. Ознакомьтесь с высокими уровнями, которые предлагают большую емкость и эффективное использование ресурсов. В зависимости от шаблонов использования более высокие категории "Премиум" часто являются более экономичными, так как они более способны.
Оптимизация затрат на среду. Рассмотрим уровень "Базовый" или "Бесплатный" для запуска предварительных сред. Эти уровни являются низкими производительностью и низкими затратами. Если вы используете уровень "Базовый" или "Бесплатный", используйте управление для принудительного применения уровня, ограничить количество экземпляров и ЦП, ограничить масштабирование и ограничить хранение журналов.
Реализация шаблонов проектирования. Эта стратегия уменьшает объем запросов, создаваемых рабочей нагрузкой. Рассмотрите возможность использования таких шаблонов, как внутренние серверные части для интерфейсов и шаблон агрегирования шлюза, что может свести к минимуму количество запросов и сократить затраты.
Регулярно проверка затраты, связанные с данными: длительные периоды хранения данных или дорогие уровни хранения могут привести к высоким затратам на хранение. Дополнительные расходы могут накапливаться из-за использования пропускной способности и длительного хранения данных ведения журнала.
Рекомендуется реализовать кэширование для минимизации затрат на передачу данных. Начните с кэширования локальной памяти, а затем изучите параметры распределенного кэширования, чтобы уменьшить количество запросов к серверной базе данных. Учитывайте затраты на трафик пропускной способности, связанные с обменом данными между регионами, если база данных находится в другом регионе.
Оптимизация затрат на развертывание. Воспользуйтесь преимуществами слотов развертывания для оптимизации затрат. Слот выполняется в той же вычислительной среде, что и рабочий экземпляр. Используйте их стратегически для таких сценариев, как сине-зеленые развертывания, которые переключаются между слотами. Этот подход сокращает время простоя и обеспечивает плавные переходы.
Используйте слоты развертывания с осторожностью. Вы можете столкнуться с проблемами, такими как исключения или утечки памяти, которые могут повлиять как на существующие экземпляры, так и на новые экземпляры. Убедитесь, что вы тщательно тестируете изменения. Сведения об операционных рекомендациях см. в разделе "Операционное превосходство".
Рекомендации
| Рекомендация | Преимущества |
|---|---|
| (план Служба приложений) Выберите бесплатные или базовые уровни для более низких сред. Мы рекомендуем использовать эти уровни для экспериментального использования. Удалите уровни, когда они больше не нужны. | Уровни "Бесплатный" и "Базовый" являются бюджетными по сравнению с более высокими уровнями. Они предоставляют экономичное решение для непроизводственных сред, которые не нуждаются в полных функциях и производительности планов premium. |
| (Служба приложений план) Воспользуйтесь преимуществами скидок и изучите предпочтительную цену: — более низкие среды с планами разработки и тестирования. - Резервирования Azure и планы экономии Azure для выделенных вычислений, подготовленных на уровне Premium V3 и Среда службы приложений. Используйте зарезервированные экземпляры для стабильных рабочих нагрузок, имеющих прогнозируемые шаблоны использования. |
Планы разработки и тестирования предоставляют сниженные ставки для служб Azure, что делает их экономически эффективными для непроизводственных сред. Используйте зарезервированные экземпляры для оплаты вычислительных ресурсов и получения значительных скидок. |
| (Служба приложений) Отслеживайте расходы, которые Служба приложений ресурсов. Запустите средство анализа затрат в портал Azure. Создание бюджетов и оповещений для уведомления заинтересованных лиц. |
Вы можете определить пики затрат, неэффективные или непредвиденные расходы на ранних этапах. Этот упреждающий подход помогает обеспечить бюджетные средства контроля, чтобы предотвратить перерасход. |
| (Служба приложений план) Масштабирование при снижении спроса. Чтобы масштабироваться, определите правила масштабирования, чтобы уменьшить количество экземпляров в Azure Monitor. | Предотвращение разбиений и сокращение ненужных расходов. |
Эффективность работы
Операционное превосходство в основном посвящено процедурам разработки, наблюдаемости и управлению выпусками.
Принципы проектирования операционного превосходства предоставляют высокоуровневую стратегию проектирования для достижения этих целей в отношении операционных требований рабочей нагрузки.
Контрольный список проектирования
Запустите стратегию разработки на основе списка проверка обзора проектирования для операционного превосходства для определения процессов для наблюдения, тестирования и развертывания, связанных с веб-приложения.
Управление выпусками. Используйте слоты развертывания для эффективного управления выпусками. Вы можете развернуть приложение в слоте, выполнить тестирование и проверить его функциональные возможности. После проверки вы можете легко переместить приложение в рабочую среду. Этот процесс не несет дополнительных затрат, так как слот выполняется в той же среде виртуальной машины, что и рабочий экземпляр.
Запустите автоматические тесты: прежде чем продвигать выпуск веб-приложения, тщательно протестируйте его производительность, функциональные возможности и интеграцию с другими компонентами. Используйте нагрузочное тестирование Azure, которое интегрируется с Apache JMeter, популярным средством для тестирования производительности. Изучите автоматизированные средства для других типов тестирования, таких как Фантом для функционального тестирования.
Развертывание неизменяемых единиц: реализуйте шаблон меток развертывания для секционизации Служба приложений в неизменяемую метку. Служба приложений поддерживает использование контейнеров, которые по сути неизменяемы. Рассмотрим пользовательские контейнеры для веб-приложения Служба приложений.
Каждая метка представляет собой автономное устройство, которое можно быстро масштабировать или масштабировать. Единицы, основанные на этой метки, являются временными и без отслеживания состояния. Проектирование без отслеживания состояния упрощает операции и обслуживание. Этот подход идеально подходит для критически важных приложений. Пример см. в разделе "Критически важные для миссии" базовые показатели с Служба приложений.
Используйте инфраструктуру как технологию кода (IaC), например Bicep, для удаления единиц с возможностью повторяемости и согласованности.
Безопасность рабочих сред. Создание отдельных планов Служба приложений для запуска рабочих и предварительных сред. Не вносите изменения непосредственно в рабочую среду, чтобы обеспечить стабильность и надежность. Отдельные экземпляры позволяют гибко разрабатывать и тестировать, прежде чем вносить изменения в рабочую среду.
Используйте низкие среды для изучения новых функций и конфигураций изолированным образом. Сохраняйте временные среды разработки и тестирования.
Управление сертификатами: для пользовательских доменов необходимо управлять сертификатами TLS.
Имеются процессы для приобретения, продления и проверки сертификатов. Если это возможно, выгрузите эти процессы в Служба приложений. Если вы используете собственный сертификат, необходимо управлять его продлением. Выберите подход, который лучше всего соответствует вашим требованиям безопасности.
| Рекомендация | Преимущества |
|---|---|
| (Служба приложений) Отслеживайте работоспособность экземпляров и активируйте пробы работоспособности экземпляров. Настройте конкретный путь для обработки запросов проб работоспособности. |
Вы можете быстро обнаруживать проблемы и выполнять необходимые действия для поддержания доступности и производительности. |
| (Служба приложений) Включите журналы диагностика для приложения и экземпляра. Частое ведение журнала может замедлить производительность системы, добавить затраты на хранение и привести к риску, если у вас нет небезопасного доступа к журналам. Следуйте приведенным ниже рекомендациям. — Регистрируют правильный уровень информации. — задайте политики хранения. — сохраняйте путь аудита авторизованного доступа и несанкционированных попыток. — обрабатывает журналы как данные и применяет элементы управления защитой данных. |
Журналы диагностики предоставляют ценные сведения о поведении приложения. Отслеживайте шаблоны трафика и выявляйте аномалии. |
| (Служба приложений) Воспользуйтесь преимуществами Служба приложений управляемые сертификаты для разгрузки управления сертификацией в Azure. | Служба приложений автоматически обрабатывает такие процессы, как закупки сертификатов, проверка сертификатов, продление сертификата и импорт сертификатов из Key Vault. Кроме того, отправьте сертификат в Key Vault и авторизуйте поставщик ресурсов Служба приложений для доступа к нему. |
| (план Служба приложений) Перед переключением приложения на рабочий слот проверьте изменения в промежуточном слоте. | Избегайте простоя и ошибок. Быстро отменить изменения к последнему известному хорошему состоянию, если вы обнаружите проблему после переключения. |
Уровень производительности
Эффективность производительности заключается в поддержании взаимодействия с пользователем даже при увеличении нагрузки путем управления емкостью. Стратегия включает масштабирование ресурсов, определение потенциальных узких мест и оптимизацию потенциальных узких мест и оптимизацию для пиковой производительности.
Принципы проектирования эффективности производительности предоставляют высокоуровневую стратегию проектирования для достижения этих целей емкости в отношении ожидаемого использования.
Контрольный список проектирования
Запустите стратегию проектирования на основе списка проверка обзора проекта для повышения эффективности для определения базовых показателей производительности на основе ключевых показателей производительности для веб-приложения.
Определите и отслеживайте показатели производительности: задайте целевые показатели для ключевых индикаторов приложения, например объем входящих запросов, время, которое приложение принимает для реагирования на запросы, ожидающие запросы и ошибки в ответах HTTP. Рассмотрим ключевые показатели в рамках базовых показателей производительности рабочей нагрузки.
Запись Служба приложений метрик, которые образуют основу показателей производительности. Сбор журналов для получения аналитических сведений об использовании ресурсов и действиях. Используйте средства мониторинга производительности приложений (APM), такие как приложение Аналитика, для сбора и анализа данных о производительности из приложения. Дополнительные сведения см. в Служба приложений справочнике по данным мониторинга.
Включите инструментирование на уровне кода, трассировку транзакций и профилирование производительности.
Оценка емкости. Имитируйте различные сценарии пользователей, чтобы определить оптимальную емкость, необходимую для обработки ожидаемого трафика. Используйте нагрузочное тестирование, чтобы понять, как работает приложение под разными уровнями нагрузки.
Выберите нужный уровень: используйте выделенные вычислительные ресурсы для рабочих нагрузок. Категории "Премиум" предлагают более крупные номера SKU с увеличенной емкостью памяти и ЦП, большим количеством экземпляров и дополнительными функциями, такими как избыточность зоны. Дополнительные сведения см. в ценовой категории "Премиум" версии 3.
Оптимизируйте стратегию масштабирования. По возможности используйте автоматическое масштабирование вместо ручного изменения количества экземпляров при изменении нагрузки приложения. При автоматическом масштабировании Служба приложений настраивает емкость сервера на основе предопределенных правил или триггеров. Убедитесь, что вы выполняете достаточное тестирование производительности и задаете правильные правила для правильных триггеров.
Если во время начальной установки вы определяете простоту, используйте параметр автомасштабирования, который не требует определения правил, и необходимо задать только ограничения.
Достаточно ресурсов, чтобы обеспечить оптимальную производительность. Выделите ресурсы соответствующим образом для поддержания целевых показателей производительности, таких как время отклика или пропускная способность. При необходимости рассмотрите возможность перемещений ресурсов.
При определении правил автомасштабирования следует учитывать время, необходимое для инициализации приложения. Учитывайте эти издержки при принятии всех решений по масштабированию.
Используйте кэширование: получение сведений из ресурса, который часто не изменяется и является дорогостоящим для доступа к производительности. Сложные запросы, включая соединения и несколько подстановок, способствуют выполнению. Выполните кэширование, чтобы свести к минимуму время обработки и задержку. Результаты запроса кэшируются, чтобы избежать повторяющихся обходов в базу данных или серверную часть и сократить время обработки для последующих запросов.
Дополнительные сведения об использовании локального и распределенного кэша в рабочей нагрузке см. в разделе "Кэширование".
Просмотрите антипаттерны производительности. Чтобы убедиться, что веб-приложение выполняет и масштабируется в соответствии с вашими бизнес-требованиями, избегайте типичных антипаттернов. Ниже приведены некоторые антипаттерны, которые Служба приложений исправляет.
Антишаблон Description Занятость внешнего интерфейса Ресурсоемкие задачи могут увеличить время отклика на запросы пользователей и привести к высокой задержке.
Переместите процессы, требующие значительные ресурсы, в отдельную серверную часть. Используйте брокер сообщений для очередей ресурсоемких задач, которые серверная часть выбирает для асинхронной обработки.Без кэширования Обслуживайте запросы из промежуточного кэша перед серверной базой данных, чтобы уменьшить задержку. Шумный сосед В мультитенантных системах арендаторы совместно используют доступные ресурсы. Активность одного клиента может негативно повлиять на использование системы другого клиента. Среда службы приложений предоставляет полностью изолированную и выделенную среду для запуска приложений Служба приложений.
Рекомендации
| Рекомендация | Преимущества |
|---|---|
| Включите параметр AlwaysOn, если приложения совместно используют один план Служба приложений. Служба приложений приложения автоматически выгружаются при простое для сохранения ресурсов. Следующий запрос запускает холодный запуск, который может вызвать время ожидания запроса. | Приложение никогда не выгружается с поддержкой AlwaysOn. |
| Рекомендуется использовать ПРОТОКОЛ HTTP/2 для приложений для повышения эффективности протокола. | Выберите HTTP/2 по протоколу HTTP/1.1, так как HTTP/2 полностью мультиплексирует подключения, повторно использует подключения для снижения затрат и сжимает заголовки, чтобы свести к минимуму передачу данных. |
Компромиссы
Если вы используете подходы в основных проверка lists, вам может потребоваться сделать компромиссы по проектированию. Ниже приведены некоторые примеры преимуществ и недостатков.
Плотность и изоляция
Более высокая плотность: Колокат нескольких приложений в одном Служба приложений планирует свести к минимуму ресурсы. Все приложения совместно используют ресурсы, такие как ЦП и память, что позволяет сэкономить деньги и снизить операционную сложность. Этот подход также оптимизирует использование ресурсов. Приложения могут использовать неактивные ресурсы из другого приложения, если с течением времени шаблоны загрузки изменяются.
Кроме того, учитывайте недостатки. Например, пики использования или нестабильности приложения могут повлиять на производительность других приложений. Инциденты в одном приложении также могут проникать в другие приложения в общей среде, что может повлиять на безопасность.
Более высокая изоляция: изоляция помогает избежать вмешательства. Эта стратегия применяется к безопасности, производительности и даже сегрегации сред разработки, тестирования и рабочей среды.
Среда службы приложений обеспечивает более эффективное управление безопасностью и защитой данных, так как каждое приложение может иметь собственные параметры безопасности. Ваша среда может содержать нарушения, так как изоляция ограничивает радиус взрыва. С точки зрения производительности свести к минимуму количество проблем с ресурсами. Изоляция позволяет независимо масштабироваться на основе конкретного спроса и планирования отдельных ресурсов.
В качестве недостатка этот подход является более дорогим и требует операционной строгости.
Надежная стратегия масштабирования
Хорошо определенная стратегия масштабирования гарантирует, что приложение может обрабатывать различные нагрузки без ущерба для производительности. Однако есть компромиссы по затратам. Выполнение операций масштабирования занимает время. При выделении новых ресурсов приложение должно быть правильно инициализировано, прежде чем он сможет эффективно обрабатывать запросы. Вы можете переоценить ресурсы (предварительно подготовленные экземпляры) для предоставления безопасной сети. Без этой дополнительной емкости во время этапа инициализации может возникнуть задержка в обслуживании запросов, что влияет на взаимодействие с пользователем. Операции автомасштабирования могут запускаться достаточно рано, чтобы обеспечить правильную инициализацию ресурсов по времени, когда клиенты используют ресурсы.
В качестве недостатка избыточные ресурсы стоят больше. Плата взимается в секунду для каждого экземпляра, включая предварительно подготовленные экземпляры. Более высокие уровни включают предварительно подготовленные экземпляры. Определите, стоят ли возможности с более дорогими уровнями стоит инвестиций.
Создание избыточности
Избыточность обеспечивает устойчивость, но также несет затраты. Целевые показатели уровня обслуживания для рабочей нагрузки определяют допустимые пороги производительности. Это становится расточительным, если избыточность превышает требования SLO. Оцените, улучшается ли избыточность уровней обслуживания или добавляется ненужная сложность.
Кроме того, учитывайте недостатки. Например, избыточность в нескольких регионах обеспечивает высокий уровень доступности, но повышает сложность и затраты из-за синхронизации данных, механизмов отработки отказа и обмена данными между регионами. Определите, может ли избыточность зоны соответствовать вашим соглашениям об уровне обслуживания.
Политики Azure
Azure предоставляет широкий набор встроенных политик, связанных с Служба приложений и его зависимостями. Набор политик Azure может проверять некоторые из предыдущих рекомендаций. Например, можно проверка ли:
Правильные сетевые элементы управления находятся на месте. Например, можно включить сегментацию сети, разместив Служба приложений в Azure виртуальная сеть путем внедрения виртуальной сети, чтобы обеспечить более широкий контроль над конфигурацией сети. Приложение не имеет общедоступных конечных точек и подключается к службам Azure через частные конечные точки.
Элементы управления удостоверениями находятся на месте. Например, приложение использует управляемые удостоверения для проверки подлинности в других ресурсах. Служба приложений встроенная проверка подлинности (Easy Auth) проверяет входящие запросы.
Такие функции, как удаленная отладка и обычная проверка подлинности, отключены, чтобы уменьшить область атаки.
Для комплексного управления просмотрите встроенные определения Политика Azure и другие политики, которые могут повлиять на безопасность вычислительного слоя.
Рекомендации Помощника по Azure
Помощник по Azure — это персонализированный облачный консультант, который помогает следовать рекомендациям по оптимизации развернутых служб Azure. Ниже приведены некоторые рекомендации, которые помогут повысить надежность, безопасность, эффективность затрат, производительность и эффективность работы экземпляров веб-приложения.
Следующие шаги
Рассмотрим следующие статьи как ресурсы, демонстрирующие рекомендации, выделенные в этой статье.
Используйте эти эталонные архитектуры в качестве примеров применения этих рекомендаций к рабочей нагрузке.
Если вы никогда не развернули веб-приложение, см. статью "Базовый веб-приложение".
Базовая архитектура в качестве отправной точки для развертывания в рабочей среде см. в разделе "Базовые высокодоступные веб-приложения с высоким уровнем доступности".
Используйте следующую документацию по продукту для создания опыта реализации: