Google SRE本を読んだ

  #book

やっとこさ読み終わったので、読む前に感じていた疑問を含めつつ感想などを書いておく。

SREってなんだろう

ユーザに価値を最速かつ継続的に提供することを目的に添えた、開発もできる運用部隊。
価値を素早く提供するためには、インフラなどプロダクトチーム以外のリソースが制約事項になってはいけない。ということで人的リソースの制約を乗り越え、SREの価値をスケーラブルにするため自動化・自律化・マイクロサービス化などを積極的に行う。ナレッジに関してもスケールするよう明文化・定量化を徹底し、エンジニアが暗黙的・良心で行っていることを明らかにして組織的に取り組む。

インフラエンジニア・チームと何が違うのか

企業文化や規模によって、インフラエンジニアの業務範囲は大きく異なるので一概には説明できない。既にインフラチームがSREとして機能している会社もあれば、ハードウェアの保守だけしている会社だってある。立ち上げ間もないベンチャーはミドルウェアから下のレイヤはすべて見ていることもあるし、そんな場合は大体SRE的な働き方をしているかもしれない。ただしそんなベンチャーの場合、スピード最優先なのでドキュメント化されていない暗黙知が満載だったり、がっつり属人化していたりするので人的リソースはスケールしていない。

仮にインフラチームを「ミドルウェアから下のレイヤを、全サービス横断して見る人達」として、SREは何が違うか考えてみる。
プレイヤーなエンジニアは、開発する時間を捻出することに意識が向いている。運用と並行して開発を行うので、とにかく時間が足りない。小さな自働化から始め、減らせた運用コストを次の開発に当て更に自働化を拡大する。その先はベストプラクティスを実践するためのフレームワークだったりマイクロサービスだったりもする。
マネージャは、人的リソースをスケールできるように組織をデザインし、チーム外との協力関係を獲得する。

この辺りを意識する必要がある。マネジメントを考えると結構インフラチームとSREは違うなぁ。

では、SREはインフラエンジニアの上位互換かというとそうでもない気がする。雑に言えばSREはものすごい知識量のジェネラリストなので、特定分野のスペシャリストではない。ミドルウェアやネットワーク、ハードウェア、セキュリティなどなどスペシャリストがいるインフラって素敵じゃん。なので「SREの活躍でインフラエンジニア不要にするぞい！」というのは個人的には違うんじゃないかなと思う。

DevOpsと何が違うのか

手段が同じということはあるけど目的が違う。DevOpsも定義がふわっとしているが、運用を楽にするというのが目的。SREはユーザにサービスを早く・継続的に提供するというのが目的。どちらも自動化はやるが、人的リソースのスケールやキャパシティプランニングはDevOpsでは扱わないんじゃないかな。

印象的だったこと

「絶対に落とさない」からの脱却

サービスに関わる人間は絶対にサービスを落とさないという気持ちで日々運用している。が、障害は起きるものだし、仮に自社サービスが可用性100%だとしてもユーザへ届く経路上でどうしても可用性は落ちてしまう。
ならばサービスで必要十分な可用性のレベル・SLOを定義して、貴重な人的リソースを過剰に消費しないようにしましょうという戦略がとられる。SLOは高ければ高いほど好ましいが、それだけコストがかかる。90%を99%にするコストに比べ、99.9%を99.99%にするコストはとても高い。

ここまでは一般的な話だが、SREでは可用性を過剰に達成しすぎてもダメだという考え方をしている。可用性を必要十分に抑えることで2つの利点が生まれる。

1つ目は過剰に達成している分を、「本来障害が起きるはずだったんだから、リスクのある挑戦をして障害が起きてもいいよね」と、挑戦の機会として扱えること。ミドルウェアのバージョンアップや依存システムの移行など、システムのレガシー化を防ぐことができ、メンテナンスコストの低下にもつながる。

2つ目は依存しているサービスに対して、依存元のSLOを織り込んだ設計を強制できること。依存先が依存元よりもSLOが低く、一蓮托生と割り切るのであればそれもよし。そうでないなら落ちることを織り込んだリトライ処理や、重要度の低いデータを破棄・遅延させるなど対策が必要になる。依存元は過剰な信頼をされることもなく、依存先の可用性も上がり、サービスも組織も健全になる。

アラートレベルを使い分ける

モニタリングの出力は以下3種ある。

