適用対象: すべての API Management レベル
この記事は、Azure API Management での断続的な接続エラーとそれに関連した待ち時間の問題をトラブルシューティングするのに役立ちます。 具体的には、この記事では、ソース ネットワーク アドレス変換 (SNAT) ポートの枯渇に関する情報とトラブルシューティングについて説明します。 さらにヘルプが必要な場合は、Azure コミュニティ サポートで Azure の専門家に連絡するか、Azure サポートでサポート要求を提出してください。
現象
API Management サービスを介して API を呼び出すクライアント アプリケーションでは、次の 1 つ以上の現象が発生する可能性があります。
- 断続的な HTTP 500 エラー
- タイムアウト エラー メッセージ
これらの現象は、BackendConnectionFailureに のインスタンスとして現れます。
特定の API Management サービス レベルでは、ご利用の API Management インスタンスの [問題の診断と解決>SNAT ポート分析 ] ページで、SNAT ポートの枯渇に関連する診断情報が Azure portal に表示される場合があります。
原因
この現象のパターンは、多くの場合、API Management サービスでの SNAT ポートの制限が原因で発生します。
クライアントが API Management API のいずれかを呼び出すたびに、Azure API Management サービスはバックエンド API にアクセスするために SNAT ポートを開きます。 Azure の送信接続で説明したように、Azure では、ソース ネットワーク アドレス変換 (SNAT) とロード バランサー (顧客に公開されていない) を使用して、パブリック IP アドレス空間内の Azure 外部のエンドポイント、および仮想ネットワーク サービス エンドポイントを使用していない Azure 内部のエンドポイントと通信します。 この状況は、パブリック IP で公開されているバックエンド API にのみ適用されます。
API Management サービスの各インスタンスには、最初に事前に割り当てられた数の SNAT ポートが割り当て済みになっています。 この制限は、同じホストとポートの組み合わせへの接続を開くことに影響します。 SNAT ポートが使い果たされるのは、同じアドレスとポートの組み合わせへの呼び出しを繰り返したときです。 SNAT ポートが解放されると、そのポートは必要に応じて再利用できるようになります。 Azure ネットワーク ロード バランサーは、4 分間待機した後にのみ、閉じた接続から SNAT ポートを回収します。
これらのポートが十分に高速に閉じられ、リサイクルされない場合、API に対するクライアント要求が急速に連続して実行されると、SNAT ポートの事前割り当て済みクォータが使い果たされ、API Management サービスがクライアント要求をタイムリーに処理できなくなる可能性があります。
軽減策とソリューション
SNAT ポートの枯渇を軽減するための一般的な戦略については、Azure Load Balancer ドキュメントの 送信接続エラーのトラブルシューティング を参照してください。 これらの戦略の中で、API Management には次が適用されます。
Azure NAT ゲートウェイを有効にする
API Management の Premium レベルの仮想ネットワーク挿入インスタンスの場合、 Azure NAT ゲートウェイ を有効にして、API Management で既定で使用できる数よりも多くの SNAT ポート (最大 64K) を提供できます。 シナリオでサポートされている場合、このソリューションは、SNAT ポートの枯渇を回避するための最も効果的な方法です。
API Management インスタンスの仮想ネットワークで Azure NAT ゲートウェイを有効にするには、API natGatewayState REST API を使用して、インスタンスの enabled プロパティをに設定します。
Note
- 現在、
natGatewayStateプロパティを設定するには、インスタンスをゾーン設定またはゾーン冗長構成にすることはできません。 - 内部モードで仮想ネットワークに挿入されたインスタンスの場合、NAT ゲートウェイはインターネットへの送信トラフィックに対してのみ機能します。
- Azure NAT Gateway では、追加のコストが発生する場合があります。
NAT ゲートウェイで設定された既定のアイドル タイムアウトは 4 分です。 アイドル タイムアウトは最大 120 分に変更できます。 詳細については、「 NAT ゲートウェイの管理」を参照してください。
アウトバウンド接続に NAT ゲートウェイを使用できない場合は、このセクションで説明する他の軽減オプションを参照してください。
API Management インスタンスをスケーリングする
各 API Management インスタンスには、API Management ユニットに基づいて、多数の SNAT ポートが割り当てられます。 より多くのユニットで API Management インスタンスをスケーリングすることで、より多くの SNAT ポートを割り当てることができます。 詳細については、「 API Management サービスのスケーリング」を参照してください。
Note
SNAT ポートの使用状況は、現在、自動スケーリング API Management ユニットのメトリックとして使用できません。
バックエンド URL に複数の IP を使用する
API Management インスタンスからバックエンド サービスの同じ宛先 IP と宛先ポートへの各接続では、個別のトラフィック フローを維持するために SNAT ポートが使用されます。 バックグラウンド サービスからのリターン トラフィックに対して異なる SNAT ポートがない場合、API Management では 1 つの応答を別の応答から分離する方法はありません。
宛先 IP または宛先ポートが異なれば SNAT ポートを再利用できるため、SNAT ポートの枯渇を回避するもう 1 つの方法は、バックエンド サービス URL に複数の IP を使用することです。
詳細については、送信プロキシの Azure Load Balancer に関する記事を参照してください。
API Management とバックエンド サービスを同じ VNet に配置する
バックエンド API が App Service などの サービス エンドポイント をサポートする Azure サービスでホストされている場合は、API Management インスタンスとバックエンド サービスを同じ仮想ネットワークに配置し、 サービス エンドポイント または プライベート エンドポイントを介して公開することで、SNAT ポート枯渇の問題を回避できます。 共通の VNet を使用して統合サブネットにサービス エンドポイントを配置すると、API Management インスタンスからそれらのサービスへの送信トラフィックがインターネットをバイパスするため、SNAT ポートの制限が回避されます。 同様に、VNet とプライベート エンドポイントを使用する場合、その宛先には、送信 SNAT ポート問題が発生しません。
詳細については、仮想ネットワークで Azure API Management を使用する方法と App Service と Azure 仮想ネットワークの統合に関する記事を参照してください。
API Management サービスを仮想ネットワークに配置し、送信呼び出しを Azure Firewall にルーティングする
API Management とバックエンド サービスを仮想ネットワークに配置するのと同様に、API Management サービスを使用して VNet で Azure Firewall を使用し、送信 API Management 呼び出しを Azure Firewall にルーティングできます。 API Management と Azure Firewall の間 (同じ VNet に配置されている場合)、SNAT ポートは必要ありません。 バックエンド サービスへの SNAT 接続の場合、Azure Firewall には 64,000 個の使用可能なポートがあり、API Management インスタンスに割り当てられる量よりもはるかに多くなります。
詳細については、 Azure Firewall のドキュメントを参照してください。
応答キャッシュとその他のバックエンド パフォーマンスのチューニングを検討する
もう 1 つの潜在的な軽減策は、バックエンド API の処理時間を短縮することです。 これを行う方法の 1 つは、応答キャッシュを使用して特定の API を構成して、API を呼び出すクライアント アプリケーションと API Management バックエンドの負荷の間の待機時間を短縮することです。
詳細については、「キャッシュを追加して Azure API Management のパフォーマンスを向上させる」を参照してください。
アクセス制限ポリシーの実装を検討する
ビジネス シナリオに適している場合は、API Management 製品に対するアクセス制限ポリシーを実装できます。 たとえば、 キーごとのレート制限 ポリシーを使用すると、指定した期間に呼び出しレートを制限することで、キーごとに API の使用が急増するのを防ぐことができます。
詳細については、「 レート制限とクォータ ポリシー 」を参照してください。