Azure での仮想マシンのメンテナンス

適用対象: ✔️ Linux VM ✔️ Windows VM ✔️ フレキシブル スケール セット ✔️ 均一スケール セット

Azure では、定期的にそのプラットフォームを更新して、仮想マシンのホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。 これらの更新の目的は、ホスティング環境のソフトウェア コンポーネントの修正から、ネットワーク コンポーネントのアップグレード、ハードウェアの使用停止まで、広い範囲に及びます。

更新は、ホストされている VM にはほとんど影響しません。 更新が影響を及ぼす場合、Azure は影響が最小となる更新方法を選択します。

• 更新で再起動を必要としない場合、VM は、ホストの更新中に一時停止されるか、または既に更新済みのホストにライブ移行されます。

• 更新で再起動が必要な場合は、Azureによって計画メンテナンスが通知されます。 Azure により、都合の良いときに自分でメンテナンスを開始できる時間枠も与えられます。 セルフメンテナンス期間は、メンテナンスの種類によって異なります。

  • ハードウェアの使用停止: 自己メンテナンス期間は通常 14 日間です。
  • ホストメンテナンス: メンテナンスが緊急でない限り、通常、セルフメンテナンス期間は 35 日です。

  Azureは、計画的なプラットフォームメンテナンスで VM の再起動が必要なケースの数を減らすために、テクノロジに投資しています。 計画メンテナンスの管理手順については、「Azure CLI、PowerShell、またはポータルを使用した計画メンテナンス通知の処理」を参照してください。

このページでは、2 種類のメンテナンスが Azure でどのように実行されるかについて説明します。 計画外のイベント (停止) の詳細については、Windows 向けの VM の可用性の管理に関する記事または Linux 向けの該当する記事をご覧ください。

VM 内で、Linux または Windows 向けの Scheduled Events を使用して、今後のメンテナンスに関する通知を受け取ることができます。

再起動を必要としないメンテナンス

ほとんどのプラットフォーム更新は、お客様の VM に影響しません。 影響を及ぼさない更新が不可能な場合、Azure は、お客様の VM への影響が最小となる更新メカニズムを選択します。

VM に影響を与えるメンテナンスが必要な場合、ほとんどは VM を一時停止することで 10 秒未満で完了します。 まれな状況で、Azure では、VM を約 30 秒間一時停止するメカニズムが使用されます。これは、汎用 VM サイズの場合、18 か月に 1 回以下の頻度で行われます。 一時停止操作の後、VM のクロックは再開時に自動的に同期されます。

メモリ保持メンテナンスは、Azure VM の 90% 以上で機能します。 G、L、N、H シリーズでは機能しません。 詳細については、 メモリ保持メンテナンスをサポートする VM サイズを参照してください。 Azure では、ライブ マイグレーション テクノロジの使用を拡大すると共に、一時停止期間を短縮するためにメモリ保持メンテナンス メカニズムの改善に取り組んでいます。

再起動を必要としないメンテナンス操作は、一度に 1 つの障害ドメインに適用されます。 それらは、プラットフォーム監視ツールから警告の正常性シグナルを受信した場合、停止します。 再起動を必要としないメンテナンス操作は、ペアになっているリージョンまたは Availability Zones で同時に行われる場合があります。 特定の変更の場合、デプロイは主に Availability Zones のペア間およびリージョンのペア間でシーケンスされますが、末尾で重複が発生する場合があります。

こうした種類の更新が、一部のアプリケーションに影響を与える可能性があります。 VM を別のホストにライブ移行する場合、影響を受けやすい一部のワークロードでは、VM の一時停止に至るまでの数分間にわずかなパフォーマンスの低下が見られることがあります。 VM のメンテナンスに対する準備をして Azure のメンテナンスの影響を減らすには、そのようなアプリケーションに Linux または Windows 向けの Scheduled Events を使用してみてください。

