このドキュメントの Google Cloud アーキテクチャ フレームワーク: 信頼性セクションで、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 分間など）で検出すると、エラーが発生しやすくなります。検出目標時間が 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 は超過しますが、エラーではありません。
ユーザー満足度の観点からは、テール レイテンシを満たさなかった場合は、使用不可能と同等であると考えることができます（つまり、レスポンスが非常に遅いため、失敗とみなされます）。そのため、可用性と同じパーセンテージを使用することをおすすめします。次に例を示します。
通常のレイテンシとみなされる範囲は、お客様次第です。Google 内の一部のチームでは 90% を適切な目標とみなしています。これは分析と、slow_typical の期間の選択に関連しています。例:
推奨アラート
これらのガイドラインを考慮し、SLO アラートの推奨ベースライン セットを次の表に示します。
| SLO | 測定期間 | バーンレート | アクション |
|---|---|---|---|
|
可用性、高速バーン 通常のレイテンシ テール レイテンシ |
1 時間 | SLO 違反から 24 時間未満 | 連絡する |
|
可用性、低速バーン 通常のレイテンシ、低速バーン テール レイテンシ、低速バーン |
7 日間 | SLO 違反から 24 時間超 | チケットを作成する |
SLO アラートは、取得に時間のかかるスキルです。このセクションの期間は推奨値であり、独自のニーズと精度に応じて調整できます。アラートを測定期間やエラー バジェットの支出と一緒に利用することも、高速バーンと低速バーンの間に別のアラート層を追加して活用することもできます。