こんにちは、 「Assured」でソフトウェア・エンジニアと翻訳をしているオリバーです。コロナで増えた体重がなかなか減らないこの頃です。今回は、Google CloudのカスタマーエンジニアによるSRE勉強会に参加してきました。スタートアップフェーズにある「Assured」でも活用できそうな学びが多数あり、個人的にはとても嬉しい機会だったのでレポートにしました。
SRE勉強会の概要
今回のSRE勉強会は、Google Cloud が開催する Site Reliability Engineering の入門的なイベントです。Visional グループ各事業部の開発チームから参加者を募り、クローズドなイベントとして開催いただきました。内容としてはSRE の基本的な考え方と Google における SRE の取り組みについて解説していただくプレゼンテーションを中心とした、2時間半のプログラムでした。
当日は、弊社から30人弱が参加し、 渋谷ストリームのGoogle オフィス入り口を埋めました。
SRE勉強会のハイライト
SRE の原則
SRE (Site Reliability Engineering) とは、その言葉の通りシステムの信頼性に重きをおいたシステム運用におけるアプローチです。当日のセッションでは、まず始めに SRE における「信頼性」とはなにか、どういうスタンスでエンジニアリングに望むべきかを説明いただきました。
原則1. いかなるシステムにおいて最も重要な機能は、信頼性である
「すごく魅力的な写真が取れるけど画質が安定しないカメラ」と「普通の写真だけど安定して撮れるカメラ」、どちらをユーザーが欲しがるか。ちゃんとこの瞬間を残せるものを選ぶ人も多いはずです。このように、信頼性は機能と比べても重要なものである、ということです。
原則2. 監視が信頼性を決めるのではない。ユーザーが決めるのだ
サーバーが稼働していて、監視システムでもすべてがグリーンになっている。それでもユーザーがサービスを利用できない状態であれば、それは正しく信頼できるシステムとはいえない、ということです。
原則3. 理想の Five-Nine (99.999% の可用性) を達成するには
巧妙に設計されたソフトウェアは 99.9%
巧妙に設計された運用は 99.99%
巧妙に設計されたビジネスは 99.999%
99.999%の可用性とはつまり、30日間で25秒間のみダウンタイムを許すということです。これを達成するのは言わずもがな非常に難しいです。
上記の引用は、うまくできたソフトウェアであれば99.9%の可用性を達成できるが、その上の99.99%の可用性を達成するには、運用のなかでトラブルをうまく回避・対処できる必要があり、さらにその上の99.999%の可用性を達成するには、それを達成するためのコストに見合うビジネスである必要がある、ということを表しています。
DevOps と SRE の関係
セッションでは、混乱しがちな DevOps と SRE という2つの言葉の関係性についても説明がありました。
Google 社では、運用のSREとDevOps を 「class SRE implements DevOps」 と定義しているそうです。つまりDevOps とは、開発や運用上における齟齬やサイロ化を解消するために作られた慣行、ガイドライン（=インターフェース）であり、SRE はそれをうまく実践するための手法や役割（=実装）である、ということです。
セッション中では DevOps における5つの主要な関心事を紹介いただき、それらを SRE としてどう実践しているかが紹介されました。
| DevOps | SRE |
|---|---|
| 組織の壁を減らす | 同じツール、同じ手法を使う |
| 失敗を普通のこととして受け入れる | エラー予算を設定する |
| 段階的に変更を加える | 失敗のコストを下げる |
| ツールと自動化を活用する | 手作業を自動化することを推奨する |
| すべて測る | 運用はソフトウェア工学の問題ととらえ、トイルも信頼性も定量化する |
「class SRE implements DevOps」 のお話については、Visional Engineering Blog の過去記事でも詳しくご紹介していますのでご覧ください。
サービスレベルの定義: SLI/SLO/SLA
セッションでは、SREの指標としてよく使われる、SLI・SLO・SLAの定義についても説明がありました。
| SLI: Service Level Index | サービスレベル指標。サービスの動作を直接測定した結果であり、サービスが機能していることを示す指標 |
| SLO: Service Level Objective | サービスレベル目標。成功したインタラクションの割合に対して設定された目標。 |
| SLA: Service Level Agreement | サービスレベル保証。ビジネス上の結果（補償等）を伴うユーザーとの契約や取り決め。 |
SLI/SLOを検討する際は、簡単に測定できる数値ではなく、ユーザーが気にすることを測定するのが最も望ましいそうですが、数値化するのが難しい場合は「ユーザーが気にすること」に類似する指標を設定しても良い、とのことでした。SLOはプロダクトとビジネスの双方に関係するため、純粋なシステムのパフォーマンスなどのSLIを指標にする必要はなく、目的、用途、サービスやプロダクトの特性に合わせてSLOの条件を選別し追跡して指標を定めていくのが良いそうです。セッション内でもSLOのターゲットの選定などについて説明がありましたが、SRE本の中で詳しい説明があります。
SLI/SLOを定義することでサービスの期待値が明確になると同時に、「SLO は上からのターゲットでもあり、下からのターゲットでもある」であるため、過度に高いSLOはお客様の期待値にズレを生じさせてしまいます。サービスにそぐわないSLOにお客様が慣れてしまうと多少のダウンタイムでも想像以上に大きな影響を引き起こすことがあるそうです。Google Cloud の記事でも以下のような記載があります。
Google では、可用性を過度に高めないようにするため、一部のサービスで定期的にダウンタイムを実施するようにしています。
また、このセッション中では他に、クリティカルユーザージャーニー（CUJ）に関する説明もありました。クリティカルユーザージャーニーとは、ビジネス上インパクトのあるユーザージャーニーのことで、SLOを定めるにあたっては最初にこのCUJを作成する、という手順を踏むのだそうです。システムのことだけを見るのではないのだと少し意外でもあり、先ほどの「ユーザーが信頼性を決める」という原則にも繋がる良いプラクティスだと感じました。
クリティカルユーザージャーニーからSLOを定める流れについては、以下のブログ記事が詳しいのでおすすめです。 Learn how to set SLOs -- SRE tips | Google Cloud Blog
リスク分析
問題が起きてしまったあとのリスク分析をどのように行うのか、セッション中に説明がありました。
説明の中では、特にインシデントなどの対応中においては、「人間の脳は、リスクの比較と評価において信頼できないということが知られており、間違った評価・分類をしてしまう」というお話もありとても印象的でした。
そういった背景もあり、Google ではリスクを定量的・客観的に分析できるフレームワークとして、以下のような指標を用いているそうです。
| ETTD: Estimated Time To Detection | リスクが発生したことを検知するまでの推定時間 |
| ETTR: Estimated Time To Resolution | 人が通知を受けてからリスクを解決するまでの推定時間 |
| ETTF: Estimated Time To Failure | 発生するリスクの推定頻度 |
このような指標を定義し「検知するまでの時間（ETTD）」と「解決するまでの時間（ETTR）」が実際のユーザーへの影響した時間を分類することで、数値化した定量的なデータをリスク分析しているそうです。
また、こうした定量的なデータを用いて、他のチームと共有、相談することで継続的な改善やError Budgetの見直しにもつなげているようです。Google では、このようなリスク分析のためのテンプレートをスプレッドシートで公開しています。
まとめ
現在、Google 社は1日あたり40億のコンテナ、10億のエンドユーザーを抱えるサービスを運営しているそうです。その巨大なサービスは、3000人の SRE によって「信頼を保証」されています。そこで生まれた文化やシステムの知見を共有していただける、とても貴重な機会でした。
最近社外報で紹介しましたが、「Assured」でもポストモーテムをゆるりとはじめていたこともあり、今回のワークショップでは個人的に以下の二点がとても印象に残っています。
- 心理的安全性の確保と徹底したデータ駆動
- リスクを客観的に分析することの必要性
自分が普段の運用のなかでポストモーテムを書くにしても、「心理的安全性」は意識できているものの、「データ駆動」に関してはまだまだすべての数値をデータ化できていないと感じます。そのうえでリスク分析についても、今回教えていただいたようなリスク評価のフレームワークを活用することができそうなので、ぜひトライしてみたいと思います :)
この記事で紹介した SRE に関する考え方は、Googleが公開している書籍でも学ぶことができます。より詳しく勉強してみたい方はぜひご覧ください。
「Assured」のチームにはまだ専任のSREはいませんが、副業などで関わっていただいている方がおります。少しでも我々のチームやエンジニアリングの取り組みに興味を持っていただけたなら、ぜひお気軽にカジュアル面談にお申し込みいただければ幸いです。
エンジニアチーム紹介ページ
カジュアル面談フォーム
最後に、この文章にアドバイスと訂正をしてくれたチームへ感謝 ;) “Thanks for the wonderful engineer and PR teams, who have reviewed, revised and helped editing.”
