Рекомендации по архитектуре службы приложений Azure (веб-приложения)

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

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

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

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

Дополнительные сведения см. в статье Анализ режима сбоя для приложений Azure.

Build redundancy: Build redundancy in the application and supporting infrastructure. Распределите экземпляры между зонами доступности, чтобы повысить отказоустойчивость. Трафик направляется в другие зоны, если одна из зон выходит из строя. Разверните приложение в нескольких регионах, чтобы убедиться, что приложение остается доступным, даже если весь регион испытывает сбой.

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

Используйте несколько экземпляров: При запуске приложения на одном экземпляре происходит немедленное одноуровневое сбой. Выделите несколько экземпляров в приложении, чтобы обеспечить высокий уровень доступности. Если один экземпляр выйдет из строя, другие экземпляры по-прежнему могут обрабатывать входящие запросы. Код приложения должен иметь возможность обрабатывать несколько экземпляров без проблем синхронизации при чтении из источников данных или записи в источники данных.

Избыточность в сетевых компонентах. Например, используйте зонально-избыточные IP-адреса и балансировщики нагрузки.

Укажите надежную стратегию масштабирования: Непредвиденная нагрузка на приложение может сделать его ненадежным. Рассмотрите правильный подход к масштабированию на основе характеристик рабочей нагрузки. Horizontal scaling, or scaling out, allows you to add more instances to distribute the load. Vertical scaling, or scaling up, increases the capacity of an existing instance, such as CPU or memory. Следите за чрезмерной подготовкой, так как добавление ненужных экземпляров увеличивает затраты без существенных преимуществ производительности.

Иногда можно увеличивать масштаб, чтобы справиться с нагрузкой. Однако если нагрузка продолжает увеличиваться, масштабируйте их до новых экземпляров. Choose the automatic, or autoscaling, approach over the manual approach. Всегда сохраняйте буфер дополнительной емкости во время операций масштабирования, чтобы предотвратить снижение производительности.

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

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

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

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

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

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

• Шаблон типа Bulkhead сегментирует ваше приложение на изолированные группы, чтобы предотвратить распространение сбоя на всю систему.

• Шаблон выравнивания нагрузки Queue-Based ставит в очередь рабочие элементы, которые служат буфером для сглаживания пиков трафика.

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

• шаблон разбиения цепи запрещает приложению многократно пытаться выполнить операцию, которая, скорее всего, завершится ошибкой.

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

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

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

Используйте инъекцию ошибок, чтобы намеренно вводить сбои и проверить механизмы самовосстановления и самосохранения. Дополнительные сведения см. в библиотеке ошибок и действий Azure Chaos Studio.

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

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

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

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

Используйте функцию автоматического лечения: Иногда приложение может столкнуться с непредвиденным поведением, которое может решить простой перезапуск. Use the auto-heal feature to define a condition that triggers auto-heal and the action that auto-heal initiates when that condition is met. Дополнительные сведения см. в обзоре диагностики службы приложений.

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

Просмотрите базовые показатели безопасности: Чтобы повысить уровень безопасности приложения, размещенного в плане службы приложений, просмотрите базовые показатели безопасности для службы приложений.

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

Создайте сегментацию через границы изоляции, чтобы содержать нарушения: Применение сегментации удостоверений. Например, реализуйте управление доступом на основе ролей (RBAC) для назначения определенных разрешений на основе ролей. Следуйте принципу наименьших привилегий, чтобы ограничить права доступа только тем, что необходимо. Кроме того, создайте сегментацию на уровне сети. Интеграция приложений Службы приложений с виртуальной сетью Azure для изоляции и определения групп безопасности сети (NSG) для фильтрации трафика.

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

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

Используйте идентификатор Microsoft Entra для всех потребностей проверки подлинности и авторизации. Используйте встроенные роли, такие как участник веб-плана, участник веб-сайта, а также универсальный участник, читатель и владелец.

