APIMリクエスト数制限の注意点

Pocket

APIMリクエスト数制限の注意点

はじめに

  • Azure API Management の流量制限ポリシーは、API Management の代表的な機能とも言えるほどの、重要なポリシーです。
  • 使い勝手もよく、使うシーンも多いかと思いますが、運用で出くわした面白い現象がありましたので、ちょこっと書いてみます。

FAQ:「ステータスコード 429 が返ってくるのですが・・・」

  • 流量制限ポリシー(代表例として limit-concurrencyrate-limit )を使っていると、時折こんな問い合わせがあります。
  • 当然、流量を制限しているため、過度なリクエストがAPIに対して送られた際には、以下のようなレスポンスが返ってきます
429 Too Many Requests

429 というステータスコードは一昔前はあまり耳馴染みのないコードであったように思いますが、
API利用の普及に伴い、「アクセス数過多なので一時的に利用制限しています」という意味であることは広まっているのかと思います。

対応:診断ログを確認

問い合わせを頂いた後のアクションとしては以下のようなものとなります。

  1. API Management の診断ログを確認する
    • Log Analytics Workspaceからクエリを発行( AzureDiagnostics | where xxx... などとしてクエリ発行)
    • 問い合わせ頂いた時刻付近のリクエスト情報を取得
  2. ステータスコードが 429 となっているログを見つけ、その前後(制限区間内)でどれほどのリクエスト数があったのかを確認
  3. API Management のポリシーを確認、流量制限系のポリシーの制限数と比較し、オーバーしていればその旨を問い合わせ元に伝える

ログを見て、明らかにリクエスト数がオーバーしていれば、上記のアクションで完了…となるわけですが、
実際には、そうならない場合もあります。

流量制限数よりずっと少ないリクエスト数なのに 429 が返ってくる?

結論から書くと、これはリクエストが 滞留 しているために起こる現象でした。

簡潔に説明するため、以下に図を示します。

わかりやすい場合(ログ件数が制限数をオーバーしている場合)

limit

この図は、横軸を時刻としたリクエスト一覧のガントチャートのような図です。

真ん中あたりに制限区間(MAX5件までリクエストOK)を設け、その中にどれだけ処理中のリクエストがあるかを数えます。

この場合は、

  • ログ検索をしてヒットするリクエスト数は 9件(濃い緑色、リクエスト起点の数を数える)
  • この 9件という件数が、制限である 5件 をオーバーしている

・・・ので、 429 エラーとなるのは自明です。

わかりにくい場合(ログ件数が制限数をオーバーしていないが429エラーとなる場合)

limit

では、こちらの場合はどうでしょうか。

  • ログ検索をすると リクエスト起点で検索をかけるため、3件のリクエストしかヒットしません
    • → 制限数の 5件 より少ないのになぜか 429エラーが返ってくる!
  • しかし、実際には 制限区間に入る前に、4件ものリクエストがすでに処理中の状態 となっています。
    • 現実的に考えれば、バックエンドの処理時間にムラがある、NW回線速度の問題・・・など?
    • リクエストが 滞留 してしまっている状態です。

このような事象は、運用上、しばしば起こります。

ログ検索をしてヒットした件数だけでなく、制限区間より前のリクエストについても調べ、

そのリクエストの所要時間(duration)も併せて考慮し、上記のようなガントチャートで考えるとわかりやすいかと思います。

まとめ

  • APIMのリクエスト数制限ポリシーを使う場合には、
    • 診断ログの件数を確認する
    • ログ件数 < 制限数 であるのに 429エラーとなる場合は、制限区間前のリクエストが 滞留 していないか確認する
  • このような事象が、現実でしばしば起こるので、リクエスト数制限値は、実際に運用が始まった後に、変わることもある。
Pocket

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です