SLO の導入

このドキュメントでは、さまざまな種類の一般的なサービス ワークロードに役立つサービスレベル目標（SLO）をいくつか定義します。このドキュメントは 2 部構成の後半です。パート 1 SLO の定義では、SLO について紹介し、サービスレベル指標（SLI）から SLO がどのように導出されるか、そしてどのような SLO が適切かについて説明しています。

State of DevOps で、ソフトウェア デリバリーのパフォーマンスを向上させると認められた機能が報告されています。これら 2 つのドキュメントでは、次の機能について説明します。

測定データ

ドメインにかかわらず、多くのサービスが共通の機能を共有し、一般的な SLO を使用できます。以下では、サービスタイプ別に一般的な SLO に関して考察しており、各 SLO に適用される SLI について詳しく説明します。

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

リクエスト主導型サービスは、クライアント（別のサービスまたはユーザー）からリクエストを受け取り、なんらかの計算を行い、ネットワーク リクエストをバックエンドに送信し、続いてクライアントにレスポンスを返します。リクエスト主導型サービスは、多くの場合、可用性 SLI とレイテンシ SLI によって測定されます。

SLI としての可用性

可用性の SLI は、サービスが稼働しているかどうかを示します。可用性の SLI は次のように定義されます。

正常に処理された有効なリクエストの割合。

最初に、「有効」の定義を決める必要があります。基本的な定義としては、「長さがゼロでないこと」や「クライアント サーバー プロトコルに準拠していること」などが考えられますが、「有効」の定義を決定するのはサービス オーナーです。有効性を評価する一般的な方法は、HTTP（または RPC）レスポンス コードを使用することです。たとえば、通常、HTTP 500 エラーは SLO にカウントされるサーバーエラーと判断され、400 エラーはクライアント エラーで SLO にカウントされません。

測定対象を決めたら、システムから返されたすべてのレスポンス コードを調べ、アプリケーションがそれらのコードを適切かつ一貫して使用していることを確認します。SLO のエラーコードを使用する場合は、コードがサービスに対するユーザー エクスペリエンスの正確な指標であるかどうかを確認することが重要です。たとえば、ユーザーが在庫切れの商品を注文しようとした場合、サイトは中断してエラー メッセージを返しますか、それとも類似商品を提案しますか。SLO で使用するには、エラーコードをユーザーの期待に関連付ける必要があります。

開発者がエラーの取り扱いを誤るということも考えられます。ユーザーが一時的に在庫切れの商品をリクエストした場合に、開発者が誤ってエラーを返すようプログラムしている場合があります。しかし、実際にはシステムは正しく機能しており、エラーは発生していません。コードはユーザーが必要なアイテムを購入できなくても、成功として返す必要があります。もちろん、このサービスのオーナーは商品が在庫切れであることを把握する必要があります。ただし、販売できないからといって、お客様にとってエラーが発生したわけではなく、SLO にカウントされるべきではありません。ただし、サービスがデータベースに接続できないためアイテムの在庫があるか判断できない場合は、エラーとなり、エラー バジェットにカウントされます。

サービスがより複雑である場合も考えられます。たとえば、サービスが非同期リクエストを処理している場合や、実行時間が長いプロセスをユーザーに提供している場合が該当します。このような場合は、別の方法で可用性を公開できます。ただし、やはり可用性は成功した有効なリクエストの割合として表すことをおすすめします。可用性は、お客様のワークロードがリクエストどおりに実行される時間（分）として定義できます（このアプローチは、可用性を測定するための「良好な時間」の方法と呼ばれることもあります）。仮想マシンの可用性は、VM に SSH でアクセスできる、VM の最初のリクエスト後の分数の割合で測定できます。

SLI としてのレイテンシ

レイテンシ（速度ともいいます）の SLI は、サービスの速度が十分かどうかを示します。レイテンシの SLI は可用性と同様に定義されます。

しきい値よりも速く処理された有効なリクエストの割合。

