Azure、10/13 に発生した Windows VM への管理操作障害の原因は ARMテンプレート公開範囲の設定誤り

投稿: 2021年10月19日
タグ: 
  クラウド  Windows  ニュースネタ

10/13 に約6時間半 Windows VM の作成・起動ができなくなった障害のレポートが公開されました。 短い文章ですが、前提がないと読みづらい書き方になってるので、順を追って内容を確認したいと思います。

Azure status history
https://status.azure.com/ja-jp/status/history/open_in_new
  • VMサービス管理操作時(VM開始/停止/作成等)に VMエージェント拡張機能を参照できなくなった
  • VMエージェント拡張機能が参照できなくなったのは、VMエージェント拡張機能が ARMサービスからのみ参照できるように公開範囲が設定されたため
  • 障害のトリガーになった更新作業自体もクラシックから ARM への移行だった
  • 複数のリリースが同時に行れているため根本原因の特定が長時間化
  • VMサービス管理操作時(VM開始/停止/作成等)に VMエージェント拡張機能を参照できなくなった

    10/13 に発生した障害で VM の起動や削除、新規作成ができなくなった訳ですが、 これの直接的な原因は『VM管理操作時に、VMエージェント拡張機能へのアクセスに失敗した』ためとのことです。

    As the result, VM management operations started to fail after receiving zero results from the regional Platform Image Repositories.
    [訳] 結果として、VM管理操作は Region Platform Image Repository から 0 の結果を受け取って失敗し始めた

    VM起動時に VMエージェント拡張機能を取得する際に 0 (ゼロ) が返ってきて失敗して各種VMの管理操作ができない状態になっていたとのことです。 VMエージェント拡張機能とは、マイクロソフトが提供するもので以下ドキュメントが参考になります。

    VM エージェント拡張機能のサポート
    https://docs.microsoft.com/ja-jp/troubleshoot/azure/virtual-machines/support-agent-extensionsopen_in_new

    本来であれば、VM起動時/作成時などに最新のVMエージェント拡張機能をダウンロードして更新する動きになると思いますが、 それができずに VM自体の操作ができなくなったということのようです。

    VMエージェント拡張機能が参照できなくなったのは、VMエージェント拡張機能が ARMサービスからのみ参照できるように公開範囲が設定されたため

    次に、『VMエージェント拡張機能になぜ参照できなくなったのか?』ですが、これはダウンロード場所を返すはずのリポジトリサービスが 『VMエージェント拡張機能の公開範囲を小さくしてしまった』ことが原因だったそうです。

    結果、『クラシック』なサービスは 最新VMエージェントのダウンロード先をリポジトリサービスから返してもらえなくなったとのことです。

    as an unintended consequence marked the Windows VM Agent extension as visible to the publishing subscription only in the ARM regional service
    [訳] 意図しない結果として、Windows VMエージェント拡張機能が ARMリージョナルサービスからしか公開サブスクリプションとして参照できないように設定された

    背景として、Azure の各リソースは Azure Resource Manager(ARM) テンプレートという JSONフォーマットの定義でリソースを表現できるようになっています。 ARMテンプレートが登場する前のものは、クラシックと呼ばれます。ちなみに、ARMテンプレートが登場したのは以下ドキュメントによると 2014年のことです。 つまり、7年前に登場した ARMテンプレートに対応できていないサービスからはアクセスできなくなったために障害になったことになります。

    Azure Resource Manager とクラシック デプロイ: デプロイ モデルとリソースの状態について
    https://docs.microsoft.com/ja-JP/azure/azure-resource-manager/management/deployment-modelsopen_in_new

    障害のトリガーになった更新作業自体もクラシックから ARM への移行だった

    さらに、今回の設定変更ですが、そもそも Azure自体で使用しているクラシックリソースを ARM に移行する過程での変更だったとのことです。

    レポート内で「拡張機能の約20% は(ARMに) 移行できた」と書いているので、残り80% はまだクラシックのようです。 その上で、障害レポートでは『ARM 以外(クラシック) からのアクセス』を「an edge case(極稀なケース)」と書いてしまうのはちょっと苦しいところです。

    障害原因を作った担当者の声を勝手に想像すると『今さら、クラシックなんて使ってるやついないでしょ。ARM にのみ公開っと』とやって、 まさか Azure自体の主要機能がクラシックのままだった、という状況を想像します。

    複数のリリースが同時に行れているため根本原因の特定が長時間化

    原因が分かってしまうと、VMエージェント拡張機能への公開設定を変更すれば良いように見えますが、「複数のリリースが同時に行われているため、 原因特定に時間がかかった」、とあります。 各分野の専門家を巻き込んで1つ1つ原因を排除して特定するのに時間がかかったようです。

    リリースが同時に行われるのはサービスの規模や数を考えらればしょうがないとは思いますが、でかいサービスに共通する Agility の無さが感じられます。 実際、今回の障害への対処策にリリースサイクルに関する項目は含まれていませんでした。

    動いているサービスの更新って難しいよね、という当たり前の話を思い出させてくれる障害レポートでした。

    さすがにARM への移行が遅すぎるのではないかと感じましたが、『この内容を(そのまま) 障害レポートとして公開してしまうバランス感覚の悪さ』は逆に好感を持ちました。
    ※おそらくユーザー向けには「最新へのアップデート」とか「バージョンアップをー」とか言ってるとは思うので。