ゼロインパクトやリブートレスの更新を含むすべてのメンテナンス アクティビティをより詳細に制御するには、メンテナンス構成機能を作成できます。 メンテナンス構成の作成では、すべてのプラットフォーム更新プログラムをスキップし、都合のよいときに更新プログラムを適用することができます。 詳しくは、「メンテナンス構成によるプラットフォームの更新の管理」をご覧ください。

ライブマイグレーション

ライブ マイグレーションは、再起動を必要とせず、VM のメモリを保持する操作です。 これにより一時停止または凍結が発生しますが、その継続時間は通常は 5 秒未満です。 G、L、N、H シリーズを除く、サービスとしてのインフラストラクチャ (IaaS) VM はすべて、ライブ マイグレーションに対応しています。 ライブ マイグレーションは、M シリーズ SKU の大部分で利用できます。 対象となる VM は、Azure フリートにデプロイされている IaaS VM の 90% 以上に相当します。

Azure プラットフォームは、次のシナリオでライブ マイグレーションをトリガーします。

• 計画メンテナンス
• ハードウェア障害
• 割り当ての最適化

計画メンテナンスの一部のシナリオでライブ マイグレーションが使用されており、Scheduled Events を使用して、ライブ マイグレーションの操作がいつ開始するか事前に把握できます。

ライブ マイグレーションを使用して、Azure Machine Learning アルゴリズムが、差し迫ったハードウェア障害または VM 割り当ての最適化を予測するときに、VM を移動することもできます。 機能低下しているハードウェアのインスタンスを検出する予測モデリングの詳細については、予測機械学習とライブ マイグレーションによる Azure VM の回復性の向上に関する記事をご覧ください。 ライブ マイグレーションの通知は、Azure portal の Monitor および Service Health のログ、およびScheduled Events に表示されます (これらのサービスを使用している場合)。

ライブ マイグレーション中の TCP 接続の回復性

データベース サーバー、メッセージ ブローカー、キャッシュ 層など、有効期間の長い TCP 接続を維持するアプリケーションでは、ライブ マイグレーション中に接続の中断が発生する可能性があります。 VM の一時停止は通常 5 秒以下ですが、一時停止中および一時停止後の TCP スタックの動作では、対処されていない場合はアプリケーション レベルの復旧時間を延長できます。

ライブ マイグレーションが TCP 接続に与える影響:

• 一時停止中、実行中の TCP セグメントは移行中の VM によって確認されません。
• 送信側 (クライアントまたはロード バランサーの正常性プローブ) は、指数バックオフで TCP 再送信を開始します。
• Azure Standard Load Balancerは、構成されたアイドル タイムアウトを超えるアイドル接続に TCP RST を送信します。 ただし、実行中のデータを使用するアクティブな接続の場合、ロード バランサーは移行の一時停止中に TCP RST を送信しません。 接続は開いたままですが、応答せず、クライアントは障害の即時シグナルを受け取っていません。
• アプリケーション レベルのチューニングを行わないと、既定の TCP 再送信動作 (Linux tcp_retries2 = 15 ) によって、接続エラーの検出が約 15 分遅れる可能性があります。

マルチインスタンスデプロイでブラスト半径を減らす:

TCP レベルの軽減策を適用する前に、アーキテクチャ ベースラインを検討してください。 ライブ マイグレーションは、可用性セットまたは仮想マシン スケール セット内で一度に 1 つの VM に影響します。 複数のバックエンド インスタンスに接続を分散すると、単一の移行イベントの影響が制限されます。

• 3 つのインスタンスを持つスケール セットは、各移行イベントがアクティブな接続の最大 3 分の 1 に影響を与えます。
• Availability Zones間でデプロイすることで、異なるゾーンでの移行が重複しないようにします。
• 複数のバックエンドに分散された接続プールを持つクライアントは、影響を受けない接続が要求をすぐに処理し続けるので、回復速度が速くなります。

