Поделиться через

Архитектурные передовые практики для управления API в Azure

Платформа Azure API Management является платформой управления и шлюзом для API во всех средах, включая гибридные и мультиоблачные. В качестве платформы как услуги (PaaS) решение "Управление API" помогает поддерживать жизненный цикл API вашей рабочей нагрузки.

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

Technology scope

В этом обзоре рассматриваются взаимосвязанные решения для следующего ресурса Azure:

  • Управление API Azure

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

Это руководство не охватывает Центр API Azure. В ней рассматриваются разделы на уровне API, связанные с управлением API, а не рекомендации по проектированию API.

Note

Not all recommendations apply to all service tiers of API Management. Многие рекомендации в этом руководстве сосредоточены на уровнях Standard v2 и классическом Premium уровнях управления API, которые являются рекомендованными производственными уровнями для большинства корпоративных рабочих нагрузок.

Important

Уровень "Премиум" версии 2 с корпоративными возможностями находится в предварительной версии. Чтобы определить, следует ли вашему проекту опираться на функции раннего доступа или доступные возможности, оцените временные сроки проектирования и внедрения в связи с доступной информацией о выпуске и путях миграции версии Premium v2.

Reliability

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

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

Контрольный список разработки рабочей нагрузки

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

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

    Оцените возможности избыточности шлюза, включая зоны доступности, несколько единиц шлюза, несколько регионов и рабочих областей. Эти функции поддерживаются на уровне "Премиум". Уровень разработчика, который не включает соглашение об уровне обслуживания (SLA), не подходит для продуктивных нагрузок. Рассмотрим компромиссы внедрения таких функций, как внешнее кэширование, которое может привести к потенциальным точкам сбоя и узких мест производительности.

  • Просмотрите возможности наблюдаемости: Рассмотрим возможности наблюдаемости службы, включая журналы и метрики Azure Monitor, Application Insights, встроенную аналитику и встроенную диагностику. Используйте эти возможности для мониторинга сигналов надежности рабочей нагрузки.

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

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

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

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

  • Выравнивание цели уровня обслуживания (SLO): Учитывайте область действия соглашения об уровне обслуживания (SLA) шлюза при установке целей уровня обслуживания (SLO) рабочей нагрузки. Служба предоставляет собственное соглашение об уровне обслуживания, но также необходимо учитывать ожидаемую надежность других компонентов рабочей нагрузки, таких как серверная часть API.

  • Устранение ошибок внутреннего сервера: Планирование ожидаемых и непредвиденных сбоев внутреннего сервера. Тестирование взаимодействия с клиентом в этих сценариях. Evaluate gateway policies to improve resiliency and enhance the client experience. Сосредоточьтесь на квотах, ограничениях скорости, политиках повторных попыток, внутренних разбиениях цепи, балансировке нагрузки и обработке исключений, как описано в спецификациях API.

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

  • Планирование аварийного восстановления (аварийное восстановление): Просмотрите параметры резервного копирования и восстановления инфраструктуры шлюза и API. Встроенные возможности резервного копирования и восстановления могут оказаться полезными в некоторых сценариях. But customer-managed options such as APIOps tooling and infrastructure as code (IaC) solutions can also be considered. Разработка стратегий для поддержания других системных данных, включая подписки пользователей.

Configuration recommendations

Эти рекомендации по надежности могут применяться либо к самой службе, либо к трафику, который проходит через API и их политики. The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(Service) Enable zone redundancy in the Premium tier and have a minimum of three units deployed.

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

В любом сценарии с активным активом планируйте горизонтальное масштабирование в оставшихся активных зонах для обработки трафика, который единицы первоначально обрабатывались в неисправной зоне.		 Устойчивость обеспечивается во время сбоя центра обработки данных в регионе. Во время полной потери центра обработки данных трафик API будет продолжать передаваться по оставшимся единицам, развернутым в других зонах.
(Service) Enable automatic scale-out based on traffic demands.

