Azure VM が「更新中（Updating）」のまま固まって操作できない──この記事では、2025 年 9 月 10 日に East US 2 で実際に起きた障害事例をもとに、原因の正体と具体的な復旧手順、そして次回以降の影響を最小化するための設計・運用のポイントを解説します。
症状の整理：East US 2 の VM が「更新中」から戻らない
今回題材にするのは、Microsoft Q&A に投稿された次のようなケースです。
- Start VM 機能で VM を起動すると初期化に失敗する
- ポータルから手動で起動しても失敗し、状態が「更新中（Updating）」のまま固定される
- 診断情報では一部の VM で
ComputeAllocationInternalErrorが記録される - 別の診断では、中東経由のネットワーク経路による遅延が示される
- すべての VM は East US 2 リージョンに配置されている
運用担当者から見ると、
- VM の再起動すらまともにできない
- 更新中の状態なので削除やサイズ変更も怖くて触れない
といった、かなり嫌な状況です。
原因：East US 2 のプラットフォーム障害（Allocator サービス不具合）
公式な障害情報のタイムライン
この事象の根本原因は、East US 2 リージョン側のプラットフォーム障害です。Microsoft Q&A の回答では、次のように説明されています。
- 2025-09-10 の 09:23 UTC ～ 13:37 UTC の間、East US 2 の VM に影響する問題が発生
- 同期間、Start/Stop を含む各種操作が失敗することがある
- 現在は障害はすでに解消済みである
また、Azure Service Health の通知文面では、
- 「2025-09-10 09:12 UTC 頃から」 East US 2 の VM / VMSS の作成・削除・更新・スケール・起動・停止にエラーが出る場合がある
- Synapse、Backup、Data Factory、AKS、Azure Databricks など VM 依存のサービスにも影響する場合がある
といった内容が案内されています。
さらに、Azure のステータス履歴では、この障害は次のように整理されています。
| 項目 | 内容 |
|---|---|
| 事象名 | サービス管理操作の失敗（Service management operations failures in East US 2） |
| 日付 | 2025 年 9 月 10 日（UTC） |
| 主な影響時間 | 09:03 ～ 18:50 UTC（サービス管理プレーンの劣化） |
| 完全復旧確認 | 19:30 UTC 頃 |
| 影響範囲 | East US 2 の AZ02・AZ03 を中心に VM / VMSS の作成・削除・スケール・起動・停止が失敗または長時間ブロック |
| 主因 | Azure Compute コントロールプレーンに属する Allocator サービスの不具合 |
つまり、ユーザー側の設定ミスや VM 内 OS の問題ではなく、「VM を管理する側の Azure 基盤」でトラブルが発生し、その結果として VM が「更新中（Updating）」から戻らない状態に陥っていました。
Allocator サービスとは何をしているのか
Azure Resource Manager (ARM) は、ユーザーの「VM を作る／起動する／止める」といったリクエストを受け取り、裏側で複数の管理サービスに処理を振り分けます。その管理サービス群の一つが、Availability Zone ごとに配置された Allocator サービス です。
今回の障害では、この Allocator に導入された新しいスロットリング（負荷制御）ロジックが、East US 2 の高いトラフィックと一部の性能問題により暴走し、
- VM の作成・起動・停止などの管理操作が、内部で大量のリトライを発生
- 結果としてコントロールプレーンが自分で自分の首を絞めるような状態になり、操作が完了しなくなる
という悪循環に陥りました。これが「更新中のまま戻らない」状態の正体です。
ComputeAllocationInternalError の意味と読み解き方
エラー名が示していること
ComputeAllocationInternalError は、文字どおり「計算リソース（Compute）の割り当てに関する内部エラー」を意味します。代表的には次のようなケースで現れます。
- リージョンや特定 SKU に一時的な容量不足が発生している
- ホスト側の障害で、VM の再配置が必要だが自動処理に失敗している
- 今回のように、Allocator などコントロールプレーン側の不具合が起きている
ポイントは、このエラー名だけで「ユーザーの設定ミス」とは言い切れないということです。特に、
- 複数の VM・複数サブスクリプションで同時多発
- Azure Q&A や Service Health でも同リージョンのエラー報告がある
といった状況なら、かなり高い確率でプラットフォーム起因を疑うべきです。
「中東経由のネットワーク遅延」との関係
今回の質問では、診断の一部に「中東経由のネットワーク経路による遅延」が出ていました。これは、VM の物理的な場所が中東に移動したわけではなく、
- クライアントから Azure へのインターネット経路が、たまたま中東経由の経路を選択していた
- 2025 年 9 月 6 日頃に Red Sea（紅海）で複数の海底ケーブル切断が発生し、その影響で中東経由のトラフィックにレイテンシ増大が出ていた
といった背景によるものと考えられます。
実際、Microsoft は Red Sea 付近のケーブル切断により、一部の Azure トラフィックに遅延が出ていることを公式に認めています。ただし、今回の East US 2 事件で VM が「更新中」から戻らなかった直接の原因は、あくまで Allocator サービスの不具合 です。ネットワーク遅延は「別レイヤーの問題」であり、診断結果を読む際はここを取り違えないようにしましょう。
まずやるべき復旧確認：停止（割り当て解除）→ 起動
ベースラインとなる対応フロー
障害が公式に「Mitigated（軽減済み）」とされ、Azure 側で根本対策が施された後、最初に行うべきは非常にシンプルです。
- 問題の VM を停止（割り当て解除）する
- 続いて VM を起動し、「実行中（Running）」に戻るか確認する
Azure CLI の例：
# VM を停止（割り当て解除）
az vm deallocate -g <リソースグループ名> -n <VM 名>
# VM を起動
az vm start -g <リソースグループ名> -n <VM 名>
PowerShell の例：
# VM を停止（割り当て解除）
Stop-AzVM -ResourceGroupName <リソースグループ名> `
-Name <VM 名> -Force -StayProvisioned:$false
# VM を起動
Start-AzVM -ResourceGroupName <リソースグループ名> `
-Name <VM 名>
ポータルを使う場合も同じで、
- 「停止」ボタンで停止（割り当て解除）を実行
- 状態が「停止（割り当て解除）」になったことを確認
- 「開始」ボタンで VM を起動し、「実行中」へ遷移するか確認
という流れになります。
停止（割り当て解除）時の注意点：動的パブリック IP
停止（割り当て解除）を行うと、VM に紐づく動的パブリック IP は解放され、再起動後に別の IP が割り当てられます。これを避けたい場合は、
- 対象 VM の NIC に割り当てられているパブリック IP を「静的」に変更する、または新たに静的 IP を割り当てる
- そのうえで停止（割り当て解除）→ 起動を実行する
アプリケーションやファイアウォール設定が IP アドレス前提で作られている環境では、特に事前周知と変更管理が重要です。
再起動後にチェックすべきポイント
起動が成功したら、次の観点で確認します。
| チェック項目 | 内容 |
|---|---|
| ポータルの状態 | 状態が「更新中」ではなく「実行中」になっているか |
| Boot Diagnostics | ブートログ・スクリーンショットに OS 側の起動エラーが出ていないか |
| 接続性 | RDP / SSH でログインできるか、アプリが想定どおり応答するか |
| Azure Monitor アラート | 起動直後に VM あるいは依存サービスで大量のアラートが出ていないか |
まだ直らないときの実務的な手当て
1. 再デプロイ（Redeploy）で別ホストへ移動
VM がどうしてもおかしい場合、同一リージョン内の別ホストに再配置する Redeploy が有効です。
az vm redeploy -g <リソースグループ名> -n <VM 名>
Redeploy の特徴：
- OS ディスク・データディスクはそのまま維持される
- NIC やパブリック IP も同じものが再接続される（ただし一時ディスクは消える）
- 内部的には別の物理ホストに VM を移し替えるイメージ
ホスト側の不整合や一時障害が疑われる場合の定番手段です。
2. 一時的なサイズ変更 → 起動 → 元サイズへ戻す
Azure Status History では、「AZ01 は Allocator の問題からは外れていたが、AMD v4/v5 や Intel v5 など一部 SKU で容量制約が発生していた」とも記載されています。
これが示唆するのは、「特定サイズにしがみつくほど、障害時や逼迫時に不利になる」ということです。対策として、
- 一時的に別サイズ（別 SKU）へ変更して起動
- 状態が安定したら必要に応じて再度元サイズへ戻す
といった回避策が取れます。
# 一時的に別サイズへ
az vm resize -g <RG 名> -n <VM 名> --size Standard_D4s_v5
# 起動
az vm start -g <RG 名> -n <VM 名>
もちろん、アプリケーション側の CPU / メモリ要件やライセンス要件を満たすサイズを選ぶ必要がありますが、「より普及しているサイズ」「複数 AZ で提供されているサイズ」を選ぶと、障害時の逃げ道が広がります。
3. リソース正常性・サービス正常性を改めて確認
操作しても改善しない場合は、そもそも障害が完全に収束しているのかを改めて確認しましょう。
- サービス正常性 (Service Health): リージョン単位の障害・メンテナンス情報
- リソース正常性 (Resource Health): 個々の VM や他リソースの正常性
前者で「まだ East US 2 の障害が続いている／残影響がある」、後者で「この VM だけ Unknown / Unavailable である」といった情報が得られます。障害の性質がわかれば、
- 復旧を待つべきか
- リージョン DR に切り替えるべきか
- 個別 VM だけの再作成に踏み切るべきか
の判断がつきやすくなります。
影響範囲のイメージ：どのサービスが巻き込まれたか
Azure Status History の Post Incident Review では、今回の East US 2 障害で影響を受けた主なサービスが整理されています。
| サービス | 代表的な影響 | ビジネスインパクトの例 |
|---|---|---|
| Virtual Machines / VMSS | 作成・削除・更新・スケール・起動・停止が失敗または長時間ブロック | 新バージョンのロールアウトが止まる、スケールアウトできず負荷耐性低下 |
| Azure Backup | VM バックアップジョブの失敗 | 保護ポイントが欠け、直近の復元ポイントが取れない |
| Azure Batch | プールの拡張・縮小・削除がスタック | バッチジョブが開始できない／終了しない |
| Azure Databricks | ジョブ実行や SQL クエリの遅延・失敗 | 夜間の ETL・データ分析が完了せず、翌朝のレポート遅延 |
| Azure Data Factory | データフローのクラスタ作成失敗などによるパイプラインエラー | DWH へのデータ取り込みや変換処理が止まる |
| Azure Kubernetes Service | クラスター／ノードプールの作成・スケール・アップグレード失敗 | Pod スケールアウトやローリングアップデートが止まり、リリース不能 |
| Azure Synapse Analytics | Spark アクティビティの実行失敗 | データレイク処理全般の停止・遅延 |
| Microsoft Dev Box | Dev Box の起動・接続に失敗 | 開発者が開発用環境にアクセスできない |
VM だけでなく、その上に乗る PaaS サービスやデータ分析基盤が芋づる式に影響を受けることがわかります。障害時は、「アプリがおかしい」ではなく、「下の VM 層で何か起きていないか」をまず疑うのが効率的です。
実務で使える：ComputeAllocationInternalError のチェックリスト
今後、別のリージョンでも ComputeAllocationInternalError が発生しうることを考えると、次のような簡易チェックリストを持っておくと便利です。
| 状況 | プラットフォーム障害の可能性 | 優先する対応 |
|---|---|---|
| 複数 VM / サブスクリプションで同時発生 | 高い | Service Health / Azure Status を確認し、リージョン障害の有無を確認 |
| 特定サイズ・特定 AZ でのみ発生 | 中程度 | 別サイズ・別 AZ への展開を試す、容量制約情報を確認 |
| 1 台だけ、かつ OS や構成を直近変更した | 低い（ユーザー要因の可能性高） | VM ハードニング・拡張機能・カスタムスクリプトなどを確認 |
| 「更新中」から長時間戻らない | プラットフォームかホスト側の問題を強く示唆 | 停止（割り当て解除）→ 起動、Redeploy、サポートチケットの検討 |
このチェックを踏まえて、むやみに構成をいじるよりも、「Azure 側の障害として経過観察すべきか」「DR 切替に踏み切るべきか」を冷静に判断できます。
ネットワーク診断結果の読み方：ルート情報に引きずられない
診断ツールが「中東経由のルートでレイテンシ増大」と報告すると、つい「VM が中東にあるのでは？」と誤解しがちです。しかし実際には、
- Azure のフロントドアやグローバルネットワーク、インターネット事業者の BGP 経路制御によって、トラフィックは常に最適（とネットワークが判断した）経路に乗り換えられる
- 海底ケーブル切断などのイベントがあると、本来の最短ルートではなく、迂回ルートを取らざるを得なくなる
といった理由で、経路が動的に変化します。
今回の East US 2 障害において、VM が「更新中」から戻らなかったのは、ルートがたまたま中東経由になっていたからではありません。Compute の管理プレーンが正常にリクエストを処理できない状態に陥っていたことが原因です。
ネットワーク診断ツールの結果はあくまで「もう一つの観測結果」に過ぎません。障害切り分けでは、
- ネットワークレイヤー（ルート・レイテンシ・パケットロス）
- コントロールプレーン（作成・削除・起動・停止など管理操作）
- データプレーン（アプリケーション通信そのもの）
のどこで問題が起きているのかを、レイヤー別に見ていくのがコツです。
再発に備える：監視・アラート整備のポイント
サービス正常性アラートを必ず有効化
リージョン障害を早期に検知するには、Azure の サービス正常性アラート を設定しておくことが必須です。
- 対象サービス：Virtual Machines、Virtual Machine Scale Sets、Backup、AKS、Synapse など
- 対象リージョン：少なくとも本番で利用しているリージョン（例: East US 2）
- 通知先：メール、Teams、Webhook（OpsGenie / PagerDuty など）
これにより、「VM が急におかしい」→「実はリージョン障害だった」という事態でも、運用チームに早く情報が届きます。
リソース正常性アラートで個別 VM の異常をキャッチ
個別 VM が Unknown / Unavailable 状態に陥った場合も見逃さないよう、リソース正常性 (Resource Health) のアラートも設定しておきましょう。
| アラート種別 | 目的 | おすすめ通知 |
|---|---|---|
| Service Health | リージョン全体の障害やメンテナンスを検知 | メール + Teams チャンネル + インシデント管理ツール |
| Resource Health（VM） | 特定 VM の停止・未知状態を検知 | メール + 運用チームのチャット |
| メトリックアラート | CPU / メモリ・接続数などの異常な変動を検知 | アプリチームとの共有チャンネル |
アラート設計のポイントは、「障害の種類ごとに誰が最初に動くか」を決めておくことです。例えば、リージョン障害であればインフラ担当、リソース単体の異常ならアプリ担当、といった役割分担を事前に整理しておきましょう。
設計面の再発防止策：冗長化と逃げ道を用意する
可用性ゾーン分散は「最低限の標準装備」
今回の障害では主に AZ02・AZ03 に問題が出ましたが、Allocator やスロットリングの挙動はゾーンをまたいで影響しうるため、「ゾーンを分けていれば絶対安全」とまでは言えません。
とはいえ、単一の物理ゾーンにワークロードを集約するよりは、
- AZ01 / AZ02 / AZ03 など複数ゾーンに VM を分散
- ロードバランサーやトラフィックマネージャーでフェイルオーバー可能にする
といった構成の方が、「ゾーン単位の障害」への耐性は大幅に高まります。少なくとも本番系は、「単一ゾーンにしか置いていない VM」がないか棚卸ししておくとよいでしょう。
リージョン間冗長（DR）で「最悪のときの逃げ場」を確保
サービスレベルの要求が高いシステムでは、リージョン間の DR（ディザスタリカバリ）も現実的に検討すべきです。
- VM ベースのシステム：Azure Site Recovery や自前レプリケーションでセカンダリリージョンへ複製
- データベース：Geo-Replication / Auto-failover group などを利用
- ストレージ：RA-GRS / GZRS を選択し、読み取り専用で他リージョンからもアクセス可能に
DR 戦略を立てる際は、
- RPO（どこまでデータ損失を許容できるか）
- RTO（どれくらいの時間で切り替えられる必要があるか）
を明確にしたうえで、「完全自動フェイルオーバー」なのか「手動でスイッチする」のかを決めておきましょう。
運用手順書をテンプレート化しておく
障害対応中に一から手順を考えるのは、心理的にも技術的にも負荷が高くなります。今回のケースを踏まえ、次のような手順を標準運用手順書として用意しておくと安心です。
- VM が「更新中」から戻らない場合の標準フロー
- Service Health / Resource Health の確認手順
- 停止（割り当て解除）→ 起動の手順（CLI / PowerShell / ポータル）
- Redeploy の実行手順と注意点
- 一時サイズ変更の可否判断、許容サイズの一覧
- リージョン障害が検知されたときの対応フロー
- 変更凍結（そのリージョンへのデプロイや設定変更を一時停止）
- ビジネス側への影響説明テンプレート
- DR 切替のトリガー条件と承認プロセス
これらを Azure DevOps Wiki や Confluence、SharePoint などで共有し、定期的に訓練しておくことで、いざというときの対応スピードが大きく変わります。
まとめ：East US 2 障害から学べること
今回の East US 2 障害は、ユーザーから見ると「VM が更新中のまま固まる」「ComputeAllocationInternalError が出る」という局所的な症状に見えましたが、その裏では Allocator サービスの不具合と、それに伴うコントロールプレーンの大規模なスロットリング問題が発生していました。
実務的には、次のポイントを押さえておくとよいでしょう。
- 2025/09/10 の East US 2 障害が直接の原因であり、現在は Azure 側で復旧済み
- 復旧確認の第一歩は「停止（割り当て解除）→ 起動」で、それでもダメなら Redeploy やサイズ変更を試す
ComputeAllocationInternalErrorは必ずしも利用者の設定ミスではなく、基盤側要因で出ることも多い- ネットワーク診断の「中東経由の遅延」は、経路制御の結果であり、VM の所在や障害原因そのものではない
- Service Health / Resource Health のアラート、可用性ゾーン分散、リージョン間 DR といった「事前の仕込み」が、次回のインシデント時の被害を大きく左右する
Azure はグローバルに巨大なプラットフォームであるがゆえに、個々のユーザーだけではどうにもならない障害が起きることもあります。その前提に立ち、監視・手順・設計を整えておくことが、クラウド時代のインフラ運用には欠かせません。
コメント