SLO を測定する

Last reviewed 2024-03-29 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、サービスレベル目標（SLO）に関するこれまでの議論を踏まえ、一般的なサービス ワークロードに関する測定の目的と方法について説明します。このドキュメントは、サービスレベル目標のコンポーネントで定義されているコンセプトに基づいています。

測定対象を決める

ドメインにかかわらず、多くのサービスが共通の機能を共有し、一般的な SLO を使用できます。このセクションでは、さまざまなサービスタイプに適用される一般的な SLO について説明し、各 SLO に適用される SLI について詳しく説明します。

以下のサブセクションでは、特定のサービスタイプについて説明し、そのサービスの簡単な説明を示します。それぞれのサービスタイプについて、可能な SLI、インジケーターの定義、SLI に関連するその他の情報を提供します。

リクエスト主導型サービス

このサービスタイプは、クライアント（ユーザーまたは別のサービス）からリクエストを受け取り、なんらかの計算を行い、ネットワーク リクエストをバックエンドに送信してクライアントにレスポンスを返します。

SLI としての可用性

可用性とは、正常に処理された有効なリクエストの割合です。可用性を SLI として使用する際に考慮すべき点を以下に示します。

  • 有効なリクエストはサービス オーナーが決定します。一般的な定義としては、「長さがゼロでないこと」、「クライアント サーバー プロトコルに準拠していること」などが考えられます。有効性を評価する方法の一つは、HTTP（または RPC）レスポンス コードの確認です。たとえば、HTTP 5xx コードは SLO にカウントされるサーバー関連のエラーですが、4xx コードはカウントされないクライアント エラーです。
  • サービスから返されたレスポンス コードを調べ、アプリケーションがこれらのコードを適切かつ一貫して使用しているかどうか確認する必要があります。コードがサービスに対するユーザー エクスペリエンスの正確な指標になっているか。たとえば、ユーザーが在庫切れの商品を注文しようとしたときの e コマースサイトの応答。リクエストが失敗してエラー メッセージが返されているかどうかを確認します。サイトで類似の商品を提案していますか。エラーコードは、ユーザーの期待に関連付ける必要があります。
  • デベロッパーがエラーの扱いを誤ることもあります。前述の「在庫切れ」のシナリオでは、デベロッパーが誤ってエラーを返す可能性があります。しかし、システムは正常に機能しており、エラーは発生していません。ユーザーがアイテムを購入できなかった場合でも、コードは成功を返す必要があります。サービス オーナーは在庫切れについて通知する必要がありますが、販売できないからといって、お客様にとってエラーが発生したわけではなく、SLO にカウントされるべきではありません。
  • 非同期リクエストを処理するサービスや、実行時間が長いプロセスをユーザーに提供するサービスは、より複雑なサービスです。可用性は別の方法で公開できますが、可用性は成功した有効なリクエストの割合として表すことをおすすめします。可用性は、お客様のワークロードが実行される時間（分）としても定義できます（「良好な時間」アプローチと呼ばれることもあります）。
  • 仮想マシン（VM）を提供するサービスについて考えてみましょう。可用性は、VM がユーザーに利用可能になった最初のリクエストからの分数で測定できます。

SLI としてのレイテンシ

レイテンシ（または速度）は、しきい値よりも速く処理された有効なリクエストの割合です。したがって、レイテンシはサービスの速さを示します。レイテンシは、特定のリクエスト タイプの開始時間と停止時間の差を計算することで測定できます。ユーザーは、このような認識でレイテンシをとらえていますが、サービス オーナーは通常、この値を非常に厳密に測定します。実際には、更新に 100 ミリ秒（ms）かかる場合と 300 ミリ秒かかる場合の差異をユーザーは識別できません。また、300～1,000 ミリ秒の範囲であれば許容範囲にすることもできます。詳細については、Rail モデルをご覧ください。

ユーザーに焦点を当てたアクティビティ中心の指標を開発します。以下に、このような指標の例を示します。

  • 操作: ユーザーが要素をクリックしてから結果が生成されるまでの時間（1,000 ミリ秒）。
  • 書き込み: 基盤となる分散システムの変更に 1,500 ミリ秒かかります。この時間は遅いとみなされますが、ユーザーは許容する傾向があります。指標に関しては、書き込みと読み取りを明示的に区別することをおすすめします。
  • バックグラウンド: データの定期更新やその他の非同期リクエストなど、ユーザーに表示されないアクション。完了までの所要時間は 5,000 ミリ秒未満です。

