きめ細かなレート制限の用語
公正な使用
XBOX は、ユーザーがプレイしているゲーム (またはアプリ) に関係なく、すべてのユーザーが同じ高品質のエクスペリエンスを持つべきだと考えています。 きめ細かなレート制限 (FGRL) は次のシナリオを解決します: 開発者 A が、サービスの最適な使用を保証するすべての XBOX services ベストプラクティスに従ったタイトルをリリースしたばかりです。一方、開発者 B もタイトルをリリースしましたが、こちらには未知のバグがあります。 このバグにより、タイトルと各ユーザーがプレゼンスをスパムし、その結果サービスが高負荷になります。 サービスは遅くなり、最終的に停止し、開発者 A のユーザーのエクスペリエンスを損なうことになりますが、原因は開発者 B のバグでした。 FGRL が実装されていれば、サービスは行儀の悪いタイトルからのリクエストの受信を停止し、開発者 A のタイトルにリソースの公正な取り分を提供できていたはずです。タイトルとユーザーの粒度
XBOX リソースの公正な使用を保証するために、タイトルとユーザーがキーとして選ばれました。 ユーザーのみを追跡すると、ユーザーエクスペリエンスが各タイトルの統合次第になるシナリオが生まれます。 例えば、ほとんどのタイトルはすでに people サービスを使用しているので、この例のために、people サービス上できめ細かなレート制限が設定され、5 分間に 100 リクエスト以下に制限されていると仮定します。 ユーザーが 1 分間に 100 リクエストを送るゲームをプレイした場合、制限を超えてしまい、people サービスへのそれ以上のリクエストが送信できなくなります。同じ期間内にそのユーザーがホーム画面に戻ってフレンドリストをクリックしたと想像してください。ユーザーはすでに制限を超えているので、ホーム画面がユーザーを制限状態にしたわけではないにもかかわらず、5 分間の間隔が経過するまでそのフレンドリストの呼び出しは失敗します。 一方、タイトルのみに基づいて制限すると、同様に不公平な結果が生まれます。 タイトルごとに制限を設定すると、タイトルの人気度が無視され、制限に達するまでリクエストは先着順で処理されるだけです。 ユーザーとタイトルのペアリングは、アクティブなユーザー数を考慮してタイトルが適切以上のリソースを使わないことを保証し、同時に各ユーザーに一貫したリソースの取り分を与えます。 上の図は、リクエストがどのように処理されるかの高レベルビューを示しています。 まずリクエストが生成され、目的のサービスによって受信されます。 リクエストを受け取ると、システムはユーザーとタイトルが合計で何回サービスにアクセスしたかを確認します:- リクエストが制限を下回っている場合、通常通り処理されます。
- リクエストが制限以上であるとわかった場合、サービスはそれをドロップし、代わりに 429 応答を返します。
バースト制限と持続制限
伝統的に、レート制限はエンドポイントごとに 1 つの制限で構成され、それが一定期間にわたって追跡されます。 この期間は、エンティティのリクエスト数が追跡される時間の長さを表します。 期間の終わりにエンティティのカウントは 0 にリセットされ、再び追跡が始まります。 このアプローチはほとんどの API で機能しますが、XBOX services を呼び出すゲームやアプリには十分な回復力がありませんでした。 上記のソリューションは、人々が一貫した安定した予測可能な方法で呼び出しを行うと仮定しています。 XBOX services の場合、サービスと要求元のタイトルによって、呼び出しパターンは劇的に異なります。 この場合に 1 つの制限だけを選択すると、呼び出しパターンのスペクトルの両端で妥協する必要があります。 XBOX services のソリューションは 2 つの期間と制限を使用します。 小さい方の期間はバースト期間と呼ばれ、大きくて長い方は持続 (サステイン) 期間と呼ばれます。 FGRL のバースト期間は常に 15 秒で、持続期間は常に 300 秒 (5 分) です。 したがって、5 分の持続期間内には 20 のバースト期間があります。 バースト制限と持続制限は同時に追跡され、そのため同時にリクエストをカウントします。 バースト制限と持続制限はどちらもサービス上に設定されており、各サービスには独自のバーストと持続のカウントがあります。 これら 2 つの制限がどのように連携するかを理解しやすくするために、下の表は、FGRL を実装したサービスに対して多数のリクエストを行うタイトルをプレイしているユーザーを示しています。 この場合、バースト制限は 15 秒で 30 リクエスト、持続制限は 5 分で 100 リクエストです。
表は、最初の 15 秒でユーザーが 35 リクエストを行いバースト制限に達したことを示しています。
それらの余分な 5 リクエストはドロップされ、5 つの 429 応答が送信されます。
スロットリングされたにもかかわらず、それらの 5 リクエストは依然として持続制限にカウントされます。
いずれかの制限に達すると、リクエストは通されません。これは 45 秒時点で両方の制限に達した時と、285 秒時点で 4 リクエストしか行われなかった時に示されています。
HTTP 429 応答オブジェクト
関連付けられたユーザーとタイトルのカウントがバーストまたは持続の制限以上になると、サービスはリクエストを処理せず、代わりに HTTP 429 応答を返します。XSAPI を使用する場合、これは 0x801901AD の HRESULT に相当します。 HTTP 429 コードは “too many requests” (リクエストが多すぎる) を意味し、“retry after X seconds” (X 秒後に再試行) の値を含むヘッダーを伴います。 FGRL の 429 応答オブジェクトには “retry after” ヘッダーが含まれており、これは呼び出し側エンティティが再試行するまでに待機すべき時間を指定します。 XSAPI を使用する開発者は心配する必要はありません。XSAPI は Retry-After ヘッダーを尊重し処理します。 実際の応答には次のフィールドが含まれます:実装済みの制限
次のサービスは FGRL 制限を実装しており、これらの制限は 2016 年 5 月 から適用されています。 これらの制限はすべてのサンドボックスおよびタイトルで同じです。 2016 年 5 月より前に XBOX Developer Platform または Partner Center 経由で公開および出荷されたタイトルはレガシーとみなされ、免除されます。
上の表は、FGRL のために選択された現在のサービスのリストを表しています。
このリストは最終的なものではなく、新しいサービスや既存のサービスが追加される可能性があります。
サービスが追加される際には、この表が更新され、アナウンスが行われます。
表内の制限は変更される可能性があります。
サービスが変化し進化するに伴い、制限も変化しますが、通知が行われ、必要なレガシー免除が適用されます。
サービスマッピングとレート制限のタイトルへの影響
注: 最新の API マッピングは定期的に更新されており、Live Trace Analyzer API Mapping にあります。