レイテンシを測定するには、リクエスト タイプごとのタイマーの開始と停止までの時間差を計算します。重要なことは、ユーザーによってレイテンシが認識されるかどうかです。よくある間違いは、レイテンシを正確に測定しすぎることです。実際には、更新に 100 ミリ秒（ms）要する場合と 300 ミリ秒要する場合の差異をユーザーは識別できません。また、300～1,000 ミリ秒の範囲であれば許容範囲とする可能性があります。

代わりに、アクティビティ ベースの指標を開発することをおすすめします。そうすることで、ユーザーは次のプロセスに集中できます。

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

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

平均（または中央値）レイテンシのみを SLI として使用することは、おすすめしません。レイテンシの中央値が極端に遅い場合、ユーザーの半数が不満を感じていることを示します。つまり、長期的なエラー バジェットに対する現実的な脅威を発見できるまで、数日間にわたってレイテンシの悪化が続く可能性があります。したがって、SLO をテール レイテンシ（95 パーセンタイル）と中央値のレイテンシ（50 パーセンタイル）で定義することをおすすめします。

ACM の記事 Metrics That Matter では、Benjamin Treynor Sloss 氏が以下の内容を執筆しています。

「実用的なレイテンシの目安では、レイテンシの 99 パーセンタイルが中央値のレイテンシの 3～5 倍を超えてはいけません。」

Treynor Sloss 氏はさらに次のように続けています。

「サービスのレイテンシの 50 パーセンタイル、95 パーセンタイル、および 99 パーセンタイルは計測する価値があり、それぞれを中心に SLO を設定するのが理想的です。」

適切なモデルでは、続いて過去のパーセンタイルに基づいてレイテンシのしきい値を決めて、各バケットに該当するリクエストの数を測定します。詳しくは、このドキュメントの後半のレイテンシのアラートに関するセクションをご覧ください。

SLI としての品質

品質の SLI は、複雑なサービスに役立ちます。たとえば、依存関係が遅いときや使用できないときに、中断することで安全に失敗するよう設計されているサービスです。品質の SLI は次のように定義されます。

サービスの中断なしに処理された有効なリクエストの割合。

たとえば、ウェブページで 1 つのデータストアからメイン コンテンツを読み込み、必要に応じて 100 個のサービスとデータストアから補助的なアセットを読み込むこともできます。オプションのサービス 1 つが使用不能であるか、遅すぎる場合であっても、補助的要素なしでそのページはレンダリングできます。中断したレスポンスが返されたリクエストの数（つまり、少なくとも 1 つのバックエンド サービスのレスポンスがないレスポンス）を測定すると、不正なリクエストの割合を報告できます。また、1 つのバックエンドからのレスポンスがないユーザーへのレスポンス数や、複数のバックエンドからのレスポンスがないユーザーへのレスポンス数を追跡することもできます。

データ処理サービス

一部のサービスはユーザー リクエストに応答するのではなく、入力からデータを消費し、そのデータを処理して出力を生成するよう設計されています。中間ステップでこれらのサービスがどのように実行されるかは、最終的な結果ほど重要ではありません。このようなサービスでは、最も強力な SLI は鮮度、カバレッジ、正確性、スループットであり、レイテンシと可用性ではありません。

SLI としての鮮度

鮮度の SLI は次のように定義されます。

しきい値よりも最近更新された有効なデータの割合。

たとえば、バッチ処理システムの鮮度は、特定の出力に対する処理の実行が正常に完了した後の経過時間として測定できます。より複雑なシステムまたはリアルタイムの処理システムの場合、パイプラインで処理された直近のレコードの経過時間をトラッキングできます。

たとえば、リアルタイムでマップタイルを生成するオンライン ゲームについて考えてみましょう。マップタイルがすぐに作成された場合にはユーザーの気に留まらなくても、マップデータがない場合や、新しくないことには気が付くかも知れません。

または、在庫追跡システムからレコードを読み取って、e コマースのウェブサイト用に「在庫のある商品 X」というメッセージを生成するシステムについて考えてみましょう。鮮度の SLI は、次のように定義できます。

過去 1 分間に更新された在庫情報を使用したビューの割合。

鮮度の低いデータを提供するための指標を使用して、品質の SLI に通知することもできます。

SLI としてのカバレッジ

カバレッジの SLI は次のように定義されます。

正常に処理された有効なデータの割合。

