Azure API Management での API 呼び出しのパフォーマンスの問題のトラブルシューティング

まとめ

この記事では、バックエンドの待機時間や HTTP 500 エラー、429 エラーなど、API 呼び出しのAzure API Managementパフォーマンスの問題をトラブルシューティングする方法について説明します。 障害を分離し、API の応答時間を向上させるには、次の手順を使用します。

この記事は、Azure API Management トラブルシューティング シリーズ ラボの 4 番目のシナリオです。 API Management トラブルシューティング シリーズのラボ手順に従って、ラボのセットアップを行ってください。

元の製品バージョン: API Management サービス
元の KB 番号: 4464929

症状

API Management の API ProductStore はバックエンド エンドポイント (https://productstoreapp.azurewebsites.net) と通信して、必要に応じてレコードの作成、読み取り、更新、削除を行います。 ただし、次の API 操作を実行すると、パフォーマンスの問題や例外が発生する可能性があります。

Note

最良のテスト結果を得るには、ID が 1 から 3 の 3 つの製品のみを保持します。

  • Products_GetAllProducts 結果を返すには 5 秒かかりますが、予想される応答時間は 1 秒未満です。

  • Products_DeleteProduct操作を使用して、前述の ID (1 ~ 3) の製品を削除すると、HTTP 500 - 内部サーバー エラーが表示され、次のメッセージが表示されます。

    "Message": "エラーが発生しました。"

  • 製品を更新する操作が予期せず調整され、 HTTP 429 - 要求が多すぎます エラーが発生します。 このエラーは、製品 ID と要求本文に関係なく発生します。 たとえば、顧客が次の例を使用して製品 ID を 1 に設定して "Tomato soup" の製品価格を更新すると、HTTP 429 状態コードが取得されます。

    テンプレート パラメーター ID : 1
       リクエスト本文: {"Name": "Tomato soup","Category": "Groceries","Price": 2.45}
       応答本文:
    {
    レート制限を超過しています。 しばらくしてからもう一度試してください。
    }

Troubleshooting

パフォーマンスの問題のトラブルシューティングを行う際に、障害を特定する最善の方法は、各セクション (受信、バックエンド、送信) にかかった時間を示す API Management インスペクター トレースをキャプチャすることです。

Products_GetAllProducts待機時間

この問題について API Inspector トレースを分析すると、バックエンドに最も時間がかかることがわかります (約 5 秒)。 この結果は、バックエンドで多少の遅さや実行時間の長い操作があることを意味します。 次の例は、API Inspector トレースのバックエンド応答時間を示しています。

転送要求
"timestamp": "2018-07-29T16:16:46.6615081Z",
"elapsed": "00:00:05.5844430",
"data": {
"response": {
"status": {
"code": 200,
"reason": "OK" }

バックエンドで低速が発生することを分離したら、Web API アプリケーションのバックエンド アプリケーション コードを調査する必要があります。 バックエンドにアクセスできないシナリオでは、次の例に示すように API Management レベルでキャッシュを実装できます。

    <?xml version="1.0" encoding="UTF-8"?>
    <policies>
       <inbound>
          <base />
          <cache-lookup vary-by-developer="true" vary-by-developer-groups="true" must-revalidate="true" downstream-caching-type="public" />
       </inbound>
       <backend>
          <base />
       </backend>
       <outbound>
          <base />
          <cache-store duration="60" />
       </outbound>
       <on-error>
          <base />
       </on-error>
    </policies>

キャッシュの詳細については、「キャッシュを追加してAzure API Managementのパフォーマンスを向上させる」を参照してください。

Products_DeleteProduct HTTP 500 内部サーバー エラー

この問題については、API Management インスペクター トレースを分析するのと同じ手順に従います。 forward-request応答属性の下に HTTP 500 状態コードが表示される可能性があります。

この状態コードは、バックエンド コードのハンドルされない例外が原因で、バックエンド API が HTTP 500 を返することを意味します。 次の例に示すように、API Management レベルでは問題はありません。

転送リクエスト (841.060 ms)
{ }
"response": {
"status": {
"code": 500,
"reason": "内部サーバー エラー"
}

Products_PutProduct HTTP 429 要求が多すぎますエラー

この問題では、API 呼び出しレート制限に達しているように見えます。 操作レベルで rate-limit または rate-limit-by-key ポリシーが実装されているかどうかを確認します。

このようなポリシーが操作レベルで見つからない場合は、[ 有効なポリシーの計算] を選択します。 このアクションでは、この問題の原因となる可能性のある製品レベルのポリシーなど、さまざまなレベルから継承されたすべてのポリシーが表示されます。

API レベルで実装されているポリシーの中には、実際には API 呼び出しレートが制限されていないものもあります。 代わりに、次の例に示すように、送信セクションのreturn-responseポリシーとset-status ポリシーを使用して、カスタマイズされた応答をクライアントに返すことで、アクションを模倣します。

    <?xml version="1.0" encoding="UTF-8"?>
    <outbound>
       <!--base: Begin Api scope-->
       <return-response>
          <set-status code="429" reason="Too many requests" />
          <set-body><![CDATA[{

    Rate limit is exceeded. Try again after some time.

    }]]></set-body>
       </return-response>
       <!--base: End Api scope-->
    </outbound>
  • Last updated on