# Microsoft Azure [[Microsoft]] のパブリッククラウドプラットフォーム。[[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]](2009-02、Azure の一般提供開始前)は、Azure を Amazon EC2(低水準・ハードウェア仮想化)と Google AppEngine(高水準・アプリケーションフレームワーク)の中間に位置づけた。アプリケーションは .NET ライブラリで書かれ、言語非依存の管理環境である Common Language Runtime(CLR)にコンパイルされる。マシンは "roles" の宣言的記述に基づいてプロビジョニングされ、自動ロードバランシングを備える点で EC2 より高水準だが、AppEngine ほど厳格な3層構造の強制はない。SQL Data Services(SQL Server の制限付きビュー)を独自のストレージモデルとして提供する初期の Azure の位置づけが記録されている。 [[Zodiac]]([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]], SOSP '24)が[[Terraform]] 経由でセマンティックチェックを検証した対象クラウドで、leading な IaC フレームワークと leading なクラウドベンダの組み合わせとして選ばれた。([[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]]) - **対象範囲**: 人気の 52 リソース種別。Zodiac はここから 510 の検証済みチェックを発掘した。 - **provider 固有のセマンティクス例**: VM とその NIC は同一リージョンでなければならない、サブネット CIDR は重複不可、"GWSubnet"/"FWSubnet" のような予約サブネット名、Premium ストレージアカウントは GZRS 冗長を使えない(レイテンシ最適化のため)、APPGW に使う IP は Standard sku 必須、など——いずれも Terraform のコンパイルを通過するがデプロイ時に違反が顕在化する。 - これらの規約は公式ドキュメントにも誤りがあり、Zodiac は Terraform Azure provider の公式使用例の 4 件のバグを発見・修正させた。 - **クラウド管理エージェントのテストベッド**: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]] は 4 モダリティ([[クラウド管理モダリティ|SDK・CLI・IaC・ClickOps]])のエージェントを Azure VM 管理で比較した。SDK は Azure Python SDK、CLI は Azure "cloud shell"、IaC は [[Terraform]]、ClickOps は Azure コンソール([[WorkArena]] ベース)を操作。SDK/CLI/IaC のモデルは [[Azure Copilot]](GPT-4 ベースの Azure 特化)。Azure 固有の制約として「standard→spot 変更は破棄・再作成が必要」「Azure Service Health の region 障害情報は Web ポータルでしか取れない」が挙がる。(Source: [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]]) - **インシデント管理研究の本番データソース**: [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] では Azure Redmond の運用エンジニア 3 名([[Feng Gao]]・[[Zhangwei Xu]]・[[Yingnong Dang]])が Microsoft Research と共同で 18 オンラインサービス(Azure および Office 365 等)の本番インシデントを分析し、[[DeepIP]] の評価データを提供した。Microsoft の AIOps 研究は Azure 本番運用エンジニアと Research 研究員の共著という構造で長期継続している。 - **AI ワークロード本番データソース**: [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] は Azure の本番 GPU クラスタから 2023-04〜2024-03 の 1 年分インシデントを採取し([[TSGuard]] の評価データ 778 件、テスト 208 件)、GPU 関連が 52.47%・System Software 27.79%・Interconnect & Networking 8.18%・User 8.83%・Framework 1.17% という分布を示した。GPU 系の recurrence rate は 8.78 で従来クラウドワークロードの code/dependency 主体構造([19] の ~40%/16.4%)と明確に異なる。標準 IB ツール `ibv_devinfo` がコンテナ内部で利用不可、`NCCL_IB_HCA` の Ethernet 取り違えなど、Azure の VM 構成固有の制約が LLM のドメイン知識欠如(Ch3)を顕在化させる例として扱われる。 - **本番インシデントトリアージの分散型エージェント化**: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] は Azure 内の 15 チーム・数百万ホストに [[Comfey]] を 22 か月間デプロイし、約 19,500 件のインシデントを 91.5% の精度でトリアージした。Azure インシデント管理システムの実証分析（2024 年 3 月〜2026 年 1 月、15 チーム分）から、インシデントの多くが 5〜30 チームにまたがること・85% が重複/準重複レポートを持つこと・月間 12.1% でトリアージ判断が覆ることを明らかにし、これらの知見がチームスコープドかつ分散型のトリアージ設計を動機づけた。先行の Azure 本番トリアージシステム [[COMET]] と比較してトリアージ精度 +7.55%・トリアージ時間 4.38 倍・緩和時間 2.91 倍の改善を報告する。(Source: [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]]) - **control plane 変更影響の component/layer 横断帰属**: [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]] は Azure control plane(CRP・NRP・RNM・DiskRP・SRP 等の region/zone/cluster レベルサービス群)を対象に、単一 component の監視では捉えられない cross-component・cross-layer の変更起因障害を検出・緩和するサービス [[Aegis (Azure Control Plane)]] を提示する。ドメイン知識駆動の相関エンジンと反実仮想射影モデルを核とし、12ヶ月の本番運用で precision・recall ともに約 80% を達成、8000 件以上のデプロイに対して意思決定を行った。同じ Azure の component レベル安全デプロイサービス [[Gandalf]](NSDI 2020)とは著者陣の一部が重複しており(Chintalapati・[[Ken Hsieh]]・[[Qingwei Lin]]・[[Yingnong Dang]])、component レベル監視から component/layer 横断監視への設計拡張の系譜を示す。(Source: [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]]) - **SRE メトリクスに基づく組織的な信頼性投資のケーススタディ**: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] は、Azure チームの SRE マネージャー [[Martin Check]] が、TTD（検出時間）・TTE（エンゲージ時間）・TTF（修正時間）・TTM（軽減時間）という時間分解メトリクスと、DRI Hops・自動検出率といった代理メトリクス、さらに「修復負債」「仮想修復負債」という2段階の負債追跡指標を用いて、機能開発と信頼性向上のどちらに投資すべきかをデータドリブンに判断した過程を記す。本エンティティが集める他ソース群(Aegis・Gandalf・Comfey 等)が Azure の障害検出・箇所特定・トリアージを自動化するシステム研究であるのに対し、本章は指標設計と組織運用のプラクティスに焦点を当てる。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]]) - **カオスエンジニアリングの実務者による、依存関係の複雑性そのものの一次記述**: [[Oleg Surmachev]]([[Microsoft]] Azure クラウドインフラストラクチャーチーム)は『カオスエンジニアリング ― 回復力のあるシステムの実践』6章([[@2022__OReillyJapan__カオスエンジニアリング - Chapter 6 Microsoftにおける実験の多様化と優先順位づけ]])で、自身が Azure 上にホスティングした個人サイト1つを例に、IIS・Windows・IaaS の VM・Hyper-V・Azure のインフラ・Azure のストレージ・データセンターの電源とネットワーク機器・サービスチームなど、数百のソフトウェアコンポーネントと約2万人のエンジニアが関与していると述べた。本エンティティが集める他ソース群(Zodiac・Gandalf・Aegis 等)が Azure の特定コンポーネント(control plane・IaC 設定等)の障害検知・防止システムを扱うのに対し、本章は「なぜ Azure のようなクラウドプラットフォーム上のシステムがそもそも複雑たりうるか」という前提そのものを、実務者の一人称視点で具体的に示す。同章はさらに、著者が Bing インフラチーム在籍時に経験した Microsoft本社の DNS 設定不具合による全社的接続障害の実例(Outlook・Skype を含むあらゆるシステムが本社ごと世界から切り離された)を報告し、意図的な障害注入(カオスエンジニアリング)による事前検証という、本エンティティの他ソース群にはない実践レイヤーの一次資料を加える。(Source: [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 6 Microsoftにおける実験の多様化と優先順位づけ]] §6.1.2, §6.2.2) - **本番メモリストランディングとCXLメモリプーリング**: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms|Pond]](ASPLOS '23、Distinguished Paper Award)は、Azure本番100クラスタ・75日分のトレース解析から、スケジュール済みコア比率が高い局面でDRAMの最大25〜30%がストランディング(全コア貸与済みだがメモリは未貸与のまま残る現象)することを初めて公開特性化した。CXL経由のメモリプーリングと2つのMLモデル(レイテンシ非感受性予測・未タッチメモリ予測)を組み合わせ、16ソケットプールでDRAM需要を7%(サーバコスト換算3.5%)削減する。本エンティティが集める他ソース群がAzure control plane・IaC設定・インシデント管理の障害検知/緩和を扱うのに対し、Pondはハードウェア(CXL)・システムソフトウェア・ML予測モデルを横断するハードウェアコスト最適化研究という異なるレイヤーを扱う。(Source: [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]]) ## 関連 - ソース: [[@2021__OReillyJapan__SREの探求 - Chapter 4 インシデントのメトリクスを用いたSREの大規模な改善]] / [[@2023__ICSE-SEIP__Aegis - Attribution of Control Plane Change Impact across Layers and Components for Cloud Systems]] / [[@2009__UCB TR__Above the Clouds - A Berkeley View of Cloud Computing]] / [[@2024__SOSP__Unearthing Semantic Checks for Cloud Infrastructure-as-Code Programs]] / [[@2025__OSR__Cloud Infrastructure Management in the Age of AI Agents]] / [[@2020__ASE__How Incidental are the Incidents - Characterizing and Prioritizing Incidents for Large-Scale Online Service Systems]] / [[@2026__FSE__TSGuard - Automated User-Centric Incident Diagnosis for AI Workloads in the Cloud]] / [[@2026__SREcon26Americas__Reliability Equilibrium - The Hidden Playbook behind SRE Influence]] / [[@2026__FSE Companion__An Agentic Framework for Triaging Incidents in Production Cloud Infrastructure]] / [[@2022__OReillyJapan__カオスエンジニアリング - Chapter 6 Microsoftにおける実験の多様化と優先順位づけ]] / [[@2023__ASPLOS__Pond - CXL-Based Memory Pooling Systems for Cloud Platforms]] - 在籍者: [[Daria Barteneva]]（Principal SRE / Observability Engineering）/ [[Martin Check]]（SRE マネージャー）/ [[Oleg Surmachev]]（クラウドインフラストラクチャーチーム、カオスエンジニアリング支持者） - 運営: [[Microsoft]] - 関連概念: [[Infrastructure as Code]] / [[設定マイニング]] / [[クラウド管理モダリティ]] / [[変更起因インシデント]] - 関連プロダクト: [[Zodiac]] / [[Terraform]] / [[Azure Copilot]] / [[WorkArena]] / [[Gandalf]] - 関連 MOC: [[Network - MOC]] / [[Software Engineering - MOC]] Gandalf 論文([[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]、NSDI 2020)では、Azure がロールアウトを stage → canary → pilot → light region → heavier region → half region pairs という段階的な safe deployment policy で展開しており、[[Gandalf]] がその最後の砦(last safeguard)として位置づけられることが記述されている。(Source: [[@2020__NSDI__Gandalf - An Intelligent, End-To-End Analytics Service for Safe Deployment in Large-Scale Cloud Infrastructure]]) ## 出典 - [[@2021__ATC__Fighting the Fog of War - Automated Incident Detection for Cloud Systems]](Warden論文(ATC 2021)の対象プラットフォーム。WardenはAzureのインシデント管理(IcM)platformに実装・デプロイされた。)