Google が実践する最先端の SRE

著者：木村健人(AoTo)
目次

はじめに

こんにちは。Datadog Japan で Sales Engineer をしている 木村健人(AoTo)です。Google Cloud の公式ユーザーグループである Jagu’e’r(Japan Google Cloud Usergroup for Enterprise) では、オブザーバビリティ分科会を立ち上げ、運営を行なっています。

昨年末、Google で25年以上 SRE を推進してきたエンジニアが『The Evolution of SRE at Google』という記事を公開しました。この記事は、従来の SRE のアプローチにシステム理論を用いた安全分析手法である STAMP/STPA を適用した経緯とその有効性を説明してます。そして Google の SRE チームは大胆にも、このアプローチが SRE の未来を象徴するものであると語っています。

では、この STAMP/STPA というアプローチはどのようなものなのでしょうか。そして、本当に Google と他の企業や組織に活かせるプラクティスなのでしょうか。 本記事では以下の構成で、STAMP/STPA のアプローチと SRE のプラクティスの関連を探り、SRE のプラクティスに適用する方法を解説します。

  • STAMP/STPA と SRE
  • なぜ従来の SRE のプラクティスでは不十分なのか？
  • Google のような大規模システムにしか関係ないことではないのか？

免責事項

本記事内で説明される内容は、筆者個人の経験に基づく意見・考え方の一例であり、所属組織を代表するものでは一切ございません。 この記事は『The Evolution of SRE at Google』をもとにして、筆者個人の視点から SRE と STAMP/STPA の要素を分解し考察するものです。 SRE のプラクティスや STAMP/STPA の理解に誤りがあれば、言及いただけますと幸いです。

STAMP/STPA と SRE

用語

まず初めに、登場する略語の原型とその日本語訳を確認しましょう。

  • STAMP: System-Theoretic Accident Model and Processes, システム理論に基づく事故モデルとプロセス
  • CAST: Causal Analysis based on Systems Theory, システム理論に基づく因果分析(CAST)
  • STPA: System-Theoretic Process Analysis, システム理論的プロセス分析
  • UCA: Unsafe Control Action, 安全でない制御アクション
  • HCF: Hazard Causual Factor, ハザード要因

複雑なシステムの事故モデル -STAMP-

STAMP とは、システムを「コントローラー」と「非コントロールプロセス」の相互作用に着目し、アクシデントの発生を説明した事故モデルです。 これは、現代の複雑化したシステムのアクシデントの原因を、システム構成要素の故障ではなくシステム内の安全制御を担う要素(コントローラー：Controller)と制御される要素(被コントロールプロセス：Controlled Process)の相互作用が働かないことにあると説明するものです。つまり、これらの安全のための制御を行う「コンポーネント」間の「相互作用」が正しく働かないことによって事故が起きると説明されます。

STAMP の考え方は、『基礎から学ぶSTAMP/STPA（1）- STAMP/STPAとは何か』にわかりやすく説明されています。

STAMP を元にした分析 - STPA

STPA は STAMP の事故モデルを前提として、「いかにして事故が起きるか」を解析する手法。 この手法は、安全のための制御つまり「コンポーネント」間の「相互作用」が、事故につながる状態である「ハザード」をコントロールできていない・間違ってるという「ハザードシナリオ」を作成し、原因を探ります。 このハザードを引き起こす原因を UCA(Unsafe Control Action) と呼び、以下の4つのタイプに分類します。

  • 与えられないとハザード：Not Providing
  • 与えられるとハザード：Providing causes hazard
  • 早/遅過ぎ・誤順序でハザード：Timing：Too early/too late, wrong order causes hazard
  • 早過ぎる停止・長過ぎる適用でハザード：Duration：Stopping too soon/applying too long causes hazard

つまりこの分析により、「ある条件下でで正しく動作をしなければハザードに繋がる」ことを明らかにし、事故の発生前に把握できます。

STPA の説明は、『基礎から学ぶSTAMP/STPA（2）- STPAの手順を理解する』にわかりやすく説明されています。

STAMP/STPA を「完全に理解」する

ここまでお読みいただいて、ある程度 STAMP/STPA の概念を捉えていただけていると幸いです。 少し説明の中で利用される用語が難解のため、ここでは STAMP/STPA を専門的な用語を利用せずに説明します。