カバレッジを定義するには、まず、入力を有効として受け入れるか、スキップするかどうかを決定します。たとえば、入力レコードが破損しているか、長さがゼロであり、処理できない場合、そのレコードをシステムの測定には無効とみなすことができます。

次に、有効なレコードの数をカウントします。この手順は、シンプルな count() メソッドまたは別のメソッドでも実施できます。この数字がレコードの合計数です。

最後に、カバレッジの SLI を生成するには、正常に処理されたレコードの数を計算し、その数を有効なレコードの総数と比較します。

SLI としての正確性

正確性の SLI は次のように定義されます。

正しい出力を生成した有効なデータの割合。

場合によっては、出力の正確性を判断するための方法を使用して、出力の処理を検証できます。たとえば、画像の回転や色付けを行うシステムでは、ゼロバイトの画像や、長さまたは幅がゼロの画像を生成することはできません。この検証ロジックは、処理ロジックそのものから分離することが重要です。

正確性 SLI を測定する 1 つの方法は、既知の正常なテスト入力データを使用することです。このデータには、既知の正しい出力データが含まれるようにします。入力データはユーザーデータを表している必要があります。場合によっては、画像を回転させる前の例のように、出力に対して数学的または論理的なチェックを行うこともできます。もう 1 つの例としては、トランザクション前後の残高の差額とトランザクションの金額が一致するかどうかを確認することで、トランザクションが有効かどうかを判断する課金システムがあります。

SLI としてのスループット

スループットの SLI は次のように定義されます。

データ処理率がしきい値よりも速い時間の割合。

データ処理システムでは、スループットは多くの場合、特定のリクエストのレイテンシ測定値の 1 つではなく、ユーザー満足度を表します。たとえば、各入力のサイズに大きな変化があれば、ジョブが許容速度で進んだ場合の各要素の実行にかかる時間を比較することは意味がありません。

1 秒あたりのバイト数は、データセットのサイズに関係なく、データの処理にかかる時間を測定する一般的な方法です。ただし、処理コストについてほぼ直線的にスケーリングされる指標であればどれでも機能します。

予想されるスループット率に基づいてデータ処理システムを分割することや、優先度が高い入力が処理され、優先度が低い入力がキューに追加されるようにサービス品質システムを実装することも検討の価値があります。いずれにしても、このセクションで定義されているスループットを測定することで、システムが期待どおりに機能しているかどうか判断できます。

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

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

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "0 * * * *"

SLI としてのスキュー

SLI の場合、スキューは次のように定義されます。

予想開始時刻の許容時間内に開始される実行の割合。

スキューは、ジョブの開始予定時刻から実際に開始するまでの時間差を測定します。たとえば、毎時間 0 分に開始されるように設定されている上記の Kubernetes cron ジョブの場合、毎時間 3 分が経過してから開始され、スキューは 3 分となります。ジョブが早く実行されると、負のスキューが生じます。

スキューは、適切なスキューを定義する許容範囲とともに、時間の経過に伴う分布として測定できます。SLI を決定するには、適切な範囲内の実行数を比較します。

SLI としての実行時間

SLI の場合、実行時間は次のように定義されます。

許容時間内に完了した実行の割合。

実行時間とは、ジョブが完了するまでにかかった時間です。1 つの実行でよく発生する障害の状態は、実際の実行時間がスケジュールよりも長くなることです。

この SLI の興味深い活用方法として、たとえば、終了しないジョブを検出するために使用する方法があります。これらのジョブは完了しないため、ジョブの完了を待つのではなく、特定のジョブの所要時間を記録する必要があります。このアプローチでは、最悪の場合であっても、完了までにかかる時間の正確な分布を把握できます。

スキューと同様に、実行時間を分布として追跡し、良好なイベントの許容範囲の上限と下限を定義できます。

他のシステムの指標の種類

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

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

測定方法

測定するものがわかると、測定方法を決定できるようになります。SLI はいくつかの方法で収集できます。

サーバー側のロギング

SLI を生成する方法

リクエストまたは処理データのサーバー側のログを処理する。

考慮事項

