はじめに
Graph API を触り始めてプログラムを作成し始めると、たまにGraph APIでエラー429が返ってきたりします。
これがスロットリングのエラーになります。
今回は、スロットリングと回避方法について調べた内容を備忘録として記載しようと思います。
スロットリングエラーの原因について
スロットリングのエラーが発生する原因は、一定時間にリクエストが多い場合にサーバー側へ偏った負荷がかからないように制限が設けられています。それがスロットリングのエラーになります。
では、一定時間の間に Graph API がどれくらい送信したらエラーになるのかというと大きく分けて以下の２つのパターンがあるようです。
- あるテナントのすべてのアプリケーションから大量の要求がある
- すべてのテナントで、特定のアプリケーションから大量の要求がある
Graph API毎にも送信する量の閾値が決まっていてるので、下にGraph API毎の閾値が記載されているので、確認してくださいね。
全体的には、10秒間に130,000リクエストとなっていて、後は個別のリクエストでも決まっているので、そちらを参考にしてくださいね。
回避方法
回避方法としては、一定時間にリクエストを送付しなければよいだけですが、例えば、バッチ処理中で行っている処理でTeamsのデータを取得する場合の時にチャネルのデータを呼び出すGraph APIを連続的に送信してしまう場合などがあるので、送信しなくてはいけない場合もあります。
その場合には、マイクロソフトの公開情報ではベストプラクティスが公開されているので、その対応をプログラムで行うのが一番良いと思います。
そのベストプラクティスとは以下と記載されています。
要は一定時間の要求は減らしなさいという事です。
ベストプラクティス
- 要求あたりの操作の数を減らす
- 呼び出しの頻度を減らす
- すべての要求が使用量の制限に計上されるため、即時の再試行を避ける
レスポンス429が返ってきた時のエラー処理を実装する場合には、以下のようになります。
Powershellなどで簡易的なスクリプトを組んでいる場合には、下に記載したエラー処理を実装するよりSloopなどを入れて、少し間隔を変えてリクエストを送信する法が実用的かもしれませんが、Graph APIを使った処理を行う場合には、どちらかの処理は必要になるといえると思います。
- レスポンス429を受け取った際には、その後のリクエストは送信しない
- レスポンス429には、Retry-after 応答ヘッダーの情報があるので、レスポンスエラーに該当するリクエストは、そのRetry-adter 応答ヘッダーに記載されている値だけ、リクエスト送信を待ってから再送します
- 再送が正常終了したら、その後のリクエストを送信するようにします