Azureの信頼を崩した決定の数々 ― 元Azure Coreエンジニアの記録

 (isolveproblems.substack.com)
3 ポイント 投稿者 GN⁺ 27 일 전 | 1件のコメント | WhatsAppで共有
  • Microsoft Azure Core内部の非現実的な意思決定が積み重なり、技術的混乱と信頼崩壊へ至った過程を元エンジニアが詳述
  • ハードウェア制約を無視したWindows機能の移植計画と173個の管理エージェントの乱立が代表的な問題として指摘される
  • このような複雑な構造がOpenAI、Anthropic、政府クラウドなどの中核ワークロードを支えており、単一のミスが世界規模の障害へ拡大する危険がある
  • 経営陣が応答しない中で、OpenAIとの関係悪化、米国政府の信頼喪失、機能リリースの遅延などの後続事態が発生
  • 結果として1兆ドル規模の時価総額消失につながり、クラウドインフラ運用における技術的現実の認識と単純性維持の重要性が強調される

Azure信頼崩壊の内部記録

  • Microsoft Azure Coreチーム内部の非現実的な意思決定プロセスと、それによる技術的・組織的混乱を扱った元エンジニアの回顧
  • Overlake R&Dチームに加わった初日から、ハードウェア制約を無視したWindows機能のOverlakeカードへの移植計画が議論される場面を目撃
  • 173個の管理エージェントが存在するが、その機能と必要性を理解している人がいないほど、複雑性と不透明性が深刻
  • この構造がOpenAI、Anthropic、政府クラウドなどの中核ワークロードを支えており、単一のミスが世界規模の障害につながる危険がある
  • 結果としてOpenAIの信頼喪失、米国防総省の公然たる不信、市場価値1兆ドル消失へつながったと記述

Azure Core入社と初期状況

  • 2023年5月1日、Azure Boostオフロードカードとネットワークアクセラレータを担当するOverlake R&Dチームにシニアエンジニアとして参加
  • それ以前にはWindowsチームとCore OSチームでカーネル改善およびコンテナプラットフォーム開発に参加し、Docker・AKS・App Services・Windows Sandboxなどの中核技術に貢献
  • Overlakeカード初期設計（2020〜2021）にも参加し、ホストOSとアクセラレータカード間の通信プロトコルを提案した経験を持つ
  • Azureプラットフォームを10年以上にわたり直接運用・開発してきた専門家として復帰

最初の会議で目撃した非現実的な計画

  • 入社初日、チームの月次計画会議でWindowsコンポーネントをOverlakeカードへ移植しようとする計画を確認
  • OverlakeカードのRAM容量と電力予算が極端に限られているにもかかわらず、チームはWindows機能を移植する試みを議論
  • ハードウェア仕様上不可能な計画であり、「ジュニア開発者数人に任せてみよう」という発言まで出た
  • 組織はWindowsをLinuxへ移植してVM管理エージェントを維持しようとする方向を真剣に検討していた
  • 筆者はこれを「現実とかけ離れた計画」と認識し、組織全体が不可能な目標へ向かう行進に入ったと判断

技術的限界と構造的問題

  • 当時のスタックは400WのXeon CPUで数十個のVMしか処理できず、ハイパーバイザーの1,024 VM上限とは大きな差があった
  • 過剰なリソース使用により**顧客VMでジッター(jitter)**が発生するなど、性能低下の問題が存在
  • このような非効率なスタックを小型のARM SoCへ移植して拡張しようとする計画は技術的に不可能
  • 筆者は「新しい技術を学ぶことより、組織全体を現実へ引き戻すことのほうがはるかに急務だった」と表現

Azure LinuxおよびOverlake関連の内部対話

  • Linux System Group責任者との90分の対話で、Overlakeカード向けに173個のエージェントが移植候補に指定されていたことを確認
  • 調査の結果、Microsoft内部の誰もこの173個のエージェントの役割・相互作用・存在理由を明確に説明できなかった
  • Azureの中核はVM・ネットワーキング・ストレージであり、その他のサービスはその上に構築されるにもかかわらず、不必要な複雑性が蓄積
  • このような制御不能な構成要素の集合が、OpenAI・Anthropic・政府クラウドなど主要ワークロードを管理している

信頼喪失とその後の事態

  • この複雑な構造は、国家安全保障および事業継続性に深刻なリスクをもたらし得る状態
  • その後、CEO、取締役会、Cloud+AI部門EVPへ送った書簡はいずれも無回答に終わった
  • 結果としてOpenAIとの関係悪化、米国政府の信頼崩壊（国防長官の公開発言）、エンジニアリングの浪費とRust移行命令、機能リリースの遅延などが発生
  • 筆者はこれを「1兆ドルの市場価値が消失した出来事」と表現し、Azureを利用する企業に対して本番環境依存の危険性を警告

結論

  • Azure内部の技術的複雑性、管理不全、非現実的な意思決定が積み重なり、信頼を失っていく過程が明らかになる
  • 中核インフラを担う組織が、現実感覚を失ったまま構造的失敗へ向かう行進を続けた事例
  • クラウドインフラの安定性と単純性、そして組織内で技術的判断力を維持する重要性が強調される

関連記事

