ゲームラグ白書 › L6 サーバーのネットワークカード
クラウドホストのメンテナンス・ライブマイグレーション Cloud host maintenance / live migration
原因ID nic-host-maintenance · 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発, 外部・外部
図と実験のあるメインページでこのカードを開く →
クラウド事業者は物理サーバー（ホスト）をメンテナンスするとき、仮想マシンを別のホストに移したり（ライブマイグレーション）、一時的に止めたりします。その間はサーバー全体が止まり、止まる時間が長いと接続が切れます。
なぜ 事業者がホストのメンテナンスや故障予測のために、仮想マシンを別のホストに移すか一時停止 → すると 移している間はCPU・メモリ・ネットワークが遅くなり、最後に仮想マシンが一瞬完全に止まる（事業者と方式によって1秒未満〜30秒前後） → 画面では サーバーの全員が同時にフリーズした後に早送り・ワープ、停止がタイムアウトより長ければ大量の切断
症状 フリーズ , 早送り , ワープ , 切断 要因 ストール, パケットロス
誰に起きるか サーバー全体
いつ ときどきランダムに
担当 主担当 インフラチーム・サーバーインフラ · 副担当 ゲーム開発チーム・サーバー開発, 外部・外部
ゲーム開発チームの対応 数秒の停止に耐えるタイムアウト、停止後に追いつくためのティック数に上限を設ける、経過時間はモノトニッククロック（monotonic clock）で計算、メンテナンス通知を受けたら進行状況を保存してユーザーを別のサーバーに移す手順。
インフラチームの対応 メンテナンス通知の購読とアラート（Google Cloudのmaintenance-event、AWSのスケジュールされたイベント・AWS Health、Azure Scheduled Events）、通知を受けたらユーザーの少ない時間帯に前もってサーバーを入れ替える、事業者が許可していればメンテナンス時刻を調整（Azure Maintenance Configuration、種類によってはAWSのスケジュールされたイベント）、メンテナンス記録と障害記録を照合。
外部の対応 クラウド事業者にメンテナンスのスケジュールと影響範囲を確認、同じインスタンスで停止が繰り返されるなら報告。
数値の目安 Google Compute Engineは、ライブマイグレーションによる停止は通常1秒よりずっと短いとしており、停止中にシステム時刻が最大5秒先に飛ぶことがあります。メタデータのmaintenance-eventの値は、移行の60秒前に変わります（それ以前にこの値を一度以上取得している場合）。Azureは、再起動が不要なメンテナンスであればほぼ常に10秒未満、まれに（一般的なサイズでは18か月に1回以下）約30秒止まり、ライブマイグレーションは通常5秒を超えません。Azure Scheduled Eventsは、こうした停止（Freeze）を少なくとも15分前に通知します。ただし、ホストのハードウェアが突然故障した場合は、通知なしですぐに復旧を始めます。
グラフでは 確認箇所 停止した時刻を事業者の記録と照合。Google Cloudは監査ログのcompute.instances.migrateOnHostMaintenance、AWSはdescribe-instance-status・AWS Healthのスケジュールされたイベント、Azureはアクティビティログ（Activity Log）のMicrosoft.Compute/virtualMachines/liveMigration/actionと、VMの可用性メトリクス（VmAvailabilityMetric）が0に落ちた時刻。サーバー内では、停止中にメトリクス・ログが空白になっていないか、直後に時刻が飛んでいないか（時刻同期のログ）を確認 該当する場合 サーバー全体が止まった時刻が、事業者の記録したメンテナンス・マイグレーションの時刻と重なり、その数秒間はサーバー内のメトリクス・ログがすべて空白 該当しない場合 事業者の記録になく、短い停止が頻繁に繰り返されるなら「CPUスチール（仮想マシン）」。カーネルログにNICのリセットの記録があれば「NICドライバー・ファームウェアの問題」 確認手段 インフラのツールで確認（ゲームコード不要）
もっと詳しく AWSはスケジュールされたイベントで通知します。system-rebootは再起動して新しいホストに移すことを、system-maintenanceはネットワーク・電源のメンテナンスで一時的に影響を受ける可能性があることを意味します。停止が数秒でも、その間にサーバーへ送ったパケットのACKを受け取れなかったクライアントは再送の待ち時間を2倍ずつ延ばしていくため、停止が解けた後もTCP接続はさらに長く止まったままになることがあります（「TCPのRTOと指数バックオフ」）。停止から復帰すると時刻が飛んで「システム時刻のジャンプ（NTPステップ）」につながることもあり、ロードバランサーのヘルスチェックが失敗してそのサーバーが一時的に外されることもあります。移行できないインスタンス（Google Cloudのベアメタルインスタンスなど）は、メンテナンス時に停止または再起動されます。
出典 Live migration process during maintenance events Google Cloud ライブマイグレーションによる停止は通常1秒よりずっと短い、停止中にシステム時刻が最大5秒先に飛ぶ、移行中はディスク・CPU・メモリ・ネットワークの性能が一時的に下がる、ライブマイグレーションしないVMはメンテナンス時に終了（ベアメタルインスタンスは非対応） Query metadata server for maintenance event notices Google Cloud maintenance-eventのメタデータ値がライブマイグレーションの60秒前に変わる（ライブマイグレーションの設定で、前回のメンテナンス以降にこの値を一度以上取得している場合） Monitor and plan for a host maintenance event Google Cloud メンテナンス時に、監査ログにcompute.instances.migrateOnHostMaintenanceのシステムイベントが残る Scheduled events for Amazon EC2 instances AWS スケジュールされたイベントの種類（system-rebootは再起動して新しいホストへ移動、system-maintenanceはネットワーク・電源のメンテナンスで一時的に影響）、メール・AWS Healthで通知、describe-instance-statusで確認、種類によっては時刻を調整可能 Maintenance and updates Microsoft Azure 再起動なしのメンテナンスはほぼ常に10秒未満の停止、まれに（一般的なサイズでは18か月に1回以下）約30秒、ライブマイグレーションは通常5秒以下、停止後に時刻を自動同期、長いTCP接続が切れたり、相手が停止中のVMに送ったデータを指数バックオフで再送して復旧がさらに遅れたりすることがある、ロードバランサーのヘルスチェックが約10秒で異常と判定、アクティビティログのMicrosoft.Compute/virtualMachines/liveMigration/actionと停止中に0になるVmAvailabilityMetricで確認、Maintenance Configurationで適用時刻を選択 Scheduled Events for Linux VMs in Azure Microsoft Azure Freeze（数秒の停止、CPU・ネットワークが止まることがある）は少なくとも15分前に通知、ホストのハードウェア故障時は通知期間なしですぐに復旧を開始 あわせて読みたい原因
同じ層：L6 サーバーのネットワークカード
同じ症状（フリーズ）を起こすほかの層の原因
図と実験のあるメインページでこのカードを見る