ゲームラグ白書 › L13 サーバー構成と運用
ログイン待機列の上限・再接続猶予の不足 Login queue cap / no reconnect grace
原因ID in-login-queue · 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発, インフラチーム・サーバーインフラ
図と実験のあるメインページでこのカードを開く →
リリース直後やメンテ明けに接続が集中すると、ログイン待機列が上限に達して新たな待機を拒否し、待っていたユーザーは一瞬切れた間に順番を失って最後尾に戻されます。
なぜ ログインサーバーが一度に受け付けられる人数より接続しようとする人が多いため待機列を設け、長くなりすぎるとサーバーを守るために新たな待機を拒否 → すると 待機列が長いほど待ち時間が延び、その間にWi-Fi・モバイル回線が一瞬途切れただけで順番を失う → 画面では 接続不可・無限ロード、待機中にエラーが出てゲームが終了、また最後尾から待ち直し
症状 接続不可・無限ロード , 切断 要因 ストール
誰に起きるか サーバー全体, 自分だけ
いつ 接続直後・メンテ明け, 夜のピーク時間帯
担当 主担当 ゲーム開発チーム・サーバー開発 · 副担当 ゲーム開発チーム・クライアント開発, インフラチーム・サーバーインフラ
ゲーム開発チームの対応 サーバー：待機列の上限をログインサーバーが実際に処理できる量に合わせる、待機中に切れたユーザーの順番を一定時間確保（再接続猶予）、順番と予想待ち時間の表示、待機列の長さ・拒否数・待機中の切断数をメトリクスとして記録。クライアント：待機中に切れてもゲームを終了せず同じ順番へ自動で再接続、再試行間隔は指数バックオフとジッターで分散。
インフラチームの対応 サーバー機器・OS：リリース前の負荷試験でログイン・ロビーサーバーの処理上限を測定、リリース時は予備機をすぐ追加できるよう準備、待機列のメトリクスを接続試行数と同じグラフで確認。
数値の目安 2021年のFINAL FANTASY XIV拡張パッケージのリリース時には、論理データセンターごとに待機人数が17,000人を超えると新たな待機を拒否していました（Error 2002）。待機中に接続が切れた場合はロビーサーバーが数十秒〜1分待ち、その間に再接続すれば待機列の途中から再開できるようにしていました。
グラフでは 確認箇所 ログイン・ロビーサーバーが記録する待機列の長さ、平均待ち時間、上限到達による拒否数、待機中の切断数を、接続試行数と同じグラフに並べて確認 該当する場合 リリース直後・メンテ明けに待機列の長さが上限で頭打ちになっている間に拒否数が増え、待機中の切断がWi-Fi・モバイル回線のユーザーに集中 該当しない場合 待機列は短いのにログインが遅いなら、DB（db-login-storm）かOSの接続待ちキュー（so-backlog）側 確認手段 ゲームサーバー・クライアントのログ・メトリクスが必要
もっと詳しく ログインが集中してDBが遅くなるケースは「ログイン殺到とN+1クエリ」、OSの接続待ちキューがあふれるケースは「接続待ちキュー（backlog）のあふれ」で扱います。この項目は、ゲームが意図的に設けるログイン待機列の設計の問題です。待機列の上限はログインサーバーを守る安全装置なので、なくせません。あふれたリクエストを早めに拒否してこそ、処理できるリクエストを処理し続けられるからです。その代わり、拒否や切断がユーザーに与える不利益を減らすことが肝心です。待機列が長くなるほど、Wi-Fi・モバイル回線のように回線が不安定なユーザーにエラーが集中します。
実際の事例 Square Enix 2021: FINAL FANTASY XIVの拡張パッケージ発売時の混雑とログイン待機列のエラー
出典 Response to Congestion (as of Dec. 11) Square Enix 論理データセンターごとに待機人数が17,000人を超えると、ログインサーバーがダウンしないよう新たな待機を拒否（Error 2002）、待機中に切れるとロビーサーバーが数十秒〜1分待ち、その間に再接続すれば待機列の途中から、過ぎれば最後尾へ Using load shedding to avoid overload Amazon Builders' Library あふれたリクエストを早めに拒否し、処理できるリクエストを処理し続けるロードシェディング あわせて読みたい原因
同じ層：L13 サーバー構成と運用
同じ症状（接続不可・無限ロード）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る