В развертываниях с несколькими регионами вторичные регионы не имеют возможности автоматического масштабирования или масштабирования. Необходимо реализовать пользовательскую функцию или приложение логики, активируемую в ответ на оповещения метрик Azure Monitor для управления корректировками единиц в зависимости от спроса.		 Достаточные ресурсы гарантированно отвечают требованиям от клиентов API, что предотвращает сбои из-за нехватки емкости.
(Service) Use a multiregion topology to support resiliency against a complete regional failure.

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

Убедитесь, что топология многорегионирования соответствует любым требованиям соответствия для данных в транзите или данных в месте расположения кэша.		 Надежная устойчивость обеспечивается во время полного регионального сбоя, что помогает обеспечить непрерывный трафик API через единицы, развернутые в других регионах.
(Service) Isolate unrelated APIs with workspaces or additional API Management instances. Влияние сбоев, вызванных неправильной настройкой или сбоем, сводится к минимуму путем разделения API между различными вычислительными экземплярами.
(API) Тщательно протестируйте выражения политики и логику и соедините их с устойчивыми методами обработки ошибок в политиках управления API. Взаимодействие с клиентом улучшается путем предотвращения новых источников сбоев в шлюзе и обеспечения корректной деградации или безопасной временной обработки сбоев.
(API службы и API) Сбор метрик надежности.

Типичные метрики надежности API включают:

- Ограничения скорости и нарушения квот.
— Частота ошибок на основе кодов состояния HTTP.
— отклонение скорости запроса от базовых показателей.
- Проверки состояния, включая состояние зависимостей.		 Отклонения от ожидаемого поведения и прошлых базовых показателей определяются. Эти данные можно использовать для трассировки основных причин, таких как измененное поведение пользователя, вмешательство из обычных операций, непредвиденные последствия новых функций или незапланированные ошибки в рабочей нагрузке.
(Сервис и API) Используйте встроенные возможности резервного копирования и восстановления, которые являются частью управления API в сборнике схем аварийного восстановления. Дополните эти особенности артефактами IaC и процессами APIOps для надежного решения, которое может обрабатывать различные сценарии, включая координацию восстановления с зависимостями и бэкэндами. Непрерывность бизнес-процессов обеспечивается путем восстановления шлюза API и восстановления определенных API после полной потери системы.

Security

Цель компонента "Безопасность" — обеспечить конфиденциальности, целостности и доступности гарантии рабочей нагрузки.

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

Note

Контрольный список и рекомендации в этом разделе посвящены защите ресурса шлюза управления API. Защита api-интерфейсов только кратко рассматривается. Дополнительные сведения см. в разделе «Снижение рисков топ-10 безопасности API OWASP» в Управлении API.

Контрольный список разработки рабочей нагрузки

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

  • Создайте базовые показатели безопасности: Просмотрите базовые показатели безопасности для управления API и включите применимые меры в базовый план.

  • Защита конвейера развертывания: Определите отдельных лиц и роли управления доступом на основе ролей, необходимые для управления платформой служб, конвейерами непрерывной интеграции и непрерывного развертывания (CI/CD) и отдельными API. Убедитесь, что только авторизованные лица имеют доступ для управления услугой и её API.

  • Оцените конфиденциальность данных: Если конфиденциальные данные передаются через запросы и ответы API в шлюзе управления API, обеспечьте защиту в течение всего жизненного цикла. Учет различных требований к защите данных в разных регионах. Evaluate service features such as multiple regions to isolate specific data. Кроме того, убедитесь, соответствует ли стратегия кэширования этим требованиям к изоляции.

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

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

  • Рассмотрите возможности проверки подлинности и авторизации API: Оцените использование поставщиков удостоверений, таких как Идентификатор Microsoft Entra, который включает встроенные группы, или Идентификатор Microsoft Entra External ID для фильтрации запросов шлюза и включения авторизации OAuth для внутренних API.

  • Шифрование сетевого трафика: Определите наиболее безопасные версии протокола TLS и шифры , поддерживаемые рабочими нагрузками. Не требуйте небезопасных версий TLS. Используйте TLS 1.3, когда это поддерживается вашими клиентами.

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

  • Определите секреты, необходимые для рабочих нагрузок: Для операции шлюза могут потребоваться сертификаты, ключи API или другие значения секретов. Просмотрите требования и возможности Azure Key Vault для хранения секретов и сертификатов. Or review the built-in API Management capabilities such as named values and managed certificates.

