Устранение неполадок времени ожидания отклика клиента и ошибок в службе управления API

2023-06-01

ОБЛАСТЬ ПРИМЕНЕНИЯ: все уровни Управление API

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

Симптомы

Клиентские приложения, вызывающие интерфейсы API через службу управления API (APIM), могут демонстрировать один или несколько следующих симптомов:

Периодические ошибки HTTP 500
Сообщение об ошибке истечения времени ожидания

Эти симптомы являются экземплярами BackendConnectionFailure в журналах ресурсов Azure Monitor.

Причина

Такая ситуация часто возникает из-за ограничений портов преобразования сетевых адресов (SNAT) в службе APIM.

Когда клиент вызывает один из интерфейсов API APIM, служба управления API Azure открывает порт SNAT для доступа к API серверной части. Как описывалось ранее в разделе Исходящие подключения в Azure, Azure использует преобразование адресов исходной сети (SNAT) и Load Balancer (не предоставляется клиентам) для обмена данными с конечными точками за пределами Azure в пространстве общедоступных IP-адресов, а также конечные точки в Azure, которые не используют конечные точки службы виртуальной сети. Эта ситуация применима только к API серверной части, доступным на общедоступных IP-адресах.

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

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

Устранение рисков и решения

Чтобы решить проблему нехватки портов SNAT, сначала необходимо диагностировать и оптимизировать производительность серверных служб.

Общие стратегии по устранению нехватки портов SNAT обсуждаются в статье Устранение сбоев исходящих подключений документации Azure Load Balancer. Следующие стратегии применимы к службе управлению API.

Масштабирование экземпляра APIM

Каждому экземпляру службы управления API выделяется несколько портов SNAT на основе единиц APIM. Можно выделить дополнительные порты SNAT путем масштабирования экземпляра службы управления API с использованием дополнительных единиц. Дополнительные сведения см. в статье Масштабирование службы управления API.

Примечание.

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

Использование нескольких IP-адресов для серверных URL-адресов

Каждое подключение от экземпляра APIM к тому же IP-адресу и порту назначения серверной службы будет использовать порт SNAT, чтобы поддерживать отдельный поток трафика. Если не будут доступны различные порты SNAT для возврата трафика из фоновой службы, APIM не сможет отделить один ответ от другого.

Так как порты SNAT можно использовать повторно, если конечный IP-адрес или порт назначения отличаются, другой способ избежать нехватки портов SNAT — использовать несколько IP-адресов для URL-адресов серверной службы.

Дополнительные сведения см. в статье Исходящий прокси Azure Load Balancer.

Размещение APIM и серверной службы в одной виртуальной сети

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

Дополнительные сведения см. с статьях Использование службы управления API Azure с виртуальными сетями и Интеграция службы приложений с виртуальной сетью Azure.

Размещение APIM в виртуальной сети и маршрутизация исходящих вызовов в брандмауэр Azure

Подобно размещению APIM и серверных служб в виртуальной сети, вы можете использовать брандмауэр Azure в виртуальной сети с вашей службой APIM, а затем направить исходящие вызовы APIM в брандмауэр Azure. Между APIM и брандмауэром Azure (который находится в одной виртуальной сети) порты SNAT не требуются. Для подключений SNAT к серверным службам брандмауэр Azure имеет 64 000 доступных портов (это намного больше портов, чем выделено экземплярам APIM).

Дополнительные сведения см. в документации по брандмауэру Azure.

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

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

Дополнительные сведения см. в статье Добавление кэширования для повышения производительности в службе управления API Azure.

Рассмотрите вариант реализации политик ограничения прав доступа

Если это подходит для вашего бизнес-сценария, можно реализовать политики ограничения прав доступа для продукта службы управления API. Например, политика rate-limit-by-key может быть использована для предотвращения пиков использования API для каждого ключа, ограничивая частоту вызовов за определенный период времени.

Дополнительные сведения см. в разделе "Ограничения скорости" и "Политики квот".