レイテンシは一般に分布として測定されます。SLI の選択をご覧ください。分布に応じて、さまざまなパーセンタイルを測定できます。たとえば、過去の 99 パーセンタイルよりも遅いリクエストの数を測定できます。このしきい値よりも速いイベントは良好とみなされ、遅いリクエストは良好ではないとみなされます。このしきい値は、プロダクト要件に基づいて設定します。通常のレイテンシとテール レイテンシなど、複数のレイテンシの SLO を設定することもできます。

平均（または中央値）のレイテンシのみを SLI として使用しないでください。レイテンシの中央値が極端に遅い場合、ユーザーの半数が不満を感じていることを示します。また、問題を発見するまでの数日の間に、サービスのレイテンシの悪化が発生する可能性があります。したがって、SLO はテール レイテンシ（95 パーセンタイル）と中央値のレイテンシ（50 パーセンタイル）で定義します。

ACM の記事 Metrics That Matter では、Benjamin Treynor Sloss 氏が次のように述べています。

  • 「実用的なレイテンシの目安では、レイテンシの 99 パーセンタイルが中央値のレイテンシの 3～5 倍を超えてはいけない。」
  • 「サービスのレイテンシの 50 パーセンタイル、95 パーセンタイル、99 パーセンタイルは計測の価値があり、それぞれを中心に SLO を設定するのが理想的である。」

過去のパーセンタイルに基づいてレイテンシのしきい値を決定し、各バケットに該当するリクエストの数を測定します。このアプローチは適切なモデルです。

SLI としての品質

品質は、サービスの低下なしに処理された有効なリクエストの割合です。たとえば、品質は、安全に失敗するように設計された複雑なサービスに役立つ SLI です。たとえば、1 つのデータストアからメイン コンテンツを読み込み、必要に応じて、さらに 100 個のサービスとデータストアからオプションのアセットを読み込むウェブページを考えてみましょう。オプション要素のいずれかが使用不能か、遅すぎる場合でも、そのページはオプション要素なしでレンダリングできます。このシナリオでは、SLI を使用して次のことができます。

  • 中断したレスポンス（少なくとも 1 つのバックエンド サービスからの返信がないレスポンス）を受け取るリクエストの数を測定すると、不正なリクエストの割合を報告できます。
  • 1 つのバックエンドまたは複数のバックエンドからのレスポンスがないレスポンスを追跡できます。

データ処理サービス

これらのサービスは入力プロセスのデータを使用して出力を生成します。中間ステップでのサービスのパフォーマンスは、最終的な結果ほど重要ではありません。最も強力な SLI は、鮮度、カバレッジ、正確性、スループットです。レイテンシと可用性は、あまり役に立ちません。

SLI としての鮮度

鮮度は、しきい値よりも最近更新された有効なデータの割合です。以下に、鮮度を SLI として使用する例を示します。

  • バッチシステムでは、特定の出力に対する処理の実行が正常に完了した後の経過時間として鮮度が測定されます。
  • リアルタイム処理やより複雑なシステムでは、パイプラインで処理された直近のレコードの経過時間を鮮度でトラッキングします。
  • マップタイルをリアルタイムで生成するオンライン ゲームの場合、ユーザーはマップタイルの作成速度を気にしないかもしれませんが、マップデータがない場合や古くなっていることには気付くかも知れません。この場合、欠落したデータや古いデータを鮮度でトラッキングします。
  • トラッキング システムからレコードを読み取り、e コマース ウェブサイト用に「在庫のある商品 X」というメッセージを生成するサービスでは、鮮度の SLI を、最近更新された（1 分以内の）在庫情報を使用しているリクエストの割合として定義できます。
  • 鮮度の低いデータを更新するための指標を使用して、品質の SLI に通知することもできます。

SLI としてのカバレッジ

カバレッジは、正常に処理された有効なデータの割合です。

カバレッジを定義する手順は次のとおりです。

  1. 入力を有効として受け入れるか、スキップするかを決定します。たとえば、入力レコードが破損しているか、長さがゼロで処理できない場合、そのレコードを指標として無効とみなすことができます。
  2. 有効なレコードの数をカウントします。このカウントは、単純な *count()* メソッドで実行でき、レコードの合計数を表します。
  3. 最後に、正常に処理されたレコードの数を計算し、その数を有効なレコードの総数と比較します。この値がカバレッジの SLI になります。

SLI としての正確性

