Service Mesh (ASM) は、サービスレベル目標 (SLO) に基づく組み込みのモニタリングとアラート機能を提供します。SLO モニタリングは、アプリケーションサービス間の呼び出しにおけるレイテンシーやエラー率などのパフォーマンスメトリクスを追跡し、アプリケーション開発者、プラットフォームオペレーター、および運用保守担当者に、サービス品質を測定および改善するための共通のベンチマークを提供します。
主要用語
サービスレベル指標 (SLI): 可用性やレスポンスレイテンシーなど、サービス健全性を測定する定量的メトリックです。
サービスレベル目標 (SLO): 定義された期間における SLI の目標パーセンテージです。SLO は 1 つ以上の SLI で構成されます。複数の SLI を 1 つの SLO に組み合わせることで、サービス全体の健全性をより正確に把握できます。
エラーバジェット: SLO 目標 (100% - SLO 目標) から導き出される、許容される信頼性の低さの量です。エラーバジェットを使用して、信頼性と開発速度のバランスを取ります。これは、機能のリリースに投資できるリスクバジェットを表します。
SLO の例:
平均秒間クエリ数 (QPS) > 100,000/s
リクエストの 99% のレイテンシー < 500 ms
リクエストの 99% の 1 分あたりの帯域幅 > 200 MB/s
SLI タイプ
ASM は 2 つの SLI タイプをサポートしています。
| SLI タイプ | 測定対象 | プラグインタイプ | 失敗条件 |
|---|---|---|---|
| サービス可用性 | 成功応答を受信するリクエストの割合 | availability | HTTP ステータスコードが 429 または 5XX (5 で始まる任意のコード) |
| レイテンシー | サービスが応答を返すまでの時間 | latency | 応答時間が指定された最大値を超える |
有意義な目標設定
目標は、実際のユーザーへの影響を反映する必要があります。たとえば、ユーザーが 200 ms と 600 ms のレイテンシーの違いを認識できない場合、レイテンシー目標を 600 ms に設定します。
サービスの種類によって、その重要度に基づき異なる目標が設定されます。
| 可用性目標 | 年間おおよそのダウンタイム | 一般的な使用例 |
|---|---|---|
| 99% | ~3 日 | 非クリティカルなサービス |
| 99.999% | ~5 分 | ミッションクリティカルなサービス |
コンプライアンス期間
コンプライアンス期間は、SLI が SLO 目標に対して測定される期間を定義します。同じ目標パーセンテージでも、時間スケールが異なると意味合いが大きく異なります。
| コンプライアンス期間 | 99% の可用性で許容される継続的なダウンタイム |
|---|---|
| 1 日 | ~14 分 (24 時間 x 1%) |
| 30 日 | ~7 時間 (30 日 x 1%) |
ASM は、7 日、14 日、28 日、および 30 日のコンプライアンス期間をサポートしています。
エラーバジェット
エラーバジェットは、SLO 違反が発生するまでに SLO が許容する失敗の量を定量化します。
計算式: エラーバジェット = 100% - SLO 目標
例: 次のパラメーターを持つサービスを考えます。
| パラメーター | 値 |
|---|---|
| SLI 失敗条件 | HTTP ステータスコードが 429 または 5XX |
| コンプライアンス期間 | 30 日 |
| SLO 目標 | 99.9% |
| エラーバジェット | 0.1% (100% - 99.9%) |
| 30 日間の総リクエスト数 | 10,000 |
| 許容されるエラーリクエスト | 10 (10,000 x 0.1%) |
この SLO を満たすには、30 日間のウィンドウ内で 10 を超える失敗したリクエストは許可されません。
エラーバジェットを活用した意思決定
エラーバジェットは、信頼性と開発速度のバランスを取るためのデータ駆動型フレームワークを提供します。
バジェットがほぼ枯渇している場合: 新しいバージョンのデプロイを避けてください。信頼性に注力します。
コンプライアンス期間の終わりにバジェットが残っている場合: SLO 違反のリスクが低いため、更新をデプロイします。
エラーバジェットは、コンプライアンス期間に等しいローリングウィンドウで計算されます。
エラーバジェット >= 0: コンプライアンス期間内で SLO が満たされています。
エラーバジェット < 0: SLO 違反が発生しました。
バーンレート
バーンレートは、エラーバジェットがコンプライアンス期間に対してどれだけ速く消費されているかを測定します。バーンレートが 1 の場合、バジェットはコンプライアンス期間とまったく同じ期間で完全に消費されます。バーンレートが 2 の場合、バジェットは半分の時間で枯渇します。
計算式: バーンレート = エラー率 / (1 - SLO)
バジェットが枯渇するまでの時間を計算するには、コンプライアンス期間をバーンレートで割ります。
30 日間のコンプライアンス期間の例:
| バーンレート | エラーバジェットが枯渇するまでの時間 | 意味 |
|---|---|---|
| 1 | 30 日 (30 / 1) | バジェットが予想通りのペースで消費される |
| 2 | 15 日 (30 / 2) | バジェットが予想の 2 倍のペースで消費される |
| 60 | 12 時間 (30 / 60) | バジェットが予想の 60 倍のペースで消費される -- 即座の対応が必要 |
アラートルール
アラートルールは、エラーバジェットが速すぎるペースで消費されている場合に通知し、SLO 違反が発生する前に対応する時間を与えます。
ASM は、マルチウィンドウバーンレートアプローチを使用します。このメソッドは、高速バーン (短期間での高いエラー率) と低速バーン (長期間での中程度のエラー率) の両方を検出し、短期的で軽微なスパイクによる不要なアラートをフィルタリングします。
マルチウィンドウアラートの仕組み
各アラートルールは 2 つのタイムウィンドウを使用します。
| ウィンドウ | 役割 | 単位 |
|---|---|---|
| 長いウィンドウ | 検出 -- 長期間にわたるバーンレートを測定し、持続的な問題を特定します。 | 数時間から数日 |
| 短いウィンドウ | 回復 -- 最近のバーンレートを確認し、問題が解決された後、アラートを迅速にクリアします。 | 数分 (長いウィンドウの 1/12) |
アラートは、バーンレートが両方のウィンドウでしきい値を超えた場合にのみ発報します。この 2 つのウィンドウ設計により、エラーが修正された後も古いアラートが持続するのを防ぎます。
ファストバーンとスローバーンのアラート
30 日間の SLO の場合、ASM は異なるバーンパターンに対応する 2 つのアラート重大度レベルをサポートしています。
| アラートタイプ | バーンパターン | トリガー条件 | バーンレートしきい値 |
|---|---|---|---|
| ページレベル (高速バーン) | 短期間での高いエラー率 -- 即座の対応が必要 | 1 時間でエラーバジェットの 2% 消費、または 6 時間で 5% 消費 | 14.4 倍または 6 倍 |
| チケットレベル (低速バーン) | 長期間での中程度のエラー率 -- 勤務時間中に調査 | 1 日でエラーバジェットの 10% 消費、または 3 日間で消費 | 3 倍または 1 倍 |
短いウィンドウの重要性
短いウィンドウが設定されていない場合、根本的なエラーが修正された後でも、アラートは長いウィンドウの期間中存続します。短いウィンドウを長いウィンドウの 1/12 に設定すると、エラー率が低下した直後にアラートがクリアされます。
例: エラー率がしきい値の2倍で3日間維持されます。エラーは3日目に修正されます。短時間ウィンドウが設定されている場合、アラートは約6時間後にクリアされます。短時間ウィンドウが設定されていない場合、アラートはエラー修正後も3日間継続します。