サービス モニタリングと SLO API は、Google が Google のサービスを管理するのと同様に、サービスを管理するのに役立ちます。サービス モニタリング機能の主要コンセプトは次のとおりです。
- サービスレベル指標（SLI）となる指標を選択する。
- SLI 値のサービスレベル目標（SLO）を SLI を使用して設定する。
- SLO によって決まるエラー バジェットを基準として使用してサービスのリスクを低減する。
このページでは、これらコンセプトについて解説し、SLO の設計時に考慮すべき点について説明します。このセクションのその他のページでは、これらのコンセプトの実践について説明します。
用語
サービス モニタリング機能の主要コンセプトは、次のとおりです。
- サービスレベル指標（SLI）: パフォーマンスを測定する指標。
- サービスレベル目標（SLO）: パフォーマンスの目標値の定義。
- エラー バジェット: 1 - SLO から開始します。実際のパフォーマンスが SLO を満たさないと減少します。
サービスレベル指標
Cloud Monitoring は、サービス インフラストラクチャのパフォーマンスを測定する指標を収集します。パフォーマンス指標の例を次に示します。
- リクエスト数: HTTP リクエストのうち、2xx または 5xx レスポンスが返されるリクエストの 1 分あたりの数など。
- レスポンス レイテンシ: HTTP 2xx レスポンスのレイテンシなど。
パフォーマンス指標は、既知のサービスタイプ群（Cloud Service Mesh、Google Kubernetes Engine 上の Istio、App Engine）に基づいて自動的に特定されます。サービスの種類を独自に定義し、そのサービスのパフォーマンス指標を選択することもできます。
パフォーマンス指標をもとにサービスの SLI が求められます。SLI は、サービスの特定の側面のパフォーマンスを表します。Cloud Service Mesh、Google Kubernetes Engine 上の Istio、App Engine のサービスについては、有用な SLI がすでに知られています。たとえば、サービスにリクエスト数やレスポンス レイテンシの指標が定められている場合、標準的な SLI は次のように比率を指定して導出できます。
- 可用性 SLI。全レスポンス数に対する正常なレスポンス数の割合で表されます。
- レイテンシ SLI。レイテンシしきい値を下回る呼び出し数と全呼び出し数の割合で表されます。
「良好なパフォーマンス」を表す別の尺度向けにサービス固有の SLI を設定することもできます。これらの SLI は一般的に次の 2 つのカテゴリに分類されます。
- リクエスト ベースの SLI。サービスの原子単位（良好な HTTP リクエストの数など）をカウントして「良好なサービス」が測定されます。
- ウィンドウ ベースの SLI。サービスの良好さは、良好さの基準（レスポンス レイテンシが特定のしきい値を下回るなど）を満たすパフォーマンスが得られた期間や時間枠の回数をカウントして測定されます。
これらの SLI の詳細については、リクエスト ベースおよびウィンドウ ベースの SLO のコンプライアンスをご覧ください。
選択したサービスの SLI を作成する例については、指標から SLI を作成するをご覧ください。
サービスレベル目標
SLO は、SLI の目標値であり、一定期間にわたって測定されます。可用性 SLI はサービスによって決まります。SLO は SLI に基づいて指定します。SLO は、「良好なサービス」とみなされる条件を定義します。Cloud Monitoring では、サービスごとに 500 SLO まで作成できます。
SLO は、次のような情報に基づいて作成されます。
- SLI。サービスのパフォーマンスを測定する尺度となります。
- パフォーマンス目標。パフォーマンスの目標レベルを指定します。
- 期間。コンプライアンス期間とも呼ばれます。SLI のパフォーマンス目標達成度合いを判定するために設定された期間です。
たとえば、次のような要件が課せられます。
- 30 日間のローリング期間中のリクエストのうち、レイテンシが 300 ミリ秒を超えるリクエストは最大 5% までとする。
- システムを 1 週間（暦週）測定し、その可用性が 99% であること。
このような要件をもとに SLO を設定できます。良い SLO を設定する方法については、SLO の設計と使用をご覧ください。
SLO コンプライアンスを変更すると、障害が発生する場合があります。これらの変更をモニタリングすることにより、十分な警告が発せられ、連鎖的な障害が発生する前に問題を修正できます。アラート ポリシーは通常、SLO のコンプライアンスのモニタリングに使用されます。詳細については、エラー バジェットのアラートをご覧ください。
SLO ではエラー バジェットを決定するため、100% 未満の有用な SLO 目標を設定してください。通常、SLO は 99% （ツーナイン）、99.9% （スリーナイン）などの数の「ナイン」と呼ばれます。設定可能な値は最大 99.9% ですが、サービスに合わせて任意の低い値に設定できます。
エラー バジェット
SLO は、コンプライアンス期間中のサービスに求められるパフォーマンス レベルを定めます。コンプライアンス期間に残ったものは、エラー バジェットとなります。エラー バジェットによって、コンプライアンス期間中にサービスに障害が発生しても SLO を満たすことができる度合いが定量化されます。
エラー バジェットは、SLO 違反となるまでにコンプライアンス期間中に発生した異常イベント（リクエストなど）の数をトラッキングします。エラー バジェットを使用して、新しいバージョンをデプロイするタスクなどのメンテナンス タスクを管理できます。エラー バジェットがゼロに近づくと、新しい更新を push するタスクなどのリスクの高い操作を行った場合に SLO 違反となる可能性があります。
コンプライアンス期間のエラー バジェットは、（1 - SLO 目標）×（コンプライアンス期間の有効イベント）です。たとえば、SLO のリクエストの 85% が 7 日間のローリング期間中に有効である場合、エラー バジェットではこれらの無効なリクエストの 15% が許容されます。1 週間に 60,480 件のリクエストがある場合、エラー バジェットはその合計の 15% となります。つまり、9,072 件のリクエストが無効でも許容されます。これより多くのエラーを処理した場合、サービスは 7 日間のコンプライアンス期間中に SLO から除外されます。
SLO の設計と使用
どのような SLO が適切で、選択の際にどのようなことを考慮すべきでしょうか。このセクションでは、SLO の設計と使用について一般的なコンセプトを概説します。このトピックの詳細については、サイト信頼性エンジニアリング: Google が本番システムを運用する仕組みの SLO に関する章で詳しく説明しています。
SLO は、サービスのパフォーマンス目標を定義します。一般に、SLO は、必要ないしは意味がある程度以上には設定しないようにする必要があります。たとえば、サービスの可用性 99% と 99.9% の違いがユーザーにわからない場合は、低いほうの値を SLO 値とします。値が大きくなるほど費用が高くなる一方、ユーザーの目には差がなく影響がないからです。SLO 100% 目標を満たすことを要件とするサービスの場合、エラー バジェットはゼロになります。このような SLO の設定は不適切です。
SLO は通常、公的または契約上のコミットメントよりも厳しく設定します。SLO は公的コミットメントよりも厳しく設定します。そうしておけば、SLO に違反する事態が発生した場合、コミットメントや契約に違反する前に問題を認識して修正できます。コミットメントや契約に違反すると、評判上、財務上、および法律上の影響が生じることになります。SLO は、早期警告システムの一部であり、そのような事態の発生を防ぎます。
コンプライアンス期間
SLO のコンプライアンス期間には次の 2 種類があります。
- カレンダー ベースの期間（日付～日付）。
- ローリング期間（n日前～現在）。ここで、nは 1～30 日の範囲です。
カレンダー ベースのコンプライアンス期間
コンプライアンス期間は、1 週間、1 か月などのカレンダー期間に設定できます。コンプライアンス期間とエラー バジェットは、わかりやすくカレンダーの境界でリセットされます。設定可能な値については、CalendarPeriod をご覧ください。
カレンダー期間を使用する場合、期間の終了時にパフォーマンス スコアが取得されます。パフォーマンス スコアは、パフォーマンスのしきい値に対して評価され、サービスがポリシーを遵守しているかどうかを確認できます。カレンダー期間を使用する場合、コンプライアンス期間にコンプライアンスを適用するのは 1 回だけです。期限の終了時刻にわかりやすいスコアの値が得られるので、コンプライアンス期間を顧客の請求期間と一致させておけば照合が容易になります（外部の支払いを利用する顧客の場合）。
カレンダー上の各月の日数が異なるのと同様、月ごとのコンプライアンス期間の日数はさまざまです。
ローリング ウィンドウ ベースのコンプライアンス期間
過去 30 日間など一定期間を遡ってコンプライアンスを評価することもできます。一定期間遡ると、ひとつ前の計算で最も古い時刻のデータが現在の計算から削除され、新しい時刻のデータに置き換えられます。
ローリング ウィンドウ ベースの場合、コンプライアンスがより頻繁に測定されます（過去 30 日間のコンプライアンスの値が、1 か月に 1 回ではなく 1 日に 1 回測定されます）。古いデータポイントが破棄され、新しいデータポイントが追加されて SLO のステータスが毎日変化するため、サービスはそれに応じてコンプライアンス遵守または違反状態となります。
リクエスト ベース SLO およびウィンドウ ベース SLO のコンプライアンス
SLO がコンプライアンス違反するかどうかは、次の 2 つの要因によって決まります。
- コンプライアンス期間の決め方。この判定については、コンプライアンス期間で説明します。
- SLO の種類。SLO には次の 2 種類があります。
- リクエスト ベースの SLO
- ウィンドウ ベースの SLO
コンプライアンスはコンプライアンス期間中に測定されたイベント総数に占める良いイベント数の比率です。SLO の種類によって、「イベント」の構成要素が決まります。
SLO が 99.9% の場合、コンプライアンスが 99.9% 以上ならば SLO を満たしています。最大値は 100% です。
リクエスト ベースの SLO
リクエスト ベースの SLO は、SLI に基づいて決まります。SLI は、リクエスト総数に占める良いリクエスト数の比率です。リクエスト ベースの SLO は、コンプライアンス期間の目標値以上になった場合に達成されます。
たとえば、「リクエストのレイテンシの 95% 以上が 100 ms 未満」となるようなリクエストベースの SLO を考えてみます。適切なリクエストとは、レスポンス時間が 100 ミリ秒未満であるため、レスポンス時間が 100 ミリ秒未満のリクエストの比率がコンプライアンスの測定値になります。この比率が 0.95 以上の場合、サービスは遵守しています。
リクエスト ベースの SLO は、コンプライアンス期間中に負荷がどのように分散されたかにかかわらず、サービスがコンプライアンス期間全体にわたって適切に提供された割合を示します。
ウィンドウ ベースの SLO
ウィンドウ ベースの SLO は、全測定間隔のうち「良い」とする基準を満たす測定間隔の数の比率として定義される SLI に基づいて計算されます。ウィンドウ ベースの SLO は、この比率が、コンプライアンス期間の目標値を上回った場合に達成されます。
たとえば、SLO が「10 分間のウィンドウの 99% 以上で、95 パーセンタイルのレイテンシの指標が 100 ミリ秒未満」であるとします。10 分間の測定期間中、95% のリクエストのレイテンシが 100 ミリ秒以下であれば、その測定期間は良好とされます。コンプライアンスの測定では、このような良い期間の比率を測定します。この比率が 0.99 以上の場合、サービスはコンプライアンスを遵守しています。
たとえば、コンプライアンス期間を 30 日間のローリング、測定間隔を分、SLO を 99% に設定するとします。この SLO を満たすには、43,200 分のうち 42,768 分（30 日分の分数の 99%）が「良好な」間隔である必要があります。
ウィンドウ ベースの SLO を使用すると、ユーザーがサービスの機能が正常または異常であると認識した時間の割合を知ることができます。この種類の SLO は、「バースト性」の異常動作の影響を隠すことができます。すべての呼び出しに失敗した測定間隔と 1 回の大きなエラーが発生した測定間隔とでは、SLO に不利となる度合いは同程度です。また、呼び出し数の少ない測定間隔とアクティビティの多い測定間隔についても、SLO に不利となる度合いは同程度です。
エラー バジェットの経過
エラー バジェットは、「良い」サービス（100%）と SLO の差で、望ましいサービスのレベルを表しています。この差の値で余裕の度合いが示されます。
一般に、エラー バジェットは最大値から開始し、時間とともに低下します。エラー バジェットが 0 を下回ると SLO 違反がトリガーされます。
このパターンには、次のような例外がいくつかあります。
リクエスト ベースの SLO をカレンダー ベースのコンプライアンス期間で測定する際に、コンプライアンス期間中にサービスのアクティビティが増加した場合、エラー バジェットの残高は実質的に増加します。
これは以下のようにして可能になります。SLO システムは、各コンプライアンス期間におけるサービスのアクティビティの量を事前に知ることができないため、あり得る値を推測します。この値は、コンプライアンス期間の開始から現在までに経過した時間における呼び出しの比率に、コンプライアンス期間の長さを掛けたものです。
アクティビティ率が上がると、その期間の予想トラフィックも増加し、その結果、エラー バジェットが増加します。
ローリングのコンプライアンス期間で SLO を測定している場合は、実質上常にコンプライアンス期間の終了段階となります。最初から始めるのではなく、古いデータポイントが継続的に追加され、新しいデータポイントが継続的に追加されます。
コンプライアンス違反の期間がコンプライアンス期間外になり、それに代わる現在の期間がコンプライアンス違反でない場合は、エラー バジェットが増大します。任意の時点において、エラー バジェットが 0 以上ならば「SLO 準拠のローリング ウィンドウ」であることを示し、エラー予算が 0 未満ならば「SLO に準拠していないローリング ウィンドウ」であることを示します。
エラー バジェットのモニタリング
アラート ポリシーを作成して、エラー バジェットが期待した速度よりも速く消費される場合に警告を表示できます。詳細については、エラー バジェットに関するアラートをご覧ください。
次のステップ
- マイクロサービスでは、マイクロサービスと、Google Cloud コンソールを使用してマイクロサービスを構成、表示、管理する方法について説明します。
- バーンレートに関するアラートでは、SLI をモニタリングして問題の可能性についてアラートする方法を説明します。
- SLO API の操作では、Cloud Monitoring API のサブセットである SLO API を使用して、サービス、SLO、関連構造を作成する方法を紹介します。