正確性は、正しい出力を生成した有効なデータの割合です。正確性を SLI として使用する場合は、次の点を考慮してください。

  • 場合によっては、出力の正確性を判断するためのメソッドを使用して、出力の処理を検証します。たとえば、画像の回転や色付けを行うシステムでは、ゼロバイトの画像や、長さまたは幅がゼロの画像を生成することはできません。この検証ロジックは、処理ロジックそのものから分離することが重要です。
  • 正確性 SLI を測定する一つの方法は、既知の正常なテスト入力データを使用することです。このタイプのデータは、既知の正しい出力を生成するデータです。入力データはユーザーデータを表している必要があります。
  • 画像を回転させる前の例のように、出力に対して数学的または論理的なチェックを実行できる場合もあります。
  • 最後に、トランザクションの前後の残高の差異を確認することで、その有効性を判断する課金システムについて考えてみましょう。これがトランザクション自体の値と一致する場合、それは有効なトランザクションとなります。

SLI としてのスループット

スループットは、データ処理速度がしきい値よりも速い時間の割合です。スループットを SLI として使用する場合は、次の点に注意してください。

  • データ処理システムのスループットは、多くの場合、特定のオペレーションの単一のレイテンシ測定値よりもユーザーの満足度を表しています。各入力のサイズに大きな変化があれば、すべてのジョブが許容速度で進んだ場合の各要素の実行にかかる時間を比較することは意味がありません。
  • 1 秒あたりのバイト数は、データセットのサイズに関係なく、データの処理にかかる時間を測定する一般的な方法です。ただし、処理コストについてほぼ直線的にスケーリングされる指標であればどれでも機能します。
  • 予想されるスループット率に基づいてデータ処理システムを分割することも検討の価値があります。または、優先度の高い入力が処理され、優先度の低い入力がキューに追加されるようにサービス品質システムを実装します。いずれにしても、このセクションで定義されているスループットを測定することで、システムが SLO の範囲内で動作しているかどうかを判断できます。

スケジュールされた実行サービス

Kubernetes cron ジョブなど、定期的にアクションを実行する必要があるサービスについては、スキューと実行時間を測定します。以下に、スケジュールされた Kubernetes cron ジョブの例を示します。

  apiVersion: batch/v1beta1
  kind: CronJob
  metadata:
  name: hello
  spec:

  schedule: "0 * * * *"

SLI としてのスキュー

スキューは、予想開始時間の許容時間内に開始される実行の割合です。スキューを使用する場合は、次の点に注意してください。

  • スキューは、ジョブの開始予定時刻と実際の開始時刻との時間差を測定します。前述の Kubernetes cron ジョブの例を考えてみましょう。毎時間 0 分に開始するように設定されているジョブが 3 分遅れて開始した場合、スキューは 3 分です。ジョブが早く実行されると、負のスキューが生じます。
  • スキューは、適切なスキューを定義する許容範囲とともに、時間の経過に伴う分布として測定できます。SLI を決定するには、適切な範囲内の実行数を比較します。

SLI としての実行時間

実行時間は、許容時間内に完了した実行の割合です。以下では、実行時間の使用に関連する重要なコンセプトについて説明します。

  • 実行時間とは、ジョブが完了するまでにかかった時間です。実行でよく発生する障害の状態は、実際の実行時間がスケジュールよりも長くなることです。
  • この SLI の興味深い活用方法として、たとえば、終了しないジョブに適用する方法があります。これらのジョブは完了しないため、ジョブの完了を待つのではなく、特定のジョブの所要時間を記録します。このアプローチでは、最悪の場合であっても、完了までにかかる時間の正確な分布を把握できます。
  • スキューと同様に、実行時間を分布として追跡し、良好なイベントの許容範囲の上限と下限を定義できます。

他のシステムタイプの指標

他の多くのワークロードには、SLI と SLO を生成するための独自の指標があります。以下の例を考えてみましょう。

  • ストレージ システム: 耐久性、スループット、最初のバイトまでの時間、blob の可用性。
  • メディア / 動画: クライアントの再生継続時間、再生を開始するまでの時間、コード変換グラフの実行完了。
  • ゲーム: アクティブなプレーヤーと対戦するまでの時間、マップを作成するまでの時間。

測定方法を決める

前のセクションでは、測定対象について説明しました。測定対象が決まったら、測定方法を決めます。SLI 指標は、いくつかの方法で収集できます。以降のセクションでは、いくつかの測定方法を取り上げ、その長所と短所を列挙し、その方法に適した実装ツールについて説明します。

サーバーサイド ロギング

サーバーサイド ロギングでは、リクエストまたは処理データのサーバーサイド ログを処理します。

サーバーサイド ロギング 詳細
利点
  • 既存のログを再処理して、過去の SLI レコードをバックフィルします。
  • サービス間セッション ID を使用して、複数のサービスにまたがる複雑なユーザー ジャーニーを再構築します。