Configuration recommendations

Эти рекомендации по безопасности могут применяться либо к самой службе, либо к трафику, который проходит через API и их политики. The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(Служба) Отключите API прямого управления, который устарел. Используйте Azure Resource Manager в качестве уровня управления. Область поверхности службы уменьшается путем удаления точки доступа уровня управления.
(Служба) Ограничить доступ к шлюзу исключительно на основании того, откуда подключаются законные клиенты.

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

— Используйте интеграцию виртуальной сети с Шлюзом приложений или Azure Front Door, если трафик должен поступать из Интернета. Configure the NSG to only accept traffic from the single point of entry.		 Конфиденциальность сетевого трафика защищена путем ограничения воздействия на диапазоны исходных IP-адресов, которые, как ожидается, содержат законные клиенты. Эти ограничения блокируют доступ из источников, которые не должны инициировать законное взаимодействие с клиентом. Ограничение доступа к законным источникам трафика повышает конфиденциальность, целостность и доступность службы.
(Service) Disable developer portal if it's not in use. Если портал используется, отключите интерфейс регистрации, отключите анонимный доступ и ограничьте доступ только к доверенным сетевым расположениям. Область поверхности службы и вероятность неправильной настройки или пренебрежения уменьшается.
(Служба) Явно задайте самые ограниченные поддерживаемые версии TLS, протоколы и шифры для клиентов и серверов. Версии и поддерживаемые шифры сокращаются только до тех вариантов, которые поддерживают клиенты и внутренние компоненты. Этот подход помогает гарантировать, что для обеспечения конфиденциальности приоритет отдается соединениям самого высокого уровня.
(Служба) Храните пользовательские сертификаты в Key Vault. Функции управления сертификатами предоставляются с помощью Key Vault, который поддерживает регулярное поворот и аудит доступа к сертификатам.
(Служба) Серверные части должны принимать трафик только из шлюзов API и должны блокировать весь остальной трафик. Предотвращается обход вредоносным трафиком средств безопасности и других сквозных аспектов, разгруженных на шлюз.
(Служба) Для экземпляров управления API, на которых размещаются API для нескольких команд или сегментированных рабочих нагрузок, необходимо разработать надежную стратегию изоляции управления доступом. Use workspaces or implement a rigorous APIOps process to achieve this strategy.

