サービスレベル指標（SLI）を選択する

Last reviewed 2024-03-29 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、サービスに適したサービスレベル指標（SLI）を選択する方法について説明します。このドキュメントは、SLO のコンポーネントで定義されているコンセプトに基づいています。

サービスレベル目標（SLO）が達成されているかどうかを判断するには、指標が必要です。これらの指標を SLI として定義します。各 SLI は、応答時間、可用性、成功率など、サービスの特定の側面の測定値です。

SLO には 1 つ以上の SLI が含まれ、クリティカル ユーザー ジャーニー（CUJ）に基づくのが理想的です。CUJ は、ユーザーがウェブサイトで目的を達成するためにたどる特定のユーザー操作や経路のセットを指します。e コマース サービスでの顧客の買い物について考えてみましょう。顧客はログインして、商品を検索してカートに商品を追加し、購入手続きページに移動して購入手続きを行います。CUJ は、ユーザーがタスクをできるだけ早く完了できるようにするためのさまざまな方法を特定します。

SLI を選択する際は、サービスに適した指標、使用できるさまざまな指標タイプ、指標の品質、必要な指標の正しい数を考慮する必要があります。

サービスタイプに適した SLI を選択する

サービスタイプは数多くあります。次の表に、一般的なサービスタイプと、各サービスタイプの SLI の例を示します。一部の SLI は複数のサービスタイプに適用されます。SLI がテーブルに複数回出現する場合、最初の SLI の例でのみ定義を説明します。SLI は、指標において「9」で表されることがよくあります。

サービスタイプ 一般的な SLI
サービス提供システム
  • 可用性 - サービスが使用可能である割合。可用性は、成功したリクエストの数をリクエストの合計数で割って定義され、99.9% などの割合で表されます。
  • レイテンシ - 一定の割合のリクエストが処理される速さ。たとえば、99 パーセンタイルが 300 ミリ秒など。
  • 品質 - リクエストへの対応の内容が、理想的な対応の内容からどの程度逸脱しているかを示します。 たとえば、0% から 100% のスケールで表します。
データ処理システム
  • カバレッジ - 処理されたデータの量。割合で表されます。たとえば、95% など。
  • 正確性 - 正しいとみなされる出力データの割合。 たとえば、99.99% など。
  • 鮮度 - ソースデータまたは集計された出力データの鮮度。たとえば、データが 20 分前に更新されたなど。
  • スループット - 処理されるデータの量。たとえば、1 秒あたり 500 MiB、1 秒あたり 1,000 リクエストなど。
ストレージ システム
  • 耐久性 - システムに書き込まれたデータに将来アクセスできる可能性。たとえば、99.9999% など。
  • Time to First Byte（TTFB） - リクエストを送信してからページの最初のバイトを受信するまでにかかる時間。
  • BLOB の可用性 - サーバーエラー以外のレスポンスを返す顧客リクエストの割合と顧客リクエストの合計数。
  • スループット
  • レイテンシ
リクエスト ドライブ システム
  • 可用性
  • レイテンシ
  • 品質
スケジュール実行システム
  • スキュー — 予想開始時間の許容時間内に開始される実行の割合。
  • 実行時間 - ジョブが完了するまでにかかった時間。1 つの実行でよく発生する障害の状態は、実際の実行時間がスケジュール時間よりも長くなることです。

さまざまな指標タイプを評価する

サービスに適した SLI を選択するだけでなく、SLI に使用する指標のタイプを決定する必要もあります。前のセクションで説明した SLI は、多くの場合、次のいずれかのタイプになります。

  • カウンタ: このタイプの指標は増加することはありますが、減少することはありません。例: ある測定ポイントまでに発生したエラーの数。
  • ゲージ: このタイプの指標は増加することも減少することもあります。例: キューの長さなど、システムの測定可能な部分の実際の値。
  • 分布（ヒストグラム）: 特定の期間に特定の測定セグメントに出現したイベントの数。たとえば、完了するまでに 0～10 ミリ秒、11～30 ミリ秒、31～100 ミリ秒かかったリクエストの数をそれぞれ測定できます。結果は、バケットごとのカウントになります（例: [0-10: 50]、[11-30: 220]、[31-100: 1103]）。

これらのタイプの詳細については、Cloud Monitoring の Prometheus プロジェクトのドキュメントと値の型と指標の種類をご覧ください。

指標の品質を考慮する

すべての指標が役立つわけではありません。イベントの総数に対する成功したイベントの割合とは別に、指標がニーズに合った SLI かどうかを判断する必要があります。その判断に役立つよう、以下に示す優れた指標の特徴を考慮してください。

  • 指標とユーザーの満足度が直接関係している。サービスの動作が遅い、不正確である、完全に機能しないなど、サービスが期待どおりに動作しないと、ユーザーは不満を抱きます。SLI をユーザーの満足度を示す他のシグナルと比較して、これらの指標に基づく SLO を検証します。この比較には、お客様からの苦情のチケット数、サポートの問い合わせの量、ソーシャル メディアの感情などのデータが含まれます。（詳しくは、SLO 目標の継続的な改善をご覧ください）。

    指標が、ユーザーの満足度を示すこのようなその他の指標に対応していない場合は、優れた SLI ではない可能性があります。

  • 指標の悪化とサービスの停止が相関している。サービスの停止中に良好なサービス結果を報告する指標は、明らかに SLI に適した指標ではありません。逆に、通常のオペレーション中に悪く見える指標も問題があります。

  • 指標の信号雑音比が良好。偽陰性や偽陽性が高頻度で発生する指標は却下してください。

  • 指標が、顧客の満足度に応じて単調かつ直線的にスケールされる。簡単に言えば、指標が改善するにつれて、顧客の満足度も向上するということです。

適切な数の指標を選択する

特に、サービスがさまざまなタイプの作業を行う場合や、さまざまなタイプのユーザーにサービスを提供する場合は、1 つのサービスに複数の SLI を設定できます。各タイプに適した指標を選択することをおすすめします。

一方、サービスの中には、直接比較できる、似たようなタイプの作業を行うものがあります。たとえば、ユーザーがサイト上のさまざまなページ（ホームページ、サブカテゴリ、トップ 10 リストなど）を表示する場合が該当します。これらのアクションごとに個別の SLI を作成するのではなく、単一の SLI カテゴリ（たとえば、ブラウズ サービスなど）に結合します。

類似したカテゴリのアクション間でユーザーの期待が大きく変化することは実際にはありません。ユーザーの満足度は、「商品の全ページをすぐに表示できたか？」という質問の回答から定量化できます。

サービスの許容範囲を正確に表現できる、可能な限り少ない数の SLI を使用します。一般的な指針として、2～6 個の SLI を使用します。SLI が少なすぎる場合、重要なシグナルを見落とす可能性があります。多すぎると、サポートチームが扱うデータの量が増えるだけで、追加のメリットはほとんどありません。SLI は、本番環境の健全性をシンプルに把握でき、全体像を把握できるものである必要があります。手に負えないもの（または期待外れで失望するようなもの）であってはなりません。

次のステップ