数か月安定稼働していた Azure Cloud Services（Extended Support）のロールが、ある朝突然 “Unknown” になり、ポータルや CLI から Start・Stop が効かない──この症状は珍しくありません。本文では “Unknown” の正確な意味、切り分けの最短ルート、再発防止までを運用の現場目線で体系化します。実案件で判明した「旧世代 vCPU サイズが原因」のケースも、手順と併せて具体的に解説します。
前提と想定読者
本記事は、Cloud Services（Extended Support, 以降 CS:ES）で Web/Worker ロールを運用中の管理者・SRE を対象にしています。最終デプロイから変更が無いのに、ある日を境にロールが “Unknown” へ遷移し、Start/Stop/Restart などの操作が受け付けられない状況を主題とします。
“Unknown” が示すこと
CS:ES の “Unknown” は、Azure ファブリックコントローラーがロール VM の状態を取得できないことを意味します。多くは以下のどちらか、もしくは複合要因です。
- ゲストエージェントの異常（心拍・状態レポートが停止、プロビジョニング失敗、ディスク/ドライバ障害など）
- ホスト／ファブリック側の障害・割当失敗（ホスト故障、クラスター切替、旧世代 SKU の容量制約、メンテナンスによる退役）
結果として制御プレーンは整合性維持のため、Start/Stop を受け付けない（もしくは「受理するが永遠に進行中」のように見える）挙動を取ります。
症状と観測の対応表
| 観測される症状 | よくある原因 | 初動アクション |
|---|---|---|
| ポータルで “Unknown”、操作不可 | ゲストエージェント停止／通信断、ホスト障害 | Service Health/Resource Health 確認、状態取得コマンド |
| 同時に併設 Web サイトもダウン | ロール全体の停止・再配置失敗 | ログ回収（RDP 有効なら）、即時の再デプロイ検討 |
| 更新をしていないのに突然発生 | 旧世代 SKU の容量制限・段階的退役 | サイズ見直し・新 SKU への移行 |
最短で効果が出る切り分けフロー
- Azure Service Health / Resource Health の確認
リージョン障害、ホスト群のイベント、資源不足警告がないかをまず見る。 - PowerShell でロール実体の状態を取得
「プロビジョニングが止まっていないか」「Updating で固着していないか」を把握。 - RDP/Serial Console（有効時）でログ採取
Windows イベントログとC:\WindowsAzure\Logsのゲストエージェントログを回収。 - 同パッケージでの再デプロイ
新しいホスト上にクリーン VM を起こす。多くの Unknown はこれで復旧。 - 復旧しない／再発する場合は SKU を見直す
旧世代 vCPU サイズを新世代へ移行。後述の表と手順を参照。 - 長引く場合は Severity A でサポートへ
発生時刻、対象リソース ID、ログ、アクティビティ履歴を即時添付。
状態確認コマンド例（PowerShell）
Az モジュール（Az.Accounts、Az.CloudService など）を最新化したうえで実行します。モジュール名やパラメータは環境により異なる場合があります。
# サインインとコンテキスト
Connect-AzAccount
Select-AzSubscription -SubscriptionId <SUBSCRIPTION_ID>
# Cloud Service のインスタンスビュー（実行/プロビジョニング状態）を取得
Get-AzCloudServiceRoleInstanceView ` -ResourceGroupName <RG_NAME>`
-CloudServiceName <CS_NAME> `
| Format-List *
# アクティビティログ（最近の失敗操作）を確認
Get-AzActivityLog -ResourceGroupName <RG_NAME> -MaxRecord 50 `| Where-Object { $_.ResourceId -like "*Microsoft.Compute/cloudServices/<CS_NAME>*" }`
| Sort-Object EventTimestamp -Descending `
| Select-Object EventTimestamp, OperationName, Status, SubStatus, Caller, CorrelationId
# Resource Health（要 Az.ResourceGraph or Az.ResourceHealth）
# 環境に応じてラッパーを用いるか、ポータルの Resource Health を参照
RDP/ログで見るべきポイント
- Windows イベントログ
- System：ディスク/ネットワーク/ドライバのエラー、再起動の痕跡
- Application：アプリ例外と依存ミドルウェアの障害
- ゲストエージェント関連
C:\WindowsAzure\Logs\WaAppAgent.log（ハートビート・拡張機能・状態報告）C:\WindowsAzure\Logs\Plugins\*（拡張の失敗）
ゲストエージェントの停止や通信断（プロキシ誤設定、証明書期限切れ等）は “Unknown” の典型要因です。
即効性のある復旧アクション
- 再デプロイ（同一パッケージ）：ホスト更新・ディスククリーンアップ効果で復旧率が高い。
- ロール単位の再起動/再作成：個別インスタンスの破損に対処。
- ステージングスロットへの再配置→スワップ：本番影響を最小化しつつ切替。
# 例：ロールインスタンスの再起動（cmdlet は環境により異なる場合があります）
Restart-AzCloudServiceRoleInstance `
-ResourceGroupName <RG_NAME> `
-CloudServiceName <CS_NAME> `
-RoleInstanceName <INSTANCE_NAME>
# 例：Cloud Service 全体の再起動
Restart-AzCloudService -ResourceGroupName -CloudServiceName 実案件の根本原因：旧世代 vCPU サイズの制約
ある環境では、数か月変更加えずに安定稼働していた CS:ES が、ある日を境に “Unknown” 固着しました。調査の結果、ロールが旧世代（非推奨）に分類される VM サイズで実行されており、リージョンの容量制限・退役計画の影響でスケジューラが満足な配置先を見つけられなくなったことが判明。新しい推奨 SKU（例：Dsv5/Esv5 世代など）へサイズ更新したところ、再配置が正常化し、Unknown から自動復帰しました。
このタイプの障害は「昨日まで動いていたのに今日からダメ」という形で突然現れます。理由は、プラットフォーム側のクラスター更新・容量最適化・旧 SKU 抑制が段階的に進行するためです。アプリケーションに変更が無くても、基盤の可用性が SKU 単位で変化します。
旧世代 → 新世代サイズの移行候補（例）
実際の選定は CPU/メモリ/ディスク IO/ネットワーク要件やコストで決めてください。下表は「とりあえず動かすための互換に近い目安」です。
| 旧世代の一例 | 置き換え候補（汎用） | 置き換え候補（メモリ最適） | 備考 |
|---|---|---|---|
| A1/A2/A3 系 | Standard_D2s_v5 / D4s_v5 | Standard_E2s_v5 / E4s_v5 | ストレージは Premium SSD を推奨 |
| D/Dv2 系 | Standard_D2s_v5 以降 | Standard_E2s_v5 以降 | 世代差で CPU/メモリ比が異なる |
| DS/DSv2 系 | Standard_D2ds_v5 以降 | Standard_E2ds_v5 以降 | ディスク最適の “d” 系も検討 |
| G 系 | Standard_Esv5 系 | Standard_M 系 | 大容量メモリが必要なら M 系 |
ポイント：「最小限のサイズ変更でとりあえず復旧」→「実測に基づく最適化」という 2 段階で進めると、ダウンタイム短縮とコスト最適化の両立がしやすくなります。
CS:ES におけるサイズ設定の更新パターン
CS:ES は ARM リソース（Microsoft.Compute/cloudServices）として管理されます。サイズは ARM（Bicep/Template）の roleProfile 側で定義するのが標準です（パッケージ単体アップロード運用でも、ARM で付随情報を持ちます）。
# Bicep（概念例：API バージョン/補助プロパティは環境に合わせて調整）
param csName string
param location string
param packageUrl string
param configContent string
resource cs 'Microsoft.Compute/cloudServices@2022-XX-XX' = {
name: csName
location: location
properties: {
roleProfile: {
roles: [
{
name: 'WebRole1'
sku: {
name: 'Standard_D2s_v5' // ★ここで新世代に更新
tier: 'Standard'
capacity: 2 // インスタンス数
}
}
]
}
packageUrl: packageUrl
configuration: configContent // ServiceConfiguration.Cloud.cscfg の内容
// osProfile / networkProfile / extensionProfile なども適宜定義
}
} テンプレートを用意しておけば、サイズ更新→デプロイ→スワップを自動化し、復旧の初動を数分で回せます。
ゼロダウンに近づける切替手順（ステージング活用）
- ステージングスロットに新 SKU でデプロイ（同一バイナリ＋サイズのみ更新）
- ヘルスチェック／APM／合成監視で機能・性能を検証
- スワップ（Staging → Production）で本番切替
- 旧本番を一定期間キープして即時ロールバック可能にしておく
この運用により、Unknown 固着時でも「新ホスト＋新 SKU」で健全な面を先に用意し、切替の所要時間だけで復旧できます。
PowerShell ランブック（実運用の雛形）
$ErrorActionPreference = 'Stop'
# 0) 前提：Az.* モジュール導入済み、CSPKG/CSCFG はストレージへ配置済み
Connect-AzAccount
Select-AzSubscription -SubscriptionId <SUBSCRIPTION_ID>
$rg = '<RG_NAME>'
$cs = '<CS_NAME>'
$newSku = 'Standard_D2s_v5'
$capacity = 2
$packageUrl = 'https://<storage>/pkg/app.cspkg'
$config = Get-Content -Raw -Path '.\ServiceConfiguration.Cloud.cscfg'
# 1) いまの状態を保存（ドリフト監査用）
$before = Get-AzCloudService -ResourceGroupName $rg -CloudServiceName $cs
$before | ConvertTo-Json -Depth 8 | Out-File ".\before-$cs.json" -Encoding utf8
# 2) サイズだけ更新するイメージの Set（実際のパラメータは環境で要調整）
Set-AzCloudService ` -ResourceGroupName $rg`
-CloudServiceName $cs ` -PackageUrl $packageUrl`
-Configuration $config ` -RoleProfileRoleSkuName $newSku`
-RoleProfileRoleCapacity $capacity
# 3) ステージングにデプロイしてヘルスチェック（擬似。実環境では Stage 用 CS を分けることも）
# New-AzCloudService -Slot Staging ... のような運用も可
# 4) 必要に応じてスワップ操作（環境の API/コマンドに合わせる）
# Switch-AzCloudServiceDeployment -ResourceGroupName $rg -CloudServiceName $cs -Swap
注： 実際のコマンド名・パラメータは Az モジュールのバージョンで差異があります。検証環境で必ずドライランしてください。
ログ・メトリック監視の強化
| 監視対象 | 推奨シグナル | 目的 |
|---|---|---|
| Resource Health | Unavailable/Degraded の検知 | プラットフォーム側イベントの即時把握 |
| Activity Log | Start/Stop/Restart/Update の失敗 | 自動化・人手操作の失敗早期検出 |
| ゲストエージェント | ハートビート欠落、拡張の失敗 | Unknown の前兆検知・RCA（原因分析） |
| アプリ/APM | エラー率、応答時間、スループット変化 | 基盤健全でもアプリ異常を逃さない |
再発防止：運用の要点
- SKU 健全性の定期点検：運用台帳に VM サイズ列を持ち、旧世代/非推奨フラグを棚卸し。
- Service Health／Advisor アラート：非推奨リソース・メンテナンス予定を自動通知。
- IaC（ARM/Bicep/Terraform）で構成を宣言：サイズ変更・再デプロイをコード化し、人手ミスを排除。
- ゲストエージェントの健全性管理：自動更新と監視。ログのローテーション・ディスク空き容量の維持。
- アップグレードドメイン/フォールトドメインの活用：ロールインスタンスは最低 2 台構成を基本に。
- スロット運用（Blue/Green）：ステージングで検証→スワップ。ロールバック時間を秒単位に。
- クォータ・家族別 vCPU の把握：新 SKU へ移行する前に容量・クォータを確認。
トラブル対応のチェックリスト（保存版）
- 現在の 状態（プロビジョニング/実行） をコマンドで取得し、ログに保存したか
- Resource Health/Service Health を確認したか
- RDP/Serial で イベントログと
C:\WindowsAzure\Logsを取得したか - 同パッケージ再デプロイを試したか（ステージング推奨）
- 復旧しないとき、VM サイズの世代を確認したか
- 新 SKU へ更新した 実装（Bicep/ARM） を用意したか
- 再発防止として アラート/IaC/スロット運用 を整備したか
- 長引く場合 Severity A でサポートにエスカレーションしたか（時刻・Correlation Id・ログ添付）
よくある誤解と注意点
- 「Unknown は待てば治る」：治るケースもありますが、基盤側の容量制約や旧 SKU 抑制が背景なら時間経過で悪化します。即座に切替面を準備。
- 「Start/Stop を何度も押せば通る」：制御側の整合性で拒否されます。ログ取得→再デプロイに切り替えましょう。
- 「アプリに変更がないから基盤要因ではない」：CS:ES は ARM 配下で進化します。SKU と拡張の適合を常に点検してください。
ケーススタディのまとめ（本件）
- 現象：数か月の安定稼働後、朝から “Unknown”。Start/Stop 不可。併設 Web もダウン。
- 切り分け：Health 確認→状態取得→RDP ログ採取→同パッケージ再デプロイ。
- RCA：旧世代 vCPU サイズの利用により、スケジューラが健全な配置先を確保できず固着。
- 恒久対応：Bicep で
roleProfile.sku.nameを新世代へ更新し、ステージング検証→スワップ。以降は IaC でサイズ台帳を管理。
障害対応テンプレ（コピペ用）
# 1) 状態取得
Get-AzCloudServiceRoleInstanceView -ResourceGroupName <RG> -CloudServiceName <CS> | fl *
# 2) 直近の失敗操作を洗い出す
Get-AzActivityLog -ResourceGroupName <RG> -MaxRecord 100 `| ? { $_.ResourceId -match "Microsoft.Compute/cloudServices/<CS>" }`
| sort EventTimestamp -desc `
| select EventTimestamp,OperationName,Status,SubStatus,CorrelationId
# 3) ロールを個別に再起動（可能なら）
Restart-AzCloudServiceRoleInstance -ResourceGroupName <RG> -CloudServiceName <CS> -RoleInstanceName <NAME>
# 4) パッケージ再デプロイ（サイズ変更は後段で）
Set-AzCloudService -ResourceGroupName <RG> -CloudServiceName <CS> -PackageUrl <PKG_URL> -Configuration (Get-Content .\ServiceConfiguration.Cloud.cscfg -Raw)
# 5) 新 SKU に変更（Bicep/ARM を用意して apply）
# roleProfile.sku.name = 'Standard_D2s_v5' など
運用のベストプラクティス（チェックポイント表）
| 項目 | 具体策 | 頻度 |
|---|---|---|
| SKU 健全性 | 旧世代/非推奨フラグの棚卸し、代替候補の表を常備 | 月次 |
| IaC 化 | Bicep/ARM 化し、サイズ・拡張・ネットワークをコードで管理 | 常時 |
| スロット運用 | Staging での事前検証→スワップ。自動化スクリプトを整備 | 各リリース |
| ゲストエージェント | 更新と心拍監視、ログ保全（ローテーション・容量監視） | 週次 |
| アラート | Service Health／Advisor／Activity Log の重要イベントを通知 | 即時 |
最後に：Unknown の“正しい怖がり方”
Unknown は「すぐ直ることもある」一方、「基盤側の非連続な変化」が背景だと自然治癒を期待して時間を浪費します。ログ採取→同パッケージ再デプロイ→新 SKU で復旧→恒久対応（IaC・監視・台帳）という標準手順を持っておけば、夜明けの突然死にも迷わず動けます。CS:ES を選好する理由はレガシー互換ですが、SKU だけは常に“現行世代”へ。これが Unknown を「一過性の事象」に留める最短コースです。
付録：よく使うファイル・パスと用語
C:\WindowsAzure\Logs\WaAppAgent.log：ゲストエージェントの主要ログC:\WindowsAzure\Logs\Plugins\*：拡張機能のログ- Activity Log：制御プレーン操作の履歴（成功/失敗）
- Resource Health：プラットフォーム視点のリソース健全性
- Service Health：リージョン/サービス全体のイベントとメンテナンス
- Staging/Production：CS:ES の 2 スロット。スワップでゼロダウンに近い切替が可能
付録：サポートチケットに添付すると喜ばれる情報
- 発生時刻（UTC/ローカル両方）
- 対象リソース ID（サブスクリプション/リソースグループ/Cloud Service 名）
- Correlation Id（失敗操作のアクティビティログ）
- イベントログ（System, Application）、
WaAppAgent.log抜粋 - 直前 24 時間の変更履歴（デプロイ／自動化ジョブ／証明書更新）
- 使用中の VM サイズと、検討中の代替候補
付録：移行後に確認する 10 のポイント
- 新 SKU で CPU/メモリ/ディスク IO のヘッドルームが十分か
- APM の 95/99 パーセンタイルが旧環境比で改善/同等か
- インスタンス数（capacity）の最適化（過剰/過少を是正）
- ディスク種別（Premium/Standard SSD）の適合
- 拡張機能（Diagnostics 等）の互換性
- スロットのロールバック手順・SLA の再確認
- クォータ（家族別 vCPU）の余裕
- コスト見積と予算アラート
- IaC のタグ/台帳への反映（世代・作成日・担当）
- 運用 Runbook の更新（本記事の手順を標準化）
まとめ
CS:ES の “Unknown” は、ゲストエージェント異常か基盤側の配置失敗が主因です。最初に Health を確認し、状態をコマンドで押さえ、ログ採取→再デプロイで回復可否を判定。旧世代 SKU が疑わしいときは即座に新世代へ移行し、ステージング検証→スワップでダウンタイムを最小化します。以降は IaC・アラート・台帳で運用をコード化し、「突然の Unknown」を「作業手順で平常化」しましょう。
コメント