SRE(サイトリライアビリティエンジニアリング)を読みました
仕事で意識することも多くなってきたので今更ながらSRE本を読みました。
書籍では大きな部とその中の章の構成となっており、ここでは部の簡潔なまとめを書きながら印象に残った章について軽くコメントをしていきます。
SREってどんな本?
この書籍はGoogleの中でSREと呼ばれる組織(あるいは活動)に関してまとめた書籍となっています。 SREはGoogleの持っている基盤の信頼性を高めるためのメソッドを一般化したり、それを助けるツールを開発したり、組織へ導入していったりと、基盤の信頼性向上を主目的とした活動のことです。 エンジニアリングの知識に留まらず、メソッドの一般化を行う抽象的な思考力、組織間でやりとりを行うソフトスキルなど幅広い能力が求められる職種であると言えます。 この書籍はそのSREについての原理原則とGoogleで行なっているより細かい実践的な手法をまとめた書籍となっており、これからSREを始めたい組織の方にはもちろん、すでに近しい活動をしておりそれをよりブラッシュアップしていきたい方にもおすすめの書籍です。
第I部 イントロダクション
第I部では「SREとは何か」「SREは何をするのか」をまとめています。
1章ではDevOpsの概念からSREへの変遷とSREが何をする活動なのかを書いています。
2章ではこの本の中では今後インフラはGoogleの基盤をベースに話していくので、そのためにGoogleの基盤の説明をするという章になっています。
1章 イントロダクション
IT界隈で2008年頃から言われているDevOpsという概念の中では、プロダクトのリリースサイクルを早めるために開発(Dev)と運用(Ops)を分けるのではなくより近い距離で手を組んで進めていく組織のあり方を説いているわけですが、現実問題としてDevは機能を追加して頻繁にリリースをしたいがOpsは安定運用のためにリリース頻度を過度にあげたくはないという対立構造を持っています。
著者はGoogleのおけるSREは「ソフトウェアエンジニアに運用チームを設計を依頼したときに出来上がるもの」と説明しています。理想的な姿として語られるDevOpsの概念を現実世界で実現するためにいくつかの拡張手段(エラーバジェットやポストモーテム)を追加し、それらを運用する仕組みをエンジニアリングで作り上げて解決していくのがGoogleにおけるSREです。
「ソフトウェアエンジニアに運用チームを設計を依頼したときに出来上がるもの」というニュアンスは、チームが大きくなったときにSREにかかるコストが線形に増加しないように自動化を駆使しながらSREを実行していく、というものだと私は捉えました。
そしてSREの中核的な信条として「エンジニアリングへの継続的な注力の保証」「サービスのSLOを下回ることなく、変更の速度の最大化を追求する」「モニタリング」「緊急対応」「変更管理」 「需要の予測とキャパシティプランニング」「プロビジョニング」「効率とパフォーマンス」をあげて個々に説明しています。
第II部 原則
第II部ではSREが扱うテーマ/原則について書かれています。
SREの重要な仕事であるサービスのリスク評価と受容、サービスレベル目標についてもここで説明されています。
トイルなタスクがあることがどのような影響を及ぼすのか、Googleでどのように自動化をしているかについて書かれているところはソフトウェアエンジニアが作る運用チームという部分のらしさが出ているように感じます。
SREが何をやっているのか、取り組むべき課題に対してどのような信条を持って臨んでいるのかを知りたい場合はこの部を読むとよいでしょう。
3章 リスクの受容
「Googleは、100%の信頼性を持つサービス、すなわち決して障害を起こすことがないサービスの構築に挑んでいると思われるかもしれません。しかし実際にはある一線を越えると、信頼性を向上させることはサービス(及びユーザー)にとって、むしろマイナスになることが分かっています。」とあるように、Googleでさえ絶対に障害を起こさない基盤の構築を目指しているわけではありません。
どのレベルの可用性を設定するかは提供するサービスに依存しますが、一例としてAdsではサービスから得られるリターンと設定する可用性レベルでのコストを考えて決定するやり方を紹介しています。
I部でも述べたDevチームとOpsチーム葛藤、すなわち「より早いスピードで機能開発を行いたいDevチーム」と「基盤を安定稼働させたいOpsチーム」という異なるメトリクスで評価されるチーム間の葛藤の解決策の一つとして「エラーバジェット」という仕組みを導入しています。
エラーバジェットとは、サービスごとに定められた可用性を損失可能な信頼性の予算として捉えて開発と運用のバランスを取る考え方です。
例えばSLOが99.999%で設定されているサービスがあるとき、エラーバジェットは0.001%となり、エラーバジェットが残っている期間であれば新しい機能のリリースを行うことができ、すでにない場合にはリリースは行わず安定運用に努めるといった形でエラーバジェットが運用されます。
4章 サービスレベル目標
サービスレベル指標(SLI)、サービスレベル目標(SLO)、サービスレベルアグリメント(SLA)の3つの区別
- SLI: 指標のこと。何をレベル評価の対象にするのか。よく使われるのはレイテンシやエラー率など
- SLO: 設定したSLIをどのレベルで提供するのかのターゲット値、あるいは範囲。自然な構造として「SLI <= ターゲット」や「下限 <= SLI <= 上限」のような形を取る
- SLA: ユーザーとの間で結ばれる契約。SLOを満たした場合に関する規定がここに記述される
これらを定義するときのアドバイスなどが書かれています。
5章 トイルの撲滅
SREの組織内でトイル作業に費やす作業が一定割合を超えないようにしよう。トイル作業が多いのはよくない。自動化で回避しよう。
第Ⅲ部 実践
第Ⅲ部では、Ⅱ部での概念的な話ではなく、Googleが実際に行なっているSREの内容をかなり細かく解説した内容となっています。
この本ではサービスの信頼性を必要性が高いものから積み上げていく階層構造として定義しています。
※書籍「Site Reliability Engineering」第Ⅲ部 実践の「サービスの信頼性の階層」より引用
各項目は実践的な内容ということでかなり細かいケースの話もあるので全部読むのはなかなか大変ですが、気になるトピックをしっかり読み込めば自分たちのSREに組み込めるノウハウが得られるはずです。
10章 時系列データからの実践的なアラート(モニタリング)
2003年頃採用していたBorgmonというモニタリングシステムの紹介とそれを使ったモニタリングのやり方を紹介しています。 Borgmonの細かいクエリなどはあまり参考になりませんが、アラートルールの構築、特にアラートは状態が頻繁に切り替わる「はためく」状態になることがあるため単なるエラー率の閾値だけで評価するだけでなく、それが継続されているかも合わせて評価するというところが面白かったです。 例示されたルールとして「10分間でのエラー率が1%を超えており、1秒あたりのエラー合計数が1より大きい場合にアラートが発行される」というものがありました。
12章 効果的なトラブルシューティング(インシデント対応/根本原因分析)
何らかの問題が発生した場合にその原因を追求し解決していく抽象的な考え方がまとめられています。 インフラ対応1年目のときに読みたかった。
14章 インシデント管理/15章 ポストモーテムの文化：失敗からの学び(インシデント対応/ポストモーテム)
顧客からインシデントが上がってきた際に一人で闇雲に対応するのではなく、インシデントとしてチームにあげ組織として対応することの大切さを解説しています。 また一度発生したインシデントをドキュメント化しチーム内で共有して再発防止を進めるポストモーテムの紹介もしています。 このポストモーテムはインシデントについて記述するのでネガティブな内容になりがちですが、それを非難するのではなく建設的に組織の知見として貯め込んでいく文化の形成についても触れており非常に参考になる内容となっています。
17章 信頼性のためのテスト
設定のテスト、ストレステスト、カナリアテスト、大規模な環境のためのテスト指南などがまとまっています。
18章 SREにおけるソフトウェアエンジニアリング(キャパシティプランニング)
インシデントベースのキャパシティプランニングについて、そしてそれを解決する社内ツールのAuxonの紹介です。 そしてそのツールを開発して組織の広めるまでの経験談です。
19章 フロントエンドにおけるロードバランシング/20章 データセンターでのロードバランシング/21章 過負荷への対応/22章 カスケード障害への対応(キャパシティプランニング)
これらの章では、流れてくる大量のクエリをどのようにさばいていくかを解説しています。 細かいロードバランシングのアルゴリズム、さらに負荷がかかり障害が起きる状態の解説なども行なっており、非常に参考になります。 (ただかなり実践的な細かい話が多いので実務で扱っていないと読みづらいかもしれません)
23章 クリティカルな状態の管理：信頼性のための分散合意(開発)
低速なネットワークや一部のメッセージが欠落するような不安定な環境下で、分散された処理が正しく処理をし続けるための分散合意の考え方の説明、およびそれの実装であるPaxosの解説をしている章です。 GCPのような複数のリージョンにまたがっているサービスにおいてデータの整合性を保つためにはこの分散合意の考え方が必要になります。 GCPの基盤ではこの分散合意の技術としてPaxosが使われており、サービスの一部が不安定になっても動き続けるための必須の技術となっています。
26章 データの完全性：What You Read Is What You Wrote(開発)
データの完全性を基盤としてどのレベルで担保すればよいのか述べた章です。 ユーザーにとってのデータの完全性とは、ユーザーがサービスにアクセスしたときに欲しいデータに触れることであり、逆にいうとそれを満たすことができれば24/365でデータの完全性を保つ必要はないとも解釈できると思います。 「 データの完全性とはクラウドのサービスがユーザーからアクセス可能であること。ユーザーからのデータアクセスは特に重要で、このアクセスは完全な形を保っていなければならない」「データの完全性をきわめて高くするための秘密は予防的な検出と素早い修復及び回復なのです。」というところに全て詰まっています。 そのためにデータのバックアップとそこからの素早い修復を常に準備し練習しておくことが重要となってきます。 データの完全性に対するSREの一般原則として「初心者の心構えを忘れないこと」「信頼しつつも検証を」「願望は戦略にあらず」「多層防御」を挙げています。
27章 大規模なプロダクトのローンチにおける信頼性(開発)
サービスのローンチ(=外部から目に見えるコードの変更があること)に対して、その品質を評価し組織間の調整を専門として動くローンチ調整エンジニア(LCE)の導入をしています。
第Ⅳ部 管理
最後のこのⅣ部では、チーム内で共同作業をすること、チームとして仕事をすることにフォーカスした話をしています。 30章では負荷が高まっているチームに対してSREを投入していくプロセスを紹介しており、SREを導入していきたい組織には参考になる情報が多いと思います。
まとめ
自分で学びがあった部分にフォーカスしながら SRE本で得たことをまとめてみました。 これを読んだ方が興味を持ってSRE本を読み始めて頂けたら幸いです。
