このドキュメントは、オンライン サービスを運営するチームがサービスレベル目標（SLO）を使用してサイト信頼性エンジニアリング（SRE）の文化の構築と導入を開始する方法を説明する 2 部構成ドキュメントのパート 1 です。SLO とは、サービスの信頼性目標レベルです。
Software as a Service（SaaS）では、プロダクトの開発速度とオペレーションの安定性との間に自然な緊張関係があります。システムを変更すればするほど、システムが破損する可能性が高くなります。モニタリング ツールやオブザーバビリティ ツールを使用すれば、開発を加速してもオペレーションの安定性に対する信頼を維持できます。このようなツール（アプリケーション パフォーマンス管理（APM）ツール）は重要ですが、その用途で最も重要なものの 1 つに、SLO の設定があります。
SLO を適切に定義すれば、安定性を犠牲にすることなく、開発を加速するデータドリブンのオペレーション決定をチームが行えるようになります。SLO を使用することで、単一の合意形成された目標に沿うように開発チームと運用チームを配置することもできます。これにより、プロダクトの作成と反復（開発）およびシステムの整合性の維持（オペレーション）という 2 つの目標の間にある自然な緊張関係を緩和できます。
SLO の詳細については、SRE ブックと SRE ワークブックをご覧ください。その他の SRE プラクティスに関しても説明されています。このシリーズでは、SLO の理解と開発のプロセスを簡素化し、SLO をより簡単に導入できるようにすることを目的としています。これらの記事を読み理解すれば、上記の本でより多くを学習できるようになります。
このシリーズは、組織に SLO を実装するための明確な道筋を示すことを目的としています。
- このドキュメントでは、SLO とは何かについて、およびサービスで SLO を定義する方法について確認します。
- SLO の導入では、ワークロードの種類に基づく SLO のさまざまな種類、SLO の測定方法、SLO に基づくアラートの開発方法を説明しています。
このシリーズは、オンライン サービスの安定性と信頼性を担当する SRE、オペレーション チーム、DevOps、システム管理者などを対象としています。この記事では、インターネット サービスがウェブブラウザやモバイル デバイスと通信する方法を理解し、ウェブサービスのモニタリング、デプロイ、トラブルシューティングの方法の基本を理解されていることを前提としています。
State of DevOps で、ソフトウェア デリバリーのパフォーマンスを向上させると認められた機能が報告されています。このシリーズでは、次の機能について説明します。
SLO が必要な理由
SRE の文化を構築する際、SLO から始める理由は何でしょうか。その理由は端的に言えば、サービスレベルを定義しなければ、顧客がサービスに満足しているかを測定することが困難になるためです。サービスレベルが定義されていない場合、（サービスを改善できることがわかっている場合でも）改善のためにどこにどれだけ投資するかを決定することが困難になります。
ユーザー向けかどうかに関係なく、すべてのサービスで個別の SLO を開発したくなることがあります。たとえば、2 つ以上のサービス（たとえば、フロントエンド サービスとバックエンド データストア）で、ユーザーが両方のサービスに依存しているが、それらを区別できない場合に、個別に測定してしまうことがよくある間違いです。よりよいアプローチは、プロダクト（サービスのコレクション）に基づいて SLO を開発し、ユーザーがこのプロダクトと行う最も重要なインタラクションに焦点を合わせることです。
そのため、効果的な SLO を開発するために、クリティカル ユーザー ジャーニー（CUJ）と呼ばれる、ユーザーとサービスとのインタラクションを理解することが理想です。CUJ では、ユーザーの目的と、ユーザーがその目的の達成のためにサービスをどのように使用するかが考慮されます。CUJ は、サービスの境界線を考慮せずに顧客の視点で定義されます。CUJ が満たされていれば顧客は満足であり、顧客の満足度がサービスの成功の重要な尺度になります。
サービスに対する顧客の満足度の重要な側面は、サービスの信頼性です。サービスが信頼できるかどうかは、サービスの内容以前の問題です。そのため、いかなるサービスにおいても信頼性が最も重要となります。一般的な信頼性の指標に稼働時間があります。通常これは、システムが稼働していた時間の長さを意味します。しかし、より有用で正確な指標である可用性の使用をおすすめします。可用性も、システムが稼働しているかどうかに関する指標ですが、システムが停止してからの時間を測定するよりも正確に稼働状況を測定できます。今日の分散システムではサービスが部分的に停止することがあり、これは稼働時間の測定でうまく捉えることはできません。
可用性は、9 の数でしばしば表現されます。たとえば、99.9% の可用性（スリーナイン）や 99.99% の可用性（フォーナイン）などがあります。可用性の SLO を測定することは、システムの信頼性を測定するための最良の方法の 1 つです。
オペレーションの成功を定義する際に SLO は有用ですが、リソースを投資する対象を選択する際にも SLO を活用できます。たとえば SRE ブックでは、9 の桁数を増やすエンジニアリングの取り組みが、費用の増加と限界効用の問題に直面することが指摘されています。一般に、可用性に 9 をもう 1 つ加えるためには、その前の 9 でかかった費用の 10 倍の費用がかかると考えられています。
SLI を選択する
SLO を達成している（問題ない）かどうかを判断するには、測定を行う必要があります。この測定で得られる指標は、サービスレベル指標（SLI）と呼ばれます。SLI では、顧客に提供するサービスのレベルが測定されます。理想的には、SLI は承認済みの CUJ と結びついています。
最適な指標を選択する
SLI の開発の最初の手順は、測定する指標を選択することです。これには、1 秒あたりのリクエスト数、1 秒あたりのエラー数、キューの長さ、特定の期間内のレスポンス コードの分布、送信バイト数などがあります。
これらの指標は、以下の種類のいずれかになることがほとんどです。
- カウンター。たとえば、ある測定ポイントまでに発生したエラーの数など。このタイプの指標は増加することはありますが、減少することはありません。
- 分布。特定の期間に特定の測定セグメントに入ったイベントの数など。たとえば、完了するまでに 0～10 ミリ秒、11～30 ミリ秒、31～100 ミリ秒かかったリクエストの数をそれぞれ測定できます。結果は、バケットごとのカウントになります（例: [0-10: 50]、[11-30: 220]、[31-100: 1103]）。
- ゲージ。キューの長さなど、システムの測定可能な部分の実際の値。このタイプの指標は増加することも減少することもあります。
これらの種類の詳細については、Prometheus プロジェクトのドキュメントと Cloud Monitoring の指標の種類の ValueType と MetricKind をご覧ください。
SLI に関する重要な違いとして、すべての指標は SLI ではありません。実際、SRE ワークブックに次のような記載があります（強調付き）。
ソフトウェア企業の多くが数百、数千の指標をトラックしていますが、SLI として適格な指標はその中のほんの一握りです。では、イベントの総数に対する良いイベントの割合の他に、良い SLI として使える指標には何があるでしょうか。適切な SLI 指標には以下のような特徴があります。
- 指標とユーザーの満足度が直接関係している。一般に、サービスが期待どおりに動作しない、動作に失敗する、動作が遅い場合、ユーザーの満足度は低下します。SLO がこれらの指標に基づいている場合、SLI をユーザーの満足度を示す他のシグナル（たとえば、苦情チケットの数、サポートの問い合わせの量、ソーシャル メディアの感情、エスカレーション）と比較することで、SLO の検証を行えるようになります。使用している指標がユーザーの満足度の指標に対応していない場合は、SLI として適した指標ではない可能性があります。
- 指標の悪化とサービスの停止が相関している。サービスの停止時に良好な状態であるとして表示される指標は、SLI に適した指標ではありません。通常のオペレーション中に良好な状態ではないとして表示される指標も、SLI に適した指標ではありません。
- 指標の信号雑音比が良好。偽陰性や偽陽性が高頻度で発生する指標は適切な SLI ではありません。
- 指標が、顧客の満足度に応じて単調に、ほぼ直線的にスケーリングされる。指標が改善するにつれて、顧客の満足度も向上します。
次の図のグラフについて考えてみましょう。サービスの SLI として使用される可能性がある 2 つの指標の時間に伴う変化がグラフ化されています。サービスが低下している期間は赤色で、サービスが良好である期間は青でハイライト表示されています。
SLI が適切ではない場合のグラフでは、ユーザーが満足していない期間とネガティブなイベント（サービスの低下、遅延、停止など）が直接対応していません。また、SLI はユーザーの満足度とは無関係に変動しています。SLI が適切な場合のグラフでは、SLI とユーザーの満足度は相関しています。また、満足度のレベルの違いが明確であり、無関係な変動がはるかに少なくなっています。
適切な数の指標を選択する
通常、1 つのサービスに複数の SLI が対応します。特にサービスが行う作業のタイプや、サービスを提供されるユーザーのタイプが異なる場合です。たとえば、読み取りリクエストと書き込みリクエストは別々の方法で動作する傾向があるため、これらを分離することは推奨されます。この場合、各サービスごとに適した指標を選択することが最適です。
一方で、多くのサービスはサービスどうしで類似した種類の作業を行うため、直接比較できます。たとえば、オンライン マーケットプレイスの場合、ユーザーはホームページを表示する、サブカテゴリやトップ 10 リストを表示する、詳細ページを表示する、または商品を検索することが考えられます。これらの各アクションで個別の SLI を開発して測定するのではなく、単一の SLI カテゴリ（たとえば、ブラウズ サービス）に結合できます。
類似したカテゴリのアクション間でユーザーの期待が大きく変化することは実際にはありません。ユーザーの満足度は、ブラウジングするデータの構造（データがプロモーション商品の静的リストから取得されたか、巨大なデータセットに対する機械学習支援の検索による結果から動的に生成されたか）には関係しません。ユーザーの満足度は、「商品の全ページをすぐに表示できたか？」という質問の回答から定量化できます。
サービスの許容範囲を正確に表現できる、可能な限り少ない数の SLI を使用することが理想的です。通常、1 つのサービスには 2～6 個の SLI が必要です。SLI が少なすぎる場合、重要なシグナルを見落とす可能性があります。SLI が多すぎると、実用性がほとんどない数多くの指標をオンコール チームがトラックしなければならなくなります。SLI は、本番環境の健全性をシンプルに把握でき、対象を把握できているという感覚を与えるものであることが必要です。
SLO を選択する
SLO は以下の値で構成されます。
- SLI。たとえば、レスポンスの総数に対する HTTP コード
200のレスポンスの数の割合など。 - 期間。指標が測定される期間です。この期間は、カレンダー ベース（月の最初の日から翌月の初日までなど）やローリング ウィンドウ（過去 30 日間など）で指定できます。
- 目標。たとえば、特定の期間に達成することが期待されるイベント全体に対する適切なイベントの目標割合（99.9% など）。
SLO を開発する際、その期間と目標を定義することが難しい場合があります。このプロセスを始める際の 1 つの方法として、SLI を特定し、時間に伴う変化をグラフ化することがあります。使用する期間と目標を決定できない場合には、SLO をすぐに完璧なものにする必要はありません。SLO を繰り返し処理し、顧客の満足度と一致させ、ビジネスニーズに合うようにします。1 か月の間はツーナイン（99.0%）から始めてみてください。
デプロイ、停止、毎日のトラフィック パターンなどのイベント中の SLO コンプライアンスをトラッキングすると、どの目標が良いか、悪いか、許容可能かに関する分析情報を取得できます。たとえば、バックグラウンド プロセスの場合に、75% の成功で十分と定義するなどできます。しかし、ミッション クリティカルでユーザーと接触するリクエストの場合は、99.95% など、より積極的な目標を設定してもよいでしょう。
もちろん、すべてのユースケースに適用できる、ただひとつの SLO は存在しません。SLO は、いくつかの要素に応じて変化します。
- 顧客の期待
- ワークロード タイプ
- サービスの提供、実行、モニタリングのためのインフラストラクチャ
- 問題となるドメイン
このシリーズのパート 2 SLO を導入するでは、ドメインに依存しない SLO に焦点を当てます。ドメインに依存しない SLO（サービスの可用性など）は、高レベルのインジケーター（毎分販売されるウィジェット数など）に置き換わるものではありません。しかしながら、ビジネス ユースケースにかかわらず、サービスの動作の有無について測定する際に活用できます。
ドメインに依存しないインジケーターは多くの場合、1 つの質問にまとめることができます（たとえば、「サービスは利用可能ですか？」、「サービスの速度は十分ですか？」）。可用性とレイテンシの 2 つの要素を考慮した SLO には、この質問の回答が含まれることがよくあります。SLO は、次のように記述できます。ここで、X = 99.9%、Y = 800 ms です。
次のステップ
- SLO を導入するを読む。この記事では、これらの定義についての詳細を探索し、さまざまなワークロードの種類に対して、より適した他の SLI を紹介しています。
- 他の SRE リソースを確認する。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。
- DevOps に関するリソースを読む。
- このシリーズに関連する DevOps 機能の詳細については、以下をご覧ください。
- DevOps のクイック チェックを確認する。業界におけるご自身の立ち位置を把握できます。