このセクションでは、サービスレベル指標（SLI）のコンセプト、適切な SLI の構成要素の定義、選択されたサービスに対する SLI の実装例について説明します。このページは、サービス固有の SLI の実装例を必要としているユーザーを対象としています。
SLI の概要
サービスの信頼度は抽象的な概念です。信頼度は、サービスとユーザーのニーズによって異なります。サービスレベル指標（SLI）はその信頼度を測る一つの尺度で、サービスの信頼度についてのコミュニケーションとサービスの管理の両方に使用されます。
SLI は、一定の時間枠を基準にして測定されます。通常、この時間枠の大きさは、その情報をもとに行われる意思決定によって異なります。たとえば、1 つの SLI は、次のような時間枠で測定できます。
- 直近の 1 時間。アラート ポリシーの作成に使用。
- 数週間。戦術的な意思決定に使用。
- 数か月。戦略的な意思決定に使用。
SLI を測定するための出発点としては、28 日間にすることをおすすめします。この値は、戦略的ユースケースと戦術的ユースケースの間でバランスを取ることができます。
詳しくは、サイト信頼性エンジニアリング ワークブックの次のセクションをご覧ください。
適切な SLI のプロパティ
ここでは、次の条件を満たす尺度を「適切」な SLI とします。
SLI がユーザーの満足度を表す良い目安となる。
適切な SLI には、ユーザーの満足度と強い相関関係があります。SLI は、サービスレベル目標（SLO）の基準として使用します。SLO は、SLI に設定された 1 つのしきい値で、SLI が定義された範囲内に収まっている場合は、ほとんどのユーザーが満足するように SLO を設定します。この関係を維持するには、SLI をユーザーの満足度を表す良い代替手段となる必要があります。
SLI がユーザーの満足度を的確に表す尺度になると、ユーザーの満足度に影響するイベントが発生したときに、SLI はある方向に変化します。同様に、ユーザーの満足度に影響するイベントがない場合、SLI は変化しません。
SLI が、ユーザーの満足度に比例して単調に増減する。
適切な SLI は、ユーザーの満足度に比例して、単調に増減します。SLI が改善すれば、ユーザーの満足度は向上します。同様に、SLI が減少すると、ユーザーの満足度も低下します。適切な SLI の値の増加量は、ユーザーの満足度の向上度合いに対応します。
SLI が 0%～100% の範囲で測定値を生成する。
適切な SLI は、パフォーマンスの測定値を 0%～100% の範囲で生成します。この範囲は直感的で使いやすいものです。たとえば、SLI のパフォーマンスが 100% の場合はすべてが機能していることを意味し、SLI が 0% の場合は何も機能していないことを意味します。
SLI を 0%～100% の範囲にすると、その SLI の SLO を簡単かつ明確に設定できるようになります。99.9% のような割合目標を設定し、サービスに対する SLI のパフォーマンスが、その SLO を満たす目標以上になるようにします。
約束事項
こうした特性を持つ SLI を実装する一つの方法は、ユーザーに対する約束事項の観点で SLI を考えることです。ある時間枠中に作成され確認された約束事項をカウントすることで、0%～100% の範囲の数値を導き出せます。また、このような SLI は、エラー バジェットともうまくつながります。特定の SLO に対するエラー バジェットとは、SLO を満たしながら、ある時間枠で確認できなかった約束事項の数です。
約束事項の例を次に示します。
- お客様のリクエストに対して HTTP
200ステータス コードを含むレスポンスを返す。 - gRPC リクエストに対して 100 ミリ秒以内にレスポンスする。
- 「仮想マシンの作成」ワークフローを正常に完了する。
- 直近の 10 分以内に更新されたデータを提供する。
- スケジュールされたバッチジョブをその開始時刻から 1 分以内に開始する。
SLI の仕様と実装
SLI の仕様とは、測定する対象のことです。仕様には、データの測定方法に関する技術的な詳細は含まれていません。たとえば、ページ読み込み時間に関する SLI の仕様は次のようになります。
- 100 ミリ秒以内に読み込まれたホームページ リクエストの割合。
SLI の測定方法は複数あり、それぞれにトレードオフとメリットがあります。SLI の測定方法が SLI の実装になります。たとえば、ページ読み込みの仕様は、次のいずれかの形で実装できます。
- アプリケーション サーバーのリクエストログのレイテンシ フィールド。
- アプリケーション サーバーによってエクスポートされた指標。
- アプリケーション サーバーの前にあるロードバランサによってエクスポートされた指標。
- システムに疑似的なリクエストを送信し、有効なレスポンスを受信するまでの時間を測定するブラックボックスのモニタリング サービス。
- ユーザーのブラウザで実行され、時刻情報を記録してコレクション サービスに返すアプリケーション固有のコード。
この選択肢のそれぞれには、次のような特性間のトレードオフがあります。
- 忠実度: ユーザー エクスペリエンスを捉える正確さの度合い。
- 対象範囲: 測定されるユーザー操作の割合。
- 費用: ソリューションの構築と保守に必要な費用とエンジニアリング時間。
通常、測定される SLI がユーザーに近くなるほど、ユーザー エクスペリエンスの忠実度は向上します。たとえば、ユーザーのブラウザ内でコードを使用する実装では、ユーザーが認識するレイテンシや、他の測定方法で認識されるレイテンシよりも、正確な測定値が得られます。
この場合のトレードオフとして、ブラウザベースの測定には、ユーザーのサービスへの接続によって生じるレイテンシも含まれます。たとえば、公共のインターネットで使用されるサービスの場合、このレイテンシは地理的位置やネットワークの条件によって大幅に異なる可能性があります。
その結果、ブラウザベースのシグナルはユーザーの満足度を適切に表現しますが、サービスの信頼度向上に役立つ実用的な情報はシグナルに含まれていない可能性があります。
このトレードオフについて、複数の測定値を組み合わせる方法については、The Telegraph の投稿をご覧ください。
バケット
サービスのプラットフォームがユーザーごとに異なる種類の処理を行う場合や、異なる結果が得られる可能性がある特定のタスクを実行する場合には、複数の SLI が必要になることがあります。
複数のタスク
異なるユーザーのカテゴリに対して複数の処理を実行し、各処理がユーザーの満足度に与える影響が異なるサービスは、複数の SLI のメリットを受けられます。
たとえば、サービスが読み取りリクエストと書き込みリクエストの両方を処理する場合、それらのタスクを実行するユーザーに次のような異なる要件があることがあります。
- 読み取りリクエストは高速でなければならない。
- 書き込みリクエストは成功する必要がある。
この異なる要件を捉えるには、SLI が 2 つのケースを区別できる必要があります。通常、SLI 指標には、値を複数のバケットに分類できるラベルがあります。
1 つのタスクで結果が異なる
同じ種類の処理を行うものの、ユーザーの期待がレスポンスに基づいて異なるサービスは、複数の SLI のメリットを受けられます。
たとえば、サービスがデータに対する読み取りアクセスのみを提供する場合、リクエストの結果によって、ユーザーのレイテンシに対する寛容性は次のように異なる場合があります。
- すぐにリクエストを再試行できるため、迅速に返されるエラーには寛容。
- リクエストが成功しても長く待たされることには比較的我慢できない。
- 最も我慢できない最悪のケース: リクエストで長時間待たされ、エラーが返される。
この場合、レイテンシ SLI が成功したリクエストと失敗したリクエストを区別できる必要があります。
次のステップ
Google Cloud 指標を使用して Google Cloud サービスに SLI を実装する方法については、以下をご覧ください。
アプリケーション固有の SLI の実装については、以下をご覧ください。
カスタム指標を報告するサービスの SLI を作成する方法については、SLO の設定: カスタム指標を使用したオブザーバビリティをご覧ください。