ゲームラグ白書 › L13 サーバー構成と運用
マッチメイキング・リージョン割り当ての誤り Wrong region assignment (matchmaking / GeoDNS)
原因ID in-region-match · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発, インフラチーム・ネットワークインフラ, 外部・外部
図と実験のあるメインページでこのカードを開く →
近いリージョンがあるのに遠いリージョンのサーバーに割り当てられると、回線に問題がなくても、そのユーザーだけPingが常に高くなります。
なぜ GeoIPデータの誤り、VPN、パーティメンバーの平均Pingでパーティ全体を割り当て、人数が足りないときに遠いリージョンまで広げるルール、DNSリゾルバーの位置を基準にした割り当て → すると 近いリージョンがあるのに、海の向こうのリージョンのサーバーに接続 → 画面では 複数のリージョンにサーバーを置いたゲームで、自分だけ（または自分のパーティだけ）Pingが常に高く、入力遅延・引き戻し・スキル不発
症状 入力遅延 , 引き戻し , 不発・ロールバック 要因 遅延
誰に起きるか 自分だけ, 特定の地域・ISP
いつ 常に, 接続直後・メンテ明け
担当 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発, インフラチーム・ネットワークインフラ, 外部・外部
ゲーム開発チームの対応 サーバー：GeoIPの代わりにクライアントが測定したリージョン別のPingで割り当て、遠いリージョンへ広げるルールにPingの上限を設ける、パーティは平均に加えて最も高いメンバーのPingも考慮、割り当てたリージョンとその時のPingをログに記録。クライアント：リージョン別のPingをUDPで測ってマッチングリクエストに添えて送る、接続中のリージョンとPingを画面に表示、リージョンを自分で選べる選択肢。
インフラチームの対応 DNSでリージョンを選ぶなら、権威DNSがEDNS Client Subnetに対応しているかを確認（ユーザーが使うリゾルバーが送らなければリゾルバーの位置で割り当てられる）、GeoIPデータベースの定期更新、リージョン別サーバーの接続ログにGeoIPの国・ASNを付けて、遠いリージョンへ行っている国・通信事業者を特定。
外部の対応 ユーザーにVPN・ラグ軽減ツールを切って再接続してみるよう案内、会社や海外のDNSを使うユーザーに通信事業者のDNSへ切り替えてみるよう案内、GeoIP事業者に誤った位置の訂正を依頼。
数値の目安 ソウルのユーザーが東京リージョンの代わりに米国西海岸リージョンに割り当てられると、Pingは約30msから約130msに増えます。GeoIPは国単位なら約99.8%当たりますが、都市単位では米国でも50km以内に収まる割合が約66%です。VPNを使うと、ユーザーの位置の代わりにVPNサーバーの位置が返ります。
グラフでは 確認箇所 リージョン別サーバーの接続記録（ロードバランサーのアクセスログ、VPCフローログ）に残ったクライアントIPにGeoIPの国・ASNを付け、国・通信事業者ごとにどのリージョンに接続したかを集計。ユーザー1人なら、そのユーザーが実際に接続したリージョンと、近いリージョンまでのPing（ユーザーが測るか、そのリージョンのサーバーからユーザーのIPへmtr）を比較 該当する場合 RTTが高いユーザー・国が近いリージョンを使わずに遠いリージョンに接続しており、近いリージョンまで測ったPingは低い 該当しない場合 近いリージョンに正しく割り当てられているのにPingが高ければ、迂回ルーティングか、そのユーザーの回線・Wi-Fi側 確認手段 インフラのツールで確認（ゲームコード不要）
もっと詳しく DNSでリージョンを選ぶ方式（位置情報・レイテンシベースのDNS）は、ユーザー本人の代わりに、ユーザーが使うDNSリゾルバーのアドレスを見て位置を推測します。ユーザーのアドレスの一部を伝えるEDNS Client Subnetにリゾルバーが対応していなければ、会社のDNSや遠くにあるDNSを使うユーザーは、リゾルバーのある場所を基準に割り当てられます。マッチングシステムも、パーティをメンバーのPingの平均で判断したり、待ち時間が長くなるとPingの基準を広げて遠いリージョンに割り当てたりします。AWS GameLift Serversも、パーティのPingのデフォルト基準は平均で、Pingの上限を50msから100ms、200msへと広げていく設定を例に挙げています。VPNを有効にしたユーザーは、中継サーバーを経由して増えた遅延（「VPN・ラグ軽減ツール経由」）と遠いリージョンへの割り当てが重なることがあるため、VPNを切って再接続したときに割り当てられるリージョンが変わるかどうかで切り分けます。近いリージョンがそもそもなく、遠いリージョンに接続する場合は「伝搬遅延（物理的な距離）」で扱います。
出典 RFC 7871: Client Subnet in DNS Queries IETF 位置によって異なる応答を返すDNSは、問い合わせを送ったリゾルバーのアドレスで位置を推測し、ユーザーから遠く離れた集中型のリゾルバーを使うと不適切な応答になる。EDNS Client Subnet（オプション機能）でユーザーのアドレスの一部を伝える How Amazon Route 53 uses EDNS0 to estimate the location of a user AWS リゾルバーがedns-client-subnetに対応していなければ、リゾルバーのアドレスでユーザーの位置を推測し、リゾルバーの位置を基準に応答（位置情報・レイテンシベースのルーティングに共通） Geolocation accuracy MaxMind 国単位で約99.8%、米国の都市単位（50km以内）で約66%、VPNを使うとエンドユーザーの代わりにVPNサーバーの位置、モバイル回線のIPは広い地域で使われるため細かい位置はわからない、データベースは継続的な更新が必要、訂正依頼が可能 FlexMatch rule types AWS レイテンシルール（maxLatency）は場所ごとのプレイヤーの遅延を見て、パーティにはデフォルトでメンバーの平均（partyAggregation avg）を使う、キューはレイテンシルールに合わないリージョンにも配置しうる Create a player latency policy AWS 全プレイヤーの平均遅延が最も低い場所に配置するが、遅延が極端なプレイヤーも配置される、Pingの上限を50msから100ms、200msへと広げていくポリシーの例 Amazon GameLift Servers UDP ping beacons AWS ゲームクライアントがホスティング拠点ごとのUDPエンドポイントで遅延を測り、配置・マッチングに使う、ICMPによるPingより実際のゲームトラフィックに近い Azure network round-trip latency statistics Microsoft Azure ソウル（Korea Central）を起点とした実測の往復中央値：東京（Japan East）29ms、米国西海岸124〜136ms Flow log records AWS VPCフローログレコードのsrcaddr：受信トラフィックなら送信元のIPアドレス あわせて読みたい原因
同じ層：L13 サーバー構成と運用
同じ症状（入力遅延）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る