Rate Limit
注釈:本資料はAI技術を用いて翻訳されています。
レート制限とは、指定された期間内にユーザーまたはクライアントがサービスにアクセスできる回数に対して、APIが課す制限のことです。
レート制限を設ける理由
レート制限はAPIにおける一般的な慣行であり、いくつかの理由から導入されています。
- 不正使用に対する保護: レート制限は、意図的か否かを問わず、APIの不正使用からAPIを保護するのに役立ちます。たとえば、悪意のある攻撃者がAPIに過剰な負荷をかけようとして大量のリクエストを送信し、サービス障害やサービス拒否(DoS)攻撃を引き起こすリスクを軽減します。レート制限を設けることで、AccelByteはこうした有害な行為を防止できます。
- 公平な利用の確保: レート制限は、APIへの公平なアクセスを促進します。特定のユーザーや組織が過剰な数のリクエストを行うと、他のすべての利用者のパフォーマンスが低下するおそれがあります。リクエストをスロットリングすることで、AccelByteは公平なリソースの利用を確保し、プラットフォーム上のすべてのお客様に一貫した体験を提供します。
- インフラの安定性の維持: APIへのリクエストが急激に増加すると、サーバーに負荷がかかり、パフォーマンスの問題を引き起こすおそれがあります。レート制限を設けることで、AccelByteはすべてのユーザーに対してスムーズで一貫した体験を維持できます。
このAPIレート制限は、本ドキュメントに記載のとおり、APIリクエストの頻度を規定するものです。これは、Public Cloudの無料トライアルに関連するものなど、他の種類の制限やクォータとは区別される別個のものです。
レート制限の仕組み
Public Cloudの場合
レート制限はRPM(1分あたりのリクエスト数)で測定されます。1分以内にリクエスト数が定義された制限を超えた場合、次の時間枠でカウントが制限を下回るまで、それ以降のリクエストは一時的にブロック(スロットリング)されます。
Public Cloudは、柔軟性と制御を提供するために2段階のレート制限システムを採用しています。デフォルトでは、次のレート制限が設定されています。
- ゲームレベルのCCU制限
- 適用範囲: この制限は、各スタジオのゲームレベル(game-namespace)に適用されます。
- 目的: インフラの安定性を確保し、お客様間で公平にリソースを割り当てるために、特定の時点でゲームにアクセスできる同時接続ユーザー数の全体的な上限を設定します。デフォルトの制限は、厳格な制限というよりはセーフガードとして機能します。この制限および制限調整の申請プロセスの詳細については、ゲームCCU制限のドキュメントを参照してください。
- スタジオレベルのレート制限: 1分あたり5000リクエスト(デフォルト、調整可能)
- 適用範囲: これは、お客様のスタジオに適用されるグローバルな制限です。お客様のスタジオに関連付けられたすべてのユーザーが行ったリクエストの総数を合算してカウントします。
- 目的: インフラの安定性を保護し、公平なリソース割り当てを確保するために、お客様のスタジオの利用全体に上限を設定します。このデフォルトの制限は、厳格な制限というよりは初期のセーフガードとして機能し、実際の利用状況に応じて調整できます。
- 例: 制限が5000 RPMの場合、お客様のスタジオに関連付けられたすべてのユーザーからのリクエストの合計は、任意の1分間で5000を超えることはできません。
- ユーザーレベルのレート制限: 1分あたり500リクエスト(デフォルト、調整可能)
- 適用範囲: この制限は、各ユーザーに個別に適用されます。
- 目的: 単一のユーザーがスタジオ全体の制限のうち過剰な割合を消費したり、同じスタジオに関連付けられた他のユーザーに影響を与えたりするのを防ぎます。
- 制約: ユーザーレベルの制限は、常にスタジオレベルの制限以下です。
- 例: 制限が500 RPMの場合、スタジオレベルの残り容量にかかわらず、単一のユーザーが任意の1分間に500を超えるリクエストを行うことはできません。
スタジオレベルとユーザーレベルの両方の制限を同時に満たす必要があります。
- 次のいずれかに該当する場合、リクエストはスロットリングされます。
- リクエストを行っている個々のユーザーが、そのユーザーレベルのRPM制限を超えた場合。
- リクエストを行っているユーザー自身は個別の制限を下回っていても、スタジオに関連付けられたすべてのユーザーからのリクエストの総数がスタジオレベルのRPM制限を超えた場合。
API別のレート制限
一部の重要なAPIエンドポイントやリソースを大量に消費するAPIエンドポイントには、組織やユーザーの制限とは独立した、独自のIPベースのレート制限が設定されている場合があります。これにより、組織全体やユーザーの制限に達していなくても、需要の高い特定のエンドポイント(ログインなど)がトラフィックによって過負荷になるのを防ぎます。
Private Cloudの場合
レート制限は、タイトルの開発ライフサイクル全体を通じて、複数の機会に協議できます。
- AccelByteの一般アーキテクチャレビューの一環として、AccelByteはお客様の現在のAccelByte APIの利用状況を評価し、レート制限に達する可能性を高めるエンドポイントの誤用がないことを確認するための推奨事項を提供します。
- お客様のゲームに対するAccelByteのローンチ準備プロトコルの一環として、AccelByteは現在の環境の容量が予想されるトラフィックを処理できることを確認するために、レート制限の考慮を含めたキャパシティプランニングを行います。
制限の基準
デフォルトのレート制限は設定されていますが、お客様のアプリケーションの進化するニーズに対応するため、AccelByteの裁量でこれらを調整する場合があります。不要な呼び出しを最小限に抑え、利用可能な場合はバッチエンドポイントを活用するなど、すべてのユーザーがAPIのベストプラクティスを実践することを強く推奨します。これらのプラクティスを採用することで、利用状況を最適化し、予期せずレート制限に達する可能性を減らせます。
サポートチケットシステムへのアクセス権をお持ちの場合や、担当のアカウントマネージャーが割り当てられている場合は、これらのチャネルを通じてレート制限に関するニーズをさらに協議できます。これにより、お客様のアプリケーションの規模が拡大しても、プレイヤーにシームレスな体験を確実に提供できます。
スロットリング問題の緩和
レート制限に達したかどうかを確認する方法
スロットリングされると、次のエラーとともにHTTPステータスコード429を受け取ります。
{
"error": {
"message": "You have exceeded the allowed request limit. Please try again later."
}
}
スロットリングエラーが継続する場合は、次の対策の採用を検討してください。
- リクエストレートの見直し
- 大量のリクエストを送信している理由を分析します。
- APIが対象とする特定のプレイヤーまたはタイトルのエンティティについて、リクエストレートを下げる方法を検討します。
- API呼び出しのバッチ処理
- API呼び出しをバッチ処理して頻度を減らします。
- 例: 毎秒更新する代わりに、10秒ごとにまとめて統計を更新します。
ベストプラクティスに従う
お客様は、問題の発生を防ぎ、発生した問題の影響を最小限に抑え、プレイヤーにより良いユーザー体験を提供するために、AccelByteのベストプラクティスガイダンスに従う責任があります。