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