きめ細かなレート制限

この記事では、Xbox サービスのきめ細かなレート制限 (FGRL) の概要を示します。 この記事では、レート制限とは何かを要約することに加えて、制限が適用されているかどうかの判断や、制限が適用されている場合に活用できるツールやリソースの判断に役立つ情報を提供します。

きめ細かなレート制限は、さまざまなタイトル間で共有される Xbox リソースの公平な使用を促進するために導入されました。 このソリューションはほとんどの伝統的な制限システムに似ており、あるエンティティが所定の期間内に行った要求数のカウントをサービスに保持させます。

サービスで指定された制限に達したエンティティは拒否状態に移行され、そのエンティティからのすべての着信要求が却下されるようになります。 所定の期間が終了し、エンティティと関連付けられたカウントがリセットされてはじめて、エンティティはこの状態を脱することができます。

きめ細かなレート制限では、前述したものと同じコア構造を使用しますが、1 つのエンティティを追跡する代わりに、FGRL はユーザーとタイトルの組み合わせを追跡し、関連付けられたカウントを 1 つではなく 2 つの異なる制限と比較します。 FGRL の二重制限はサービスごとに施行されます。つまり、GameClips の要求カウントが Presence の要求カウントに影響を及ぼすことはありません。

以下のセクションでは、ユーザーとタイトルのペアリング、二重制限、HTTP 429 制限応答オブジェクトについて詳しく説明します。

きめ細かなレート制限の用語

公平な使用

どのようなゲーム (またはアプリ) をユーザーがプレイしていても、同じ高品質のエクスペリエンスが個々のユーザーに提供されるべきだというのが Xbox の考えです。 きめ細かなレート制限 (FGRL) は、次のシナリオを解決します。

開発者 A は、すべての Xbox サービスのベスト プラクティスに従ってサービスを最適に使用できるタイトルをリリースしたばかりであり、開発者 B もタイトルをリリースしましたが、このタイトルには不明なバグがあります。 このバグによってタイトルおよび各ユーザーがプレゼンス情報を大量送信し、サービスの負荷が高まります。 開発者 B のバグが問題の原因でしたが、サービスが遅くなり、最終的に停止して開発者 A ユーザーのエクスペリエンスを壊します。

FGRL が実装されている場合、サービスは、不正なタイトルからリクエストの受信を停止でき、リソースのパイの公平なスライスである開発者 A のタイトルを提供できます。

タイトルとユーザーの細分度

タイトルとユーザーの組み合わせは、Xbox リソースの公平な使用を保証するための鍵として選ばれました。

ユーザーだけの追跡では、ユーザー エクスペリエンスが各タイトルの統合に翻弄されるシナリオが生まれます。 たとえば、ほとんどのタイトルでは People サービスを既に使用していますが、公平な使用という目的のために、5 分間で 100 回までは要求を許容する、きめ細かなレート制限を People サービスに対して設定するとします。

ユーザーがプレイするゲームで 1 分間に 100 回の要求を行った場合、制限を超過し、ユーザーは People サービスに対してそれ以上の要求ができなくなります。同じ期間中にユーザーがホーム画面に戻ってフレンド リストをクリックしますが、既に制限を超えているので、ユーザーが制限状態になったのはホーム画面が原因でないにもかかわらず、5 分の期間が過ぎるまでフレンド リストの呼び出しは失敗します。

タイトルのみに基づいた制限はこれに代わる方法ですが、同じく不公平な結果を生みます。 タイトルごとに制限を設定すると、タイトルの人気度が無視され、ただ単に、制限に達するまで先着順に要求が処理されます。

ユーザーとタイトルのペアリングにより、どのタイトルもアクティブ ユーザー数に応じた適切な量を超えてリソースを使用しない一方で、個々のユーザーには一貫した量のリソースが配分されることが保証されます。

上の図は、要求が処理される流れの概要を示しています。 まず、要求が生成され、目的のサービスによって受信されます。 要求を受信したら、システムは、ユーザーとタイトルの総合でサービスにアクセスした回数をチェックします。

• 制限内に収まっている場合、要求は通常どおり処理されます。
• 要求が制限以上になっている場合、サービスは要求を破棄し、代わりに 429 応答を返します。

応答では、期間が切り替わってユーザーとタイトルの要求が処理可能になるまでの時間を示します。

バーストと持続の制限

従来のレート制限は、所定の期間にわたって追跡されるエンドポイントあたり 1 つの制限で構成されます。 この期間は、エンティティの要求カウントが追跡される時間の長さを表します。 期間が終わるとエンティティのカウントは 0 にリセットされ、再び追跡が始まります。

このアプローチはほとんどの API に対して機能しますが、Xbox Live を呼び出すゲームやアプリにとっての柔軟性は不十分でした。 前述のソリューションは、ユーザーによる呼び出しが、一貫していて、安定的で、予測可能な方法で行われることを想定しています。 Xbox サービスのケースでは、サービスおよび要求側のタイトルごとに、呼び出しパターンが著しく異なります。

このケースでは、1 つの制限だけを使用すると、呼び出しパターン範囲の両端で妥協が必要になります。 Xbox サービスのソリューションでは 2 つの期間と制限を使用します。 短いほうの期間をバースト期間、長いほうの期間をサステイン期間と呼びます。

FGRL のバースト期間は常に 15 秒であり、サステイン期間は常に 300 秒 (5 分) です。 つまり、5 分のサステイン期間に 20 のバースト期間が含まれます。

バースト制限とサステイン制限はどちらも同時に追跡を行っており、そのような性質上、同時に要求をカウントします。 バースト制限とサステイン制限はどちらもサービスで設定されます。つまり、サービスごとに固有のバースト カウントとサステイン カウントがあります。