VM の一時停止中は、一時停止されたバックエンドに対する Azure Standard Load Balancer の正常性プローブも失敗します。 ロード バランサーは、バックエンドを約 10 秒以内に異常としてマークし (既定の 5 秒間隔で 2 回連続するプローブ障害)、新しい接続のルーティングを停止します。 この条件は、新しい接続が自然に保護されていることを意味します。 この記事で説明する TCP 軽減策は、移行が開始される前に既に確立されている既存の接続に対処します。

推奨される軽減策:

次の軽減策は補完的です。 一緒に実装すると、ライブ マイグレーション イベントの影響を数分のダウンタイムから自動復旧の数秒に減らすことができます。

軽減策 1: TCP_USER_TIMEOUT (最速の検出)

TCP_USER_TIMEOUT は、カーネルが送信されたデータの受信確認を待機してから接続が停止したことを宣言する時間を制御します。 これをソケットあたり 30 秒 (30000 ミリ秒) に設定すると、検出時間が大幅に短縮されます。

// Per-socket (recommended)
int timeout = 30000; // 30 seconds in milliseconds
setsockopt(fd, IPPROTO_TCP, TCP_USER_TIMEOUT, &timeout, sizeof(timeout));

または、システム全体の再送信数を減らします。

# /etc/sysctl.conf — reduces retransmit ceiling to ~25-50 seconds
net.ipv4.tcp_retries2 = 5

Windowsの考慮事項:

TCP_USER_TIMEOUT ソケット オプションは Linux に固有です。 Windowsでは、TCP 再送信動作は異なる方法で制御されます。

• Windowsの既定値は 5 回の再送信 (TcpMaxDataRetransmissions) であり、チューニングなしで約 25 ~ 50 秒の検出時間が既に提供されています。
• Windowsの検出時間をさらに短縮するには、レジストリを調整します。

# Reduce TCP retransmissions (system-wide, requires reboot)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" `
    -Name "TcpMaxDataRetransmissions" -Value 3 -Type DWord

TcpMaxDataRetransmissionsを 3 に設定すると、最初の再送信タイムアウトに応じて検出時間が約 10 ~ 20 秒に短縮されます。

軽減策 2: スケジュールされたイベント (プロアクティブ ドレイン)

スケジュールされたイベント サービスは、ライブ マイグレーションが開始される前に事前通知を提供します。 アプリケーションは Freeze イベントをリッスンし、一時停止が発生する前に事前に接続をドレインできます。

GET http://169.254.169.254/metadata/scheduledevents?api-version=2020-07-01
Headers: Metadata: true

ライブ マイグレーション イベントは次のように表示されます。

{
  "EventType": "Freeze",
  "ResourceType": "VirtualMachine",
  "Resources": ["myVM"],
  "EventStatus": "Scheduled",
  "NotBefore": "2026-04-29T18:00:00Z"
}

Freeze イベントが検出された場合:

1. 影響を受けるノードでの新しい接続の受け入れを停止します。
2. 既存の接続をドレインする (クライアントに他のノードへの再接続を通知する)。
3. タイムアウトの上限を設けて、進行中の操作が完了するまで待機します。
4. 必要に応じて、EventId をポストバックしてイベントを確認します。

軽減策 3: TCP キープアライブ チューニング

TCP キープアライブ プローブは、移行イベントの後にアイドル状態になった接続を検出します。

net.ipv4.tcp_keepalive_time = 30      # seconds before first probe (default: 7200)
net.ipv4.tcp_keepalive_intvl = 10     # seconds between probes (default: 75)
net.ipv4.tcp_keepalive_probes = 3     # probes before declaring dead (default: 9)

これらの設定では、アイドル状態の古い接続が 60 秒以内に検出されます (30 + 10 x 3)。 キープアライブ プローブも Standard Load Balancer のアイドル タイムアウトに対するアクティビティとしてカウントされるため、ロード バランサー自体がアイドル接続をタイムアウトするのを防ぎます。

軽減策 4: クライアント側の再試行ロジック

アプリケーション レベルの再接続と再試行ロジックにより、障害検出方法に関係なく復旧が保証されます。