メリット:

  • 既存のログを再処理して、過去の SLI レコードをバックフィルできます。
  • サービス間セッション ID を使用すると、複数のサービスにまたがる複雑なユーザー ジャーニーを再構築できます。

デメリット:

  • サーバーに届かなかったリクエストは記録されません。
  • サーバーのクラッシュを引き起こすリクエストが記録されない場合があります。
  • ログ処理の時間によっては、古くなった SLI が発生する可能性があります。このため、運用レスポンスには不十分なデータとなる可能性があります。
  • ログを処理するコードの記述は、エラーが発生しやすく時間がかかります。

実装方法とツール:

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

SLI を生成する方法

ユーザーからのリクエストを処理する、またはデータを処理するコードから SLI 指標をエクスポートする。

考慮事項

メリット:

  • 通常、コードへ新しい指標を追加することはすばやく、低コストで可能です。

デメリット:

  • アプリケーション サーバーに届かなかったリクエストは記録されません。
  • マルチサービス リクエストは追跡が難しい場合があります。

実装方法とツール:

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

SLI を生成する方法

負荷分散インフラストラクチャ（Google Cloud のグローバル レイヤ 7 ロードバランサなど）の指標を使用する。

考慮事項

メリット:

  • 通常、指標と過去のデータがすでに存在するため、エンジニアリング作業を軽減できます。
  • 測定は、お客様の最も近くでありながらも、サービスを提供するインフラストラクチャ内で行われます。

デメリット:

  • データ処理の SLI では使用できません。
  • 複数リクエストのユーザー ジャーニーの概算値です。

実装方法とツール:

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

SLI を生成する方法

定期的に構築されたリクエストを送信するクライアントを構築し、レスポンスを検証する。データ処理パイプラインの場合は、既知の正常な入力データを作成し、出力を検証します。

考慮事項

メリット:

  • マルチリクエストのユーザー ジャーニーにおけるすべてのステップを測定します。
  • インフラストラクチャの外部からリクエストを送信することで、SLI のリクエストパス全体がキャプチャされます。

デメリット:

  • 合成リクエストに対するユーザー エクスペリエンスの近似値であり、誤解を招く可能性もあります（偽陽性と偽陰性の両方）。
  • 特殊なケースをすべてカバーするのは難しいため、統合テストが必要になります。
  • 高い信頼性目標を実現するには、正確な測定を行うために頻繁に調べる必要があります。
  • プローブのトラフィックによって、実際のトラフィックが減少する可能性があります。

実装方法とツール:

クライアント インストルメンテーション

SLI を生成する方法

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

考慮事項

メリット:

  • ユーザー エクスペリエンスを最も正確に評価できます。
  • CDN や決済機関などのサードパーティの信頼性を数値化できます。

デメリット:

  • クライアント ログの取り込みと処理のレイテンシのため、運用上のレスポンスのトリガーには適しません。
  • SLI の測定値には、直接的な制御の対象外の可能性がある、変動が激しい要素が多数含まれます。
  • インストルメンテーションをクライアントに組み込むには、多くのエンジニアリング作業が必要になる場合があります。

実装方法とツール:

測定方法の選択

理想的には、サービスに対するお客様のエクスペリエンスに最も近い測定方法を選択し、労力を最小限に抑える必要があります。それには、上記の表のメソッドを組み合わせる必要が生じることもあります。以下に、時間の経過に伴い実装できる推奨アプローチを、手軽な順に示します。

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

目標の設定

目標を設定する最善の方法の 1 つは、SLO とその開発方法を記述した共有ドキュメントを作成することです。SLO を実装し、反復作業を重ねるにあたり、チームがドキュメントを繰り返し使用できます。

ビジネス オーナー、プロダクト オーナー、エグゼクティブが、このドキュメントを確認することをおすすめします。このような関係者は、サービスの期待とプロダクトの信頼性のトレードオフに関する分析情報を提供できます。

会社にとって最も重要なユーザー ジャーニー（CUJ）用に、SLO を開発するためのテンプレートは次のとおりです。

  1. SLI 仕様（可用性や鮮度など）を選択します。
  2. SLI 仕様の実装方法を定義します。
  3. 計画に目を通し、CUJ がカバーされていることを確認します。
  4. 過去のパフォーマンスまたはビジネスニーズに基づいて SLO を設定します。

