한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

ロードバランサーの偏り・ヘルスチェックの誤判定 LB imbalance, bad health checks

原因ID dc-lb-imbalance · 主担当 インフラチーム・ネットワークインフラ · 副担当ゲーム開発チーム・サーバー開発

接続が1台のサーバーだけに集中したり、すでに落ちたサーバーに人を送り続けたりします。

なぜ振り分けルールが合っていないか、ヘルスチェックが実際の状態を捉えられていない → すると 1台のサーバーだけが過負荷、または落ちたサーバーへの接続試行 → 画面では 一部のチャンネル・一部の人だけスローモーション、接続不可・無限ロード

症状: スローモーション, 接続不可・無限ロード
要因: ストール, パケットロス
誰に起きるか: 特定の場所・チャンネル
いつ: 接続直後・メンテ明け, 人が集中したとき
担当: 主担当 インフラチーム・ネットワークインフラ · 副担当ゲーム開発チーム・サーバー開発
ゲーム開発チームの対応: ロードバランサーからの確認リクエストに、実際のゲームの状態（ティックの進行、DB接続）を見て応答するヘルスチェックの実装、サーバーの負荷の値も一緒に返す。
インフラチームの対応: ヘルスチェックを実際のゲームの応答を確認する方式に変える、サーバー負荷に基づく振り分け、サーバーごとの接続数の差を監視。
グラフでは: 一部だけ高い · サーバーごとの接続数・CPU使用率
確認箇所: ロードバランサー配下のサーバーごとの接続数（ss -s）とCPU使用率を1つのグラフに重ねて確認し、ロードバランサーのターゲットのヘルス状態（AWSはCloudWatchのHealthyHostCount・UnHealthyHostCount）をゲームサーバーの実際の状態と比較
該当する場合: 1〜2台のサーバーだけ接続数・CPUがほかのサーバーより大きく高いか、ティックが止まったサーバーがヘルス状態「正常」のまま新しい接続を受け続けている
該当しない場合: サーバーごとの接続数が均等なのに1つのチャンネルだけ重ければ、そのチャンネル内の負荷（「シングルスレッドのエリア過負荷（ホットスポット）」）
確認手段: インフラのツールで確認（ゲームコード不要）
実際の事例: AWS 2025: AWS us-east-1のDynamoDB DNS障害と長引いた復旧

出典

Load Balancing in the Datacenter Google
単純なラウンドロビンではタスク間のCPU使用量が最大2倍まで開く、バックエンドが応答・ヘルスチェックに負荷を載せて返す重み付き振り分け、リクエストの受け付けを止めるlame duck状態
Health checks for Network Load Balancer target groups AWS
ヘルスチェックはデフォルト30秒間隔・2回失敗で除外、UDPサービスはTCP・HTTPのヘルスチェックで確認するため、実際のサービス状態を反映するよう構成することを推奨
CloudWatch metrics for your Network Load Balancer AWS
HealthyHostCount・UnHealthyHostCount：正常・異常と判定されたターゲットの数

あわせて読みたい原因

同じ層：L5 データセンターのネットワーク機器

同じ症状（スローモーション）を起こすほかの層の原因

固定タイムステップの追いつき処理の暴走 L1 クライアントのゲームプロセス
スレッド過多とコンテキストスイッチ L7 サーバーOS（カーネル）
コンテナのCPUスロットリング（CFSクォータ） L7 サーバーOS（カーネル）
サーバーの電源管理（C-state・周波数制御）による遅延スパイク L7 サーバーOS（カーネル）
定期実行ジョブ L7 サーバーOS（カーネル）
OS・カーネル・ドライバー・ファームウェアのアップデート後の性能変化 L7 サーバーOS（カーネル）
遅いクライアントによるブロッキング送信 L8 ソケットとプロトコル
ブロッキングI/O構造 L8 ソケットとプロトコル

図と実験のあるメインページでこのカードを見る