はじめに
Auth0を実サービスに利用する上で欠かせない観点として「Rate Limit」というものがあります。
https://auth0.com/docs/troubleshoot/customer-support/operational-policies/rate-limit-policy
Auth0には様々な観点でRate Limitが設定されており、充分に理解した上でアプリケーションの設計をしないと、ユーザーが増加してきたタイミングで障害発生に繋がる可能性があり、注意が必要です。
また、アプリに求められる要件を満たすため契約のプラン変更が必要になることもあり（契約毎に Rate Limitが異なります：参考）、その場合、根本解決までのリードタイムが長くなり得ますので、早い段階で手を打つことが重要です。
今回は、特に重要な「APIのRate Limit」についてご紹介します。
Rate Limitの考え方
Rate Limitは「Burst Limit」と「Sustained Limit」に分かれており、それぞれ以下を表します。
- Burst Limit：一時的にAPIの実行回数が増加した場合の上限
- Sustained Limt：一定の頻度でAPIが実行され続けた場合に可能な上限
例えば、以下のリンクの「Rate Limit Use Cases（Rate Limitのユースケース）」を参照すると、
- Burst Limit：5
- Sustained Limit：6 /分
の場合の例が挙げられています。
これは、残カウントとして保持できる最大値が5であり、60秒 / 6 = 10秒 毎に1カウント追加されることを意味します。
つまり、10秒毎に1回のAPI実行なら制限に引っかかることなく継続的に利用可能であり、それ以上の頻度で実行されたとしても残カウントが0にならない範囲（瞬間的に5回実行された場合でも、その後は一気に落ち着く場合など）であれば問題ないことになります。
Authentication API
Auth0から提供されるAPIであるAuthentication APIにもRate Limitが関係します。
Authentication APIは、ログイン・ログアウト・トークン取得・パスワード変更メールの送信など、認証認可に関わる処理を扱うAPIです。
https://auth0.com/docs/api/authentication
Auth0テナントのPublic Cloudで利用するプランでRate Limitを比較してみます。
なお、Enterpriseプランは本番環境に対して提供される値を示しています。
| プラン | Burst Limit | Sustained Limit |
| Free | 300 | 5 /秒（300 /分） |
| Self-Service | 25 | 25 /秒 |
| Enterprise (Production) | 100 | 100 /秒 |
※上記に加え、エンドポイント毎の制限もあります
プランによって値が異なることが分かります。
なお、上記を超える値が必要な場合は、Private Cloudなど追加契約が必要となります。
2024年1月のアップデートで、Public Cloud契約でも200RPSまでは対応できるようになりました（参考）。
Management API
Management APIについても、Rate Limitが関係します。
組織やユーザーの作成・検索・削除をはじめ、Auth0ダッシュボード上で可能な操作を行えるようなAPIとなっています。
https://auth0.com/docs/api/management/v2
こちらも同様に、Public Cloudのプランで比較してみます。
| プラン | Burst Limit | Sustained Limit |
| Free | 2 | 2 /秒 |
| Self-Service | （エンドポイント毎の値） | （エンドポイント毎の値） |
| Enterprise (Production) | 50 | 16 /秒 |
※Enterpriseプランは上記に加え、エンドポイント毎の制限もあり
Authentication APIでも注意事項として記載していましたが、実はエンドポイント毎の制限もあります。
例えば、組織名から該当組織の情報を取得する（Get Organization by Name）Management APIの場合、Self-ServiceプランだとBurst Limitが10、EnterpriseプランだとBurst Limitが20となっています。
基本的に組織に関するエンドポイントは制限が厳しめになっているため、組織の概念を取り入れた設計が必要な場合、特に注意が必要です。
監視
これまでの内容は要件定義および設計に関わるものでしたが、サービスのリリース後には突発的なアクセスの集中や、予期しないユーザー操作が発生する可能性があります。
対策として、Rate Limitの消費を監視することで枯渇を事前に検知でき、障害の予防に繋げることができます。
監視対象としては、API実行時のResponse Headerが利用できます。
実際に、Public CloudのFreeプランにおいてAPIを実行した際の値を以下に示します。
●Authentication APIのログインエンドポイント（GET /authorize）
X-Ratelimit-Limit: 300
X-Ratelimit-Remaining: 299
X-Ratelimit-Reset: 1711932973「X-Ratelimit-Limit」が300となっており、FreeプランのBurst Limit値の300と一致していることが分かります。
この実行でカウントが1消費されたため、「X-Ratelimit-Remaining」は299となっていますが、「Sustained Limit」が 5 /秒 のため、秒間5回以下のAPI実行ペースなら299を下回ることはありません。
その他
Rate Limitに関する情報として、その他の事項を記載しておきます。
（１）Private Cloudでは、Rate Limitはテナント間で共有される
Private Cloudにて複数テナントを使用している場合に、あるテナントでのAPI実行が他のテナントに影響することを意味します。
つまり、開発・ステージング・本番のように用途毎にテナントを作成している場合、開発環境やステージング環境で負荷を掛けすぎると、本番環境にまで影響が出てしまう可能性があります。
ただし、本番環境用のProductionタグと比較して、DevelopmentタグとStagingタグが付いたテナントのRate Limitは上限が低いため、開発・ステージング環境でRate Limitを超過したからといって、本番環境で即時にRate Limit超過が発生する訳ではありません。
参考：https://auth0.com/docs/get-started/auth0-overview/create-tenants/set-up-multiple-environments
（２）Rate Limitを超過した場合は429エラーが返却される
アプリ側のハンドリングとして、429エラーが返ってきた際は時間を空けて自動で再実行するような実装が推奨されます。
また、超過した際には、Auth0のログにも出力されます。
（超過した状態が続いた場合は、429エラーの度にログ出力されるのではなく1時間後にその旨が出力されるようです）
（３）負荷テストを実施する場合は、事前に申請が必要
ログインやAuth0のAPI実行などについて負荷テストを実施したい場合、Auth0サポートへの事前申請および日程調整が必要です。
さらに、負荷テストが許可されるにはEnterpriseプラン（Private Cloud含む）が必要なこと、Productionタグが付いたテナントのみ実施可能なことなど、考慮事項が多く注意が必要です。https://auth0.com/docs/troubleshoot/customer-support/operational-policies/load-testing-policy
おわりに
Auth0のAPIは非常に便利ですが、早い段階からRate Limitを把握して進めないと、思わぬ所に落とし穴がある可能性があります。
今回の内容を踏まえたうえでアプリ要件に応じて適切なプランを選択し、Rate Limitを意識しながら開発・運用することで、サービスの安定化に繋げて頂ければと思います。
ソリューションサービスのご紹介
TC3はOkta CIC(Customer Identity Cloud)を代表とするIDaaSを活用したデジタルサービス開発のプロフェッショナルです。
すでに実践的に設計・実装された基盤を用いることで、事業部やサービス間の調整を減らし、リリースまでの期間を早め、ユーザー体験を向上させるといったメリットの多い開発プランをご提供します。
トライアル・MVP開発の段階から、どのようにIDaaS/CIAMを導入するかについてもサポートさせていただきますので、お気軽にお問い合わせください。
詳しくはデジタル顧客接点トータルサービスをご覧ください。
ひとまず情報のキャッチアップだけしておきたいという方は、こちらからニュースレターの購読ができます。
デジタル顧客接点トータルサービスに関する詳細のご紹介資料は以下からダウンロードいただけます！
