レート制限に関するよくある質問
Last Updated:
Okta Workforce Identity Cloud(WIC)とCustomer Identity Solution(CIS)のレート制限に関する質問については、このFAQを参照してください。
目次
一般的な理解
レート制限とは何ですか?
Oktaがレート制限を実装した理由は何ですか?
レート制限ヘッダーにはどのような情報が含まれますか?
バーストレート制限とは何ですか?
レート制限の管理
レート制限の現在のステータスを確認するにはどうすればよいですか?
レート制限に近づいた場合、どのように通知されますか?
どのようにレート制限の使用状況の履歴を確認しますか?
レート制限を超過した場合はどうなりますか。また、レート制限エラーにはどのように対処すればよいですか?
レート制限内に収まるようにアプリケーションを最適化するには、どうすればよいでしょうか?
レート制限はアプリケーションのパフォーマンスにどのように影響しますか?
レート制限の適用方法は地域や国によって異なりますか?
いくつかのAPIのレート制限に違反することが予想される大規模なアクティビティを計画しています。このアクティビティを
パフォーマンスに影響を与えずに管理するにはどうすればよいですか?
デフォルトのレート制限では不十分なため、より高いレート制限が必要だと思います。
使用しているテナントでこれを有効にするには、どのようなプロセスに従う必要がありますか?
ドキュメントとリソース
各APIエンドポイントのレート制限に関する詳細なドキュメントはどこで入手できますか?
一般的な理解
レート制限とは何ですか?
レート制限とは、Oktaのサービスの利用リクエストの頻度を制御するメカニズムで、リソースのフラッディングの防止、公正な使用の確保、サービス拒否攻撃などの悪意のあるアクティビティの防止を実現します。Oktaでは、一般向けエンドポイント全体にレート制限を適用することで、すべてのお客様とテナントでの使用状況を制御できます。Oktaは、レート制限に固定ウィンドウアルゴリズムを使用します。
レート制限の対象となるOkta APIのセットとは別に、Oktaがプラットフォームに適用するレート制限には他にもいくつかのタイプがあります。詳細については製品ドキュメントを参照してください。
orgのレート制限ダッシュボードを信頼できる情報源として使用して、API名のレート制限設定を確認することをお勧めします。
Oktaがレート制限を実装した理由は何ですか?
レート制限は、SaaS業界の標準的な手法であり、サービスの最適なパフォーマンスと可用性を確保するために、さまざまなプロバイダーやベンダーによって使用されています。この機能はOktaに限ったことではなく、サービスの安定性と信頼性を高めるための業界全体の取り組みです。
-
- サービス品質を維持します。レート制限は、一定期間にわたるリクエスト数を制限することで、不正な行動の影響を軽減し、障害から保護し、リソースの効率的かつスケーラブルな使用を促進します。
- 公平な使用を確保します。公平なリソース割り当てにより、単一の組織やユーザーがシステムリソースを独占することがなくなり、すべての人に公平なアクセスが可能になります。また、レート制限は、悪意のあるユーザーが他のユーザーのサービスを低下させる可能性のあるフラッドリクエストを作成する能力を制限することで、悪用を防止します。
- インフラストラクチャを保護します。レート制限は、トラフィックの急激な増加を管理しながら、リクエストのバランスの取れた負荷分散を維持するのに役立ちます。受信リクエストのレートを制限することで、偶発的または意図しないリクエストフラッディングの影響を軽減することもできます。
レート制限ヘッダーにはどのような情報が含まれますか?
APIリクエストを実行すると、Oktaは現在のレート制限ステータスに関する情報を提供する次のような特定のヘッダーを返します。
-
- X-Rate-Limit-Limit:現在のリクエストに適用されるレート制限の上限。
- X-Rate-Limit-Remaining:現在のレート制限ウィンドウに残っているリクエスト数。
- X-Rate-Limit-Reset:UTC epoch時間で指定される、レート制限がリセットされる時刻。
たとえば、APIエンドポイントに次のレート制限があるとします。
レート制限:1分あたり1000リクエスト
APIレスポンスで次のx-headerを受信した場合:
-
- X-Rate-Limit-Limit: 1000
- X-Rate-Limit-Remaining: 0
- X-Rate-Limit-Reset: 1731007800
これで、次のことがわかります。
-
- テナントは、そのAPIに許可されている1000件のリクエストのうちすべてを使い果たし、レート制限ウィンドウに残っているリクエスト数は0です。
- この固定時間ウィンドウ内で行われる新しいリクエストは、レート制限を超えたため拒否されます。
- 新しいリクエストは、レート制限がリセットされる1731007800(2024年11月7日午後7:30:00 UTC)以降に行うことができます。
バーストレート制限とは何ですか?
Oktaは、デフォルトのエンドポイントレート制限に違反するリクエストレートに対して追加の許容量を提供することで、お客様へのサービスとしてバーストレート制限を導入しました。この機能は、計画外のトラフィックの急増がユーザーエクスペリエンスに影響を与えるリスクを軽減するのに役立ちます。バーストレート制限は、認証および認可エンドポイントでのみデフォルトでアクティブになっています。
組織がバースト対応エンドポイントのデフォルトのレート制限を超過した場合、orgは警告とバースト通知を受信します。この時点でバーストバッファが適用されます。バーストレートのしきい値を超えると違反が発生し、以下に述べるような結果になります。
次のバーストレート制限の例では、基本(デフォルト)しきい値は1000で、バーストレートは基本レートの5倍、つまり5000に設定されています。
バーストレート制限が適用された場合のAPI応答のx-headerは、次の値を持ちます。
-
- X-Rate-Limit-Limit: 1000
- X-Rate-Limit-Remaining: 1
- X-Rate-Limit-Reset: 1731007800
注:バーストレート制限は保証されるものではなく、特定の時点でのシステム容量に依存します。バーストレート制限を常に使用しているお客様は、サービス中断のリスクを軽減するためにDynamicScaleの購入をご検討ください。
レート制限の管理
レート制限の現在のステータスを確認するにはどうすればよいですか?
- Admin Consoleのウィジェット。OktaのAdmin Consoleには、管理者が過去24時間または過去7日間のレート制限の警告と違反を追跡できるレート制限モニタリングウィジェットが用意されています。リストされている違反をクリックするか、[表示]を選択すると、管理者はレート制限ダッシュボードにアクセスできます。
- レート制限ダッシュボード。管理者がレート制限の消費をプロアクティブに監視し、潜在的なレート制限の問題を調査するのに役立つように、Admin Consoleのダッシュボードが提供されています。
- レート制限HTTP応答ヘッダー。レート制限をレポートするための3つのヘッダー(X-Rate-Limit-Limit、X-Rate-Limit-Remaining、X-Rate-Limit-Reset)があります。応答内の関連するヘッダーをチェックして、レート制限を監視できます。
- 通知。警告、バーストレート、および違反のしきい値を超えた場合には、Okta System Logを介した通知とシステム管理者へのメール通知を行います。Okta Admin Consoleにもバナー警告が表示されます。イベントフックを使用して、通知をアクティブに監視し、対応することもできます。
レート制限に近づいた場合、どのように通知されますか?
- SysLog、ウィジェット、メール通知。デフォルトでは、適用可能なすべてのAPIに対して60%の警告しきい値が設定されています。警告しきい値を超えると警告通知が生成されます。警告は、生成されたSystem Logイベント、Admin Consoleのレート制限モニタリングウィジェットのエントリー、Oktaスーパー管理者へのメール通知で表示されます。同様に、違反が発生すると、同じチャネルを介して違反通知が生成されます。
- レート制限ダッシュボードの通知。System Logのすべてのレート制限通知(警告、違反、バースト)も、レート制限ダッシュボード上にリンクとともに一覧表示されます。
- カスタム通知。Oktaでは、イベントフックを利用してレート制限の警告と違反をプロアクティブに監視することを推奨しています。一般的なユースケースは、Slackなどの統合メッセージングプラットフォームで通知を生成するワークフローイベントトリガーです。
どのようにレート制限の使用状況の履歴を確認しますか?
システムログデータは、Oktaプラットフォームに最長で3か月間保持され、この期間のレート制限関連のログイベントの確認に使用できます。レート制限ダッシュボードのすべてのイベント(警告、バースト、違反)を過去24時間、過去7日間、先月、または過去3か月に分割することもできます。レート制限ダッシュボードでAPI名をクリックすると、最長過去8日間までの使用量の1分ごとの詳細ビューが表示されます。
レート制限を超過した場合はどうなりますか。また、レート制限エラーにはどのように対処すればよいですか?
定義されたレート制限を超過すると、「HTTP 429 Too Many Requests(HTTP 429 リクエストが多すぎます)」ステータスコードが返され、リセット時刻までそれ以降のすべてのリクエストの処理が停止されます。APIを使用している場合、ヘッダー応答にはX-Rate-Limit-Resetが含まれ、次のリクエストを行うまでの待機時間をクライアントに通知します。また、前述の通知タッチポイントを通じて、警告と違反イベントの通知を受け取ります。APIによっては、違反通知を受け取る前にburst rate limit applied(バーストレート制限が適用されます)通知を受け取る場合もあります。
再試行を最適に管理するための手法を実装することをお勧めします。指数関数的バックオフを使用した再試行ロジックは、このようなアルゴリズムの一例です。このシナリオでは、レート制限に達すると、クライアントはリクエストの再試行までの待機時間を徐々に長くします。このアプローチでは、X-Rate-Limit-Resetヘッダーが確実に守られるようにして、ウィンドウがリセットされる時間を確保することで、継続的に制限に達するリスクが軽減されます。
レート制限内に収まるようにアプリケーションを最適化するには、どうすればよいでしょうか?
- Oktaでは、ベストプラクティスを使用して、応答のキャッシュ、バッチジョブリクエストの作成、指数関数的バックオフの使用、冗長な呼び出しの最小化などの手法でAPI呼び出しを最適化することを推奨しています。
- APIキャッシュはAPI応答のコピーを保存して将来のリクエストを高速化し、データを繰り返し取得する必要性を減らすことで、全体的なパフォーマンスを向上させます。たとえば、ユーザーのデバイスにデータを一時的に保存することで、クライアント側のキャッシングを実装できます。
- limitクエリパラメーターを、この機能をサポートする個々のAPIエンドポイントに対して使用することもできます。APIエンドポイントあたりのリクエスト数は、デフォルトのlimit値を最大値まで増やすことで減らすことができます。
- たとえば、API /api/v1/logsに対するHTTP GETリクエストはデフォルト値の100に設定されます。ログのボリュームが多い場合は、デフォルト設定を最大値(1000)まで増やすことをお勧めします。詳細については、こちらをご覧ください。
- また、必要に応じてクライアントベースのレート制限を利用することをお勧めします。クライアントベースのレート制限を有効にすると、各クライアントからのリクエストを追跡し、割り当てられたレート制限に制限できます。詳細については、こちらをご覧ください。
同じAPIによって頻繁に違反が発生する場合は、アプリケーション側に適切なキャッシュと冗長性対策が講じられていないことを示していることに注意してください。このような場合は、提案されたベストプラクティスに従って設計を見直して調整することをお勧めします。
レート制限はアプリケーションのパフォーマンスにどのように影響しますか?
アプリケーションがレート制限を超えると、429エラー応答を受信し、リセット時刻までその特定のエンドポイントに追加のリクエストを送信できなくなります。これにより、Oktaとの信頼性の高いやり取りに依存している他のアプリやユーザーに混乱を招く可能性があります。アプリケーション間での公正かつ公平なアクセスを確保するため、Oktaではトークンとアプリケーションのレート制限を提供しています。これを使用して、トークンまたはアプリが使用できる組織全体のレート制限を管理できます。良好なユーザーエクスペリエンスを維持するためには、これらの応答を適切に処理することが重要です。
レート制限の適用方法は地域や国によって異なりますか?
いいえ。
いくつかのAPIのレート制限に違反することが予想される大規模なアクティビティを計画しています。パフォーマンスに影響を与えずにこのアクティビティを管理するには、どうすればよいですか?
計画されているアクティビティが、データの読み込みまたは処理を行う制御されたAPIイベントである場合、レート制限の管理についてOktaのベストプラクティスに従うことをお勧めします。デフォルトのレート制限を遵守し、リクエストレートが想定される範囲内に収まるように管理します。
計画したアクティビティの管理が著しく難しい場合(エンドユーザーへの影響を予測するのが難しいマーケティングイベントなど)は、Oktaにお問い合わせいただくことをお勧めします。このような計画的で頻繁には発生しないアクティビティは、一時的にレート制限を引き上げてもよいユースケースの例となります。ただし、引き上げのビジネス上の正当性を慎重に確認することをお勧めします。レート制限の引き上げリクエストプロセスについては、こちらに従い、イベントの15営業日前までにリクエストが届くようにしてください。
デフォルトのレート制限では不十分なため、より高いレート制限が必要だと思います。使用しているテナントでこれを有効にするには、どのようなプロセスに従う必要がありますか?
レート制限の引き上げが必要な場合は、2つの選択肢があります。
-
- 一時的なリクエストの場合:
- デフォルトのレート制限がニーズを満たさないことに気付いた場合、Oktaに一時的なレート制限の引き上げをリクエストできます。このようなリクエストは、ユースケースとビジネス上の正当性に基づいて評価されます。ビジネス上の正当性を裏付けるために、過去のユースケースやデータ(昨年の感謝祭セールの違反イベントなど)を根拠として使用することが推奨されます。一時的なレート制限引き上げをリクエストするプロセスについては、こちらをご覧ください。リクエストは、レート制限の引き上げが必要となる開始日の15営業日前までに受理される必要があります。各リクエストは個別に評価されます。以前のリクエストが承認されたからといって、今後の承認が保証されているわけではありません。Oktaは、サービスレベルを維持するプロセスにおいて、予告なしに制限を増減する場合があります。Oktaは、悪用、スパム、サービス拒否攻撃などのセキュリティ上の問題を防ぐために、その他の機能をレート制限する権利を留保します。
- 恒久的なリクエストの場合:
- CISのお客様:
- 認証および認可エンドポイントのみに高いレート制限が必要なCISのお客様は、組織ごとにDynamicScaleアドオンサービスを購入できます。DynamicScaleは、購入したティア乗数に応じて、デフォルトのレート制限を最大1000倍に引き上げます。このアドオンは、本番環境組織またはプレビュー組織向けに購入できます。DynamicScaleは、認証および認可エンドポイントのサブセットにのみ適用できます。orgのレート制限ダッシュボードでAPI名を確認し、DynamicScaleの設定を確認できます。
- その他のエンドポイントについては、CISのお客様は、ここで説明するプロセスを使用してレート制限の引き上げリクエストを提出できます。一時的なレート制限は選択肢にならない理由について、詳細なユースケースとビジネス上の正当性を提出する必要があります。各リクエストは個別に評価され、承認は保証されません。以前のリクエストが承認されたからといって、今後の承認が保証されているわけではありません。Oktaは、各リクエストがシステムパフォーマンスおよび利用可能な容量に与える影響を、提出時に評価します。
- WICのお客様:
- WICのお客様の場合、購入したUniversal Directoryライセンスの量に基づいてWorkforce乗数が組織に適用されます。Workforce乗数は、認証および認可エンドポイント向けのみに高いレート制限を付与します。Workforce乗数の詳細については、こちらをご覧ください。
- Workforce乗数エンドポイントまたはその他のエンドポイントでレート制限の引き上げが必要な場合は、こちらで説明されているレート制限の引き上げリクエストプロセスに従ってリクエストできます。一時的なレート制限は選択肢にならない理由について、詳細なユースケースとビジネス上の正当性を提出する必要があります。各リクエストは個別に評価され、承認は保証されません。以前のリクエストが承認されたからといって、今後の承認が保証されているわけではありません。Oktaは、各リクエストがシステムパフォーマンスおよび利用可能な容量に与える影響を、提出時に評価します。
- CISのお客様:
- 一時的なリクエストの場合:
注:DynamicScaleの対象となるエンドポイントに対して一時的な引き上げリクエストが継続的に行われる場合、Oktaはそのリクエストを拒否し、お客様にDynamicScaleの購入を検討するためにアカウントチームに連絡するよう求める場合があります。