Применение элементов управления безопасностью сети: Интеграция службы приложений с виртуальной сетью для управления исходящим трафиком. Используйте частные конечные точки для контроля входящего трафика, ограничения доступа к экземпляру Службы приложений из виртуальной сети и отключения общедоступного доступа к Интернету. For more information, see Network routing.

Разверните брандмауэр веб-приложения (WAF), чтобы защититься от распространенных уязвимостей. Шлюз приложений и Azure Front Door интегрируют возможности WAF.

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

Исходящий трафик из приложения в другие службы PaaS должен выполняться через частные конечные точки. Рассмотрите возможность размещения компонента брандмауэра для ограничения исходящего трафика в общедоступный Интернет. Оба подхода помогают предотвратить кражу данных.

Дополнительные сведения см. в разделе "Сетевые функции службы приложений".

Encrypt data: Help protect data in transit by using end-to-end Transport Layer Security (TLS). Use your customer-managed keys for full encryption of data at rest.

Не используйте устаревшие протоколы, такие как TLS 1.0 и 1.1. Убедитесь, что все веб-приложения используют только HTTPS и применяют TLS 1.2 или более поздней версии. Минимальная версия TLS по умолчанию — 1.2. Дополнительные сведения см. в обзоре TLS службы приложений .

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

Сквозное шифрование TLS: Сквозное шифрование TLS доступно в планах службы приложений уровня "Премиум". Эта функция шифрует трафик во всей транзакции, что сводит к минимуму риск перехвата трафика.

Уменьшите область атаки: Удалите конфигурации по умолчанию, которые вам не нужны. Например, отключите удаленную отладку, локальную проверку подлинности для сайтов диспетчера управления версиями (SCM) и обычную проверку подлинности. Отключите незащищенные протоколы, такие как ПРОТОКОЛ HTTP и протокол передачи файлов (FTP). Принудительное применение конфигураций с помощью политик Azure. For more information, see Azure policies.

Реализуйте ограничивающие политики общего доступа к ресурсам (CORS): Используйте ограничивающие политики CORS в веб-приложении, чтобы принимать только запросы из разрешенных доменов, заголовков и других критериев. Применение политик CORS с помощью встроенных определений политик Azure.

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

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

Включите журналы ресурсов для приложения: Включите журналы ресурсов для приложения для создания комплексных следов действий, которые предоставляют ценные данные во время расследований, которые следуют инцидентам безопасности. Для получения дополнительной информации см. журналы ресурсов Azure Monitor.

При оценке угроз рассмотрите возможность ведения журнала в рамках процесса моделирования угроз.

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

Непрерывно отслеживайте модель затрат для отслеживания расходов.

Оцените скидки: Более высокие уровни включают выделенные вычислительные экземпляры. Вы можете применить скидку на резервирование, если рабочая нагрузка имеет прогнозируемый и согласованный шаблон использования. Убедитесь, что вы анализируете данные об использовании, чтобы определить тип резервирования, соответствующий рабочей нагрузке. Дополнительные сведения см. в разделе Экономия затрат на зарезервированные экземпляры службы приложений.

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

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

Рассмотрим компромисс между плотностью и изоляцией: Вы можете использовать планы службы приложений для размещения нескольких приложений на одном вычислительном ресурсе, что экономит затраты на общие среды. For more information, see Tradeoffs.

Оцените последствия стратегии масштабирования по затратам: При реализации автомасштабирования необходимо правильно разработать, протестировать и настроить масштабирование и настроить его масштабирование. Установите точные и минимальные ограничения для автомасштабирования.

Упреждающая инициализация приложения для надежного масштабирования. Например, не подождите, пока ЦП достигнет 95% использования. Вместо этого запустите масштабирование при примерно 65%, чтобы дать достаточно времени для выделения и инициализации новых экземпляров в процессе масштабирования. Однако эта стратегия может привести к неиспользуемой емкости.

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