STAMP では、システム事故の原因をある特定のイベントではなく、事故につながる状態を放置していたことで起こると考えます。 そして STPA は、その事故に繋がる状態(ハザード状態)からどのようにして事故に至ったかを、事故につながったイベントの有無やタイミングと期間で分析します。

このように STAMP/STPA のような事故モデルや分析手法は、複雑なシステムで発生する事故を抽象化して理解するための考え方 です。 ここではさまざまな用語が定義されますが、それぞれは実際のシステムの抽象概念から構成されています。用語それ自体には重大な意味を含まないため、大枠で理解いただいても SLI/SLO の設定に活用できます。

SRE への適用

ここでは、STAMP/STPA で利用される用語を簡単に説明し、SRE が普段用いている用語を用いながら SRE のプラクティスへの適用方法を考察します。。

  • 事故(アクシデント): 望まれない・計画されていないイベントで損失に至るもの
  • ハザード: 最悪の環境下でアクシデントに至る、システムの状態
  • UCA(安全でない制御アクション): ハザードを引き起こす条件、平常時の安全な制御アクション以外のもの
  • HCF(ハザード要因): ハザードが引き起こされる要因、根本原因
  • 安全制約: ハザードを防止するために必要となるルール、ハザードの裏返し

事故(アクシデント) は、SRE が直面するインシデントと似ています。 ハザード状態から SRE をはじめとするシステム開発者・担当者に認知されることで、事故やインシデントとして管理されます。事故やインシデントは単一のイベントですが、STAMP はこの原因を単一のイベントとして捉えるのではなく、ハザード状態に至らしめる UCA(安全でない制御アクション)があり、事故はそれが顕在化しただけであると考えることがポイントです。

ハザード は、サービスレベルを損なう可能性のあるシステムの状態です。 SLO とエラーバジェットではシステムの定義された信頼性を監視します。必ずしも信頼性に影響を与えないため通常の SLO では把握しきれません。SRE が STAMP を取り入れることで、信頼性を低下させる可能性のある危険状態であるハザードを捉える SLO を定義できます。

UCA(安全でない制御アクション) は、ハザードを引き起こす原因となる特定のシステム動作です。 前述した4タイプのように、必要なアクションや不要なアクションを特定したり、そのタイミングや期間までを含めて多角的にのタイプを把握します。これにより、ハザードに至る条件を事前に整理し、それぞれの条件に合致した際に発見する仕組みを SRE のプラクティスに組み込むことができます。

HCF(ハザード要因) は、ポストモーテムで明らかにすべき根本原因を指します。 特に「HCF の特定」は STPA の最終段階(Step②)で行う内容であるため、必ずしも全てのシナリオで障害発生前に実施できるものではありません。そのため、HCF は特に障害発生時の分析に STPA を活用した際に導き出せる根本原因として、SRE のプラクティスの中で活用することが想定されます。

安全制約 はハザードに至る経緯を把握し、ハザードを起こさないために守るべき安全な動作要件を定義したものです。 まず初めに、どのような状態が望ましいかを考えて簡易的な安全制約を導き、その後 UCA を特定し詳細な安全制約を定義できます。こうした安全制約は SLO を定義する対象を定めたり、キャパシティプランニングの参考にできます。

なぜ従来の SRE のプラクティスでは不十分なのか？

SRE は理論で形式化されているものではなく、その概念が広まり多くの賛同を得て実践されているプラクティスの集合体です。 その一方で古くからあるシステム工学・制御工学の理論をはじめ、形式化された分析手法を用いることで、これまで実践者に委ねられていた暗黙知を形式知とすることができます。

SRE のプラクティスは十分に素晴らしいものである一方で、これらのプラクティスを理想通りに適用しようとしても、明確な根拠をもとにその基準を決めることが難しい場面が多く存在します。 こうした背景からも STAMP/STPA のアプローチは SRE のプラクティスに活かせる点が多くあることは想像いただけるのではないでしょうか。

ここからは SRE のプラクティスである、SLI/SLO の設定やキャパシティプランニングを例に、これらを実践する難しさに触れながら STAMP/STPA の有効性を確認します。

SLI/SLO

