- GoogleのSREは、サービス規模が拡大しても障害を減らしてきたが、個人情報侵害やデータ損失のような絶対に防がなければならない損失に対しては従来の方法だけでは不十分だと判断し、STAMPを導入した
- STAMPは個々のコンポーネント故障よりもシステムの相互作用と制御の失敗に焦点を当て、CASTは事故調査に、STPAはリスク分析に活用される
- データフローモデルと線形の原因連鎖は、100を超えるノードのRPCダイアグラム、古くなったアーキテクチャモデル、欠落した要件を前にすると、分析の限界が大きくなる
- 2021年の社内quota rightsizer事故では、誤ったリソース使用量フィードバックと伝達されなかったpending changeが数週間にわたって危険状態を生み、最終的に障害につながった
- GoogleはSTPA分析にengineer-weeks規模の労力を投入して数百のシナリオを見つけ、Google Cloudや社内ネットワーク、複数製品の安全設計へとSREの範囲を広げている
従来のSRE手法が直面した限界
- Google製品は世界中で数十億人が毎日利用しており、この25年間でサービス規模は大きく拡大したが、障害はむしろまれになっている
- SREはこれまでSLO、エラーバジェット、隔離戦略、徹底した事後分析、段階的ロールアウトによって安定性を拡張してきた
- 現在の課題は、単に障害頻度を下げることではなく、発生そのものを防がなければならない損失を扱うことにある
- 従来のエラーバジェットは状態の少ないWebサービスには概ね適していたが、エラーバジェット0に近い損失を扱うには十分ではない
- AIとMLがほぼすべての製品の中核となり、自動化がスケーラビリティを可能にする中で、コストとエネルギー効率もユーザー機能と同じくらい重要になっている
従来のSRE思考の構造
- 伝統的なリスク分析は大きく3つの要素で構成される
- システムをモデル化する方法
- 問題が発生する仕組みを説明する原因理論
- リスクを見つける探索アルゴリズム
- Google SREの従来手法は明示的な理論として定式化されてはいなかったが、ソフトウェアアーキテクチャとデータフローモデルを中心にリスクを分析してきた
- データフローモデルは、ネットワークリクエストやデータがシステムのさまざまな部分の間をどのように移動するかを示す
- このモデルは自然に線形の原因と結果の推論につながる
- 各コンポーネントのSLOを見て安定性保証を理解する
- 呼び出し元の要件を満たしているか、または上回っているかを確認する
- 事後分析では、個別の事象から一般的なパターンを導く帰納的推論を用いる
- 1回の事象を修正して終わるのではなく、同種の事象全体を防ぐ方法を探す
- 繰り返し発生するアラートをエンジニアリング上の解決策に変え、問題の原因を取り除こうとする
データフローモデルと線形原因分析の限界
- システムの複雑さが年々増すにつれ、データフローモデルではGoogle規模の複雑性を扱いきれなくなっている
- RPCダイアグラムやソフトウェアアーキテクチャモデルは、抽象化を一貫して使わなければ過度に複雑になり、たいてい不完全または古いままになりがちである
- こうしたモデルはシステムのダイナミクスを十分に示せない
- どのRPCがフローを開始しうるのか
- エラーがどのように伝播するのか
- どのコンポーネントが深刻な障害を引き起こしうるのか、またどのコンポーネントは小さな問題しか起こさないのか
- ある相互作用が特定の文脈では安全でも、別の文脈では安全でない理由は何か
- システム全体の目標は何か
- 各コンポーネントが全体目標に対してどのような責任を持つのか
- 100を超えるノードを持つデータフローダイアグラムは、欠陥探索の出発点としてすでに圧倒的である
- 要件定義段階で安全要件が欠落または誤っていると、設計が要件を完全に実装していてもシステム安全性は損なわれうる
- 障害データから学ぶ方法には、まだ一度も起きていない損失を予測して防ぐうえで限界がある
STAMPが変える考え方
- Google SREはシステム理論と制御理論を取り入れ、MITのNancy Levesonが開発したSTAMPフレームワークを採用した
- STAMPは事故をコンポーネント故障の連鎖ではなく、システム制御が十分に機能しなかった結果として捉える
- CASTは事故後の調査に、STPAはリスク分析に用いられる
- STAMPは安全性を個々のコンポーネント属性ではなく、システムレベルの創発的特性として扱う
- 分析の問いも変わる
- 従来の問い: どのソフトウェアサービスが失敗したのか
- STAMPの問い: システム各部分のどの相互作用が十分に制御されていなかったのか
- 複雑なシステムにおける多くの事故は、各コンポーネントが設計どおりに動作していても、組み合わさることで安全でない状態を生んだ結果でありうる
制御理論の4つの条件
- W.R. Ashbyの『An Introduction to Cybernetics』にある制御条件は、LevesonのSTAMP手法に統合されている
- プロセスを制御するには4つの条件が必要である
- 目標条件: コントローラが目標を持っていること
- 行動条件: コントローラがシステム状態に影響を与えられること
- モデル条件: コントローラがシステムモデルを持っていること
- 可観測性条件: コントローラがシステム状態を把握できること
- SREの実務では、これらの条件を複雑なシステムを効果的に制御するために必要な要素を確認する基準として活用できる
危険状態が生む対応の余地
- 線形の原因連鎖モデルは通常、正常運用と損失運用という2つの状態しか示さない
- 正常運用から損失運用への遷移はたいてい突然で、損失を防ぐための対応時間がほとんどない
- SREが高速burnと低速burnのSLOを併用する理由も、実際の被害の前段階にある問題を検知するためだが、こうしたSLOは通常、個別コンポーネントの属性である
- STAMPはこれをシステムレベルの危険状態として定式化する
- 危険状態とは、特定の最悪環境条件と結びついたときに、1人以上のステークホルダーに損失をもたらすシステム状態または条件の集合である
- 危険状態は個別イベントや個別コンポーネントレベルの現象ではない
- システムは事故が発生する前に長期間危険状態にとどまりうる
- バグが入り込んでいるが、まだトリガーされていない
- アラートは発生したが、誰にも届いていない
- サーバーが過少プロビジョニングされているが、人気機能から突然トラフィックを受ける
- エンジニアリングの目標は、すべての単一障害を排除することではなく、システムが危険状態に入らないようにすること、あるいは危険状態から正常運用に戻すことである
2021年のquota rightsizer事例
- Googleは社内インフラにおいて、一部ソフトウェアのリソースquotaを設定し強制している
- 効率向上のため、各サービスがquotaのうちどれだけを使っているかを監視し、継続的に使用量が少なければ自動的にquotaを縮小する
- STPAの観点では、quota rightsizerはサービスquotaを減らす制御行動を持つ
- この行動が安全でないのは、rightsizerがサービスの実際の必要量よりも低くquotaを減らしてしまう場合である
- サービスはリソース不足状態になる
- STPAではこれを安全でない制御行動、すなわちUCAと呼ぶ
- UCAには4つのタイプがある
- 必要な制御行動が提供されない
- 不正確または不十分な制御行動が提供される
- 制御行動が誤ったタイミングまたは順序で提供される
- 制御行動が早く止められすぎる、または長く適用されすぎる
- quotaを実際の必要量より低く減らすのは、2番目のタイプのUCAである
フィードバック経路で明らかになった脆弱性
- 安全要件は「quota rightsizerは現在のサービス必要量より低くquotaを減らしてはならない」とまとめられる
- この要件は将来の設計、テスト計画、システム理解に役立つ
- STPAは、この安全要件に違反させる具体的なシナリオを見つけるよう分析を構造化する
- rightsizer事例では、4つの代表的シナリオを調査できる
- rightsizer自体が誤動作する
- rightsizerが誤ったフィードバックを受け取る、またはフィードバックをまったく受け取れない
- rightsizerが行動を送ろうとしたが、quotaシステムが受け取れない
- quotaシステム自体が誤動作する
- 実際に目立ったシナリオは、現在のリソース使用量フィードバックが過小に計算される場合だった
- リソース使用量の計算には、複数のデータコレクタと複雑な集計ロジックが含まれる
- 計算結果が実際より低ければ、rightsizerは設計どおりに動作していてもquotaを誤って引き下げてしまう
- 従来はquota調整アルゴリズムと出力精度に多くの関心が向けられていたが、フィードバック経路はあまり理解されていなかった
- STPAは制御経路だけでなくフィードバック経路の問題も見つけられるようにし、Googleの複数システム分析でもフィードバック経路の理解不足がよく見られた
事故が損失につながった流れ
- 2021年の事故では、Googleインフラの重要サービスで使用中のリソースに関する誤ったフィードバックがrightsizerに送信された
- rightsizerは新しいquotaを計算し、実際の使用量よりはるかに少ないリソースが割り当てられることになった
- 予防措置として、quota縮小は即時適用されず、誰かが介入する時間を与えるため数週間保留された
- しかし、pending changeに関するフィードバックは誰にも伝えられなかった
- システムは数週間にわたって危険状態にあったが、それを探していなかったため、損失を防ぐ機会を逃した
- 数週間後、quota縮小が適用されると大規模な障害が発生した
- GoogleはSTPAを使って、このような問題を複数のシステムで事前に予測している
Google SREが向かう先
- Google SREは複雑性をバグとみなすのではなく、制御理論とSTPA、CASTを活用して、より包括的で先回り型の信頼性アプローチへ移行している
- 目標は障害に反応することにとどまらず、最初からより安全なシステムを設計することである
- Googleは最も複雑なシステムの一部をSTPAで分析しており、分析1件あたりengineer-weeks規模の労力で、影響範囲の異なる数百のシナリオを発見している
- 発見されたシナリオは、障害につながる前に緩和される
- 迅速な暫定修正
- より慎重に計画されたソフトウェアエンジニアリング
- Googleの定期計画プロセスを活用したコストと中断の最小化
- 現在の作業は、非常に複雑なGoogle Cloudシステム、大規模な社内ネットワークシステム、複数のGoogle製品に集中している
- SREにおけるシステム安全手法への転換は、エンジニアが構築するシステムを理解する新しい方法を提供し、その動作についてより強い保証を与える方向を目指している
まだコメントはありません。