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

[アーティクル]
04/13/2024

Azure API Management トラブルシューティングシリーズに関するブログを参照して、これはラボの 4 番目のシナリオです。問題を再現するには、この手順に従ってラボのセットアップ手順に従っていることを確認します。

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

現象

APIM の API ProductStore はバックエンドエンドポイント (https://productstoreapp.azurewebsites.net) と通信して、必要に応じてレコードを簡単に作成、読み取り、更新、削除します。ただし、以下に示す API 操作の呼び出し中に、パフォーマンスの問題や例外が発生する可能性があります。テストを容易にするために、ID が 1 ~ 3 の 3 つの製品のみを保持します。

Products_GetAllProducts API 関数の 1 つは、結果を返すために 5 秒かかっています。一方、予想される応答時間は 1 秒未満です。
上記のいずれかの ID (1 から 3) を持つ製品を削除するときに、Products_DeleteProduct操作を呼び出すことで、HTTP 500 - 内部サーバーエラー と次のメッセージが表示されます。

{
"Message": "エラーが発生しました。
}
製品を更新するProducts_PutProduct操作が予期せず調整され、HTTP 429 がスローされます。要求で送信する製品 ID と要求本文に関係なく、次のエラーメッセージを含む要求が多すぎます。たとえば、顧客が製品 ID = 1 の "Tomato Soup" の製品価格を以下の Json 本文で更新すると、HTTP 429 状態コードが取得されます。

テンプレートパラメーター ID : 1
要求本文: {"Name": "トマトスープ","Category": "Groceries","Price": 2.45}
応答本文:
{
レート制限を超えています。しばらくしてからやり直してください。
}

トラブルシューティングの手順

パフォーマンスの問題のトラブルシューティング中に、エラーの分離手法として最適な方法は、[各セクション (受信/バックエンド/送信) にかかった時間を示す [APIM インスペクタートレース] をキャプチャすることです。
最初の問題について API Inspector トレースを分析すると、[バックエンド] セクションでほとんどの時間 (約 5 秒) がかかっています。つまり、バックエンドで実行速度が低下したり、実行時間が長くなったりします。

"source": "forward-request",
"timestamp": "2018-07-29T16:16:46.6615081Z",
"elapsed": "00:00:05.5844430","data": {
"response": {
"status": {
"code": 200,
"reason": "OK"
}
遅さがバックエンドにあることを分離したら、Web API アプリケーションのバックエンドアプリケーションコードを調査する必要があります。バックエンドにアクセスできないシナリオでは、次のように APIM レベルでキャッシュを実装できます。 Azure 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>
```
2 番目の問題 (HTTP 500 - 内部サーバーエラー) については、APIM インスペクタートレースを分析するのと同じ手順に従います。"forward-request" 応答属性の下に HTTP 500 状態コードが表示されます。
これは、バックエンドコードで未処理の例外が発生したため、バックエンド API が HTTP 500 を返したことを意味します。APIM レベルでは問題はありません。

forward-request (841.060 ms)
{
"response": {
"status": {
"code": 500,
"reason": "内部サーバーエラー"
}
3 番目の問題 (HTTP 429 - 要求が多すぎます) では、API 呼び出しレート制限に達しているように見えます。おそらく、操作レベルで実装されている "レート制限" または "キーごとのレート制限" ポリシーがある場合は、チェックできます。
このようなポリシーが操作レベルで見つからない場合は、[ 有効なポリシーの計算 ] ボタンをクリックします。このボタンをクリックすると、この問題の原因となる可能性のあるポリシーが製品レベルにある場合など、さまざまなレベルから継承されたすべてのポリシーが表示されます。
ここで、一部のポリシーは API レベルで実装されており、API 呼び出し速度は実際には制限されませんが、カスタマイズされた応答を送信セクションで 'return-response' ポリシーと 'set-status' ポリシーを使用してクライアントに返すことによって、そのアクションを模倣しています。
```
<?xml version="1.0" encoding="UTF-8"?>
<outbound>
   
   <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>
   
</outbound>
```

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティサポートにお問い合わせください。 Azure フィードバックコミュニティに製品フィードバックを送信することもできます。

次の方法で共有

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

現象

トラブルシューティングの手順

お問い合わせはこちらから

フィードバック

フィードバック

その他のリソース