Site Reliability Engineering（SRE）は、Googleが提唱したソフトウェアエンジニアリングの手法で、信頼性を定量的に管理するアプローチです。従来の運用チームが「障害を起こさない」ことを目標にしていたのに対し、SREは「許容できる範囲で障害を受け入れ、その分を開発速度に充てる」という考え方を採る。筆者がSREのプラクティスを導入した複数のチームで共通して得られた成果は、運用負荷の定量化と、開発チームとの建設的な対話の実現だった。
SLI（Service Level Indicator）は、サービスの信頼性を測定するための具体的なメトリクスです。SLIを適切に定義することが、SRE実践の出発点となります。
SLIの定義で重要なのは、ユーザー体験に直結するメトリクスを選ぶことです。サーバーのCPU使用率やメモリ使用量といったインフラメトリクスではなく、ユーザーが実際に感じるサービスの品質を反映するものでなければなりません。
代表的なSLIの種類は以下の通りです。
筆者の経験から、良いSLIには以下の特徴があります。
たとえばWebアプリケーションのAPIであれば、「ステータスコード5xxを除いたレスポンスの割合」を可用性SLIとし、「レスポンスタイムが300ms以下のリクエストの割合」をレイテンシSLIとするのが一般的です。
SLO（Service Level Objective）は、SLIに対する目標値です。SLOの設定はSREの中核をなす作業であり、ここを適切に行えるかどうかが成否を分ける。
SLOを設定する際に考慮すべきポイントは以下の通りです。
具体的なSLO設計の例を挙げると、ECサイトの商品検索APIであれば、可用性SLOを99.9%（30日間で約43分のダウンタイム許容）、レイテンシSLOを95パーセンタイルで300ms以下と設定するのが妥当なラインでしょう。
エラーバジェットは、SLOの裏返しとして算出される「許容できる障害の量」です。SLOが99.9%であれば、エラーバジェットは0.1%となります。30日間で約43分のダウンタイムが「使える予算」として割り当てられるわけです。
エラーバジェットの本質的な価値は、信頼性と開発速度のトレードオフを定量的に管理できることにあります。エラーバジェットが潤沢にあれば、リスクの高いリリースやインフラ変更を積極的に行える。逆にエラーバジェットが枯渇しつつある場合は、信頼性改善に注力すべきだという明確なシグナルとなります。
エラーバジェットを実効性のある仕組みにするには、バジェットの消費状況に応じた行動指針をあらかじめ定めておく必要があります。
このポリシーは開発チーム、SREチーム、プロダクトマネージャーの三者で合意しておくことが重要です。合意がない状態でエラーバジェットを導入しても、機能しません。
SLOは設定して終わりではなく、継続的に運用・改善していくものです。以下のサイクルを回すことが重要です。
SLI/SLOの導入で筆者が経験した、あるいは見聞きした典型的な失敗パターンを共有します。
あれもこれもとSLIを定義しすぎると、どれが重要か分からなくなります。最初は2〜3個の核心的なSLIに絞り、運用が安定してから追加するのが良い。
CPU使用率90%以上がSLI違反、といった定義は避けるべきです。CPU使用率が高くてもユーザーに影響がなければ問題ないし、逆にCPU使用率が低くてもアプリケーションのバグでエラーが多発する場合もあります。あくまでユーザー体験に基づいたメトリクスを選ぶ。
SLOとエラーバジェットは技術的な仕組みですと同時に、組織的な合意でもあります。開発チームだけで決めても意味がなく、ステークホルダーを巻き込んだ上で導入しなければ形骸化します。
SLI/SLOとエラーバジェットの導入は、技術的にはそれほど難しくありません。難しいのは、組織としてこの仕組みを受け入れ、活用し続けることです。まずは1つのサービスから小さく始め、チームが成功体験を積んでから他のサービスに展開していくのが、筆者が最も推奨するアプローチです。完璧なSLOを最初から求めるのではなく、運用しながら学び、改善していく姿勢が大切です。
入会申込
ログイン