Teams должны иметь доступ только к собственным API. Они не должны иметь доступ к другим API, которые могут размещаться в том же экземпляре.		 Боковое перемещение злоумышленников из одного скомпрометированного API, установленного в другие не связанные API, уменьшается.
(API) Store secrets in Key Vault and expose them to policies through named values. Не используйте Key Vault для хранения несекретов. Используйте свойства именованного значения непосредственно для этих значений. Смена секретов рекомендуется через один уровень управления в Key Vault, аналогичный подходу, используемому для сертификатов. Этот процесс гарантирует, что управление API обновляется соответствующим образом. Именованные значения также обеспечивают согласованный интерфейс конфигурации политики как для секретов, так и для несекретов. Весь доступ к секретам также аудируется в Key Vault, чтобы предоставлять историю доступа. Только хранение секретов в Key Vault сводит к минимуму зависимость от Key Vault и не превращает Key Vault в службу конфигурации приложения.
(API) Use different user-assigned managed identities for different APIs by using the authentication-managed-identity policy. Каждый API может иметь независимое удостоверение, которое поддерживает цели сегментации с помощью минимального доступа к привилегиям для каждого API. Он также обеспечивает более высокую доступность аудита в внутренних системах.
(API) По возможности требуется, чтобы клиенты выполняли проверку подлинности с помощью потоков OAuth 2.0 вместо использования предварительно общих ключей, включая ключи подписки или сертификаты клиента. Идентификация клиента для целей аудита улучшается, смена ключей устраняется, а нагрузка на клиентов на защиту секретов уменьшается по сравнению с использованием предварительно общих ключей.
(API) Suppress HTTP headers from API responses by using the set-header policy that might expose implementation details. Стоимость для злоумышленников увеличивается за счет сокрытия информации о реализации.
(API) Don't use API tracing in production. Предотвращается утечка конфиденциальных данных в трассировках запросов.
(API) Используйте Defender для API. Предоставляются аналитические сведения о безопасности API, рекомендации и обнаружение угроз.
(API) Protect back-end resources by delegating key security checks in API policy, such as validate-jwt, ip-filter, validate-headers, validate-content. Объем недостоверного трафика, который достигает служб бэкэнда, уменьшается путем выполнения проверок безопасности на шлюзе. Этот подход разгрузки помогает защитить целостность и доступность этих ресурсов.
(API) Примените методики жизненного цикла разработки безопасности (SDL) к изменениям в политике API так же, как предлагаемые изменения применяются к коду приложения в рамках вашей рабочей нагрузки. Политики выполняются с высоким уровнем привилегированного доступа к трафику API. Предотвращается обход защит внутреннего уровня для конфиденциальности, целостности и доступности через скомпрометированный шлюз API.
(Service & API) Use managed identities for service and API dependencies. Подключения к Key Vault, Центрам событий Azure и другим зависимостям, таким как сертификаты и именованные значения, устанавливаются без использования предварительно общих секретов.
(API службы и API) Подключайтесь к зависимостям, таким как Key Vault, Центры событий и бэкэнды, через частные сетевые подключения, когда это возможно. Конфиденциальность трафика защищается, не выводя трафик за пределы частной сети.
(API службы) Клиентский трафик, ориентированный на API, доступные в Интернете, должен сначала пройти через брандмауэр веб-приложения, такой как Web Application Firewall, прежде чем он достигнет управления API. Кроме того, защита общедоступных конечных точек с помощью Защиты от атак DDoS Azure. Объем нелегитимного трафика, который достигает шлюза и служб бэкэнда, уменьшается путем проведения проверок безопасности с использованием брандмауэра веб-приложения. Уменьшение этого трафика помогает защищать целостность и доступность этих ресурсов.
(Служба и API) Оцените и включите все элементы управления соответствием политике Azure, подходящие для вашей рабочей нагрузки. Экземпляр управления API соответствует требуемому положению и сохраняет согласованность по мере развития рабочей нагрузки благодаря наличию политик безопасности.

Cost Optimization

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

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

Контрольный список разработки рабочей нагрузки

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

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

    If you implement workspaces, evaluate the costs of using separate versus shared workspace gateways to address the distinct API flow requirements of various API teams or stakeholders.

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

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

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

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

Configuration recommendations

Эти рекомендации по оптимизации затрат могут применяться либо к самой службе, либо к трафику, который проходит через API и их политики. The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(Служба) Используйте наименее дорогой уровень , поддерживающий требования рабочей нагрузки. Например, выберите уровень "Стандартный" вместо уровня "Премиум", если рабочая нагрузка не получит преимущества от добавленной функциональности таким образом, чтобы оправдыть рентабельность инвестиций (ROI). Неиспользуемые или неиспользуемые возможности не используется.
(Service) Use nonproduction tiers or transient infrastructure in lower environments, such as development environments, proof-of-concept deployments, and initial cost modeling activities. Затраты на ресурсы сохраняются для сред, которые могут оставаться полезными без полного зеркального отображения точных требований к конфигурации или времени простоя рабочей среды.
(Служба) Сокращение масштаба при уменьшении спроса. Configure autoscale rules or other automated processes to reduce units when gateway capacity drops below defined thresholds. Ненужные затраты сокращаются путем сопоставления емкости с спросом.
(Service) Calculate any cost advantages of a federated model for API management by using workspaces to serve APIs while also providing team isolation. Область развертывания и управления уменьшается. Этот подход направлен на достижение экономии масштаба от времени и покупок ресурсов.
(Service) Decommission workspaces when they're no longer in use. Неиспользуемые ресурсы не тратятся.
(Service) Use the built-in cache if your workload's cached data fits within the constraints of the built-in cache in your tier. Затраты, связанные с приобретением и обслуживанием внешнего кэша, совместимого с Redis, избегаются.
(Service) Block malicious traffic before it reaches the gateway by using network controls, DDoS protection, and web application firewalls. Определенные уровни управления API несут расходы на основе количества операций HTTP-запросов, которые обрабатывает шлюз. В результате нежелательный трафик, например запросы, созданные ботом, могут увеличить затраты.

