GoogleにおけるSREの進化過程

 (usenix.org)
4 ポイント 投稿者 GN⁺ 2025-01-05 | 1件のコメント | WhatsAppで共有
  • Googleの製品は世界中で数十億人が使用しており、これらの製品が安定して動作することが重要である。GoogleのSREチームは、サービスの信頼性を高めるためにさまざまな方法を開発してきた。
  • 従来のSRE手法（エラーバジェット、ポストモーテムなど）は、GoogleがWebサービスを規模拡大する上で大きく貢献してきた。
  • 最近ではAI·MLなどによりシステムの複雑性が大幅に増加し、新しいアプローチが必要になった。
  • システム理論と制御理論は、複雑な相互作用を体系的に把握することに有用である。
  • 単に「問題が発生した後に解決する」方式から脱し、システムレベルの根本設計から安全性を担保するアプローチが必須となる。

STAMP概要

  • MITのナンシー・レベソン教授が提案したSTAMP（System-Theoretic Accident Model and Processes）は、単一コンポーネントの故障よりも、より複雑なシステム相互作用の観点から事故（事象）を分析する。
  • 既存の因果関係（「バグがあるから故障した」）ではなく、「システム全体がどのような誤った制御フローに陥ったのか」を重視する。
  • Causal Analysis based on Systems Theory（CAST）で事故を再構成し、System-Theoretic Process Analysis（STPA）でリスク要因を事前に把握する。

制御理論の基礎 – 4つの条件

  • 制御理論では効果的な制御のために4つが必要である
    • 目標条件: 目標（例：特定指標の維持）があること
    • 行動条件: 目標を達成するためにシステム状態に影響を与えられること
    • モデル条件: システムを理解するためのモデル（内部的・外部的）が必要
    • 観測可能条件: 現在のシステム状態を把握できるセンサーなどの観測体制が必要

障害（Outage）を制御問題として扱う

  • 従来は障害を「連鎖的故障」と説明する傾向が強かった。
  • STAMPはこれを「不適切な制御と相互作用」の視点で解釈し、システムレベルで安全性を確保する。
  • 単に「最初の故障がどこで始まったか」を見つけるのではなく、「どの制御/フィードバックの流れが異常だったか」を総合的に検討する。

ハザード（Hazard）状態から時間を確保する

  • 伝統的な因果モデルでは正常状態から一瞬で障害状態へ移行するため、対応時間が非常に短い。
  • STAMPでは「ハザード状態」という概念を導入し、完全な障害発生以前に危険に入った地点を見つける。
  • ハザード状態を検知した後に積極的に介入することで、実際の障害に至る前に予防する余地が生まれる。

実際の事例で見ていく

  • Google内部の「クォータ・リサイザー（Rightsizer）」が、サービス使用量を基準にリソースを再割り当てする。
  • STPAの視点から「誤った使用量情報を受け取り、実際の必要量より少なくリソースを減らしてしまう状況」を事前に識別可能である。
  • 設計段階では主に「正確な制御ロジック」のみを重視していたが、STPAを適用すると、フィードバック経路（リソース使用量の計算プロセスなど）で問題を発見した。
  • 2021年には、実際に誤ったフィードバックが蓄積されて大きな問題につながり、数週間にわたってハザード状態だったが気づかれなかった事例がある。

今後の方向性

  • Google SREは、STAMP・STPA・CASTなどシステム理論ベースのアプローチにより、より高いレベルの安全性と複雑性管理を追求する。
  • 小規模なエンジニアリング投資（数週間程度）だけでも、大規模システムで多数の潜在的リスクシナリオを見つける。
  • 既存の信頼性文化に加え、制御理論ベースの分析を導入すれば、AI·ML時代においても安定したサービス提供の可能性が高まる

関連記事

1件のコメント

 
GN⁺ 2025-01-05
Hacker News 意見

  • Googleのエンジニアリングアプローチは、スタートアップにとって有害になり得る。SREは救世主コンプレックスを持つ傾向があり、他チームの技術設計をやり直そうとする

    • これは、法務チームが会社を運営しようとする現象に似ている

  • Sidney Dekkerの著作にも共通点がある

    • システム全体を評価し、事故に関与した人々の認知状態を把握して、なぜ自分たちの判断が正しいと信じるに至ったのかを分析している
    • 複雑なシステムの独立した変化が安全性に与える影響を示している

  • CASTのアプローチは魅力的に見える

    • 失敗やニアミスに関する多くの分析が必要であり、これを実装する際に最も難しい部分は人間だ

  • CASTと機械的解析作業の間には興味深い類似点がある

    • システム構成要素がどのように相互作用するかを分析するフレームワークを提供している

  • 形式的な安全工学フレームワークをニューラルネットワークの分析に適用した事例があるかどうか気になる

    • 複雑な因果関係とシステムレベルの振る舞いを追跡する手法は有用かもしれない

  • "rightsizer"の例も、従来の方法で分析されていて同じ結果になっていた可能性がある

    • この新しいアプローチのほうが、より簡単で実行しやすい

  • ソフトウェアテストが嫌われるのは、外部要因による欠陥が原因だ

    • このアプローチがそれを解決するのに役立つかもしれない

  • CASTは多因子の根本原因分析に似ている

    • MITのナンシー・レヴェソン教授によるCASTの主張を支持している

  • SRE/DevOpsは日常的な役割の一部なのかという疑問

    • 多くの場合、これは既存の運用ロールのリブランドにすぎないと思う

  • Google SREの特徴は、新しい製品を出す際にSREの支援が必要だという点だ

    • 限られたSRE数が、良いアイデアをさらに良くする

  • 記事が長すぎて、肝をつかみにくい

    • CASTとSTPAへの言及が最も重要で価値がある

  • このアプローチがFAANG以外のスケールでも価値があるのだろうか

    • リスク回避に多くの投資をする傾向がある

  • DevOpsと同様に、SREの意味は拡張されつつある

    • SREはソフトウェアを作成したり、システム障害の処理など、さまざまな役割を担う