ページは日中深夜問わず鳴ったら最後、全ての作業を投げ捨て最優先で対応しなければならない。それだけに心身共に削られるページはむやみやたらに飛ばさない。
大原則としてユーザ影響があるものはページを飛ばし、なければチケットなりログに落とすだけで良い。ユーザ影響を知るためにホワイトボックスモニタリングだけでなく、ブラックボックスでのモニタリングが重要になる。

サーバが落ちたらページを飛ばすのは一般的だが、冗長化されていてそこにリクエストが振られないのであればページを鳴らす必要はない。ウェブサーバのディスクが逼迫していても、ロードバランサから抜いてしまえば問題ない。

障害が起きたら再発防止を行って、着実にページを減らしていく。ホワイトボックスモニタリングで検知されるものは、システムを自動化・自律化させ排除していく。ただし、簡単なブラックボックスモニタリングではリクエスト先の引きの問題もあるので、各種ヘルスチェック機構も充実させる必要がある。もちろん観測できていないのは問題外。

SREとGCP

GoogleはSREの価値を全力でスケールさせる。
SREの価値をスケールさせる上で、SREエンジニアの人数に制限されてはいけない。最大公約数やベストプラクティスを見つけ出しドキュメント化する。そして実装可能なものに解釈し、ライブラリやフレームワーク、(マイクロ)サービスとして実装・提供する。それらを利用するだけでSREの価値を享受できる。そしてこれをさらにスケールさせて社外に飛び出したのがGCPになる。言ってしまえばGCPはSRE as a Serviceみたいな感じじゃなかろうか。

Googleで実際に使っているという点でGCPとAWSは思想が異なる。AWSも確かにAmazonで使われているが、全てのサービスを使っているかは怪しい気がする。ユーザリクエストを募集して、投票数の高いものをサービス化したりもしているわけだし。自社で利用しているものとユーザが求めたものが混在しているのがAWS。自社で利用しているものだけが存在しているのがGCP。という印象、実際は違うかもしれない。

SREを実践するとしたら考えること

SREを理解するためのシミュレーション

本に書かれたことを始めから全てやるのは無理なので、優先度を付けて取り組んでいくことになる。
仮に次のような状況を設定して、どうやって取り組んでいくか考えてみると具体的なアクションが見えてくるんじゃなかろうか。

小さく始めるSRE

SREを始めるにあたってぶつかる最初の難題は、SLOとかエラーバジェットの定義が難しい点じゃなかろうか。全くSREに馴染みのない状態から、お試しでやってみるのであれば、ページ件数と対応時間を指標に使ってみるのも良いと思う。重要なのはSREとプロダクトチームで利害を一致させ、その利益をユーザが受ける構造にすること。自分たちのサービスレベルを知るために起きた障害の振り返りを定例化して確認していく。取り組み方や思想の共有ができてきてから、SLOやエラーバジェットは調整していけばいいんじゃないかな。

そもそもいきなりプロダクトチームを巻き込むのすら気が引ける、もっと小さく始めたいという場合、上記のページ件数を指標にしてインフラチーム内で実施してみるのも意味はあると思う。ミドルウェアなレイヤのページ削減や自動化・自律化はある程度インフラ内だけでも実施できる。ただし、独りよがりなエラーバジェットを掲げて「あいつらいつも障害起こしてんな」と見られる危険もあるので、やはりプロダクトチームと一緒にやったほうが良いのは変わらない。

最後に

「SREを設立します!」ってなんか流行に乗っているみたいで恥ずかしくない?

個人的にバズワードに乗っかっているミーハー感は感じつつも、個人で取り組むものではないので、組織としてアピールするのは間違ってはいないと思う。組織的にちゃんと取り組む、インフラエンジニアの良心に過剰に依存しないという宣言でもあるはず。少なくとも分析チームが既にあるのに「ビッグデータチームを設立します!!」よりはよっぽど意味がある。

インフラエンジニアの生存戦略として

インフラエンジニアであり、ソフトウェアエンジニアでありたいと願う人が健全に働くには、を組織的にデザインしたのがSREという印象。なのでそんな人にはとても魅力的な経験・環境なんじゃなかろうか。日中定常業務をして、人が減った夜に開発をするという黒い環境ではなく、日中に腰を据えて開発できる環境を一緒に捻出していきましょうとアプローチしてくれるのだから嬉しいったらないね!!