1件のコメント

 
GN⁺ 27 일 전
Hacker News の意見

  • 毎日 Azure を使っている立場からすると、今回の暴露が事実なら本当にいろいろ説明がつく気がする
    UI は雑だし、ドキュメントは AI が書いたように不正確 で、サービスの種類が多すぎて何を使えばいいのかさえわからない
    コンサルタントの助けなしでは設定が難しく、設定後もちゃんと動いているのか確信が持てない
    正直、これがいまだに動いているのが不思議なくらいだ

    • 昔は Azure のドキュメントに感心していたが、1週間かけて実装したあとテスト環境で GraphAPI がドキュメント通りに動かず、完全に失敗した
      それ以来、ドキュメントを信じていない
    • Azure のコンサルタントたちと仕事をしたことがあるが、彼らも Azure を嫌っている
    • 経営陣がクレジットが多いという理由で AKS に移行したが、pod がランダムにクラッシュ し、DB ノードのディスク遅延が急増した
      GCP で安定して動いていたサービスが予測不能になった

  • Azure OpenAI が高負荷時に他の顧客の プロンプト応答を漏えい するのを見たことがある
    関連ツイートもある
    なのに誰も気にしていない雰囲気だ

    • 「Azure OpenAI」が正確に何を意味するのか気になる — GitHub Copilot、Microsoft Copilot、OpenAI API、それとも Azure 上でホストされた LLM のどれなのか？
      まるで完全な ワイルド・ウェスト のような状況だ

  • この記事の主張があまりに具体的で驚いた
    内部告発者なのか、単に不満を持つ元社員なのか気になる
    CEO と取締役会に直接報告したという部分が特に印象的だ
    アメリカ企業文化でこうした手続きが 「慣例的」 だというのは違和感がある
    Azure が本当にここまで不安定なのか、実際のユーザー体験が気になる

    • 実際に SRE として AWS、Azure、GCP をすべて運用 しているが、障害の 80〜90% は Azure で起きている
      Azure は問題を認識しておらず、原因もわからず、しかも 関心すらなさそうに見える
      チーム全体が Azure を嫌っている
    • Azure は 一貫性の問題とレースコンディション が多すぎる
      AWS Bedrock で OpenAI モデルが使えるようになり、Azure を避けられるのがうれしかった
      信頼性は依然として深刻な問題だ
    • 大企業は短期指標のために 品質を犠牲にする 判断をよく下す
      「早く出して後で直そう」という戦略が、結局こういう結果を招く
    • 以前、Azure コンテナから脱出して 管理コントローラの脆弱性 を発見したセキュリティレポートを見たことがある
      あの時から信頼しなくなった
    • 無料クレジットをもらっても、AWS や GCP を有料で使う方がましだと思う

  • 文章がやや 感情的に誇張 されていて、本来の意図がぼやけた感じがする
    Azure の社内等級体系や Sev2 レベルの問題はそれほど特別なものでもない
    Azure に問題はあるが、規模が大きいのだから荒い部分があるのは当然だ
    本当の成熟とは、システムの中で改善しようとする姿勢だと思う

    • 取締役会に直接手紙を送ったのは、組織内で絶対にうまくいかない行動 だ
      Azure がひどい状態なのかもしれないが、書き手のアプローチにも問題があった可能性がある
    • AWS と GCP は UX/DX がはるかに良く、Azure は なぜ動かないのかすら教えてくれない
      Azure に対する印象は完全に否定的だ
    • Microsoft は政府機関の標準的なソリューションだが、全面リライトの提案 は現実的ではない
      書き手のアプローチがむしろ信頼を損ねている
    • 書き手が言及したような低い等級の人たちに 中核システムを任せている構造 に驚いた
    • 「すべて壊れていると叫ぶ人たち」は多いが、それは 組織が惰性化した問題 なのかもしれない
      新しい社員が「wtf/day」と叫ぶ頻度が、組織の健全性の指標のように思える
      Azure は外から見ても 品質が底 だ
      AWS に追いつこうとして機能を急いで投入した結果、巨大な 技術的負債の沼 に陥っている
      IPv6、azcopy、VM アップグレードのような基本機能でさえ、いまだに不安定だ

  • 昔の同僚が Azure を毎日使っているが、その 不満の爆発 を聞くたびに今回の記事の内容が理解できる
    12年前にクラウド専門化を選ぶ際、Azure を少し触って 遅くて壊れたプラットフォーム だと感じたが、今回の記事はその判断を裏付けてくれる

  • 記事の後半で Microsoft が 2025 年に 15,000 人を削減 したという部分が印象的だった
    AI ブーム後の現実を示す事例のように思える

    • ただ、その部分は記事の弱い主張だと思う
      OpenAI との契約は GPU 容量の問題で、削減とは別の話だ
      本当の問題は エンジニアのローテーションと責任の不在 だ
      プロジェクトごとに新しい人員が投入され、オーナーシップが失われていく

  • ホストが突破されるとすべての VM メモリにアクセス可能だという部分は 非常に危険に聞こえる

    • そんなアーキテクチャを 良いアイデアだと思った環境 が想像すらできない
    • 書き手が何を期待していたのかわからない

  • Satya Nadella の年収が 9,650 万ドルで 22% 上昇したという CNBC の引用と、
    Artemis II の宇宙飛行士が「Outlook が 2つとも動かない」と言った話を並べて見たのが 皮肉 だった

    • 「Outlook が 2つ」って、すでに 1つでも多い

  • 記事の内容は誇張されているようだが、自分も似たようなシステムを運用したことがある立場として、安定性を守るために絶えず戦わなければならなかった記憶 がある
    他の会社でも似た問題を見たことはあるが、Azure 規模の深刻さではなかった
    こうした構造は結局 自己破壊ループ につながる気がする

  • 2018 年に Azure を使ってみたが、遅くて高いのに品質はひどい ものだった
    GitHub フォーラムで他のユーザーたちと一緒に、基本機能すら動かない問題を解決しようと苦労した
    今回の記事が当時の疑問を解いてくれた
    個人的には Google Cloud が最もよく設計されたプラットフォーム だと感じたが、AWS より 人的サポートが不足している点 は残念だ

    • GCP のサポートは本当に ひどい
      担当者が 3か月の間に 3回変わり、クォータ申請やシステム制限に関する問い合わせ が無視されることも多い