1. 接続エラー (タイムアウト、RST、または接続拒否) を検出します。
2. 停止している接続を閉じて、接続プールから削除します。
3. 同じノードまたは別のノードへの新しい接続を開きます。
4. 指数バックオフを使用して操作を再試行します。

データベース SDK と接続プールの場合は、定期的な正常性チェック (たとえば、10 ~ 15 秒ごとに軽量 ping) を有効にして、接続を事前に検証します。

接続プールの構成:

有効期間が長い接続を維持する接続プールは、最長有効期間の設定の恩恵を受けます。 この設定により、定期的な接続のリサイクルが強制され、1 つの接続が将来の移行イベントから無制限のリスクを蓄積しないようにします。

最大存続時間を 30 分に設定すると、アクティブなヘルスチェックがなくても、接続が検知されない古い状態のまま長時間放置される前に、自然に置き換えられます。

監視と可観測性:

ライブ マイグレーション イベントが TCP 接続に与える影響を検出して測定するには、次の方法を使用します。

• Azure Monitor VM 可用性メトリック (プレビュー): VM の一時停止中に 0 に低下します。 移行イベントを検出するために、しきい値が 1 未満の VmAvailabilityMetric にアラート ルールを作成します。
• スケジュールされたイベント アクティビティ ログ:ライブ マイグレーション イベントは、操作名がMicrosoft.ComputeMicrosoft.Compute/virtualMachines/liveMigration/action プロバイダーのアクティビティ ログに表示されます。また、メタデータ サービスを使用してクエリを実行すると、Freeze イベントとして表示されます。
• アプリケーション レベルの接続エラー率: アプリケーション メトリックで TCP 接続のリセット、タイムアウト、再接続の数を監視します。 VM 可用性の低下と関連する接続エラーの急増により、移行への影響が確認されます。
• TCP 再送信カウンター: Linux では、 /proc/net/netstat フィールドの TCPTimeouts を監視するか、 ss -ti を使用して個々のソケットの再送信数を観察します。 既知のメンテナンス時間帯に再送信数の増加が見られることは、接続に影響が及んだことを示しています。

# Linux: Check TCP timeout statistics
cat /proc/net/netstat | grep -i timeout
# Or per-socket retransmission info
ss -ti | grep -i retrans

通常の操作中にこれらのメトリックのベースラインを確立すると、移行イベントの影響を定量化し、軽減策が期待どおりに動作していることを簡単に検証できます。

ライブ マイグレーションの中断に対する許容度がゼロのワークロード

ライブ マイグレーションの中断を許容できないワークロードの場合は、メンテナンス構成で専用ホストAzure使用することを検討してください。 専用ホストを使用すると、ホスト レベルのメンテナンスがいつ行われるのか制御できるため、突然のライブ マイグレーション イベントを排除できます。

再起動を必要とするメンテナンス

計画メンテナンスで VM の再起動が必要になるまれなケースでは、事前に通知が届きます。 計画メンテナンスには、"セルフサービス フェーズ" と "予定メンテナンス フェーズ" の 2 つのフェーズがあります。

通常 4 週間続くセルフ サービス フェーズ中に、ご利用の VM でメンテナンスを開始します。 セルフ サービスの一環として、個々の VM に照会し、その状態と自分が最後に行ったメンテナンス要求の結果を確認できます。

セルフサービス メンテナンスを開始すると、VM は、既に更新済みのノードに再デプロイされます。 VM が再デプロイされるため、一時ディスクは失われ、仮想ネットワーク インターフェイスに関連付けられた動的パブリック IP アドレスは更新されます。

セルフサービス メンテナンス中にエラーが発生した場合、その操作が停止し、VM は更新されず、セルフサービス メンテナンスを再試行するオプションが提供されます。

セルフ サービス フェーズが終了すると、予定メンテナンス フェーズが開始します。 このフェーズの間、ユーザーはメンテナンス フェーズについて照会することはできますが、自分でメンテナンスを開始することはできません。

再起動を必要とするメンテナンス管理の詳細については、Azure CLI、PowerShell、またはポータルを使用した計画メンテナンスの通知の処理に関する記事を参照してください。