CUJ は、1 つのサービスまたは 1 つの開発チームまたは組織に制限しないでください。99.5% で動作する数百のマイクロサービスに依存しているもののエンドツーエンドの可用性をまったく追跡していなければ、顧客満足度は低い可能性があります。

ロードバランサ、フロントエンド、ミキサー、バックエンド、データベースの 5 つのサービスに順番に依存するクエリがあるとします。

各コンポーネントの可用性が 99.5% であれば、ユーザーにとっての可用性は最悪の場合、次のようになります。

99.5% × 99.5% × 99.5% × 99.5% × 99.5% = 97.52%

これは、5 つのサービスのいずれかにエラーが発生するとシステム全体がエラーとなるため、ユーザーにとって最悪のケースの可用性となります。このケースに該当するのは、スタックの全レイヤが各ユーザー リクエストを処理するためにすぐに使用でき、中間での再試行やキャッシュ、クエリなど復元力を高める要素がない場合のみです。このようにサービスを緊密に結合させるシステム設計は不適切であり、マイクロサービス モデルを否定するものです。

分散サービスの SLO に対してパフォーマンスを部分的に測定しても（サービス別）、お客様のエクスペリエンスは正確に反映されず、慎重すぎる解釈をしてしまう可能性があります。

代わりに、フロントエンドで SLO とパフォーマンスを比較して、ユーザー エクスペリエンスを把握します。コンポーネント サービスに障害が発生しても（クエリが自動的に再試行されるため）、ユーザークエリが成功しても、ユーザーには影響がありません。内部サービスを共有している場合、これらのサービスは、お客様とのやり取りとして機能するユーザー向けのサービスを使用して SLO のパフォーマンスを個別に測定できます。SLO は互いに独立して処理する必要があります。

スマート再試行、キャッシュ保存、キューイングなどの復元力を高める要素を使用することで、可用性の低いサービス（99.9% など）の上に高可用性サービス（99.99% など）を構築できます。

一般的に、統計学の実用的知識があれば、基盤となるサービスまたは組織のレイアウトを理解していなくても、SLO を読んで理解できます。

SLO ワークシートの例

SLO を開発する際には、次のことを実施するよう留意してください。

  • SLI でイベント、成功基準、成功と失敗の記録方法が指定されていることを確認します。
  • 良好なイベントの割合で SLI 仕様を定義します。
  • SLO で、ターゲット レベルと測定機関の両方が指定されていることを確認します。
  • 関係者が付随するトレードオフと細かい点を理解できるよう、アプローチのメリットとデメリットについて説明します。

たとえば、次の SLO ワークシートを検討してください。

CUJ: ホームページの読み込み

SLI タイプ: レイテンシ

SLI 仕様: 100 ミリ秒未満で処理されるホームページ リクエストの割合

SLI 実装:

  • サーバーログのレイテンシ列から測定された、100 ミリ秒未満で処理されるホームページのリクエストの割合（デメリット: この測定では、バックエンドに到達できないリクエストは含まれません）。
  • 仮想マシン上で実行されているブラウザで JavaScript を実行するプローバーによって測定された、100 ミリ秒未満で処理されるホームページのリクエストの割合（メリットとデメリット: この方法では、リクエストがネットワークに到達できない場合のエラーは取得しますが、ユーザーのサブネットにのみ影響する問題は取得されません）。

SLO: 100 ミリ秒未満で処理された過去 28 日間のホームページ リクエストの 99%

SLO とアラート

SLO などの新しいオブザーバビリティ システムの導入における誤ったアプローチは、そのシステムで古いシステムを完全に置き換えることです。そうではなく、SLO は補完するためのシステムとして考えるべきです。たとえば、既存のアラートを削除する代わりに、ここで説明する SLO アラートと並行して実行することをおすすめします。このアプローチでは、SLO アラートを予測するレガシー アラート、SLO アラートと並行して実行されるアラート、起動しないアラートを特定できます。

