レート制限

プライベートAIサービス・コンテナには、異なるカテゴリのエンドポイントに対して、コンテナが処理できる1分当たりのリクエスト数を制御するための構成可能な方法が用意されています。これにより、スケーラビリティが向上し、サービス拒否(DOS)攻撃などの不正使用を防止できます。

コンテナは、2つのタイプのエンドポイントを区別します。それぞれ個別に構成可能なレート制限があります:

• モニター・エンドポイント: 運用モニタリングおよびヘルス・チェックに使用され、/healthや/metricsなどが含まれます。構成ファイルのmonitor_requests_per_min (デフォルト値60)によって制御されます。
• サービス・エンドポイント: /v1/embeddingsや/v1/modelsなど、他のすべてのAPI機能が含まれます。構成ファイルのservice_requests_per_min (デフォルト値3000)によって制御されます。

このように分離することで、ヘルスおよびメトリックのスクレイピングだけでなくモニタリングも、ユーザーまたはクライアント・アプリケーションからの通常のAPIトラフィックの処理能力を妨げないことが保証されます。

コンテナ管理者は、次のように、構成JSONファイルにratelimiterセッションを追加してmonitor_requests_per_minおよびservice_requests_per_minを指定することで、レート制限付きでコンテナを起動できます。

{
  "ratelimiter": {
    "service_requests_per_min": 3000,
    "monitor_requests_per_min": 60
  }
}

この構成ファイルの例では、IPアドレスごとに1分当たり3000件のAPI (サービス)リクエストと、IPアドレスごとに1分当たり60件のモニター(ヘルス、メトリック)リクエストの制限を設定しています。

各IPアドレスは、サービス・グループとモニター・グループの両方で個別に追跡され、カウンタは1分ごとにリセットされます。クライアントが60秒以内に割り当てられた割当て制限を超えた場合、サーバーはHTTP 429 (リクエストが多すぎる)で応答します。このロジックにより、可観測性エンドポイントの応答性を維持しながら、コアAPIが過負荷状態になるのを防ぎます。

リクエストの使用状況をモニターするのに役立つレスポンス・ヘッダーがいくつか用意されています:

• x-ratelimit-limit-requests: エンドポイントに応じて、構成ファイルで定義されている"service_requests_per_min"または"monitor_requests_per_min"と同じです。IPアドレスごとに1分当たりの許容最大リクエスト数を示します。
• x-ratelimit-remaining-requests: 合計リクエスト数がリセットされるまでの残りのリクエスト数を示します。
• x-ratelimit-reset-requests: 合計リクエスト枠が再充填されるまでの残り秒数を示します。

たとえば、service_requests_per_min値が500で、クライアントが最初の25秒で400件のスコアリングまたは推論のリクエストを送信した場合、レスポンスにはx-ratelimit-limit-requests = 500、x-ratelimit-remaining-requests = 100 (500 - 400)およびx-ratelimit-reset-requests = 35s (60秒- 25秒)が含まれます。

monitor_requests_per_minute値が120で、クライアントが最初の15秒で60件のヘルス・チェック・リクエストを送信した場合、レスポンスにはx-ratelimit-limit-requests = 120、x-ratelimit-remaining-requests = 60 (120 - 60)およびx-ratelimit-reset-requests = 45s (60秒- 15秒)が含まれます。