この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
はじめに
筆者が入社した直後 2017/4 吉日に、弊社 IT 推進室長の植木（当時、オペレーションチームの部長）が「SRE 勉強会するよ」という発言に端を欲し各自英語版を翻訳した資料を持ち寄り全９回の SRE 勉強会が 2017/5/11 より開始されました。本勉強会のアウトプットとして、本ブログを執筆します。
なお、本ブログ記事はSRE 勉強会の対象となった第１章〜第９章まで（第２章を除く）を要約した形でお届けし、SRE を知るきっかけとなれば幸いであると考えております。そのため、興味をお持ち頂いた読者の方々は下記のオンライン本もしくは翻訳本のいずれかをお手に取って頂き、その詳細について学んで頂ければと思います。
SRE とは
誤解を恐れずにざっくり説明すると、以下になります。
- Site Reliability Engineer
Google 社が開発しているサービスや製品が徐々にスケールしていく過程において、システム管理者の役割が従来のものから変化していく中で、改めて見直されたシステム管理者としての新しい役割。また、その役割を担うエンジニア
- Site Reliability Engineering
スケールしていくサービスを高い信頼性で、かつ出来る限り低コストで運用するために行うこと。また、構築や開発と運用を対立させずにサービスをリリースするための方法や、その考え方など
なお、上記はあくまでも個人の所感となります。（厳密な定義は、無いんじゃないかと思われます）
SRE 本について
世間では、DevOps という概念が時間を掛けようやく定着し始めておりますが Google が提唱し始めた SRE と呼ぶサービス運用の新しい方法も無料のオンライン本が公開されたことによって広がりを見せ始めているような気がします。Google 社では 2003年に最初の SRE チームが結成されて以来、数多くのサービスで様々な課題を解決し、その経験に基づくベストプラクティスがここで紹介する書籍に纏められております。
オンライン本は、以下からアクセスできます。（英語のみ）
また、O'Reilly Japan 社から翻訳本が出版されたことで英語が苦手な方（筆者含む）も学び易い状況になったと感じます。
原著の著者、出版関係者の方々および翻訳者の方々へはこの場を借りて心よりお礼を申し上げます。（筆者も翻訳本を購入させて頂きました。）
序章
「願望は戦略にあらず」
「開発（Dev）」と「運用（Ops）」というチーム体制に分けられた環境での、これまでのシステム管理者のアプローチに対するデメリットと 問題点について言及しています。要約すると、新機能をリリースしたい「Dev」チームとシステムを安定稼働させたい「Ops」チームとの 終わりのない対立が起こるという問題点を指摘しています。Google はこれに対し、「Ops」に替わる自動化を前提としたシステムを構築する エンジニア（つまり、SRE）のチームを編成し、「Dev」チームと一丸となって最終的に自律的（自動的に自己修復するような）システムを構築することで対処しています。これまでのアプローチとは異なる目標を設定することにより、チーム間の対立構造を解決したようです。
２章 SRE の観点から見た Google のプロダクション環境
Google のプロダクション環境が紹介されている章であるため、勉強会ではスキップさせて頂きました。 翻訳本を手に入れたので読み進めてみたところ、用語を説明するために Google 内部の仕組みが紹介されています。 例えば、３章以降で頻出する Borg（Google のクラスタオペレーティングシステム）の説明などが記載されています。 ＃Borg の子孫が Kubernetes にあたります。
３章 リスクの受容
サービスの信頼性に関して「可用性におけるリスク」と「イノベーションの速度およびサービス運用の効率性」という視点でバランスが大事だということが述べられています。サービスリスクを、そのサービスにより行われているビジネスリスクと意識的に合わせることで必要以上の信頼性を高めようとはせず、「機能追加」や「技術的な負債の払拭」、「運用コストの低減」を行う機会を手に入れるメリットが得られるようです。 そのためにはまず、サービスリスクを計測し許容度を特定する必要があります。リスク許容度を明確化するには、サービスに対して以下の項目を考慮していきます。
- 可用性のターゲットレベル
- 障害の種類
- コスト
- 可用性以外のメトリクス（例えば、リクエストに対するレイテンシなど）
次に、「Dev」チームと「SRE」チームの意見の相違に対してリスクと労力の線引きが必要になりますが客観的なメトリクスを定義しデータに基づいた判断を持って、両者に合意して貰うためにサービスレベル目標（一般的に SLO と呼ばれるもの）に基づくエラーバジェットを規定するようです。エラーバジェットとは、サービスの信頼性がどの程度損なわれても許容できるかを示す明確で客観的なメトリクスを示しています。
例えば、以下のような状況です。
- プロダクトマネージャーが SLO を規定。四半期内で期待されるサービスの稼働時間が設定されます。
- 実際の稼働時間は、中立な第三者であるモニタリングシステムによって計測されます。
- 上の２つの値の差異が、四半期内の「損失可能な信頼性」という「予算（バジェット）」の残りになります。
- 計測された稼働時間が SLO を超えていれば（つまりエラーバジェットが余っているなら）、「Dev」チームは新しいリリースをプッシュできます。
エラーバジェットを規定するメリットは、「Dev」チームと「SRE」チーム両者に共通の目標を設定することであると述べられています。 これにより、リリース頻度の判断やサービス障害に関する議論を効果的に落ち着かせることができるようです。
４章 サービスレベル目標
SLI（サービスレベル指標）、SLO（サービスレベル目標）、SLA（サービスレベルアグリーメント）を定義した上で、計測し評価を行う重要性を述べています。各定義に対する一般的な計測対象を示します。
- SLI ... リクエストのレイテンシ、エラー率やシステムスループットおよび可用性や耐久性
- SLO ... SLI で計測されるサービスレベルのターゲット値、あるいはターゲット値の範囲
- SLA ... ユーザーとの間で結ぶ、明示的、あるいは暗黙の契約（SLO が満たされなかった時にどうなるか？という質問に対して、明確な規定がない場合 SLA ではなく、SLO である）
特定のサービスが SLA を持っているか否かに関わらず SLI/SLO を定義し、その下でサービスを管理することには価値があると述べられています。なお、SLI として選択すべきメトリクスはサービス提供者およびユーザーの関心事を設定すべきであり SLO は、ユーザーの関心事から計測することが好ましいと述べられています。たくさんある指標の中から注意を払い、計測すべき指標を取捨選択しましょう。例えば以下のように、提供するサービスによって計測すべき指標は異なります。
- ユーザーとやりとりするサーバーシステム ... 可用性、レイテンシ、スループット
- ストレージシステム ... レイテンシ、可用性、耐久性
- ビッグデータシステム ... スループット、エンドツーエンドのレイテンシ
さいごに
全９回におよぶ勉強会の内容を要約しても、相応の文章量となるため前編というかたちで区切らせて頂きました。 後編では本勉強会で一番盛り上がったであろう「５章 トイルの撲滅」から始まります。
ご興味ありましたら、是非後編もご一読ください。
ではでは
1