SRE の原則は、原因ではなく、症状に基づいてアラートを出すことです。SLO は、その性質上、症状の測定値です。SLO アラートを導入すると、症状アラートが他のアラートとともに起動される場合があります。原因ベースのレガシー アラートが SLO や症状なしで起動する場合、これらを完全に停止することを検討し、チケット発行アラートに変更するか、後から参照するためにログに記録します。

このトピックの詳細については、SRE ワークブック、第 5 章をご覧ください。

SLO バーンレート

SLO のバーンレートとは、障害が発生してから、ユーザーがエラーの影響を受け、エラー バジェットがすべて消費されるまでの速度を表します。バーンレートを測定すると、サービスが SLO に違反するまでの時間を判断できます。SLO のバーンレートに基づいたアラート作成は、有用なアプローチです。SLO は期間に基づくもので、きわめて長期間（数週間または数か月）にわたることもあるので注意してください。ただし、SLO 違反が実際に発生する前に、その違反につながる条件をすばやく検出することが目的です。

次の表は、秒間クエリ数（QPS）が一定であると仮定し、所定の期間内にリクエストが 100% 失敗した場合の、目標の達成までにかかる時間を示します。たとえば、30 日間で 99.9% の SLO を測定した場合、その 30 日間は 43.2 分のダウンタイムを許容できます。このようなダウンタイムは、たとえば一度にまとめて発生しても、複数のインシデントにわたって間隔を空けて発生してもかまいません。

目的 90 日 30 日 7 日 1 日
90% 9 日 3 日 16.8 時間 2.4 時間
99% 21.6 時間 7.2 時間 1.7 時間 14.4 分
99.9% 2.2 時間 43.2 分 10.1 分 1.4 分
99.99% 13 分 4.3 分 1 分 8.6 秒
99.999% 1.3 分 25.9 秒 6 秒 0.9 秒

実際には、高い成功率を達成するためには、100% の停止インシデントが発生しないようにする必要があります。ただし、多くの分散システムは、部分的に停止することや安全に低下する場合があります。SLO アラートは、このような部分的な障害であっても、人為的に阻止する必要があるかどうかを判断する方法を提供します。

アラートのタイミング

重要なのは、SLO のバーンレートに基づいて行動を起こすタイミングです。一般に、エラー バジェットが 24 時間で枯渇する場合、すぐに修正を依頼する必要があります。

失敗率の測定は必ずしも簡単ではありません。小さなエラーが続くと不安があおられてしまいますが、結局はすぐに解決して SLO への影響もほとんどない場合もあります。同様に、システムが長期間にわたってわずかに破損している場合、このようなエラーが SLO 違反につながることもあります。

理想的には、チームがこれらのシグナルに対応して、特定の期間に発生したエラー バジェットのほとんどを使い切るようにします（ただし、上限を超えないようにします）。エラー バジェットを使いすぎると、SLO に違反してしまいます。少なすぎると、十分なリスクを負っていないことになり、オンコール チームの負担が大きくなってしまいます。

そこで、人為的な介入を必要とするほどシステムが破損していると判断するタイミングを決定する方法が必要です。以下のセクションでは、この質問に対するアプローチについて説明します。

高速バーン

SLO バーンの種類の 1 つは、高速 SLO バーンです。エラー バジェットの消費ペースが速く、SLO 違反を避けるために介入を要求するからです。

サービスの通常の秒間クエリ数（QPS）が 1,000 であり、7 日間の測定結果で 99% の可用性を維持したいとします。エラー バジェットは、約 600 万のエラー（約 6 億のリクエストのうち）を許容しています。たとえば、エラー バジェットを使い切るまでに 24 時間あれば、毎秒約 70 個、または 1 時間に 252,000 個がエラー数の上限となります。これらのパラメータは、連絡可能なインシデントが四半期ごとのエラー バジェットの 1% 以上を消費する必要があるという一般的なルールに基づいています。

1 時間が経過する前に、エラーのレートを検出するかを選択できます。たとえば、次の図に示すように、1 秒あたり 70 エラーのレートが 15 分間観察された後に、オンコール エンジニアに連絡することもできます。

画像

24 時間の予算のうち 1 時間を費やす前に、問題を解決するのが理想的です。このレートを短い時間枠（1 分間など）で検出すると、エラーが発生しやすくなります。ターゲットの平均検出時間（MTTD）が 15 分未満の場合は、この数値を調整できます。

