Microsoft の Azure では、全世界に広がる 300 以上のデータセンターの数百万台を超えるサーバーを運用するために SRE が組織され、日々の安定稼働に向けて支援しています。その支援には、システム、サービス、製品でのサービス停止時の対応やその改善、新しい機能のリリースや変更などにあるリスクの評価、品質の確認などさまざまな活動が含まれます。
この記事では Azure の SRE チームがどのように組織され、どのような原則に基づいて運用しているか紹介します。
SRE の活動について、以下のような Microsoft のイベントやブログ記事、Podcastなどでも断片が紹介されているので参考になります。
- Advancing Microsoft Azure reliability
- Advancing safe deployment practices
- Outages are inevitable and here's what you should know
- Anatomy of an outage and evolving our cultures towards transparency
- Episode 504 - Azure Reliability SRE
SRE チームのミッション・役割
Azure では、毎日さまざまなサービスで新しいリリースが展開されており、それにより各データセンターやサービスで大小さまざまな障害が発生する可能性があります。このような大規模な運用を支えるために、さまざまな SRE のロールが存在し、多くのツールやプログラム・プロセスが日々の業務に使用されています。
Azure の SRE は開発組織の中のカスタマーエクスペリエンスチームに所属しており、さらにその中で複数の SRE チームに分かれています。そしてそれぞれのチームが異なるミッション・役割を担っています。
たとえば、リスクを評価しているチーム(Risk SRE)、Azure の各サービスの信頼性向上の支援を担当しているチ-ム(Service SRE)などがあります。私が所属している Change SRE では、後述する R2D や SDP などのプログラムを通じて、Azure プラットフォームやサービスに適用される変更リリースの信頼性と品質向上を支援しています。
SRE 全体として、すべての開発・運用担当のエンジニアが信頼でき、安全でセキュアなクラウドサービスを構築および運用することを容易にする というミッションに掲げており、このミッションのもと OKR や KPI などの目標が設定されます。
SRE チームではサービスをオンボードする際、以下のようにフェーズを分けて運用改善に必要な機能を実装していきます。それぞれのフェーズで KPI を設定し、達成するために活動します。
- Service Fundamentals
開発チームとコミュニケーションを取りサービスの基礎を理解する。セキュリティのような基本的な要件を KPI として設定する。 - Service Health and SDP
モニタリングの実装によるオブザーバビリティの向上や SLI/SLO を設定する。BRAIN(後述)による検出精度や SLO のカバレッジを KPI として設定する。 - Operational Efficiency
サービス停止時のオンコールの参加やトイルの削減を行い運用効率化を図る。インシデントの数やノイズ、TTx(後述)を KPI として設定する。
※3. Operational Efficiency 以降も、変更管理やリリースの自動化などのフェーズがあり、それぞれのフェーズで KPI が設定されています。
ここで重要なのが SRE チームは相談役としての役割だけでなく、上記の様な機能を実装していくということです。 そのため、開発チームとのコミュニケーションが重要であり、開発チームが SRE チームに対して信頼を持ち、協力して取り組むことが求められます。Podcast では、SRE チームがオンボードする際に開発チームからの信頼を得るまでには時間がかかることがあるとも話されています。
SRE プレイブック
Azure の SRE チームでは、SRE プレイブックと呼ばれるフレームワークを作成し原則やアプローチを定義しています。
SRE プレイブックには SRE のエンゲージメントのオペレーティングモデルや、前述のようなフェーズごとの KPI に対する具体的なタスク等が記載されています。
たとえば以下は SRE の原則の一例です。
- プレイブックは、SRE チームとプロダクト開発チームの健全な関係性に基づいており、信頼、協力、およびコードとプロダクションに対する共同の責任がその基盤となっている
- プレイブックは、データ駆動型であり、Operation Excellence と Reliability の KPI に基づいてエンゲージメントの方向性を決定する。但し、盲目的にデータを信じることはない
- 各フェーズには期限があり、フォーカスした取り組みと長期的かつ広範な結果の達成のために時間を制限する
さらに SRE プレイブックにはパターンとプラクティスが記載されており、過去のエンゲージメントから得られた知見・経験やそこから導かれる具体的な作業が記載されています。
パターンは再利用可能であることが必要で、特定のサービスに固有するものであってはならないとされています。
たとえば、以下のようなパターンが記載されています。
- SLI と SLO の実装
- 合成モニタリング
- 効果的なトラブルシューティングガイドの確立
パターンは既存のドキュメントと重複しないこと、ゴール・ノンゴールが含まれていること、KPI の改善に役立つ内容であることが求められ、単純な技術ドキュメントにならないことが重要なポイントです。
SLI と SLO の実装
パターンの一つである SLI と SLO の実装についてみてみましょう。
SLI と SLO は言うまでもなくプラットフォームの信頼性を測定するための重要な要素です。一方で意味のある SLI と SLO を定義するにはサービスの理解と同時にユースケースの理解が必要です。たとえば、仮想マシンの CPU の使用率が 100 パーセントになった場合、それがサービスの信頼性にどのような影響を与えるかは状況によって異なります。SLO を定義するには、サービスの重要な機能やユーザーの期待値を考慮する必要があります。
プレイブックでは以下のステップで SLI と SLO を実装することが推奨されています。
- タスク1: クリティカルユーザージャーニー(CUJO)の収集と検証
- タスク2: SLI の特定
- タスク3: SLO の定義
- タスク4: サービスのインストルメント化
- タスク5: SLI と SLO 定義の実装
- タスク6: SLI の検証と改善
メトリクスは OpenTelemetry を用いて収集され、専用のデータベースに格納されます。設定したSLI や SLO、エラーバジェット、インシデント等 は共通のダッシュボードで確認ができます。
実装した SLI はその品質を保つためにスコアリングされて改善に活用されます。スコアは測定可能性、感度、関連性、SLI 標準への準拠の 4 つの基準で評価され、ダッシュボードで可視化されます。
一度定義・実装した SLI を固定化せず、かつサービスに依存しない標準的な方法で改善を続けることが期待されます。
サービスのデプロイメント
SRE チームは新しいサービスや機能をリリースする際のツールやプロセスを構築・改善し、リリースの信頼性を向上させることにも取り組んでいます。
新しいサービスや機能をリリースする際、Azure では Safe Deployment Practices(SDP) によってデプロイします。SDP は、サービスのリリースを安全に行うためのプラクティスであり、リリースの前後に行う検証やリスクの管理、リリースのロールバックなどが含まれます。
具体的なサービスの定義を SDP に従った方法で行い特定の操作を行うことでデプロイメントが進行します。SDP によるデプロイメントによって CD パイプラインがトリガーされます。デプロイメントは Azure のすべてのリージョンに同時に行われるわけではなく、ロールアウトのステージを設けて段階的にリリースされます。SDP については冒頭で紹介した Ignite 2024 のセッションや Mark Russinovich のブログ記事などで紹介されています。
SDP の概念(Outages are inevitable and here's what you should know, Ignite 2024)
SDP は機械的に扱われるもので人によるレビューは行われません。テストの実施状況やエラーバジェットに応じてデプロイをコントロールするために Ready to Deploy(R2D) と呼ばれるプロセスが実装されています。
R2D ではレビューの参加者やレビューの観点、リリース後のモニタリングの設定、リリース後のサービス停止からの復旧方法などを定義し、標準化することによりリリースの信頼性を向上させています。
オンコール
SRE チームはオンコールの Direct Responsible Indivisuals(DRI) のローテーションに参加することがあります。
DRI はインシデントがあった時のプライマリのエンジニアとして、インシデントの評価、サービス停止の宣言、影響の軽減に責任を持ちます。サービス停止の基準は事前に決まったルールで重要度が決まり、重要度に応じたタスクが発生します。
インシデントは IcM と呼ばれるインシデント管理システムで管理されます。インシデント管理の詳細は以下の記事が参考になります。
以下は IcM のインシデントの画面イメージです。インシデント ID、状態、影響しているサービス、サポートのケース数などが確認できるようになっています(Towards Intelligent Incident Management: WhyWe Need It and HowWe Make It より抜粋)。
インシデントの画面イメージ
サービス停止と宣言された場合、DRI 以外にもインシデントマネージャーなど複数のロールが関与します。それぞれのロールはタスクが予め決まっておりロールに応じた対応が求められます。また自動的にブリッジコールが作成され、DRI はそのブリッジコールに参加し問題の軽減に取り組みます。ブリッジコールは Teams でホストされますが、Azure 自体のサービス停止があった場合 WebEx にフォールバックします(このしくみは Project Dialtone と呼ばれる取り組みの一部で実装されています)。
Project Dialtone(Outages are inevitable and here's what you should know, Ignite 2024)
DRI はサービス停止時の対応だけなく軽減されたあとのポストインシデントレビュー(PIR)の作成や監視の調整、バグ修正のリクエストなどを行います。
まとめ
この記事では Azure を運用している SRE チームの原則と主なタスクについて紹介しました。
運用していく中で蓄積されたデータをもとに研究を行い、その成果を活用して運用を改善していくサイクルが実践されている点は興味深いですね。
今回紹介した内容は一部なのでほかにも多くの取り組みがありますが、Azure の信頼性を高めるために SRE チームがどのような活動を行っているかを知っていただけたら幸いです。
Discussion