これら 2 つの制限がどのように連動するかの理解に役立つよう、次の表では、FGRL を実装したサービスを何度も要求するタイトルをプレイしているユーザーを示します。 このケースでは、バースト制限は 15 秒間に 30 回の要求、サステイン制限は 5 分間に 100 回の要求です。

表によると、35 回の要求を行ったことにより、ユーザーは最初の 15 秒でバースト制限にかかっています。 超過分の 5 回の要求は破棄され、429 応答が 5 回送信されます。

この 5 回の要求はスロットルされましたが、サステイン制限までのカウントでは引き続き数えられます。 表に示されているように、一度でもどちらかの制限にかかると、両方の制限にかかっている 45 秒からの期間だけでなく、要求が 4 回しか行われていない 285 秒からの期間でも、すべての要求が破棄されています。

HTTP 429 応答オブジェクト

関連付けられたユーザーとタイトルのカウントがバースト制限またはサステイン制限のどちらか以上になると、サービスは要求の処理をやめ、代わりに HTTP 429 応答を返すようになります。 XSAPI を使用する場合、これは0x801901ADの HRESULT と同じです。 HTTP 429 コードは、「リクエストが多すぎる」を意味し、「X 秒後に再試行」の値を含むヘッダーが付随します。

FGRL の 429 応答オブジェクトには、呼び出し側エンティティが再試行までに待たなければならない時間を指定する "retry after" ヘッダーが含まれます。 再試行までの待ち時間が考慮されて適切に処理されるため、XSAPI を使用する開発者は心配する必要はありません。

実際の応答には以下のフィールドが含まれます。

実装された制限

以下のサービスは FGRL 制限を実装しており、これらの制限は 2016 年 5 月以降適用されています。 これらの制限はすべてのサンドボックスおよびタイトルに共通です。

Xbox 開発者プラットフォームまたはパートナー センター経由で公開され、2016 年 5 月よりも前に出荷されたタイトルは、すべてレガシとみなされ、制限の適用が免除されます。

上の表は、FGRL の対象に選ばれたサービスの現在のリストを表します。 このリストは最終版ではなく、新しいサービスや既存のサービスが追加される可能性があります。 サービスが追加される場合、この表を更新し告知を行います。

この表内の制限は、変更される可能性があります。 サービスの変更や進化に伴って制限も変更される可能性がありますが、変更時はその旨を告知し、必要なレガシ免除措置を講じます。

サービスのマッピングとタイトルのレート制限の効果

注: 最新の API マッピングは定期的に更新されており、Live Trace Analyzer API マッピングに関するページで参照できます。

FAQ

スロットルされているかどうかの判断方法と可能な対処手順

「Xbox サービスの呼び出しのベスト プラクティス」を参照してください。呼び出しパターンを改善するための手順に加えて、スロットリングの問題を通知および軽減するために XSAPI アサーション、XSAPI Social Manager、および XSAPI Multiplayer Manager をどのように使用できるかを説明しています。

Xbox サービス呼び出しのトレースを記録してから、Xbox サービス トレース アナライザー ツールを使用して、そのトレースを分析することもできます。 トレースを記録するには、Fiddler を使用して .SAZ ファイルを記録するか、XSAPI の組み込みトレース ログを使用します。

XSAPI でトレースを有効にして使用するには、「サービス呼び出しを確認するための Trace Analyzer」をご覧ください。 トレースを用意すると、スロットリングされた呼び出しの検出時に Xbox サービス トレース アナライザー ツールが警告を発します。

制限が変更される可能性はありますか?

公表された制限を今後変更する意図はありません。 しかしながら、必要が生じた場合、一部の制限が厳しくなる可能性はあります。その場合、RETAIL にリリース済みのタイトルは、更新された制限の適用が免除されます。

制限が適用されるサービスは増えますか。

はい。より多くのサービス、また新しいサービスで制限が導入されます。 しかしながら、この最初の FGRL リリースと同様、必要な告知を行い、適切な予防措置を講じます。

これらの変更はいつ発効しますか。

レート制限は 2016 年 5 月以降適用されています。 2018 年 4 月現在、指定されたサステイン制限の 10 倍を超えるタイトルは、Xbox 認定プロセスで認定されません。

制限を順守できない場合はどうなりますか?

「Xbox サービスの呼び出しのベスト プラクティス」を参照し、必ず、記載されている手順に従ってください。 何らかのソーシャル サービスでレート制限の適用を受けている場合は、ソーシャル マネージャーの使用も検討してください。

これらの手順に従ってもなお、制限を守ることが難しい場合は、担当のデベロッパー アカウント マネージャーにご連絡ください。

注: 指定された制限以上のタイトルは、2018年 4 月以降認定されません。 たとえば、上の表で指定されているように、サステイン制限が、300 秒間に 300 の呼び出しに設定されている場合、300 秒間に呼び出しが 3000 以上であるタイトルは認定されません。 テスト ケースを含め、詳細情報については、「XR-132 サービスへのアクセス制限」を参照してください。

既存のタイトルはどうなりますか。

2018 年 4 月以前に RETAIL にあったタイトルはレガシとみなされ、制限が免除されます。

コンテンツ アップデートはどうですか。

レガシまたは適用免除タイトルについてはコンテンツ アップデートも免除対象になりますが、ゲームのサービス統合部分を最適化するためのツールおよびアセットを利用することを強くお勧めします。

コンテンツ アップデートが可能になるまでの間、ゲームへの適用免除を申請できますか。

担当のデベロッパー アカウント マネージャーにお問い合わせください。