予定メンテナンス中の可用性に関する考慮事項

予定メンテナンス フェーズまで待つ場合、ご利用の VM の可用性を最大限に保つために考慮すべき事柄がいくつかあります。

ペアになっているリージョン

各 Azure リージョンは、同じ地理的近傍内の別のリージョンとペアになっています。 それらは合わせて 1 つのリージョン ペアになります。 予定メンテナンス フェーズの間、Azure はリージョン ペアの一方のリージョンの VM だけを更新します。 たとえば、Azure は米国中北部の VM の更新中、同時に米国中南部の VM を更新することはありません。 ただし、北ヨーロッパなどのその他のリージョンは、米国東部と同時にメンテナンスされる可能性があります。 各リージョンに対して適切に VM を分散させるためには、リージョン ペアの動作を理解することが大切です。 詳細については、Azure リージョン ペアに関するページを参照してください。

可用性ゾーン

可用性ゾーンは、Azure リージョン内の一意の物理的な場所です。 それぞれのゾーンは、独立した電源、冷却手段、ネットワークを備えた 1 つまたは複数のデータセンターで構成されています。 回復性を確保するため、有効になっているリージョンにはいずれも最低 3 つのゾーンが別個に存在しています。

可用性ゾーンは、障害ドメインと更新ドメインを組み合わせたものです。 Azure リージョン内の 3 つのゾーンに 3 つ以上の VM を作成する場合、VM は実際には 3 つの障害ドメインと 3 つの更新ドメインに分散されます。 Azure プラットフォームは更新ドメインへのこの分散を認識し、異なるゾーン内の VM が同時に更新されないようにします。

各インフラストラクチャの更新は、1 つのリージョン内でゾーンごとにロールアウトされます。 ただし、ゾーン 1 でデプロイを行っているときに、ゾーン 2 で別のデプロイを同時に実行できます。 デプロイはすべてシリアル化されているわけではありません。 ただし、リスクを軽減するために、再起動をが必要な 1 回のデプロイでは、一度に 1 つのゾーンのみロールアウトします。 一般に、再起動が必要な更新プログラムは可能な限り回避され、Azure によって Live Migration の使用や顧客の制御が試行されます。

仮想マシン スケール セット

フレキシブル オーケストレーション モードの仮想マシン スケール セットは、Azure コンピューティング リソースです。これにより、均一オーケストレーション モードの仮想マシン スケール セットのスケーラビリティと可用性セットのリージョンの可用性の保証を組み合わせることができます。

フレキシブルなオーケストレーションを使用すると、インスタンスを複数のゾーンに分散させるか、単一のリージョン内の障害ドメインに分散させるかを選択できます。

可用性セットと均一スケール セット

Azure VM にワークロードをデプロイするとき、可用性セット内に VM を作成して、アプリケーションの高可用性を確保することができます。 可用性セットを使用すると、再起動を必要とする停止またはメンテナンス イベントの間であっても、少なくとも 1 つの VM を確実に使用できるようになります。

可用性セット内の個々の VM は最大 20 個の更新ドメインに分散されます。 予定メンテナンス中は、どの時点においても 1 つの更新ドメインのみが更新されます。 更新ドメインは必ずしも順番に更新されるとは限りません。

均一オーケストレーション モードの仮想マシン "スケール セット" は、同一の VM のセットを単一のリソースとしてデプロイして管理するために使用できる Azure コンピューティング リソースです。 スケール セットは、可用性セット内の VM と同じように、UD をまたがって自動的にデプロイされます。 可用性セットと同様に、均一スケール セットを使用する場合、予定メンテナンス中に更新される UD は一度に 1 つだけです。

高可用性のための VM の設定の詳細については、Windows 向けの VM の可用性の管理に関する記事または Linux 向けの該当する記事をご覧ください。

次のステップ

計画メンテナンスを管理するには、Azure CLI、Azure PowerShell、またはポータルを使用します。