Оцените стоимость механизма блокировки по сравнению с предполагаемой стоимостью снижения количества операций HTTP, чтобы оценить, имеет ли этот подход окупаемость инвестиций.		 Расходы, возникшие из-за чрезмерной вредоносной или nuisance HTTP-операций с шлюзом, сокращаются.
(API) Оптимизируйте выражения политики и обработку и код, чтобы избежать чрезмерного использования вычислительных ресурсов, таких как процессор, сеть или память. Ненужное развертывание дополнительных единиц для обеспечения емкости для неоптимизированных реализаций политик и кода не требуется.
(API) Оцените стоимость размещения логики между шлюзом, серверной частью или общедоступной точкой входа, например Azure Front Door. Такая же обработка часто может происходить на любом из этих уровней, каждая из которых имеет собственные компромиссы. Однако некоторые слои могут обеспечить экономию средств из-за неиспользуемой емкости, доступной на этом уровне. Например, логика кэширования, изначально реализованная в серверной части, может быть более экономичной, реализованной на уровне шлюза с помощью встроенного кэша. Этот подход снижает дополнительные затраты на сеть и вычислительные расходы на внутренние службы. Нагрузка на ресурсы с высокой стоимостью сводится к минимуму путем размещения возможностей в наиболее экономичном уровне. Этот подход перемещает рабочие нагрузки на уровни с запасной емкостью или более низкими затратами на вычислительные ресурсы.

Operational Excellence

Операционное совершенство в основном сосредоточено на процедурах, касающихся практик разработки , наблюдаемости и управления релизами.

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

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

Контрольный список разработки рабочей нагрузки

  • Просмотрите ключевые знания и навыки, необходимые для работы службы: К областям относятся жизненный цикл API, процессы DevOps, сетевые и подключения, мониторинг и наблюдаемость, а также разработка программного обеспечения. Этот подход включает конфигурацию политики, модульное тестирование и создание конвейеров CI/CD.

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

  • Оцените стандартные средства для поддержки операций службы. For example, adopt APIOps methods, such as GitOps and CI/CD, to publish APIs and manage API configurations. Используйте средства IaC для изменений конфигурации уровня обслуживания. Проектирование повторно используемых артефактов, которые могут легко переходить из сред разработки в рабочую среду. Consider integrating a linter like Spectral, either self-managed or as integrated into an Azure service like Azure API Center, into API approval pipelines.

  • Определите ключевые операционные метрики и журналы: Просмотрите метрики для рабочей среды. Эти метрики включают емкость шлюза, использование ЦП, использование памяти и количество запросов. Review logs and observability tools, such as Azure Monitor and Application Insights. Определите стратегии и средства, необходимые для эффективного управления большими объемами данных наблюдения в рабочих средах. Определите запросы, которые предоставляют полезные сведения как для оператора шлюза, так и для заинтересованных лиц, отслеживающих определенные размещенные API.

  • Планирование регулярного тестирования рабочих нагрузок с помощью нагрузочного тестирования.

  • Определите операционные задачи за пределами процессов CI/CD или IaC , требующих автоматизации. Планирование автоматизации в таких областях, как управление источниками политик управления API, политиками Azure и конкретными конфигурациями портала разработчика.

Configuration recommendations