SLI はサービスレベル指標、SLO はサービスレベル目標の略語で、SRE のプラクティスの基礎として広く知られています。 これらの設定や運用・改善などの知見は本 Web マガジンの SRE Magazine にも多く共有されているので、是非ご覧ください。

SLI/SLO の特定・設定は頻繁に様々な知見や試みが共有されているように、これらは一見簡単に思えますが正しく実践するのは難しい SRE のプラクティスの一つです。SLI/SLO を設定することは簡単ですが、障害を早期に特定できるものであるかや不必要に複雑なものでないかなど、運用効率を背景に考慮するべきことが多くあります。 こうした現状からも、STAMP/STPA の考え方を SLI/SLO の特定に適用する意義があります。STAMP/STPA のアプローチからハザードや安全制約を分析し定めることで、 SLI/SLO を設定する根拠として明文化できます。

本当に必要な SLI/SLO を定義することは簡単ではありません。STAMP/STPA のように、複雑なシステムの障害要因となるシナリオを分析することで、根拠をもってこれらを実践しやすくなります。

キャパシティプランニング

一般的にキャパシティプランニングとは、「ユーザー体験を損なわずに、計画停止と計画外停止が同時に発生する状況に対応するためのプロビジョニングを計画する」ことです。 SRE 本のベストプラクティス集でも触れられている「N+2」構成のように、単純化したキャパシティプランニングであれば比較的簡単に定義できます。しかし、複雑なシステムそれだけでは適切なキャパシティとは限りません。 こうした場合に、STAMP/STPA を活用することで、安全制約の観点からキャパシティプランニングの値を設定することも可能です。

つまり、どのような UCA が想定されるかのシナリオを把握することで、その逆となる安全制約を守るために必要なキャパシティを導き出せます。

このように、これまで単純化された定義や暗黙知として運用されていたものが、根拠を持って値を定めることができるのが STAMP/STPA のような形式化されたモデル・分析手法を取り入れる利点といえます。

Google のような大規模システムにしか関係ないことではないのか？

この問いには原文でもそうではないことが、随所で示唆されています。 一方で SRE のプラクティスを正しく適用することが難しいような複雑なシステムにこそ、こうしたモデルを適用する効果が高まることも事実です。

原文では実際の例として、Google のソフトウェアサービスに適用されているクォータサービスの UCA(安全でない制御アクション) の例が紹介されています。 このクォータサービスはソフトウェアサービスが一貫してクォータを下回る場合に、クォータを動的に削減します。この時、クォータが実際の使用量を下回れば、「与えられるとハザード」となる UCA としてハザードに陥ります。

こうした UCA が見つかった際に、個々の事象への対策ではなく安全制約を脅かす他タイプの UCA を考慮することで、十分な SLI/SLO を特定・設定することに繋がります。 このように、STAMP/STPA のアプローチはシステム規模に関わらないことがお分かりいただけると思います。

実際に、これらのアプローチは SRE のプラクティスを拡張するものではなく、SRE のプラクティスを強化するものであることがお分かりいただけたと思います。

まとめ

  • SRE のプラクティス を実践するためには、複雑なシステムを理解するためのモデルが有効となる
  • Google SRE チームはシステム理論と制御理論によって提唱される事故モデル(STAMP)を SRE のプラクティスの強化に採用している
  • STPA はコンポーネント間の相互作用によって起きる事故を分析する手法で、STAMP を用いたシステムの分析に利用できる
  • STAMP/STPA のように、潜在的に障害につながるシナリオを知ることで、SRE のプラクティスの適用から安全なシステムの設計に役立てられる

おわりに

SRE(サイト信頼性エンジニアリング) という概念自体も、ソフトウェア工学という一つの工学分野から生まれたものです。こうした概念にも、制御工学から生まれた STAMP/STPA をはじめとする様々な形式化されたアプローチを適用することで、よりよい実践的な仕組みが出来上がります。SRE が生まれてから20年近くが経過し、様々な知見からそのアプローチには多くの知見が取り入れられています。様々なシステムや対象に SRE を適用している現在、ここの事象に対し何が必要かを考察し、SRE のプラクティス自体の改善に繋げることが重要なのではないでしょうか。

こうした STAMP/STPA の適用事例を参考に、皆様が SRE のプラクティスを深めるきっかけとなれば幸いです。

参考文献