SLO を定義する

このドキュメントは、オンライン サービスを運営するチームがサービスレベル目標（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 で、ソフトウェア デリバリーのパフォーマンスを向上させると認められた機能が報告されています。このシリーズでは、次の機能について説明します。

用語

このシリーズのドキュメントでは、次の用語と定義を使用します。

  • サービスレベル。特定のサービスがユーザーに対して期待される作業をどの程度行えているかに関する測定値。この測定値は、ユーザーの満足度という形で説明できます。その測定方法は、サービスの内容、ユーザーが何をサービスに期待しているか、サービスで実現できるとの説明を受けている内容などに基づきます。

    例: 「ユーザーは、サービスが利用可能で高速であることを期待しています。」

  • クリティカル ユーザー ジャーニー（CUJ）。ユーザーが 1 つの目的を達成するために行うサービスとの一連のインタラクション（1 回のクリックやマルチステップ パイプラインなど）。

    例: 「ユーザーが購入手続きボタンをクリックし、カートが処理されて領収書が返されるレスポンスを待ちます。」

  • サービスレベル指標（SLI）。定量的に測定可能な、サービスレベルに関するユーザーの満足度の指標。サービスレベルを測定するためには、そのサービスレベルに関するユーザーの満足度を表す指標（サービスの可用性など）を測定する必要があります。SLI は、サービスの改善や低下に伴い経時変化するグラフ上の線と考えることができます。

    例: 「直近 10 分間における成功したリクエストの数を、直近 10 分間の有効なリクエストの数で割った値を測定します。」

  • サービスレベル目標（SLO）。サービスがほとんどの時間帯で達成すると期待されるレベル。SLI は、これに対して測定されます。

    例: 「14 日間で測定されたすべての有効なリクエストの 95% でサービスのレスポンスが 400 ミリ秒（ms）より早い必要があります。」

    SLO と SLI の関係を示すグラフ。

  • サービスレベル契約（SLA）。SLO が満足されなかった場合の対応に関する説明。通常、SLA はプロバイダと顧客との間の法的契約であり、補償の条項が含まれる場合もあります。SRE に関する技術的な議論においては、この用語はしばしば避けられます。

    例: 「1 暦月の間にサービスによって 99.95% の可用性を実現できなかった場合、サービス プロバイダは、サービス内容についての規定を遵守できなかった時間に対して 1 分単位でお客様に補償します。」

  • エラー バジェット: SLO 違反となるまでに許容できる時間や好ましくないイベントの数。この測定値は、ビジネスでどの程度の数のエラーが想定されるか（許容できるか）を示します。エラー バジェットは、リスクを伴う可能性がある意思決定を行ううえで重要です。

    例: 「SLO が 99.9% の可用性の場合、リクエストの 0.1% でインシデント、事故、試験運用のいずれかが原因のエラーが発生することが許容されます。」

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 を 2 つの数値の比率として扱うことを通常はおすすめしています。すなわち、良いイベントの数をイベントの総数で割ります。」

「この場合の SLI の範囲は 0～100% であり、0% は何も動作していない、100% は何も壊れていないという意味になります。この尺度は直感的に理解できます。また、このスタイルはエラー バジェットのコンセプトに容易に適応します。」

ソフトウェア企業の多くが数百、数千の指標をトラックしていますが、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 です。

有効なリクエストの X% が成功し、Y ms より早く成功しています。

次のステップ