低速バーン

もう 1 つの種類のバーンレートは、低速バーンです。たとえば、週のエラー バジェットを 5 日目または 6 日目までに使い切るバグや、月のバジェットを 2 週目までに使い切るバグが発生したとします。どのように対応することが最適でしょうか。

この場合、低速 SLO バーンアラートを導入し、アラート ウィンドウが終了する前に、エラー バジェットすべてを使い切ることになると通知を受け取ります。もちろん、このアラートによって偽陽性が多数返される可能性もあります。たとえば、エラーは短時間であるものの、エラー バジェットをすばやく消費する速度で発生する条件がよく発生するとします。その場合、短時間しか継続せず、長期的にエラー バジェットを脅かさないため、条件は偽陽性になります。目標は、エラーのソースをすべて排除することではなく、エラー バジェットを超えないように許容範囲以内に収めることです。エラー バジェットを脅かすことのないイベントであれば、人の介入を促すアラートの作成は避けます。

低速バーンイベントの場合は、呼び出しやメールではなく、チケットキューでの通知をおすすめします。低速バーンイベントの発生は緊急事態ではありませんが、バジェットが枯渇する前に人間による対応が必要です。これらのアラートに、チームリストへのメールを使用することは避けてください。煩わしく、すぐに無視されてしまうからです。チケットは追跡可能、割り当て可能、および転送可能である必要があります。チームは、チケットの量、クローズ率、対応可能性、重複に関するレポートを作成します。対処できないチケットが多すぎる場合、過度の作業負担の好例です。

SLO アラートをうまく使用するには時間がかかり、チームの文化と期待によって決まります。SLO アラートは時間の経過とともに細かく調整できます。また、ニーズに合わせて、複数のアラート方法を導入してさまざまなアラート ウィンドウを作成することもできます。

レイテンシ アラート

可用性アラートに加えて、レイテンシのアラートを受け取ることもできます。レイテンシの SLO を使用すると、レイテンシ目標を満たさないリクエストの割合を測定できます。このモデルを使用すると、エラー バジェットの高速バーンまたは低速バーンを検出するのに使用するのと同じアラートモデルを利用できます。

レイテンシの中央値 SLO に関してすでに説明したように、リクエストの半数は完全に SLO 対象外となります。つまり、長期的なエラー バジェットに影響が出るまで、ユーザーが数日にわたってレイテンシの悪化を経験する可能性があります。代わりに、サービスではテール レイテンシ目標と通常のレイテンシ目標を定義する必要があります。通常のレイテンシに過去 90 パーセンタイルを使用し、テール レイテンシに 99 パーセンタイルを使用して定義することをおすすめします。これらの目標を設定したら、各レイテンシ カテゴリで予想されるリクエストの数と、遅すぎると予想されるリクエスト数に基づいて SLO を定義できます。このアプローチは、エラー バジェットと同じコンセプトであり、同じように扱われます。その結果、「90% のリクエストが通常のレイテンシ内で、99.9% はテール レイテンシ ターゲット内で処理される」というような文になります。これらのターゲットを使用すると、ほとんどのユーザーが通常のレイテンシを体験する一方で、テール レイテンシ ターゲットよりも遅いリクエスト数もトラックできます。

サービスによっては、大きく変動する予想ランタイムになる場合があります。たとえば、データストア システムからの読み取りと書き込みでは、パフォーマンスが大幅に異なることがあります。想定されるすべての可能性を列挙するのではなく、次の表のようにランタイム パフォーマンス バケットを導入できます。このアプローチでは、これらのタイプのリクエストが識別可能で、各バケットに分類済みであることを前提としています。リクエストがその場ですぐに分類されることはありません。

ユーザー向けウェブサイト
バケット 予想される最大ランタイム
読み取り 1 秒
書き込み / 更新 3 秒
データ処理システム
バケット 予想される最大ランタイム
小 10 秒
中 1 分
大 5 分
最大 1 時間
特大 8 時間

