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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Создайте сегментацию через границы изоляции, чтобы содержать нарушения: Примените сегментацию удостоверений. Например, реализуйте управление доступом на основе ролей (RBAC) для назначения определенных разрешений на основе ролей. Следуйте принципу наименьших привилегий, чтобы ограничить права доступа только тем, что необходимо. Кроме того, создайте сегментацию на уровне сети. Интеграция приложений Службы приложений с виртуальной сетью 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 с помощью управляемого удостоверения приложения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Автоматизация развертываний: Используйте конвейеры непрерывной интеграции и непрерывного развертывания с помощью Azure DevOps или GitHub Actions для автоматизации развертываний и уменьшения усилий вручную. Дополнительные сведения см. в статье "Непрерывное развертывание в службе приложений".

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

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

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

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

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

Управление сертификатами: Для пользовательских доменов необходимо управлять сертификатами TLS.

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

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

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

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

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

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

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

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

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

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

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

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

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