> ## Documentation Index > Fetch the complete documentation index at: https://auth0.com/llms.txt > Use this file to discover all available pages before exploring further. # レート制限ポリシー > Auth0のレート制限ポリシーについて説明します。 Auth0は、最適なパフォーマンスを維持し、不正利用や技術的な問題、過剰なトラフィックから保護するために、サービスの使用を制限しています。Auth0による制限の仕組みを確認して、最高のユーザーエクスペリエンスを提供できるようにアプリケーションを構成することをお勧めします。 アカウントに適用されるレート制限については、「[レート制限の構成](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)」にあるレート制限ポリシーの表を参照してください。 ## レート制限について Auth0は、過剰な数の要求からサービスを保護し、サービスの中断・低下から顧客を守るために、制限を適用しています。 Auth0は、観察した上で、以下を含む一連の制限を適用します。 * 環境への要求（プライベートクラウドのみ） * APIまたはAPIエンドポイントを介したテナントへの要求 * その他の制限 ### 環境要求の制限（プライベートクラウドのみ） プライベートクラウドでは、プライベートクラウドのパフォーマンス階層に基づいて環境要求が制限されます。詳細については、「[AWSのプライベートクラウド](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-aws)」または「[Azureのプライベートクラウド](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-azure)」をお読みください。 現在、プライベートクラウド環境のレート制限は、Auth0製品がSLAを満たす範囲での最大負荷に設定されています。しかし、Auth0は、現時点では環境内の特定のテナントにのみレート制限を課し、制限を超えると顧客に通知しています。プライベートクラウドのほとんどのユースケースでは、顧客が1つの運用テナントを管理しているため問題になりませんが、複数の運用テナントをセットアップしている場合には、環境にあるすべてのテナントで予期される負荷を考慮しなくてはならないため、モニタリングを追加で実装することになります。 たとえば、あるPerformance Plus環境のレート制限が1500 rpsだとしましょう。この環境では、クライアントに1400 rpsでサービスを提供するテナントと、900 rpsで提供するテナントの2つを作成することができます。どちらのテナントもレート制限を超えていませんが、環境全体の負荷は2300 rpsとなり、レート制限を800 rps超過しています。その結果、ユーザーエクスペリエンスの質が低下し、環境の可用性が公開されているSLAを下回ってしまう可能性があります。 環境のレート制限を超過すると、サービスレベル合意（SLA）が無効になります。 プライベートクラウドでの負荷テストで考慮するべき事柄については、「[AWSのプライベートクラウド](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-aws)」と「[Azureのプライベートクラウド](/docs/ja-jp/deploy-monitor/deploy-private-cloud/private-cloud-on-azure)」を参照してください。 ### テナントでの要求の制限 Auth0は、テナントで実行できる要求の数を制限しています。これらの制限は、APIに応じて、さらには各APIのエンドポイントに応じて構成されています。 #### APIレート制限 Auth0はAPIのエンドポイントにかかわらず、特定のAPIに対する要求の数を制限しています。APIの制限は以下に応じて異なります。 * API * 認証 * 管理 * 本番、開発、ステージング） * （無料、エッセンシャル、プロフェッショナル、エンタープライズのパブリック、プライベート） たとえば、無料の非本番テナントの制限は有料サブスクリプションの本番テナントの制限とは異なります。特定のレート制限の構成については、「[レート制限の構成](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations)」を参照してください。 ### ユーザー要求 1つのエンドユーザー要求（ログインやサインアップなど）では通常、Authentication APIのエンドポイントに対して複数の要求が開始されます。エンドユーザー要求とAuthentication APIのエンドポイントに対する要求数の比率はいくつかの要因に依存します。 * 認証されているエンティティ（マシン、エンドユーザーの携帯電話、デスクトップアプリケーションなど） * 認証エクスペリエンス（新しいユニバーサルログイン、クラシックログインなど） * 認証フロー（ログイン、サインアップ、パスワード変更など） * 認証フローの種類（ユーザー名/パスワードでのログイン、ソーシャルログインを使ったログイン、既存の認証トークンがすでに存在するときのログインなど） 拡張性を活用している顧客が、拡張性の構成によってはAuthentication APIだけでなく、Management APIに対しても、さらに要求を追加する可能性があります。 Auth0の構成がAPIの使用に与えるかもしれない影響を推定する方法については、「[レート制限のユースケース](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-use-cases)」を参照してください。 #### エンドポイントのレート制限 Auth0は、APIエンドポイントに対して行われる要求の数を制限しており、エンドポイント運用の数を制限していることもあります。APIエンドポイントでの制限も以下によって異なります。 * API * テナントタイプ * サブスクリプションレベル たとえば、無料の非運用テナントに対する制限は、有料のサブスクリプションを持つ運用テナントとは異なります。 ### テナントでの要求の制限順序 テナントに対して要求が行われると、Auth0は、まずAPI全体の制限と、次に特定のAPIエンドポイントの制限と照らし合わせて、要求を評価します。 ### その他の制限 #### データベースのログイン制限 データベース接続の場合、ユーザーアカウントやIPアドレスによっては、ある種のログイン試行の反復が制限されます。Auth0は、システムの全体的な健全性を保護するために、ユーザー/パスワードのレート制限を適用して負荷を軽減します。Auth0を過度にカスタマイズすると、サービスの質が低下する可能性があります。これは次のような原因で起こります。 * 負荷の高いストレステスト * ベンチマークテスト * ユーザーに何度もログインを要求する非効率なコード Auth0 APIの各ポリシーに記載されているように、要求に制限が適用されます。 また、同一ユーザーのログインに対するレート制限もあります。1つのIPアドレスが同一のユーザーアカウントへ1分間に20回のログイン試行を行うと、レート制限が適用され、そのユーザーに対して許可されるログイン試行は1分当たり10回になります。この制限数には、成功と失敗両方のログイン試行がカウントされます。 Auto0の[［Brute-force Protection（総当たり攻撃防御）］](/docs/ja-jp/secure/attack-protection/brute-force-protection)や[［Suspicious IP Throttling（不審なIPのスロットリング）］](/docs/ja-jp/secure/attack-protection/suspicious-ip-throttling)でもログインやサインアップを制限できますが、それらはレート制限から独立したものです。Auth0がどのように潜在的な不正行為を検出・処理しているかについては「[攻撃防御](/docs/ja-jp/secure/attack-protection)」をお読みください。 #### 多要素認証でのSMSメッセージの制限（エンドユーザーのみ） 1時間に10以上のSMSメッセージをデバイスへ送信しようとすると、レート制限の例外を知らせるエラーメッセージが届きます。 メッセージの制限を超えた場合、最初のメッセージ要求から少なくとも1時間待たないと、次のメッセージ要求を行えません。1時間が経過するごとに、1回の試行が許可されます。 #### ネイティブのソーシャルログインの制限 ネイティブのソーシャルログインフローの要求に適用される制限は、要求のボディーに基づいて特定され、以下の基準に従います。 | 要求の種類 | 本文 | | -------------------- | ---------------------------------------------------- | | `grant_type` | `urn:ietf:params:oauth:grant-type:token-exchange` | | `subject_token_type` | `http://auth0.com/oauth/token-type/apple-authz-code` | #### パブリックパフォーマンス パブリックパフォーマンスオファリングは、エンタープライズサブスクリプションに利用できるアドオンで、既存のパブリッククラウドのデプロイメントを拡張します。このオファリングにより、1ヵ月​に48時間までAuthentication APIの要求制限をエンタープライズのデフォルト要求制限100 RPSの乗数へ動的に増やすことが許可されます。 このアドオンは、Authentication APIの要求制限のみを拡張し、Management APIや、Authentication APIの範囲外でレート制限されているその他のエンドポイントには適用されません。 現在、3つのパブリックパフォーマンス修飾子（2x、3x、4x）があり、1ヵ月​に48時間までAuthentication APIにそれぞれ200、300、400 RPSを許可します。月間割り当てから1分間隔で48時間がカウントされ差し引かれ、毎月1分間隔で2880の乗数レベルでAPIの使用を可能にします。 Authentication APIへの要求の量がデフォルトの100 RPSを超過すると、1分間隔で月間許容量から差し引かれ、トラフィックは乗数に関連付けられているレートで許可されます。トラフィックはその時点から連続1分間、追加の控除をトリガーすることなく乗数の範囲内で継続できます。 控除のインターバルイベントのモニタリングは[テナントログ](/docs/ja-jp/deploy-monitor/logs/log-event-type-codes)から可能です。各控除は、使用済み・残りの許容量に関する情報を含んだ関連する`appi`テナントログイベントタイプを生成します。 詳細については、[レート制限 - エンタープライズ](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-configurations/enterprise-public)のAuthentication APIを参照してください。 #### プライベートパフォーマンスバースト プライベートパフォーマンスバーストオファリング（現在、AWSで30xおよび60xのレベルで​利用可能）は、最大30x（3,000 RPS）または60x（6,000 RPS）のバースト（ピーク）パフォーマンス容量を月あたり最大80時間利用できます。バーストパフォーマンス容量の半分である基本パフォーマンス容量は、その月の残りの期間利用でき​ます。 30xプライベートパフォーマンスバーストには次のものがあります。 * 基本容量：全月1,500 RPS * バースト/ピーク容量：月間最大80時間まで3,000 RPS 認証トランザクションが基本API要求制限を超えてバーストした場合、月間許容量から1時間が差​し引かれます。その時点から、連続1時間にわたってトラフィックが高い率で継続する可能性があります。しきい値を再び超えると、上記の方法で追加の控除が行われます。 80時間の許容量がなくなると、新しい月間許容量が有効になるまで、認証トラフィックは基本容量に制​限されます。 #### 拡張性の同時並行処理制限 Auth0では、APIに対してレート制限とバースト制限が設定されます。レート制限は、システムが持続的に許可する持続可能な最大のトラフィック量で、バースト制限は、1つの時間間隔においてシステムが許可する短期的な最大のトラフィック量です。Auth0のレート制限とバースト制限は連携し、動的なトラフィック量に対して効果的な制限機能を提供します。 Auth0のレート制限は、以下の構成を含むトークンバケットアルゴリズムを使用しています。 この2つの数値からバースト制限と持続的レート制限が算出されます。 持続的レート制限がリスエスト毎秒（RPS）で算出される場合、新しい要求はミリ秒単位で追加されます。持続的レート制限がリスエスト毎分（RPM）で算出される場合、新しい要求は秒単位で追加されます。 ## レート制限アルゴリズム Auth0はAPIに対してレート制限とバースト制限を設定しています。レート制限はシステムが持続的に許可する持続可能な最大のトラフィック量で、バースト制限は1つの時間間隔においてシステムが許可する短期的な最大のトラフィック量です。Auth0のレート制限とバースト制限は連携し、動的なトラフィック量に対して効果的な制限機能を提供します。 Auth0のレート制限は、以下の構成を含むトークンバケットアルゴリズムを使用しています。 * \*\*バースト制限：\*\*バケットのサイズに等しい * 一般的に、レート制限のキーは2つの主要な要素に基づきます。 * APIとエンドポイント * テナントタイプ * 場合によっては、以下の要素も使用されます。 * ソースIP * ターゲットユーザーID * \*\*持続的レート制限：\*\*1分または1秒当たりの要求数で表した補充率 * **バケットサイズ：** 新しい要求が追加される前に、APIまたはエンドポイントが全般に受信する要求の最大数、または特定のユーザーやIPアドレスから受信する要求の最大数です。 * \*\*補充率：\*\*バケットに新しい要求が追加される割合です。 この2つの数値からバースト制限と持続的レート制限が算出されます。 * \*\*バースト制限：\*\*バケットのサイズに等しい。 * \*\*持続的レート制限：\*\*1分または1秒当たりの要求数で表した補充率です。 持続的レート制限が要求毎秒（RPS）で算出される場合、新しい要求はミリ秒単位で追加されます。持続的レート制限が要求毎分（RPM）で算出される場合、新しい要求は秒単位で追加されます。 ## もっと詳しく * [エンティティ制限ポリシー](/docs/ja-jp/troubleshoot/customer-support/operational-policies/entity-limit-policy) * [レート制限のユースケース](/docs/ja-jp/troubleshoot/customer-support/operational-policies/rate-limit-policy/rate-limit-use-cases)