欠点
  • サーバーに届かなかったリクエストは記録されません。
  • サーバーのクラッシュを引き起こすリクエストが記録されない場合があります。
  • ロギングの時間によっては、古くなった SLI が発生する可能性があります。このため、運用のレスポンスとしては不十分なデータとなる可能性があります。
  • ログを処理するコードの記述は、エラーが発生しやすく時間がかかります。
実装方法とツール

アプリケーション サーバーの指標

アプリケーション サーバー指標では、ユーザー リクエストを処理するコードまたはデータを処理するコードから SLI 指標をエクスポートします。

アプリケーション サーバーの指標 詳細
利点
  • 通常、コードへ新しい指標を追加することはすばやく、低コストで可能です。
欠点
  • アプリケーション サーバーに届かなかったリクエストは記録されません。
  • マルチサービス リクエストは追跡が難しい場合があります。
実装方法とツール

フロントエンド インフラストラクチャの指標

フロントエンド インフラストラクチャ指標では、ロード バランシング インフラストラクチャ（Google Cloud のグローバル レイヤ 7 ロードバランサなど）の指標を使用します。

フロントエンド インフラストラクチャの指標 詳細
利点
  • 通常、指標と過去のデータがすでに存在するため、エンジニアリング作業を軽減できます。
  • 測定は、お客様の最も近くでありながらも、サービスを提供するインフラストラクチャ内で行われます。
欠点
  • データ処理の SLI では使用できません。
  • 複数リクエストのユーザー ジャーニーの概算値です。
実装方法とツール

合成クライアントまたはデータ

合成クライアントまたはデータでは、定期的に偽のリクエストを送信し、レスポンスを検証するクライアントを使用します。

合成クライアントまたはデータ 詳細
利点
  • マルチリクエストのユーザー ジャーニーにおけるすべてのステップを測定します。
  • インフラストラクチャの外部からリクエストを送信することで、SLI のリクエストパス全体がキャプチャされます。
欠点
  • 合成リクエストに対するユーザー エクスペリエンスの近似値であり、誤解を招く可能性もあります（偽陽性と偽陰性）。
  • 特殊なケースをすべてカバーするのは難しいため、統合テストが必要になります。
  • 高い信頼性目標を実現するには、正確な測定を行うために頻繁に調べる必要があります。
  • プローブのトラフィックによって、実際のトラフィックが減少する可能性があります。
実装方法とツール

クライアント計測

クライアント計測では、ユーザーが操作するクライアントにオブザーバビリティ機能を追加し、SLI を追跡するサービス インフラストラクチャにイベントをログに記録します。

クライアント計測 詳細
利点
  • ユーザー エクスペリエンスを最も正確に評価できます。
  • CDN や決済機関などのサードパーティの信頼性を数値化できます。
欠点
  • クライアント ログの取り込みと処理のレイテンシのため、運用上のレスポンスのトリガーには適しません。
  • SLI の測定値には、直接的な制御の対象外の可能性がある、変動が激しい要素が多数含まれます。
  • 計測をクライアントに組み込むには、多くのエンジニアリング作業が必要になる場合があります。
実装方法とツール

測定方法を選択する

SLO の測定方法と測定内容を決定したら、次に、労力を最小限に抑えるため、サービスに対するお客様のエクスペリエンスに最も近い測定方法を選択します。そのために、上記の表で説明した方法の組み合わせが必要になることもあります。以下に、実装可能な推奨アプローチを手軽な順に説明します。

  • アプリケーション サーバーのエクスポートとインフラストラクチャの指標を使用する。通常、これらの指標にはすぐにアクセスでき、値もすぐにわかります。一部の APM ツールには、SLO ツールが組み込まれています。
  • クライアント計測を使用する。以前のシステムでは通常、エンドユーザーのクライアント計測が組み込まれていないため、計測の設定には多大な投資が必要になります。ただし、クライアント計測を提供する APM スイートまたはフロントエンド フレームワークを使用すると、顧客満足度に関する分析情報がすぐに手に入ります。
  • ログ処理を使用する。サーバー エクスポートやクライアント計測（前述）を実装できないが、ログが存在する場合は、ログ処理が最適なアプローチです。もう 1 つの方法は、エクスポートとログ処理を組み合わせることです。エクスポートを一部の SLI（即時の可用性など）の即時ソースとして使用し、ログ処理を長期間のシグナルガイド（SLO とアラートで説明する低速バーンのアラートなど）として使用します。
  • 合成テストを実装する。お客様がどのようにサービスを利用しているかについて基本的なことを把握したら、サービスをテストします。たとえば、テスト アカウントで正常であることが確認されているデータをシードし、そのデータを照会します。このアプローチは、トラフィックが少ないサービスなど、容易に確認できなかったエラーモードを特定するのに効果的です。

次のステップ