Эти рекомендации по повышению эффективности работы могут применяться либо к самой службе, либо к трафику, который проходит через API и их политики. The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(Служба) Настройте журналы ресурсов диагностики Azure для управления API. Журналы, созданные платформой, доступны для запроса обычных операций, потребностей по запросу или срочных сценариев, таких как аудит безопасности.
(Служба) Используйте Службу "Сетка событий Azure" для автоматизации на основе значимых событий, создаваемых экземпляром службы управления API, например APICreated. Задачи автоматизации или уведомлений можно создавать вокруг ключевых событий жизненного цикла, происходящих в экземпляре API Management.
(Service) Avoid using a self-hosted gateway if a Microsoft-hosted gateway unit works in your scenario. Задачи автоматизации или уведомлений можно создавать вокруг ключевых событий жизненного цикла, происходящих в экземпляре API Management.
(Служба) Примените все встроенные политики Azure Policy, которые помогают управлять вашим экземпляром и ограничивать его в соответствии с требованиями рабочей нагрузки, включая требования безопасности. For example, use deny policies to prevent APIs from being exposed over HTTP or to prevent the enabling of the direct management REST API. Use audit policies if deny policies aren't available, or create custom deny policies if it's important to your workload. Экземпляр управления API соответствует проектированию и остается согласованным по мере изменения нагрузки.
(Служба) Ознакомьтесь с возможностями диагностики и решения проблем на портале Azure.

Используйте страницу состояния сети в портале, чтобы устранить проблемы с подключением к сети.		 Специалисты по обеспечению надежности сайта могут выявлять и устранять проблемы с производительностью шлюза, доступностью служб и сетевым подключением во всех средах.
(API) Use Event Hubs to handle log or event streams from API invocations that require near real-time reactions or short-timeframe windowed operations. Предоставляется доступность записей журнала практически в режиме реального времени. Задержка приема данных журнала, которая возникает при ведении журнала в Azure Monitor через API, избегается.
(API) Support the usage of API tracing in development to help developers understand their policy implementation. Производительность разработчика оптимизирована, предоставляя аналитические сведения о реализации политик в API. Без этой возможности разработчикам необходимо внедрять ухищрения в реализацию политики, чтобы получить информацию.
(API) Always define back ends by using the backends feature of API Management. Reference these back ends by ID in policy by using set-backend-service. Load balanced back ends should be defined as a backend pool. Изменения в бэкенд-подключении применяются ко всем API, использующим бэкенд, без необходимости обновления кода отдельных политик. Риск неправильной настройки или пропущенных изменений политики API уменьшается, и сценарии, в которых несколько API используют одну и ту же серверную часть, подходят для этого уровня абстракции конфигурации.
(API) Разработайте подход к версиионированию ваших API, чтобы он соответствовал возможностям управления версиями и ревизиями системы управления API. Этот подход учитывается в операциях развертывания API. Стратегия управления версиями API, поддерживаемая вне поля управления API, используется для использования встроенных возможностей вместо создания пользовательских решений.
(Сервис и API) Определите согласованный, устойчивый операционный процесс для добавления, изменения и удаления API. Determine whether to manage this experience manually through the portal or implement it through an APIOps process. Предпочитайте использовать подход на основе IaC вместо подхода на основе портала.

API Management's representation in the Resource Manager API consists of many child resources, so it's important to adopt a layered approach for IaC-based management of this resource collection.		 Спецификации API и их реализации шлюза интегрируются в процессы управления изменениями рабочей нагрузки. Этот подход предотвращает обработку изменений серверных API-интерфейсов иначе, чем они представлены клиентам API через шлюз.

Performance Efficiency

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

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

Начните свою стратегию проектирования на основе контрольного списка проверки проектирования для производительности, чтобы определить базовый уровень, основываясь на ключевых показателях эффективности для управления API.

