SRE実践の手引 ─ 信頼性をどう制御するか？ から始める、現実的な指標と目標の設計と計測
SREの役割には、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといった複数のキーワードが存在するがゆえ、なかなかうまく実践できない、という声もあります。本稿では、難しく見られがちなSREの内実を、「信頼性の制御」というコンセプトを軸に整理し、小さく始める一歩を坪内佑樹（ゆううき）さんが解説します。
275
こんにちは。SREの研究者をやっているゆううき（@yuuk1t）です。
SRE（Site Reliability Engineering）は、従来のオペレーションエンジニア、システム管理者（sysadmin）と呼ばれる人々が担っていた技術領域の新しい形です。Googleによって提唱され、日本国内でも2015年ごろからWebコンテンツ事業者のコミュニティを中心に広く知られるようになりました。SREを学ぶために書籍やWeb記事を読んだものの、いざ実践しようとしたときに何から始めればよいか分からないという方は意外と多いのではないでしょうか。
本記事では、信頼性、SLIとSLO、エラーバジェット、トイル、ソフトウェアエンジニアリングといったSREにおける各種キーワードを、「信頼性の制御」というコンセプトを軸として整理した上で、これから本格的にSREを始めるための最初の一歩を紹介します。
SREとは何か？ なぜ始めることが難しいのか？
SREが何であるかということは、SREが取り扱う話題が広範にわたることから、意外と説明が難しいのではないでしょうか。SREの原点とも言える書籍『SRE サイトリライアビリティエンジニアリング』{$annotation_1}（以降では「SRE本」とする）でも、「はじめに」の章には次のように書かれており、名前だけからSREが指す内容までは分からないと言えます。
それでは、サイトリライアビリティエンジニアリング（SRE）とはいったい何なのでしょうか。この名前が、その内容をはっきりとは表現できていないことは認めざるをえません。
これまで著者は、SREとはReliability、つまり信頼性を向上する技術であるという説明をしていたことがあります。サービスの信頼性は高いに越したことはないため、サービス提供者は当然信頼性をより高くしようとします。信頼性を高くするには、信頼性を損ねる要因であるヒューマンエラーやソフトウェアのエラーを防がなければなりません。
ヒューマンエラーを防ぐ最も手っ取り早い手段は、システムに変更を加えないことです。ソフトウェアのエラーについても、ソフトウェアの更新により予期せぬエラーが発生することがあるため、ソフトウェアを更新しないことで、エラーの発生を防げてしまいます。
しかし、ソフトウェアを更新しなければ脆弱性が残り、ソフトウェアの実行効率も向上せず、新しい機能も使えないという困った状態になります。加えて、システムを変更しないということは自動化もされないため、システム管理者は手作業に多くの時間を費やすことになります。その結果、長期的に見ると、気づかないうちにユーザーにも不便を強いることになり、別の新しいサービスに乗り換えられてしまうことにつながるでしょう。
そこで、信頼性とシステムに変更を加える速度を、長期的に両立することが必要となってきます。「SRE本」では、100%の信頼性を達成することは非現実的であり、目標として目指すものではなく、プロダクトが必要とする信頼性を達成すればよいとされています。
そこで、信頼性の目標値を設定し、目標を過剰達成せず、リスクを取って、変更速度を向上させていくという考え方が有効となります。したがって、SREとは信頼性を高める技術というよりは、むしろ信頼性を制御する技術と言えます。
どのような情報システムや組織に有効か？
SREにおける信頼性を制御する手法は、どのような情報システムに対しても有効であるというわけではありません。
前述のようにシステムを変更し続けることが前提となるため、パッケージソフトウェアのようにソフトウェアのライフサイクルが製品を納品して完了するものではなく、ユーザーが利用しながらも変更を続けていくような情報システムにSREはフォーカスしています。
また、100%の信頼性を目指さないことから、人命に直接関わるような100%の信頼性を求められる情報システムには向かず、エラーを許容可能なシステムに対して有効です。
例えば、Webサービスやクラウド・ホスティングサービスは、リリースした後にも継続的に開発を続けて運用することを前提としており、直接的に人命に関わることもあまりないため、SREが有効と言えます。
ただし、情報システムは広く利用されるほど、暗黙的に高い信頼性が求められ、自分たちが提供するシステムも100%の信頼性を提供しなければならないと思い込んでしまうことがあります。このような非常に高い信頼性を求めがちな傾向を踏まえて、限定的でもよいのでエラーを許容できないかと模索することが、変更速度の向上につながります。
また、このような情報システムの性質に加えて、エラーを許容することが前提となることから、サービスを開発する組織に失敗を許容する組織文化があることが、SREの実践には必要です。
システムを絶対に停止させてはいけないような圧力があったり、障害が発生するたびに再発防止のルールが増えたりする組織では、障害を恐れたり、障害発生後の事後処理が面倒になってしまって、変更速度がどんどん低下してしまいます。
SREがアプローチする問題意識は何か？
SREが有効なシステムにおいて、SREは具体的にどのような問題意識にアプローチするのでしょうか。筆者は次の3つが、SREがアプローチする主要な問題意識であると考えています。
- (a) 信頼性が、要求される水準に達していない
- (b) データセンターまたはクラウドサービスの利用料金が高い
- (c) サービス開発やサービスを支える基盤の変更速度が向上しない
(a)の問題意識はサービスの利用者から直接観測できるため、利用者から解決を要求されることも多いでしょう。(b)の問題意識についても、料金は定量的に観測しやすいため、費用削減が要求されやすい性質があります。したがって、一般に(a)と(b)は解決に向けてアプローチされやすく、それだけ解決の手段にもこれまで数多くの議論がなされています。
一方で(c)の問題意識は、変更速度が向上していないことにより、古いバージョンのソフトウェアや減価償却済みのハードウェアを使い続けていたり、単一障害点が残り続けていたり、新システムに部分的に移行できないままだったりするような状態で表出します。開発速度や変更速度の定量化が難しく、実際に開発や運用に携わるエンジニアにしか感じられないことから、なかなか解決に向けてアプローチしづらいものです。
ここでは、アプローチしづらい分、議論が少ない(c)の問題意識にフォーカスを当てることにします。
SREを実践するとはどういうことか？
(c)の問題意識を持つ要因として一般に挙げられるのが、手作業による日々のメンテナンスや、割り込みから始まるシステムアラートへの対応など、トイル（toil）と呼ばれる作業が大量に発生している状況です。
トイルを削減して変更速度を向上するには、オペレーションの自動化が必要となり、SREがソフトウェアエンジニアリングに注力する必要があります。オペレーションの自動化が進むと、システムの障害に素早く気づいたり、障害からすぐに復旧できるようになるため、結果的に信頼性を高めることにもつながります。「SRE本」ではSREの時間のうち、エンジニアリング作業に最低50%の時間を充てることを提案しています。
しかし、ソフトウェアエンジニアリングに時間を割り当てるといっても、現在目の前にあるトイルやその他の仕事が消えるわけではないため、すぐに実践することが難しいケースもあるでしょう。
また、ソフトウェアを自動化すると、ソフトウェア自体にバグがあったり、想定外の挙動をする可能性がでてきます。そのため、信頼性を低下させる恐れが生まれ、自動化に対して億劫になることもあり得ます。
そこで、トイルを削減するには、サービスにとって必要となる信頼性の指標と目標を明確に設定し、目標を下回らなければリスクを取ってよいとする仕組みをつくることが有効です。
SREの世界では、サービスの信頼性レベルの指標をSLI（Service Level Indicator）、指標に対する目標値をSLO（Service Level Objective）と呼びます。このSLIとSLOは、四半期などの一定期間ごとに設定するのが通例です。
SLIとSLOにより、信頼性の予算（バジェット）を期間内にどれだけ消費したかを計測しておき、予算の残量に応じて、どれだけリスクを取って変更してよいかを定量的に判断できます。このような仕組みを、SREの用語で「エラーバジェット」と呼びます。
このように信頼性を計測し、エラーバジェットにより信頼性を制御し、変更速度を向上できていれば、SREを実践していると言えるでしょう。
SREを始める難しさはどこにあるのか？
ここまでの話で、SREを実践することは一見すると簡単そうですが、一体どこに難しさがあるのでしょうか。SREを始める難しさとして、ここでは次の3点を挙げます。
- 計測可能なSLIの設計
- 適切なSLOの設定
- トイルまたは変更速度の計測
まず、計測可能なSLIの設計についてですが、Webや書籍で良いとされているSLIには、計測のための仕組みが追加で必要となり、これが難しい点です。
書籍『The Site Reliability Workbook』{$annotation_2}などで紹介されているSLIは、リクエスト駆動のシステムの場合、SLO期間内のリクエストの総数の中から特定の条件を満たしたリクエストの割合を計測する必要があります。特定の条件とは、例えばHTTPの200系の成功応答であることや、計測ウィンドウ内のHTTPリクエスト数の95パーセンタイルの応答時間が500ms以下であるといったものです。
この計測を実現するには、リクエストのログをなんらかのデータベースに保存し、解析するシステムが必要となります。したがって、信頼性を計測するには、ログ解析システムを構築する手間が増え、SREの実践を気軽に開始しづらくなります。
ただし、エムスリーの事例{$annotation_5}のように、もしすでにElasticsearchなどのデータストアにログを保存しているのであれば、リクエスト単位のSLIを設定するとよいでしょう。
次に、適切なSLOの設定についてです。SLOを大きくしすぎれば、予算が少なくなり、リスクを取れなくなります。逆にSLOを小さくしすぎると、ユーザーの体験を損なってしまいます。エラーバジェットが導入されていれば、予算があるだけリスクを取るため、SLOを過剰達成することは期待しないことになります。したがって、大きすぎず、小さすぎない値を設定しなければならない難しさがあります。
最後に、トイルの計測の難しさについてです。SRE実践の効果を測定をするために、トイルがどの程度削減されたか、つまり変更速度がどの程度向上したかを確認する必要があります。しかし、トイルはあらかじめ計画されたものではなく、割り込みにより発生するため、トイルにどの程度時間を割いたのかを直接計測することは難しいです。
また、タスク全体としてはトイルではなくても、部分的に繰り返し作業が含まれていたりするなど、トイルを内包していることもあります。タスク全体のうち、トイルに要した時間のみを計測することは難しいでしょう。
このように、SREを始める難しさの要因は、システム構築の手間はもちろん、エンジニアや単一チームだけではコントロールできない課題、タスク管理にまで及びます。
難しさを踏まえてSREを始める方法
エンジニアHubに会員登録すると
続きをお読みいただけます（無料）。
続きをお読みいただけます（無料）。
登録ボタンを押すと、利用規約とプライバシーポリシーに同意したことになります。
登録のメリット
- すべての過去記事を読める
- 過去のウェビナー動画を
視聴できる - 企業やエージェントから
スカウトが届く