レート制限（Indeed PLUS）
Indeed PLUS API のレート制限を管理します。
過剰な API 呼び出しは Indeed のサービスを妨げる可能性があります。プラットフォームとその利用者を保護するため、Indeed はレート制限を使用しています。
レート制限は、一定期間内にクライアントが実行できる API 呼び出しの総コストに上限を設けます。これにより、Indeed のシステム、顧客、パートナーを保護できます。
Indeed PLUS APIを呼び出すと、5,000ミリ秒後にタイムアウトとなります。
Job Sync API のレート制限 もご覧ください。
レート制限の仕組み
クライアン トが GraphQL の操作を実行すると、Indeed はその操作のコストを測定します。各クライアントには予算があります。60 秒以内の操作の総コストがその予算を超えると、Indeed はそのクライアントにレート制限を適用します。
クライアントにレート制限が適用されると、Indeed は以降の操作をブロックし、HTTP ステータスコードを返します。
Indeed は操作コストをローリング合計で追跡します。クライアントが操作を実行してから 60 秒後に、その操作のコストはローリング合計から削除されます。これにより、他の呼び出しに使える容量が空きます。
各クライアントには独自のローリング合計があります。クライアント間で合計は共有されません。Indeed は、さまざまなクライアントのニーズに対応するため、容量の異なる複数のティアを提供しています。
この例は、最大容量が 100 の Indeed PLUS API に対するレート制限を示しています。
単位は説明のためのものです。
| 時刻 | パートナーの操作 | コスト | Indeed からのレスポンス | ローリング合計 最大容量: 100 |
|---|---|---|---|---|
| 12:00:00 | 操作なし | 0 | レスポンスなし | 0 |
| 12:00:30 | Call A | 50 | 成功 | 50 |
| 12:01:00 | Call B | 50 | 成功 | 100 （容量上限） |
| 12:01:15 | Call C | 10 | エラー | 100 （容量上限） |
| 12:01:30 | 操作なし | Call A がローリング合計から削除される | 50 |
自分のレート制限
Indeed は、各クライアントのニーズに応じて、特定のレート制限を持つティアを割り当てます。利用可能なティアは複数あります。
クライアントにレート制限が適用されるとどうなるか
クライアントがレート制限を超えると、以降の各呼び出しは HTTP 429 response status code を返します。クライアントがレート制限を超えた後、Indeed は API 呼び出しを処理しません。
連携では、レート制限に対応できるようにしてください。すべてのクライアントに適した単一の方法はないため、顧客のニーズに合う方法を選んでください。
クライアントにレート制限が適用されている場合は、Indeed の担当者に連絡し、トラフィックの見積もりを共有してください。ティアの変更を支援できます。
レート制限から復旧する
クライアントにレート制限が適用されている場合:
- 以降の API 呼び出しは、ローリング合計から十分な操作コストが失効するまでブロックされ、HTTP 429 を返します。
- クライアントがレート制限を超えた後、Indeed は API 呼び出しを処理しません。コストが下がるまで、以降の呼び出しはブロックされたままです。
これを解消するには、次を実施してください。
- リクエストパターンを確認する: プロセスが API 呼び出しを過剰に実行していないか確認します。
- ベストプラクティスを実装する: 推奨事項については、レート制限を回避する をご覧ください。
- Indeed の担当者に連絡する: トラフィックの見積もりを共有し、ティア変更の支援を受けます。
レート制限に近づいているかを知る
次のような状況では、トラフィックが増加してレート制限につながる場合があります。
- 自然で緩やかな増加: Indeed から詳細を連絡する場合があります。
- 急な増加: ローンチやキャンペーンなどの正当なトラフィックの場合もあれば、バグや悪意のある主体による不正なトラフィックの場合もあります。Indeed は原因を常に特定できるとは限らないため、そのトラフィックを不正とみなしてクライアントにレート制限を適用する場合があります。正当な急増が見込まれる場合は、次のセクションをご覧ください。
トラフィックの増加が見込まれる場合に、レート制限の影響を避ける
リクエスト量が安定している場合や徐々に増加している場合、操作の種類と内容が安定しており、このドキュメントのベストプラクティスに従っていれば、クライアントにレート制限が適用される可能性は低くなります。クライアントが上限に近づくと、Indeed から詳細を連絡する場合があります。
リクエスト量が 25% 以上増加すると見込まれる場合や、操作の種類または内容に大きな変更がある場合は、2 週間前までに Indeed に連絡してください。影響の見積もりに役立つ、次のようなデータを共有してください。
-
リクエスト数の増加:
- ピーク時の追加リクエスト数
- 関係する操作
- 増加の期間
-
操作の種類と内容の大きな変更を説明する:
- 関係する操作
- 操作例
レート制限を回避する
レート制限の可能性を下げるには、次のベストプラクティスに従ってください。
ログを記録して監視する
すべてのリクエストの結果をログに記録し、監視します。特に、各レスポンスの HTTP ステータスを監視してください。ステータスが 2xx の成功コードではない場合は重要です。これにより、レート制限を検知しやすくなります。
ボットを検知してブロックする
ボットによる不正利用が疑われる場合のアラートを設定します。アラートを受け取ったら、必要に応じてそのボットからのリクエストをブロックしてください。理想的には、影響を抑えるために自動でブロックします。
ユーザー入力を検証する
無効なリクエストがローリングコスト合計に追加されないように、ユーザー入力を検証してください。
最小限のデータをクエリする
必要なデータだけをリクエストしてください。これにより、各操作のコストが下がります。
クローラーのクロール頻度を下げる
Googlebot などの正当なクローラーを想定している場合や受け入れている場合でも、高負荷時のレート制限を避けたい場合は、クロール頻度の制限を検討してください。詳細については、Reduce the Googlebot crawl rate をご覧ください。
再試行までに待機する
システムで失敗したリクエストをリトライする場合は、レート制限が発生したときにリトライ間隔を長くし、リトライ回数を減らしてください。