Контрольный список разработки рабочей нагрузки

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

  • Сбор данных о производительности: Просмотрите возможности встроенной аналитики, метрик Azure Monitor, журналов Azure Monitor, Application Insights и Центров событий для сбора и анализа производительности на различных уровнях детализации.

  • Узнайте, как определить проблемы с производительностью в реальном времени: Показатели динамической производительности включают доступность службы Azure, ошибки ответа HTTP и ошибки, возникающие в разделе "Диагностика и устранение проблем " на портале. Устранение неполадок с производительностью и доступностью с помощью Application Insights, запросов Kusto и рекомендаций из системы диагностики управления API на портале Azure.

  • Test performance: Test performance under production conditions by using load testing.

  • Оцените смежные службы, которые могут повысить производительность: Политики кэширования или внешний кэш могут повысить производительность определенных операций API. Azure Front Door и Шлюз приложений являются распространенными вариантами разгрузки TLS.

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

Configuration recommendations

Эти рекомендации по эффективности производительности могут применяться либо к самой службе, либо к трафику, который проходит через API и их политики. The (Service) or (API) designators indicate whether a recommendation targets the service or the APIs.

Recommendation Benefit
(Служба) Динамическое масштабирование в соответствии с требованиями. Configure autoscale rules or other automated processes to adjust gateway units to match a target usage capacity. Эластичность достигается на основе параллельного использования, что предотвращает истощение ресурсов развернутых в настоящее время единиц или чрезмерное распределение емкости.
(API) Minimize expensive processing tasks, such as generating large buffered payload sizes, by using the validate-content policy on large request bodies or by maintaining a high number of active WebSockets. Нагрузка на единицы масштабирования уменьшается, что позволяет обрабатывать больше запросов одновременно, прежде чем выполнять горизонтальное масштабирование.
API сервиса Сбор метрик производительности.

К общим метрикам производительности API относятся:

— Узнать время обработки самого шлюза и всей операции.
Метрики использования ресурсов шлюзовых устройств.
— измерения пропускной способности, такие как запросы в секунду или мегабиты в секунду.
— соотношение попаданий кэша.		 Фактические показатели производительности измеряются по целевым объектам рабочей нагрузки.
(Служба и API) Определите процент выборки для Application Insights, который обеспечивает достаточную видимость и при этом не влияет на производительность. Требования к данным о наблюдаемости удовлетворяются без влияния на общую производительность.
(Службы и API) Оцените влияние на производительность в зависимости от размещения логики между вашим шлюзом, серверной частью или точкой публичного входа, например, Azure Front Door. Одни и те же задачи обработки часто могут возникать на любом из этих уровней с компромиссами производительности и ограничениями в возможностях оптимизации для каждого из них. Если задача, например политика API управления API, введет слишком много задержки, рассмотрите, может ли эта задача выполняться где-то в другом месте более оптимизированным способом. Задачи, добавляющие задержку в API, выполняются в вычислительных ресурсах, оптимизированных для удовлетворения требований рабочей нагрузки.

Azure policies

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

  • Шлюз настроен на зональную избыточность.
  • Для шлюза службы "Управление API" предусмотрены надлежащие элементы управления сетью, такие как развертывание в виртуальной сети.
  • Конечные точки конфигурации службы недоступны публично.
  • API REST управления отключен.

Для полноценного управления ознакомьтесь с встроенными определениями Azure Policy и другими политиками, которые могут повлиять на безопасность шлюза управления API.

Рекомендации Помощника по Azure

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

For more information, see Azure Advisor.

Советник может предложить другие рекомендации в вашей производственной системе, такие как:

  • Невозможность требовать длинные размеры ключей JWT в политике validate-jwt.
  • Вы использовали устаревшую версию API Resource Manager для развертывания ресурса.
  • Токены ключа API близки к сроку истечения.
  • Сбой в операции ротации сертификата.

Tradeoffs

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

Высокая доступность благодаря избыточности и изоляции

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

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

Масштабируйте в соответствии с спросом

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

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

Федеративный против распределенного подхода

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

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

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

Example architecture

Базовая архитектура, демонстрирующая основные рекомендации: архитектура целевой зоны управления API.

Next steps

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

Следующие статьи демонстрируют некоторые из рекомендаций, обсуждаемых в этой статье.