現在のシステムの状態を測定すると、これらのリクエストの実行に通常かかる時間がわかります。例として、動画のアップロードを処理するシステムについて考えてみましょう。非常に長い動画の場合、処理にさらに時間がかかると予想されます。次の表に示すように、動画の長さ（秒単位）を使用して、バケットに分類できます。この表では、バケットあたりのリクエスト数と、ランタイムの 1 週間にわたるさまざまなパーセンタイルの分布を記録しています。

動画の長さ 1 週間に測定されたリクエストの数 10% 90% 99.95%
小 0 - - -
中 190 万 864 ミリ秒 17 秒 86 秒
大 2,500 万 1.8 秒 52 秒 9.6 分
最大 430 万 2 秒 43 秒 23.8 分
特大 81,000 36 秒 1.2 分 41 分

そうした分析から、アラート用のパラメータをいくつか導き出すことができます。

  • fast_normal: 最大 10% のリクエストが今回よりも高速です。今回よりも早いリクエストが多すぎる場合、ターゲットに問題があるか、システム自体が変更された可能性があります。
  • slow_commonly: 少なくとも 90% のリクエストが今回よりも高速です。この制限により、メインのレイテンシ SLO が発生します。このパラメータは、ほとんどのリクエストの速度が十分であるかどうかを示します。
  • slow_tail: 少なくとも 99.95% のリクエストが今回よりも高速です。この制限により、遅いリクエストが増えすぎないようにします。
  • deadline: ユーザーのリモート プロシージャ コールまたはバックグラウンド処理がタイムアウトして失敗するポイント（通常、上限はシステムにハードコードされています）。これらのリクエストは本当に遅いわけではありませんが、実際にエラーが発生して、可用性の SLO にカウントされます。

バケットを定義する際のガイドラインは、バケットの fast_typical、slow_typical、slow_tail を互いの指標の範囲内に保つことです。このガイドラインでは、バケットの範囲が広すぎないようにしています。バケット間の重複やギャップを避けないようにすることをおすすめします。

バケット fast_typical slow_typical slow_tail deadline
小 100 ミリ秒 1 秒 10 秒 30 秒
中 600 ミリ秒 6 秒 60 秒（1 分） 300 秒
大 3 秒 30 秒 300 秒（5 分） 10 分
最大 30 秒 6 分 60 分（1 時間） 3 時間
特大 5 分 50 分 500 分（8 時間） 12 時間

これにより、api.method: SMALL => [1s, 10s] のようなルールになります。この場合、SLO トラッキング システムでは、リクエストを確認し、バケットを判別します（メソッド名や URI を解析して、ルックアップ テーブルと比較します）。次に、そのリクエストのランタイムを基に統計情報を更新します。700 ミリ秒の場合、slow_typical ターゲット内に含まれます。3 秒であれば、slow_tail 内に含まれます。22 秒の場合、slow_tail は超過しますが、エラーではありません。

ユーザー満足度の観点からは、テール レイテンシを満たさなかった場合は、使用不可能と同等であると考えることができます（つまり、レスポンスが非常に遅いため、失敗とみなされます）。そのため、可用性と同じパーセンテージを使用することをおすすめします。次に例を示します。

全リクエストの 99.95% は 10 秒以内に満たされる。

通常のレイテンシとみなされる範囲は、お客様次第です。Google 内の一部のチームでは 90% を適切な目標とみなしています。これは分析と、slow_typical の期間の選択に関連しています。例:

すべてのリクエストの 90% は 1 秒以内に処理される。

推奨アラート

これらのガイドラインを考慮し、SLO アラートの推奨ベースライン セットを次の表に示します。

SLO 測定期間 バーンレート アクション

可用性、高速バーン

通常のレイテンシ

テール レイテンシ

 1 時間 SLO 違反から 24 時間未満 連絡する

可用性、低速バーン

通常のレイテンシ、低速バーン

テール レイテンシ、低速バーン

 7 日間 SLO 違反から 24 時間超 チケットを作成する

SLO アラートは、取得に時間のかかるスキルです。このセクションの期間は推奨値であり、独自のニーズと精度に応じて調整できます。アラートを測定期間やエラー バジェットの支出と一緒に利用することも、高速バーンと低速バーンの間に別のアラート層を追加して活用することもできます。

次のステップ