Azure の裏側を支える SRE の世界

Transcript

1. Azure の裏側を支える SRE の世界 〜パブリッククラウドの信頼性を実現する組織と技術〜 CloudNative Days Summer 2025 May 23rd, 2025 1:20pm-2:00pm Tsubasa Nomura
2. 乃村 翼 Site Reliability Engineer Microsoft corporation : tsubasaxZZZ https://gihyo.jp/book/2025/978-4-297-14903-1
3. 今日話すこと SRE の必要性 Azure における SRE の組織・位置づけ AIOps の活用 Azure の SRE のしごと
4. SRE の必要性 IT システムの現実 ハードウェアは壊れる 人はミスをする ソフトウェアにはバグがある
5. SRE の必要性 サイトリライアビリティエンジニアリングは、組織が システム、サービス、製品において適切なレベルの 信頼性を持続的に達成できるよう支援すること を目的とした工学分野である David N. Blank-Edelman. SRE をはじめよう
6. SRE の必要性 サイトリライアビリティエンジニアリングは、組織が システム、サービス、製品において適切なレベルの 信頼性を持続的に達成できるよう支援すること を目的とした工学分野である David N. Blank-Edelman. SRE をはじめよう
7. SRE の必要性 信頼性 可観測性 障害管理 テスト戦略 デプロイ戦略 etc... 適切なレベル SLI/SLO エラーバジェット リスク評価 etc... 持続的 自動化 オンコール トレーニング/スキル開発 etc... プロダクト管理 開発 テスト/QA プロダクション へのプッシュ プロダクション での運用 SREはプロダクションでの運用に集中 最終結果を改善するためにパイプラインを改善 Software Delivery Life Cycle パイプライン David N. Blank-Edelman. SRE の探求
8. Azure のスケール リージョン数 60+ データセンター数 300+ ネットワーク 442 km+ PoPの数 190+ サーバー 数百万台
9. Azure における SRE の組織 ミッション すべての開発・運用担当のエンジニアが信頼でき、 安全でセキュアなクラウドサービスを構築および運用することを 容易にする
10. Azure における SRE の組織 Azure 部門(開発部門) に所属 CXP(Customer Experience)部門の一部 隣のチームに CRE チームなど SREチーム - Change SRE - Services SRE - Apps SRE - etc... Satya Nadella (CEO) Commercial (Sales/Support/etc..) Azure CXP (Customer Experience) SRE CRE etc... Security etc...
11. SRE のしごと サービスのオンボーディング 変更レビュー 障害分析 オンコール リスク分析 標準化 etc...
12. SRE のしごと サービスのオンボーディング 変更レビュー 障害分析 オンコール リスク分析 標準化 etc... 今回主に説明するパート
13. SRE のしごと サービスのオンボーディング 変更レビュー 障害分析 オンコール リスク分析 標準化 etc... サービスの信頼性やオペレーショナルエクセレ ンスを向上させるためにフレームワークを Playbookとして開発・共有 当事者意識 と共同責任 SREと開発チームは相互に関係し 責任を持つことを前提とする 確立された手法の尊重 実証済みの効果的なアプローチを 定義する データに基づく判断 運用と信頼性のKPIを活用した方 向性を決定する 集中と成果 各フェーズの時間制限と集中的な 取り組みを定義する 再利用可能なプラクティス 運用経験から抽出された汎用的な パターンを定義する Azure と整合性のある継 続的な進化 他の取り組みや Azure の進化と 連携し継続的に更新する <Playbook の原則>
14. Playbook に基づいたワークフロー 1. Service Fundamentals 2. Service Health and Safe Deployment Practice(SDP) 3. Operational Efficiency 4. Release and Change Management Automation 5. Reliability Risk Reduction 6. Scalability and Capacity Planning それぞれのフェーズに期間 / 成果 / KPI / タスク（それぞれのタスク単位の成果)を決めて実行する 例) Service Fundamentals - 特定のスコアカードのスコア値 Service Health and SDP - BRAIN の検出精度 / SLO のカバレッジ Operational Efficiency - インシデント数 / アラートノイズ率 / TSG のカバレッジ Reliability Risk Reduction - Outage の調査 TSG = トラブルシューティングガイド
15. Playbook に基づいたワークフロー 1. Service Fundamentals 2. Service Health and Safe Deployment Practice(SDP) 3. Operational Efficiency 4. Release and Change Management Automation 5. Reliability Risk Reduction 6. Scalability and Capacity Planning それぞれのフェーズに期間 / 成果 / KPI / タスク（それぞれのタスク単位の成果)を決めて実行する 例) Service Fundamentals - 特定のスコアカードのスコア値 Service Health and SDP - BRAIN の検出精度 / SLO のカバレッジ Operational Efficiency - インシデント数 / アラートノイズ率 / TSG のカバレッジ Reliability Risk Reduction - Outage の調査 TSG = トラブルシューティングガイド
16. Safe Deployment Practice(SDP)
17. Azure におけるデプロイのスケール感 変更のデプロイ数: 数百 / day <変更の主な種類> 新機能のリリース アーキテクチャ変更 一部のコード修正 コンフィグ変更 各リージョンへのデプロイは完全に自動化されている →変更すると直ちに障害が発生する可能性がある
18. 安全なデプロイを実現するために カナリアの活用 • カナリーリージョンへのリリース • ベイクタイムを設定し潜在的な 障害パターンを検出 段階的なリリース • リージョンペアとゾーンの段階的な リリース ヘルスシグナルの実装 • ヘルスモニタリングによる正常性メトリックの監視 • AIOｐｓによる異常検知 ロールバックの実装 • 問題検出時の自動復旧
19. Playbook に基づいたワークフロー 1. Service Fundamentals 2. Service Health and Safe Deployment Practice(SDP) 3. Operational Efficiency 4. Release and Change Management Automation 5. Reliability Risk Reduction 6. Scalability and Capacity Planning それぞれのフェーズに期間 / 成果 / KPI / タスク（それぞれのタスク単位の成果)を決めて実行する 例) Service Fundamentals - 特定のスコアカードのスコア値 Service Health and SDP - BRAIN の検出精度 / SLO のカバレッジ Operational Efficiency - インシデント数 / アラートノイズ率 / TSG のカバレッジ Reliability Risk Reduction - Outage の調査 TSG = トラブルシューティングガイド
20. SLO / SLI
21. 適切な SLI/SLO の設定 1. クリティカルユーザージャーニー(CUJO)の収集・検証 天気予報を提供するサービスの場合: 例)ユーザーが翌日の天気予報データをアプリで表示する= CUJO 2. SLI の特定 SLIは成功した操作の実際の割合を測定する: 例) 天気予報API呼び出しの成功率 3. SLO の定義 顧客に公開される公式のサービス レベル アグリーメント (SLA) に関連付ける 4. サービスをインストルメント化 5. ダッシュボード化 6. 継続的な検証 測定可能性、感度、関連性、SLI の標準の準拠
22. Playbook に基づいたワークフロー 1. Service Fundamentals 2. Service Health and Safe Deployment Practice(SDP) 3. Operational Efficiency 4. Release and Change Management Automation 5. Reliability Risk Reduction 6. Scalability and Capacity Planning それぞれのフェーズに期間 / 成果 / KPI / タスク（それぞれのタスク単位の成果)を決めて実行する 例) Service Fundamentals - 特定のスコアカードのスコア値 Service Health and SDP - BRAIN の検出精度 / SLO のカバレッジ Operational Efficiency - インシデント数 / アラートノイズ率 / TSG のカバレッジ Reliability Risk Reduction - Outage の調査 TSG = トラブルシューティングガイド
23. BRAIN(AIOps)
24. そのまえに... インシデント管理のはなし SREの仕事としてオンコールや障害分析を担当することがある サービス停止のフェーズ: Detection / Triage / Investigation / Mitigation 各フェーズに対する KPI: Time To Detect(TTD) Time To Engage(TTE) Time To Mitigate(TTM) Incident と Outage: Incident = 特定のコンポーネントやサービスの問題 Outage = サービス停止を伴う障害 出典：Chen et al., ESEC/FSE 2020, DOI: 10.1145/3368089.3417055
25. そのまえに... インシデント管理用CRM: IcM 大規模障害の場合、 このようなインシデントが大量に作成される... 出典：Chen et al., ESEC/FSE 2020, DOI: 10.1145/3368089.3417055
26. インシデントの検出・トリアージ・相関関係の生成 BRAIN[1] Microsoft の AIOｐｓ の取り組みのひとつ 機械学習ベース サービスや IcM に組み込まれている インシデント検出 時系列データとイベントシーケンスから異常を検出 インシデント自動トリアージ インシデントに関するオンコールエンジニアのやりとりをもとに担当チームを特定 インシデント相関関係 冗長なエンジニアリング作業を軽減し、障害の影響範囲推定を支援 出典：Chen et al., ESEC/FSE 2020, DOI: 10.1145/3368089.3417055
27. トリアージの精度向上 Triangle[2] LLM+エージェントを活用したトリアージの 精度向上 意味的蒸留メカニズム 3種類のキーフレーズ （障害の場所、症状、必要な能力）を抽出 マルチロールエージェントフレームワーク 3つの専門化されたエージェント（Analyser、Triage Decider、Team Manager）による 協調作業 エージェント間交渉 最適なチーム選択（人間エンジニアの意思決定プロセスの模倣） チーム情報強化 自動的にモニタリングデータベースから関連情報を収集し、エンドツーエンドの自動化を実現 出典：Yu et al., "Triangle: Empowering Incident Triage with Multi-LLM-Agents", 2025. BRAIN を置き換 えるものではない
28. AIOps の進化 機能 BRAIN (2020) Triangle (2025) 主な目的 インシデントの自動検出・トリアージ・相 関関係の生成 トリアージ 技術基盤 従来の機械学習モデル (LSTM, GRU, ランダムフォレスト) 大規模言語モデル (LLM) + マルチエージェントシステム インシデント理解 統計的特徴抽出とパターン認識 意味的蒸留による深い言語理解 トリアージ方法 機械学習による自動分類 LLMエージェント間の交渉による合意形成 外部情報活用 過去インシデントと信号相関の活用 自動的なチーム情報強化メカニズム 人的介入 エンジニアの作業を補助 完全なエンドツーエンド自動化 効果 TTD, TTE, TTM, TTB, TTFの短縮 20%以上の精度向上、TTEの大幅短縮 Azure の運用を支える AIOps #1【イントロ編】 https://zenn.dev/openjny/articles/78f91604a8c30f おすすめ！
29. SRE のしごと サービスのオンボーディング 変更レビュー 障害分析 オンコール リスク分析 標準化 etc... 今回主に説明するパート
30. 変更レビュー サービス停止の最も大きな原因 = 変更 変更に関するOutageを無くすことをゴールに変更レビューの取り組み 変更レビューの流れ 1. サービスのオンボーディング Dev→SRE: サービスの概要、リリースツールの理解、リリース頻度の理解 SRE→Dev: 変更レビューの理解 2. 変更レビューの実施 リリース情報の登録、Pre-deployment call の実施 3. 変更の承認 リスクレベルの判定と承認(もしくは保留・リジェクト)
31. 変更レビュー Pre-deployment call の参加者 リクエスター Dev 担当者 ファシリテーター SRE 品質レビュアー リクエスターのVP / Director / SRE 観点 • リクエスターは変更点やリスクを理解しているか • SDP に沿ったデプロイになっているか • テストは実施しているか • ロールバックは実装されているか • ヘルスシグナルは設定されているか • フィーチャーフラグは利用されているか • ペイロードは適切なサイズか • カナリア環境で十分なベイクタイムを経ているか 総合的に判断し リスクレベルを評価 参考: 安全なデプロイ プラクティス https://learn.microsoft.com/ja- jp/devops/operate/safe-deployment-practices
32. つくってみたツール 1. レビューツールいい感じにしてくれる君 ブラウザの拡張機能として開発 デプロイ日時が過去日付の場合マーキング ロールバック時間が未設定の場合にマーキング 指定したリージョンの背景色変更 見やすいCSSの適用 結果: レビュー対象の漏れを防げるように メンバーからも良い評価 2. 仮想的にレビューしてくれる君 リリースの内容を取り込み変更点や問題点、確認が必要な点、リスクを評価 LangChainを使いエージェントとして実装 リクエスター、QR、VPの役割の作成→レビュー結果を生成 ブラウザ拡張によって、各レビューの画面から生成ページへジャンプ 結果: 肌感覚で事前準備にかかる時間を20%くらい削減できた 詳細はこちら https://zenn.dev/microsoft/articles/sr e-time-saving-tool-development
33. 参考資料 [1] Chen, Z., Kang, Y., Li, L., Zhang, X., Zhang, H., Xu, H., Zhou, Y., Yang, L., Sun, J., Xu, Z., Dang, Y., Gao, F., Zhao, P., Qiao, B., Lin, Q., Zhang, D., & Lyu, M. R. (2020). Towards intelligent incident management: why we need it and how we make it. Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE 2020), 1487-1497. https://doi.org/10.1145/3368089.3417055 [2] Yu, Z., Ma, M., Feng, X., Ding, R., Zhang, C., Li, Z., Chintalapati, M., Zhang, X., Wang, R., Bansal, C., Rajmohan, S., & Lin, Q. (2025). Triangle: Empowering Incident Triage with Multi-LLM-Agents. Unpublished manuscript, Microsoft Research. https://www.microsoft.com/en-us/research/publication/triangle- empowering-incident-triage-with-multi-llm-agents/
34. まとめ • パブリッククラウドにおいてもSLI/SLOの設定やインシデント管理、 変更管理など地道なタスクに取り組んでいる • AIOｐｓ はどんどん進化している • Azure の SRE たちは日々 Passion をもって 進化と改善に熱中してます！
35. © Copyright Microsoft Corporation. All rights reserved.