Оптимизация затрат на среду: Рекомендуется использовать базовый уровень или бесплатный уровень для запуска предварительных сред. Эти уровни отличаются низкой производительностью и низкими затратами. Если вы используете базовый или бесплатный уровень, используйте управление для принудительного применения уровня, ограничить количество экземпляров и ЦП, ограничить масштабирование и ограничить хранение журналов.

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

Регулярно проверяйте затраты, связанные с данными: Расширенные периоды хранения данных или дорогие уровни хранилища могут привести к высокой стоимости хранения. Дополнительные расходы могут накапливаться из-за использования пропускной способности и длительного хранения данных ведения журнала.

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

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

Используйте слоты развертывания с осторожностью. Вы можете столкнуться с проблемами, такими как исключения или утечки памяти, которые могут повлиять на существующие экземпляры и новые экземпляры. Убедитесь, что вы тщательно тестируете изменения. For more information about operational guidance, see Operational Excellence.

Manage releases: Use deployment slots to manage releases effectively. Вы можете развернуть приложение в слоте, выполнить тестирование и проверить его функциональные возможности. После проверки вы можете легко переместить приложение в рабочую среду. Этот процесс не несет дополнительных затрат, так как слот выполняется в той же среде виртуальной машины, что и рабочий экземпляр.

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

Запуск автоматических тестов: Прежде чем продвигать выпуск веб-приложения, тщательно протестируйте его производительность, функциональные возможности и интеграцию с другими компонентами. Используйте нагрузочное тестирование Azure. Он интегрируется с Apache JMeter, популярным средством для тестирования производительности. Изучите автоматизированные средства для других типов тестирования, таких как Фантом для функционального тестирования.

Automate deployments: Use continuous integration and continuous deployment pipelines with Azure DevOps or GitHub Actions to automate deployments and reduce manual effort. Дополнительные сведения см. в статье "Непрерывное развертывание в службе приложений".

Развертывание неизменяемых единиц: Реализуйте шаблон меток развертывания , чтобы разделить службу приложений на неизменяемую метку. Служба приложений поддерживает использование контейнеров, которые по сути неизменяемы. Consider custom containers for your App Service web app.

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

Используйте технологию "инфраструктура как код" (IaC), такую как Bicep, чтобы создавать единицы с повторяемостью и согласованностью.

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

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

Manage certificates: For custom domains, you need to manage TLS certificates.

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

Определите и отслеживайте показатели производительности: Задайте целевые показатели для приложения, такие как объем входящих запросов, время, необходимое приложению для реагирования на запросы, ожидающие запросы и ошибки в ответах HTTP. Рассмотрим ключевые показатели в рамках базовых показателей производительности рабочей нагрузки.

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

Включите инструментирование на уровне кода, трассировку транзакций и профилирование производительности.

Assess capacity: Simulate various user scenarios to determine the optimal capacity that you need to handle expected traffic. Используйте нагрузочное тестирование, чтобы понять, как работает приложение под разными уровнями нагрузки.

Выберите нужный уровень: Используйте выделенные вычислительные ресурсы для рабочих нагрузок. Уровни Premium версии 3 обеспечивают более крупные номера SKU с увеличенной емкостью памяти и ЦП, большим количеством экземпляров и дополнительными функциями, такими как избыточность зоны. Дополнительные сведения см. в ценовой категории "Премиум" версии 3.

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

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

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

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

Use caching: Retrieving information from a resource that doesn't change frequently and is expensive to access affects performance. Сложные запросы, включая соединения и несколько подстановок, влияют на время выполнения. Выполните кэширование, чтобы свести к минимуму время обработки и задержку. Результаты запроса кэшируются, чтобы избежать повторяющихся обходов в базу данных или серверную часть и сократить время обработки для последующих запросов.

For more information about using local and distributed cache in the workload, see Caching.

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