クラウドネイティブ｜知る×学ぶ技術・機能解説、ノウハウ｜クラウドネイティブ
SREとは｜サイト信頼性エンジニアリングに必要な人材やスキルとは
「新たな機能や改善された機能を短いサイクルでリリースしながら、安定したサービスを提供し続けたい。」
DXに取り組む担当者を悩ますのが、このようなニーズの存在です。
実は「短いサイクルのリリース」と「安定的なサービス提供」は、背反する要望だからです。
この2つの要望を両立させるために最近注目されているのが、「SRE（サイト信頼性エンジニアリング：Site Reliability Engineering）」です。
そこで本記事では、SRE の概要から注目を集める理由、実現するうえで必要な人材やスキルについてわかりやすく解説します。
▼ 目次
・SRE（サイト信頼性エンジニアリング）とは
・SREが注目を集める理由とメリットとは
・基本をおさえよう、SREのコンセプト
・SREを実現するために必要な人材、スキルとは
1. SRE（サイト信頼性エンジニアリング）とは
SRE（サイト信頼性エンジニアリング : Site Reliability Engineering）とは、Googleが提唱・実践しているシステム管理とサービス運用の方法論です。
その内容はかなり具体的な方法論に落とし込まれていますが、基本的な考え方は以下のとおりです。
- 信頼性こそがあらゆるプロダクトの基本的な機能である。
- 信頼性はシステム側の観点からではなく、ユーザーの観点で計測すべきであり、100％の信頼性を目指すのではなく、定量的な目標値を定め、それの目標値をクリアすることを目指すべき。
- 信頼性を高めるには、開発者と運用者の垣根を超えて、安定的な運用管理を行う必要がある。
- 安定稼働を実現するにはミスの起こりにくい環境が必要であり、そのためには自動化が必須となる。
これらを見ると、DevOpsの考え方に近いものだと感じられるでしょう。
実際にGoogleが公開しているYouTube動画「What’s the Difference Between DevOps and SRE? (class SRE implements DevOps)」の概要欄には、下記が記述されています。
- DevOps is like an abstract class in programming, and SRE is one possible implementation of that class.
- DevOpsはプログラミングの抽象的なクラスのようなもので、SREはそのクラスの一つの可能な実装です。
動画 1. What’s the Difference Between DevOps and SRE? (class SRE implements DevOps)
つまりDevOpsはより高いレベルの抽象概念であり、SREはこれをより具体的な形に落とし込んだものなのです。
GoogleがSREを実践するチームを立ち上げたのは2004年だと言われており、決して新しい方法論ではありません。
すでに20年近くの歴史があり、当初はわずか7人でスタートしたSREチームも、2020年には1200名以上のソフトウェアエンジニアを擁する組織になっています。
このあたりのSREの歴史については、SREチーム立ち上げの立役者の一人となったBen Treynor氏が登場するYouTube動画「The History of SRE」が参考になります。
動画 2. The History of SRE
なぜ最近になってSREが注目されるようになったのでしょうか。
それはDX推進の流れの中で、システム開発・運用に求められるものが大きく変化したからです。
2. SREが注目を集める理由とメリットとは
従来のシステム開発は、下記の様なウォーターフォール型のプロセスを経ることが一般的でした。
- 要件を定義する
- 基本設計・詳細設計を行う
- 設計をプログラムコードとして実装・テスト
- 開発チームから運用チームに成果物を引き渡す
開発されたものが運用チームに引き渡されれば開発チームの仕事は終了し、そこから先の運用フェーズは運用チームの責任になります。
運用チームのミッションは、引き渡されたシステムを安定的に運用することです。
つまり開発と運用がそれぞれ果たすべき役割は、明確に区別されていたのです。
しかし、DXを推進する場合には、このようなウォーターフォール型の開発プロセスは適していません。理由は、DXでは常にユーザーや市場の反応を見ながら、リリースされたサービス（プロダクト）を見直し、改善や機能拡張を続けていくことが重要になるためです。
つまり短いサイクルでプロダクトをリリースし続けていく「アジャイル型」の開発が求められるのです。
実際問題、開発チームと運用チームが分離している状態では、このような取り組みを進めていくことは困難です。理由は、プロダクトのリリースについて、開発チームと運用チームは正反対のモチベーションを持っているためです。
開発チームにとっては、新たなリリースでプロダクトの完成度が高まるのであれば、それをぜひ行いたいと考えるでしょう。
自分たちが世の中に出したものが、より多くのユーザーを満足させる可能性があるからです。
その一方で運用チームは、すでに安定的に動いているシステムに手を入れたくはありません。理由は、新たなリリースには新たな障害を引き起こすリスクがあり、その対応に追われる危険性があるためです。
このような矛盾を解消するために誕生したのが、DevOpsという開発・運用の組織論であり、これを具体的な方法論にまで落とし込んだのがSREであることが注目を集めている理由なのです。
また、SREを実践することによるメリットとして、インフラシステムの運用担当者の負担を軽減できる点が挙げられています。
SRE がインフラ運用の負担を軽減できる理由について解説した記事は、以下よりご覧いただけます。
3. 基本をおさえよう、SREのコンセプト
SREを理解するには、その方法論を支える基本的なコンセプトや、そこで登場する用語を理解しておく必要があります。
これらは多岐にわたるのですが、ここでは基本中の基本と言える、以下の3つのコンセプトを取り上げます。
3-1. SREにとっての信頼性とは何か、どのように評価するのか
SREで最も重視されるのは信頼性の実現です。
これはサービスレベルと言い換えてもいいでしょう。それではSREにとっての信頼性（サービスレベル）とは、具体的にどのようなものなのでしょうか。
まず冒頭でも触れたように、信頼性はシステム側の観点からではなく、ユーザーの観点で計測すべきものです。
例えばシステム監視ツールでは問題が存在しないように見えても、ユーザーから見て問題があれば、それは信頼性を損なう事象なのです。
また信頼性は必ずしも「可用性」とは一致しません。可用性ももちろん重要ですが、ユーザーから見たレスポンスタイムや、正しい結果が得られることも含まれます。つまり「ユーザーが期待した通りの動きをすること」こそが信頼性なのです。
そのためSREでは、以下の４つの手順と指標を用い、信頼性を評価します。
- CUJ（Critical User Journey）
- CUJとは、ユーザーが特定のサービスを利用して目的を達成する際に、「どのような操作を行うのかを明確にした上で、その中で特に重要な操作と、そこで求められるユーザー体験を特定する」という手順を指す
- 例えば動画コンテンツ配信サービスであれば、「再生」ボタンをクリックしてから再生が始まるまでの時間などが、これに相当する
- SLI（Service Level Indicators）
- SLIとは、サービスレベル指標とも呼ばれており、CUJで特定されたユーザーの操作に対し、どの程度まで「ユーザーが許容できる範囲で完了できているか」の指標
- 例えば「再生」ボタンをクリックしてから動画再生が始まるまでの許容時間が１秒であれば、この時間内で完了した割合がどの程度なのか、という数値がSLIになる
- 待ち時間などのユーザー体験を示す数値を、単純に平均化しないこと
- ユーザーが許容できる範囲内で処理が行われたケースを「良いイベント」とし、この良いイベントの数が全体の何％に相当するかを計測する
- このようなデータの扱い方を「パーセンタイル」と呼ぶ
- SLO（Service Level Objectives）
- SLOとは、サービスレベル目標とも呼ばれており、SLIとして計測された数値の目標値
- 必ず「タイムウィンドウ（計測期間）」を設定しておくことが重要
- 例えば「過去30日間で99％のレスポンスタイムが1秒未満であること」といった内容で定義する
- SLA（Service Level Agreement）
- SLAは、サービスレベル契約とも呼ばれており、通常はSLOが達成できなかった場合に、ユーザーに対してどのような補償を行うかを、契約として明記すること
3-2. 開発と運用のバランスをどのようにとっていくのか
前述のように、新規リリースと安定性の確保は、背反する要素です。
これは開発と運用が連携または一体化したDevOpsの組織論を採用した場合でも、避けることはできません。
リリース頻度が多くなれば安定性を阻害する危険性が高くなり、安定性を優先しすぎるとリリース頻度が低下してしまうのです。
このような背反する要素を両立するには、どちらか一方に偏りすぎずバランスを取っていく、というアプローチが有効です。
そのためにSREが採用しているコンセプトが「エラーバジェット」です。
例えばSLOを99％に設定した場合を考えてみましょう。
このとき実際のSLIが99.5％だとすれば、SLOを下回るまでまだ0.5％の余裕があることになります。
この0.5％にタイムウィンドウをかけたものが、エラーバジェットです。
エラーバジェットに余裕がある場合には、新機能のリリースで生じる信頼性低下のリスクを負うことができるため、開発・リリースに時間を費やすことができます。
逆にエラーバジェットが使い果たされた場合には、SREチームは新機能のリリースを中止し、信頼性を高めるための対策を優先しなければなりません。
つまりSLOを下回るまでの時間的な余裕を、開発のための時間的バジェット（予算）として捉えるのです。
このような共通認識を持つことで、リリース頻度と安定性のバランスを取ることが容易になります。
3-3. 自動化を確実に推進していくための考え方
安定性を阻害する可能性があるのは新規リリースだけではありません。
ヒューマンエラーもその大きなファクターです。
また手動で行う作業が多ければ、運用効率も低下します。
これらを最小化していくことも、SREの重要なポイントだと言えます。
しかし闇雲に自動化に取り組んでしまうと、その目的を忘れがちになり、自動化のための自動化といった、手段が目的化してしまうことにもなりかねません。
また自動化で得られる効果が見えない状態で取り組み始めてしまうと、壁にぶつかった際にモチベーションを維持することが困難になる、といった問題も発生します。
この問題を回避するため、SREでは「トイル（Toil）」という言葉を使っています。
トイルとは、直訳すれば「労苦」となります。SREでは下記の特徴を持つ作業と定義されています。
- 人手で行われる
- 繰り返される
- 自動化が可能
- 戦術的、長期的な価値がない
- サービスの成長に比例して増加する
SREではこの定義に当てはまる作業をトイルとして洗い出し、作業に費やされる時間を明確にした上で、その影響を測定します。
そしてトイルの影響を最小化してくことを目的として、自動化に取り組んでいきます。
このようなプロセスを経るため、SREにおける自動化の目的は明確であり、そのモチベーションを維持することも容易になっています。
4. SREを実現するために必要な人材、スキルとは
このようにSREは実に興味深い方法論であり、DevOpsを実現する上で大きな戦力となり得るものです。
しかしその実践は必ずしも簡単ではありません。
SREを実践するメンバーをSREs（一人の場合でもsを付けます）と呼びますが、SREsには下記が求められるためです。
- 開発と運用の両方の経験
- 自動化に必要なコード作成のスキル
- DevOpsに対する深い理解
一般企業がこのような人材を確保するのは、IT人材が不足している日本では、かなりハードルが高いと言えるでしょう。
実は当のGoogleですら、潤沢な人員を確保しているとはいえない状況だと言われています。
日本企業がDX推進のためにSREを実践していくには、十分な知識とスキルを持った専門家がいる組織の支援を受けながら、社内のスキル蓄積とマインドセットの変革を、段階的に進めていく必要がありそうです。
まとめ
この記事で述べたポイントをまとめると以下のようになります。
- SREはDevOpsを具体的な方法論に落とし込んだものであり、Googleは2004年から実践している
- これが最近になって注目されるようになったのは、DX推進のためにアジャイル開発が求められるようになり、DevOpsの実践が必要になってきたから
- SREにはこの方法論を支える様々なコンセプトがあるが、特に以下の3つが重要
- SREにとっての信頼性とは何か、どのように評価するのか
- 開発と運用のバランスをどのようにとっていくのか
- 自動化を確実に推進していくための考え方
- SREを実践するには開発・運用の経験とコーディングのスキル、DevOpsに対する深い理解を持つ人材が必要
尚、GoogleはSREに関して、数多くの記事や動画、書籍を提供しています。
興味のある方はぜひ、以下のサイトを参照することをおすすめします。
