ゲームラグ白書 › L5 データセンターのネットワーク機器
ロードバランサーのアイドルタイムアウト Load balancer idle timeout
原因ID dc-lb-idle · 主担当 インフラチーム・ネットワークインフラ · 副担当 ゲーム開発チーム・クライアント開発, ゲーム開発チーム・サーバー開発
図と実験のあるメインページでこのカードを開く →
ロードバランサーは、アイドル状態の接続を一定時間後に削除します。ゲーム側は接続が維持されているものとみなしているうちに、切断されてしまいます。
なぜ プレイヤーがしばらくパケットを何も送らない（会話ウィンドウ、離席） → すると ロードバランサーがアイドル接続を整理（よくあるデフォルト値は60〜350秒） → 画面では 再び動いた瞬間に切断
- 症状
- 切断
- 要因
- パケットロス
- 誰に起きるか
- 自分だけ, サーバー全体
- いつ
- しばらく放置した後
- 担当
- 主担当 インフラチーム・ネットワークインフラ · 副担当 ゲーム開発チーム・クライアント開発, ゲーム開発チーム・サーバー開発
- ゲーム開発チームの対応
- クライアント：最も短いアイドルタイムアウトの半分以下の間隔でハートビートを送る（60秒のALBの後ろなら30秒以下）、切れたら自動で再接続。サーバー：ハートビートに応答し、一定時間受け取れなければ先に接続を整理、セッショントークンで引き継ぐ。
- インフラチームの対応
- 経路上にあるロードバランサーのアイドルタイムアウトの値を確認してゲーム開発チームに共有し、必要なら延ばす。
- 数値の目安
- AWS ALBは60秒、NLBはTCP 350秒・UDP 120秒、Azure Load BalancerはTCP 4分がデフォルト値です。ALBとNLBのTCPの値は変更できますが、NLBのUDP 120秒は変更できません。ALBは時間が来るとサーバー側の接続も閉じますが、NLBは黙って削除するため、サーバーが気づかないまま接続が残りやすくなります。
- グラフでは
- 接続が一斉に切れる · 切断数、切断前のアイドル時間
- 確認箇所
- 経路上にあるロードバランサーのアイドルタイムアウトの設定値を確認し、切れた接続ごとに最後のパケットから切断までにかかった時間を集計。AWS NLBならCloudWatchのTCP_ELB_Reset_Count（ロードバランサーが送ったRSTの数）も確認
- 該当する場合
- 切れた接続のアイドル時間が設定値（ALB 60秒、NLB TCP 350秒など）の直後に集中し、その時間より長く放置してから動くと再現する。NLBではその時刻にTCP_ELB_Reset_Countが増える
- 該当しない場合
- アイドル時間と関係なく切れるならこの原因ではない。ロードバランサーを通さずに直接つなぐサーバーで350秒付近に集中するなら「クラウドのセキュリティグループによる接続追跡の期限切れ」、ユーザーの家庭用ルーター側なら「NATマッピングの期限切れ」
- 確認手段
- インフラのツールで確認（ゲームコード不要）
出典
- Edit attributes for your Application Load Balancer AWS
ALBのアイドルタイムアウトはデフォルト60秒（1〜4,000秒）、クライアント・ターゲットとの接続がこの時間通信しなければロードバランサーが接続を閉じる - Network Load Balancers AWS
NLBのTCPアイドルはデフォルト350秒（60〜6,000秒）、過ぎると追跡だけを止め、その後にデータが来るとRST、UDPフローの120秒は変更不可 - Configure load balancer TCP reset and idle timeout Microsoft Azure
Azure Load Balancerのアイドルタイムアウトはデフォルト4分（4〜100分）、超えるとセッション維持の保証なし、TCPリセットはオプション設定 - CloudWatch metrics for your Network Load Balancer AWS
TCP_ELB_Reset_Count：ロードバランサーが生成して送ったRSTパケットの数
あわせて読みたい原因
同じ層：L5 データセンターのネットワーク機器
同じ症状（切断）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る