SLO の設計

このページでは、サービスレベル目標（SLO）の作成前に必要になる可能性のある情報を説明します。

SLO の概要については、サービスレベル目標の概要をご覧ください。

SLI タイプとコンプライアンス目標

Anthos Service Mesh は、次の種類のサービスレベル指標をサポートします。

  • レイテンシ: リクエストに対してレスポンスを返すのにかかる時間（ミリ秒単位で測定）。
  • 可用性: サービスが正常に応答した時間の割合。

サービスに必要なコンプライアンス目標も定義します。一般に SLO は、ユーザーにとって必要以上に、意味がある程度以上には設定しないようにする必要があります。ユーザーがどの程度でサービスの劣化に気付くかを考慮します。たとえば、サービスのレイテンシが 300 ミリ秒または 500 ミリ秒のいずれかであるとユーザーが判断できない場合は、高いほうの値を SLO のレイテンシしきい値として設定します。値が小さくなるほど達成するのに費用が高くなる一方、ユーザーは違いに気付きません。

コンプライアンス ターゲットを設定する場合は、サービスのエンドユーザーの要件を考慮します。たとえば、従業員が休暇期間を予約するために使用する内部ツールは、99% の可用性目標（1 年間で最大 3 日のダウンタイム）を設定すれば十分です。ただし、オンライン ストアの重要なサービスには、99.999% の可用性（1 年間で最大 5 分のダウンタイム）が必要になる場合があります。

コンプライアンス期間

SLO は、SLI の目標を定義するだけでなく、SLI が測定される期間を指定します。たとえば、1 日における 99% の可用性は、月全体に対する 99% の可用性とは異なります。前者の SLO では、連続するダウンタイムが 14 分を超えることはありません（24 時間 × 1%）。後者の SLO では、連続するダウンタイムが最大 7 時間（30 日 × 1%）になります。

コンプライアンス期間は、ユーザーとのサービスレベル契約（SLA）に SLO が含まれている場合は特に重要です。SLA は、サービスのユーザーとの契約であり、通常は SLO を満たしていない場合の対応を指定します。ユーザーと SLA を結ぶかどうかは、プロダクトまたはビジネスでの決定です。しかし、モニタリングの目的では、SLO を作成するときにコンプライアンス期間を指定する必要がなおもあります。

SLO を構成するときは、コンプライアンス期間の種類を選択します。

  • カレンダー: [期間の種類] として [カレンダー] を選択した場合は、[期間の長さ] も（日、月、週のいずれかに）指定します。期間は重複せず、カレンダーの開始日と終了日に固定されます。コンプライアンス評価は期間の終了時にのみ行うことができます。

  • ローリング: [期間の種類] に [連続] を選択した場合は、[期間の長さ] として日数（たとえば、30 日など）を指定します。カレンダーの期間とは異なり、ローリング期間には固定の開始日と終了日が設定されません。Anthos Service Mesh は、ローリングのコンプライアンス期間に基づいて SLO を継続的に評価します。ひとつ前の計算で最も古い時刻のデータが現在の計算から削除され、新しい時刻のデータに置き換えられます。ローリングの期間を使用すると、過去 30 日間のコンプライアンスの値が、1 か月に 1 回ではなく 1 日に 1 回測定されるため、コンプライアンスがより頻繁に測定されます。ただし、SLO のステータスが毎日変化するため、サービスは遵守と違反の状態を行き来する可能性があります。

エラー バジェット

もう 1 つの重要なモニタリング コンセプトは、エラー バジェットです。SLO は、SLI と、コンプライアンス期間中にサービスの成功を測定するターゲット値を指定します。SLO のエラー バジェットは、サービスが SLO 違反になるまでの非遵守状態の時間の合計を表します。したがって、エラー バジェットは 100% - SLO% になります。たとえば、ローリングの 30 日間の可用性 SLO に 99.99% のコンプライアンス目標がある場合、30 日間のエラー バジェットは 0.01% となり、30 日間で許可されているダウンタイムがたった 4 分あまりとなります。SLO 100% を満たすことを要件とするサービスの場合、エラー バジェットはゼロになります。

エラー バジェットは、サービスが SLO 違反となるまでにコンプライアンス期間中に発生することが許容される違反した SLI 測定数をトラッキングします。エラー バジェットを使用して、新しいバージョンのデプロイなどの保守タスクの管理に役立てることができます。エラー バジェットが枯渇に近づいたときは、新しいアップデートをデプロイするなどのリスクの高いアクションを行うのに適切な時期ではありません。逆に、コンプライアンス期間の終盤にエラー バジェットが豊富にある場合、SLO 違反のリスクが低いため、新しい機能のリリースが望ましいことがあります。

カレンダー コンプライアンス期間で SLO を測定している場合、Service Mesh は最大値でエラー バジェットを開始し、時間の経過とともにバジェットを削減します。これにより、エラー バジェットが 0 未満になると SLO 違反がトリガーされます。Anthos Service Mesh は、コンプライアンス期間の終了時に SLO のエラー バジェットをリセットします。

ローリングのコンプライアンス期間で SLO を測定している場合は、実質上常にコンプライアンス期間の終了段階となります。最初から始めるのではなく、古いデータポイントが継続的に削除され、新しいデータポイントが継続的に追加されます。コンプライアンス違反の期間がコンプライアンス期間外になり、SLO がコンプライアンス違反でない場合は、エラー バジェットが増大します。任意の時点において、error budget ≥ 0 は SLO 遵守のローリング ウィンドウであることを示し、error budget < 0 は SLO を遵守していないローリング ウィンドウであることを示します。

次のステップ