レート制限（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 | 呼び出しA | 50 | 成功 | 50 |
| 12:01:00 | 呼び出しB | 50 | 成功 | 100 （上限到達） |
| 12:01:15 | 呼び出しC | 10 | エラー | 100 （上限到達） |
| 12:01:30 | アクションなし | ローリング合計から呼び出しAを削除 | 50 |
レート制限はどのくらいですか？
Indeedは、クライアントのニーズに応じて、各クライアントに特定のレート制限のティアを割り当てます。さまざまなクライアントに対応するため、複数のティアが用意されています。
クライアントがレート制限の対象になるとどうなりますか？
レート制限を超えると、それ以降の各呼び出しはHTTP 429レスポンスステータスコード（リクエスト過多）を返します。クライアントがレート制限を超えた後に行われたAPI呼び出しを、Indeedは処理しません。
レート制限の対象になった場合の処理を必ず実装してください。すべてのクライアントに当てはまる単一の方法はないため、顧客のニーズに合った方法で対応してください。
レート制限の対象になっている場合は、Indeed担当者に連絡し、トラフィックの見積もりを提供してください。担当者がティアの変更を支援できます。
レート制限から復旧するにはどうすればよいですか？
現在レート制限の対象になっている場合：
- レート制限を超えるそれ以降のAPI呼び出しは、60秒間隔でブロックされ、HTTP 429エラーを返します。
- クライアントがレート制限を超えた後に行われたAPI呼び出しを、Indeedは処理しません。コストが減少するまで、それ以降の各呼び出しはブロックされます。
これを解決するには、次を実施します。
- リクエストパターンを確認する：プロセスが過剰なAPI呼び出しを行っていないか確認します。
- ベストプラクティスを実装する：推奨事項については、レート制限を回避するにはどうすればよいですか？をご覧ください。
- Indeed担当者に連絡する：トラフィックの見積もりを提供して、ティアの変更を支援してもらいます。
レート制限が近いことを知るにはどうすればよいですか？
レート制限の対象となりうるトラフィック増加のシナリオは、次の2つです。
- 自然な漸増：Indeedから詳細を連絡することがあります。
- 急増：ローンチやキャンペーンなどの正当なトラフィックの場合もあれば、バグや悪意あるアクターによるトラフィックなど不正なものの場合もあります。Indeedが根本原因を特定するのは難しいため、Indeedはトラフィックを不正と仮定してレート制限を適用する可能性があります。正当なトラフィックの急増が見込まれる場合は、次のセクションをご覧ください。
トラフィックの増加が見込まれます。レート制限がビジネスに影響しないようにするにはどうすればよいですか？
リクエスト数が安定または徐々に増加しており、操作の種類と 内容が安定しており、本ドキュメントに記載のベストプラクティスを実装していれば、ほとんどの場合レート制限の対象にはなりません。レート制限が近づくと、Indeedから詳細を連絡することがあります。
リクエスト数が25%以上増加すると見込まれる場合、または操作の種類や内容に大幅な変更が見込まれる場合は、発生予定日の2週間前にIndeedにご連絡ください。次のような、影響の見積もりに役立つデータを提供してください。
-
リクエスト数の増加：
- ピーク時の追加リクエスト数
- 関係する操作
- 増加の期間
-
操作の種類と内容の大幅な変更：
- 関係する操作
- 操作のサンプル
レート制限を回避するにはどうすればよいですか？
レート制限を回避するため、次のベストプラクティスを検討してください。
ログとモニタリング
すべてのリクエストの結果をログに記録してモニタリングします。特に、レスポンスのHTTPステータスが2xx成功コード以外の場合は注意してモニタリングします。これにより、レート制限の対象になっていることを検知しやすくなります。
ボットを検知してブロックする
ボットの不正利用が疑われる場合のアラートを設定します。アラートを受信したら、ボットのリクエストをブロックするなどの対応を行います。影響を最小限に抑えるため、理想的にはこのようなボットからのリクエストは自動的にブロックします。
ユーザー入力を検証する
不正なリクエストがローリングコスト合計に追加されないよう、ユーザー入力を検証します。
必要最小限のデータをクエリする
必要なものだけをリ クエストして、操作ごとのコストを下げます。
クローラーのクロール頻度を下げる
Googlebotなどの「良い」クローラーが想定されている、あるいは歓迎している場合でも、レート制限の原因になることが懸念されるなら、高負荷時にクロール頻度を制限することを検討してください。詳細については、Googlebotのクロール頻度を下げるをご覧ください。
リトライ前に待機する
リクエストが失敗した場合にリトライするロジックを実装していることがあります。レート制限の対象になっている場合は、リトライの間隔を長くし、リトライ回数を減らすことを検討してください。