Googleが提唱するSREとは何か。SREの信頼性とは
xOps領域のプラットフォーマーを目指して幅広いサービスを展開しているテックカンパニー、スリーシェイク。例えば、藏本氏が携わっている「Sreake」もその一つ。SreakeはGoogleが提唱するSREの考え方に従って、AWSやGoogleクラウドを利用しているお客さまサービスの技術戦略、設計、構築、運用までをワンストップで支援するサービスである。
「クラウドネイティブな技術領域に強みを持つエンジニアが、お客さまチームのメンバーという立ち位置で最新技術の提案から運用までをトータルに支援する」と藏本氏は説明する。しかも技術的な対応に閉じるのではなく、SREチームの組成や文化の定着化、技術者の採用・育成コンサルティングなども合わせてサービスすることができるのだ。
Googleが提唱するSREの考え方に従っているとはいえ、SRE本の序章に書かれたベンジャミン・トレイナー・スロス氏によるSREの定義をイメージするのは難しい。そこでスリーシェイクではSREを「効率的なサービス運用をベースにサービスの信頼性とイノベーションスピードとのバランスを取りながら、ユーザーに提供する価値を最大化すること。またはそれを行うチームだと考えることにした」と藏本氏は語る。
SREの信頼性について、Googleでは次の3点を提唱している。
1点目は、「いかなるシステムにおいても最も重要な機能は信頼性である」こと。「これは信頼性を損なわない範囲で機能提供をしようという考え方です」（藏本氏）
2点目は、「監視が信頼性を決めるのではない。ユーザーが決めるのだ」。SREの考え方が浸透してきているので、信頼性＝CPU使用率と考える人は少なくなっているが、「信頼性はシステムの状態ではなく、ユーザー経験に基づいて定義されるべきだ」と藏本氏は語る。
CUJ（クリティカルユーザジャーニー：重要な顧客体験）という言葉にあるように、対象とするサービスにおいて、重要な顧客体験に焦点を当て、その顧客体験に及ぼす影響をもとに、監視項目は定義されるべきだとアドバイスする。「システムの状態ではなく。ユーザー影響に基づいて監視を行うことで。不要なアラート対応の削減や、稼働時間の確保が見込めます」（藏本氏）
3点目は、「可用性100％を信頼性の目標とすることは間違いである」。過度の信頼性はコストに跳ね返るからだ。「仮にフォーナインからファイブナインに可用性を高めたとしても、その効果をユーザーが気づくのは難しいことからもわかるでしょう」（藏本氏）
システム運用において信頼性と機能開発はトレードオフの関係にある。運用側は安定したシステム提供を優先するため、できるだけ変更したくないという考えになる。なぜならシステム障害の7割は変更により発生すると言われているからだ。
一方の開発側はビジネスサイドの要望に応えて、新しい機能をより早く提供したいと考える。つまり運用と開発ではそれぞれが求めるインセンティブが異なる。だからバランスを取ることが難しいのである。
信頼性とイノベーションスピードのバランスを取るためのカギを握る考え方が、SRE原則でうたわれている「リスクの受容」と「SLOの定義」である。「信頼性を定量化し、定量化された信頼性に基づき、開発と運用が同じ基準でリスクを管理する。こうすることで信頼性とイノベーションスピードのバランスを取ることができる」と藏本氏は説明する。
信頼性の定量化はSLI（サービスレベル指標）、SLO（サービスレベル目標）、エラー予算を定義することから始まる。SLIとはシステムの善しあしを判断するための指標である。SLOとはサービスレベルに対する内的な目標値で、SLIを基に定義される。エラー予算は許容できる不具合の割合で、1-SLOで表すことができる。「エラー予算を基にエラー予算ポリシーを定め、ポリシーに従って対応することで、開発、運用が同じ基準を用いたリスク管理を実行できる」（藏本氏）
効率的なサービス運用を考える
効率的なサービス運用とは、ソフトウェアエンジニアリングでシステム運用の問題を解決することであり、それが行える状態にあることを指す。
例えば煩雑で繰り返しの多い運用業務については、手動の手作業（トイル）を自動化することで撲滅していく。トイルをそのままにしておくと生産性が低下するだけではなく、キャリアの停滞、士気の低下につながるからだ。「Googleではトイルに費やされる時間を業務時間の50パーセント未満にすることを目指していると書かれています」（藏本氏）
またメンバーへの過負荷・属人化という問題に対しては、適切なモニタリングによりデータに基づき業務をハンドリング、過負荷を削減していく。システムのモニタリングに閉じずに、業務上のトイルの発生頻度やトイルに割かれている時間についても可視化し、データドリブンなハンドリングが行える状況を目指すことも含まれている。
「DatadogやPrometheus、Splunkなど、さまざまなサービスが提供されているが、組織にあったサービスを選定し、まずは見える化を進めていくことが大事だと思う」と藏本氏はアドバイスする。
さらにリリース作業の負担という問題は、信頼性の担保されたリリーススキームで軽減することで対応できる。なぜなら、多くの障害は人の手が加わることによって発生するからだ。Terraformを用いたIaC化、CicleCIなどを用いたCICDの導入など、構成管理やリリースエンジニアリングの仕組みを利用し、再現可能で自動化されたリリースプロセスを整備することが重要だ。
SREの効果をまとめると次のようになる。まずはシステムの状態ではなく、ユーザー影響に基づいて、監視を行うことで、不要なアラート対応の削減が見込めること。次にSLO定義・エラー予算の導入により、障害対応と機能開発間の優先順位を明文化し、開発と運用間で意識統一が測れるといった効果が得られること。そして手作業（トイル）を削減することで、本来実施したい作業にリソースを投下でき、ヒューマンエラーの削減による信頼性向上に寄与すること。最後にデータに基づいて、トイル解消など、取り組みの優先度を決めることができるため、納得感や、効率の向上が見込めることだ。
SREを組織に浸透させるためのアプローチ
このように多くの効果が得られるSREを、組織に浸透させていくのは一筋縄ではいかない。そこでスリーシェイクでは、SREチームの位置づけ・目的を定義することを、SREを組織に導入する最初のステップとして位置づけている。組織の役割が曖昧で、メンバーに目的が浸透していないと、期待通りの結果を得られない原因となるからだ。その上で、スリーシェイクではGoogleが提唱するアプローチにこだわらず、お客さまの現状を踏まえた導入アプローチを採用している。
SREを浸透させていくアプローチはわかったが、実際にどういうところからSREに着手すればよいのか、悩んでいる人も多い。藏本氏は実践内容例として、監視基盤導入、SLI/SLOの定義、運用体制整備、IaC（Infrastructure as Code）、CI/CDの導入、パフォーマンス分析などを挙げている。
「もちろん、これらをすべて一気に実践するのは無理がある。まずは小さく始めて、SREチームで成功体験を得ることが大事」と藏本氏。一つのプロダクトやサービスに展開して、成功すれば横展開していくのである。できれば新しいサービスで試すのが望ましいが、そう都合よく新しいサービスが生まれるわけではない。「既存サービスの中で、導入対象を選定し、小さく始めるのがベストプラクティスとなる」（藏本氏）
導入対象のサービスを選定した後は「当社ではSLI、SLO、エラー予算を定義することから始めることが多い」と藏本氏は話す。これらの定義を上質なものにするためには、ある程度目星をつけながら、とにかくデータを取得することがおすすめだ。メトリクスなどの収集は、上質なSLIやSLOの設定に使うだけではない。トイルの削減にもつながるからだ。
次はポストモーテムを実施する。ポストモーテムとは、インシデントとその影響、インシデントを軽減または解決するために取られたアクション、根本原因、およびインシデントの再発を防止するためのフォローアップアクションを書面で記録することである。適切な振り返りをするためには、障害解析に対して追跡ができるような仕組みが必要になる。そしてもう一つ大事なことは「特定個人を非難しない文化であること。つまり心理的安全性を担保していること」が重要だと藏本氏は言う。障害はシステマティックな問題や仕組みの問題だからだ。
組織へのSRE導入の難しさとして、例えば、SREを導入する対象が決済基盤など、SREのSLOやエラーを許容する考え方と相性が悪いケースもある。このようなケースの場合は、「このサービスについて、SLOによるハンドリングをストップし、別の領域にSREの導入を進めていくことは一つの手」と藏本氏は語る。先述したように、SRE導入には、小さく始めて効果の出やすい領域から実績を作って行くことが、何よりも大事だからだ。
さらに藏本氏はSRE人材の育成に関しても言及。SRE人材はOSやネットワーク、モニタリング、トラブルシュートなど、多くの技術スキルが求められる。さらに、関係する組織やアプリケーションの知識、関連システムの変更への対処方法など、提供サービス・システムに対するナレッジが必要になる。「これを一人の人間で満たすのは不可能に近い」と藏本氏は話す。
藏本氏たちがSREを導入する際は、理想的なチームを話し合って決めた上で、例えば、開発部門からSREチームに留学してもらう形でバーチャルチームを結成し、内部での運用について知ってもらうような対応を行っている。
とはいえ内製化や増員を考えるとSREを教育していく必要がある。その手法として藏本氏が注目しているのがオライリーの『SREの探究』という本で紹介されている「アクティブラーニング」である。アクティブラーニングとは座学ではなく生徒が能動的に考え、学習する教育方法で、同書ではアクティブラーニングの例としてロールプレイングゲームやカードゲームなどを活用した方法が紹介されている。「いずれの方法を用いるにしても、泥臭く障害やサービスを理解していくことが必要になる」と藏本氏。
最後に藏本氏は次のように参加者に呼びかけセッションを締めた。「Googleが提唱するSREは、現在サービスを運用する上で最適だと言われる方法論の一つ。SRE本の通りに実践することが真のゴールではない。SREのプラテクティスを自分たちなりに解釈し、組織にあったSREを手のつけやすいところから小さく始めていきましょう」
