Azure VM の物理ホストにおける​メモリ劣化検知と Live Migration による自動復旧

Azure VM / SRE Azure VM の物理ホストにおける メモリ劣化検知と Live Migration によ る自動復旧 VM の一時停止時間 0.838 秒 Azure の通知内容、Live Migration と VM-PHU の違い、Resource Health の分類 、SRE として確認したいことを整理する 解説記事（Zenn） zenn.dev/skmkzyk/articles/azure-vm-memory-degraded ゲスト OS の再起動なしで 健全なホストへ移行

01 何が起きたか：二段階の通知で予防的に復旧 ① 事前通知：物理ホストのメモリ劣化 物理ホストのメモリに劣化の可能性。Azure が安全な移行を試行。自 動移行を待つか、期限までに Redeploy するかを選択可能。 Redeploy 期限：2026/10/30 8:07 JST（障害予告ではない） ② 完了通知：Live Migration 成功 メモリ状態を保持する Live Migration により VM は 0.838 秒間一時 停止。追加のユーザー操作は不要。 ゲスト OS の再起動は伴わない 実際の Resource Health 履歴（完了通知） イベントの時系列 1 2 3 4 5 6 劣化を検知 リスク通知 移行準備 一時停止 移行完了 完了通知 ホストメモリに異常の兆候 クラッシュ・性能低下の可 能性 Live Migration を試行 VM が 0.838 秒停止 メモリ状態を保持し実行継 続 追加操作不要

02 Live Migration・VM-PHU・Redeploy の違い 比較項目 Live Migration（今回） VM-PHU Redeploy 主な目的 VM の物理ホスト間移行 物理ホストのソフトウェア更新 VM を別ホストへ再配置 物理ホストの変更 あり 原則なし あり メモリ状態 移行先へ引き継ぐ 同一ホスト内で保持 保持されない ゲスト OS の再起動 原則不要（短時間の Freeze） 原則不要（一時停止あり） 発生する 一時ディスク 通常維持 — 内容が失われる可能性 実施タイミング Azure 側で制御 Azure 側で制御 ユーザーが選択できる 判断：事前通知で「ホストのメモリ劣化を検知し移行を試みる」と示されていたため、今回は VM-PHU によるホスト更新ではなく、劣化した ホストから VM を退避させる Live Migration と解釈するのが妥当。完了通知が出て Resource Health も回復していれば、改めて Redeploy する必要性は低い。

03 Resource Health での分類：Degraded と Downtime Freeze 事前通知に対応 完了通知に対応 VirtualMachinePossiblyDegradedDueToHardwareFailure WithRedeployDeadlineLiveMigrationEligible LiveMigrationSucceeded Context Platform initiated Context Platform initiated Category Unplanned Category Unplanned ImpactType Degraded ImpactType Downtime Freeze ハードウェア障害の予測により可用性にリスクがある状態。性能がすで に低下しているとは限らない。 Live Migration が成功し、短時間の一時停止が発生したことを示す。OS 再起動（Downtime Reboot）とは区別される。 Azure 公式では Live Migration の一時停止は通常 5 秒未満。今回の 0.838 秒はその範囲内で、ゲスト OS の再起動を伴わない「Freeze」に 該当する。

04 SRE として確認・備えておきたいこと 事後に確認すること ✓ Resource Health の履歴 検知・移行完了の時刻、Available への復帰、新たな異常の有無。 Resource Graph で複数サブスクリプションを横断確認 ✓ アプリへの影響 応答時間・エラーレート・外形監視・DB 接続を移行時刻と照合。1 分集計では見えないため秒単位の監視やトレースも併用 ✓ OS 再起動の有無 Windows は System イベントログ、Linux は uptime / journalctl / last reboot。再起動があれば別イベントを調査 今後の運用で考慮すること 障害予測は回避の保証ではない 移行前にホストが故障すれば予期しない停止も。冗長構成・ Availability Zones・再試行は引き続き必要 Freeze を考慮したタイムアウト設計 短すぎるタイムアウトは基盤メンテを障害として観測。処理特性 と再試行の安全性で設計 Scheduled Events の活用 Freeze / Reboot / Redeploy をゲスト OS から取得。ただし通 知なしの停止にも備える