はじめに

こんにちは、MSPセクションの秋山です。
12/2(月)に「Google Cloud The Art of SLO ワークショップ」に参加してきました。
The Art of SLO ワークショップ ~サービスやアプリケーションの信頼性の計測と運用~

ワークショップでは、Googleが実践しているSLO設計・信頼性の監視/測定等の手法について学びました。
ワークショップの内容とワークショップのテーマとなっている SRE、SLO、SLI等について解説いたします。

1. サイト信頼性エンジニアリング（SRE:Site Reliability Engineering）

SREは、Googleが提唱した信頼性向上のためのエンジニアリングアプローチです。現代のITシステムでは、開発スピードを向上させることが重視されていますが、それと引き換えにシステムの安定性が損なわれてしまうこともあります。SREは、開発の高速化とシステムの安定性を両立するための手法です。

SRE Books

Googleが公開しているSRE Booksに基本原則や実践方法が紹介されています。（オンライン版は無料で閲覧できます）

なお、SRE Booksでは、SREの原則について以下のように定義されています。

  • リスクの受け入れ：信頼性を極限まで高めるにはコストがかかるため、エラーバジェットを活用する
  • サービスレベル目標：サービスレベル指標(SLI)、目標(SLO)、契約(SLA) の定義とサービスを測定するための適切な指標を選択する
  • 労力の削減：永続的な価値のない反復作業を減らし、重要な開発に時間を割く
  • 分散システムの監視：何が起こっているのかを把握し、信頼性を確保する
  • リリース エンジニアリング：一貫性があり繰り返し可能な信頼性の高いリリースプロセスを定義する
  • シンプルさ：ソフトウェアのシンプルさが信頼性を高める

SREの目的

SREの目的は、ユーザーが不満を感じないギリギリのサービスレベルを維持しながら、開発スピードを向上させることです。必要以上に高い目標値を達成することは、運用コストの増加や開発スピードの低下を招きます。

そのために、SREではサービスの信頼性を担保する指標を定め、それをモニタリングし続けることが重要です。
その指標として、「SLA」、「SLO」、「SLI」の3つと「エラーバジェット」について紹介します。

2. サービスレベル契約（SLA）

SLA（Service Level Agreement）は、サービス提供者と顧客の間で取り決められるサービスの品質や可用性に関する合意です。具体的には、「サービスをどの程度の水準で提供するのか」を明確にし、双方が期待値を共有するための契約書や合意書として機能します。

3. サービスレベル目標（SLO）

SLO（Service Level Objective）は、サービスの信頼性をどのレベルで提供するかを定量的に定めた目標値です。例えば、「99.9%の稼働時間を保証する」といった具体的な目標が該当します。

SLOの目的

  • 顧客満足度を測る指標となる
  • チーム全体の方向性を統一する
  • トラブル発生時の対応基準を明確化する

SLOを定義することで、開発者はSLOを満たせる範囲でリリースするという基準ができます。また、運用者はすべてのエラーに神経質になりすぎず、SLOを満たしていればある程度のエラーは許容できると考えることができます。つまりSLOを定義することは、開発者と運用者の関係改善に役立ちます。

SLOの設定

SLOはぎりぎり達成できればサービスの典型的なお客さまが満足するような、性能や可用性のレベルにすべき

サービスの信頼性をより高く確保・維持しようとするほど運用コストがかかるため、SLOの値はぎりぎり達成できるレベルが好ましいです。

4. サービスレベル指標（SLI）

SLI（Service Level Indicator）は、SLOを達成するために監視・測定する具体的な指標です。サービスの信頼性の定量化できる尺度となります。
例えば以下のような指標があります。

  • 可用性：有効なリクエストのうち正常に処理された割合
  • レイテンシー：有効なリクエストのうち閾値よりも早く処理された割合
  • 品質：品質を劣化させることなく処理された有効なリクエストの割合
  • 鮮度：しきい値よりも新しく更新された有効なデータの割合
  • カバレージ：処理に成功した有効なデータの割合
  • 正確性：正確な出力を生成する有効なデータの割合
  • スループット：データ処理レートがしきい値よりも速い時間の割合

SLIの選び方

ユーザー体験に直接影響を与える指標を選ぶのが好ましいです。具体的には、指標がある程度安定しており、指標の悪化がサービスで起きる問題と相関するものです。
以下のような指標はSLIに適しません。

  • 異常時のみ生じるメトリクス
  • 指標が上下しやすくユーザ満足度と相関が低いもの

SLIの定義

SLI = （良いイベント/有効なイベント）✖️１００％

分母を「すべてのイベント」ではなく「有効なイベント」としているのは、関係なさそうなイベントを除いてノイズを減らすことを目的としています。それにより、SLIをより正しく計測できます。
また、ユーザジャーニーあたりのSLIの設定数の目安としては、３~５個が良いとされています。

SLIを設定するには

一例ですが、以下のような流れで設定していきます。

  1. SLIを定義します
    例：レイテンシーの場合
    有効なリクエストのうち閾値よりも早く処理された割合
  2. 定義を具体化します
    例：レイテンシーの場合
    ロードバランサーで測定された、1000ms以内に完全なレスポンスがクライアントに返されている/xxx/xxxへのリクエストの割合
    • 「有効なリクエスト」→「完全なレスポンスがクライアントに返されている/xxx/xxxへのリクエスト」
    • 「閾値よりも早く処理された」→「1000ms以内に」
    • どこで測定するか→「ロードバランサーで測定された」
  3. ユーザージャーニーを追って網羅できているか確認します

SLI/SLOの継続的な改善

SLOを定期的に見直して改善していくことが好ましいです。

  • もしSLOを満たしているのにユーザ満足度が低い場合には、SLOが低すぎないか確認が必要です。
  • 一方で、SLOを大幅に満たしている状況であれば、リリース頻度を上げていくという判断も可能です。

5.エラーバジェット

エラーバジェットは、システムに許容される失敗や障害の限度を定量化したものです。具体的には、サービスレベル目標（SLO）から計算される「許容できるエラーの範囲」を示し、システムの信頼性向上と新機能開発のバランスを取るための指標として活用されます。

エラーバジェットの計算方法

SLOが「稼働率99.9%」の場合、ダウンタイム（許容される停止時間）は、28日で「40分19秒」です。この「40分19秒」が28日間に許容されるエラーバジェットです。これを越えない範囲で障害や問題が発生しても、目標の範囲内とみなされます。

エラーバジェットの目的とメリット

  • 過剰な信頼性を追求するのではなく、開発と信頼性のいいバランスを見つけられる
  • 開発チームが自分でエラーバジェットをどう使うか決めてリスクを管理できる
  • システム稼働時間に対する責任を共有する（インフラ障害もエラーバジェットを消費する）

エラーバジェットの運用方法

SLI（サービスレベル指標）を用いて、現在のエラーバジェット消費率を監視します。
例えば、状況に応じて以下のような判断が可能となります。

  • エラーバジェットの消費が早い場合
    • 新機能のリリースを停止し、信頼性向上のための改善（バグ修正、パフォーマンス最適化など）を優先します。
  • エラーバジェットが十分残っている場合
    • リスクの高い実験や新しい機能のリリースを積極的に進めることができます。

まとめ

ワークショップでは、時間いっぱいまで質疑応答が盛り上がっており、SRE等への関心の高まりを感じました。

以下の記事では、SLI / SLO の定義から、New Relic を使った計測・可視化までがわかりやすく解説されています。
【次世代MSP】SLI / SLO を定義してみた ～ New Relic でサービスの見える化に挑戦！

最後までご覧いただきありがとうございました。