Service Mesh (ASM) は、サービスレベル目標 (SLO) に基づいたすぐに使える監視およびアラート機能を提供します。レイテンシやエラー率など、アプリケーションサービス間の呼び出しのパフォーマンスメトリクスを監視できます。このトピックでは、SLO 関連の概念について説明します。
SLI と SLO
サービスレベル指標 (SLI) は、サービスの健全性を測定するメトリクスです。SLO は、サービスが達成する必要がある目標または目標の範囲です。SLO は、1 つ以上の SLI で構成されます。
SLO は、マイクロサービス指向アプリケーションのパフォーマンス、品質、および信頼性を記述、測定、監視するための正式な方法を提供します。SLO は、アプリケーション開発者、プラットフォームオペレーター、および O&M 担当者にとって共有の品質ベンチマークです。SLO を参照として使用して、サービス品質を測定し、継続的に改善できます。複数の SLI で構成される SLO は、サービスの健全性をより正確に記述するのに役立ちます。
SLO の例:
1 秒あたりの平均クエリ数 (QPS) > 100,000/秒
99% のアクセスリクエストのレイテンシ < 500 ミリ秒
99% のアクセスリクエストの 1 分あたりの帯域幅 > 200 MB/秒
SLI の種類と目標
ASM は、次の SLI の種類をサポートしています。
サービスの可用性: アクセスリクエストが正常に応答された割合を示します。この SLI の種類のプラグインの種類は availability です。アクセスリクエストに返される HTTP ステータスコードが 429 または 5XX の場合、アクセスリクエストは正常に応答されません。5XX は、ステータスコードが 5 で始まることを意味します。
レイテンシ: サービスがリクエストへの応答を返すのに必要な時間を示します。この SLI の種類のプラグインの種類は latency です。最大レイテンシを指定できます。指定された期間より後に返された応答は、不適格と見なされます。
SLI の種類を定義するだけでなく、目標を設定する必要があります。目標は合理的である必要があります。たとえば、ユーザーが 200 ミリ秒と 600 ミリ秒のレイテンシの差を判別できない場合は、レイテンシの目標を 600 ミリ秒に設定します。
目標を設定する際には、ユーザーの要件も考慮する必要があります。さまざまなアプリケーションは、アプリケーションに対するユーザーの要件に応じて、さまざまな目標を達成する必要があります。たとえば、重要度の低い一部のサービスシステムは 99％ の可用性目標を満たし、重要なサービスシステムは 99.999% の可用性目標を満たす必要があります。99％ の可用性では年間約 3 日間のダウンタイムが許容され、99.999% の可用性では約 5 分間のダウンタイムが許容されます。
コンプライアンス期間
SLI が測定される SLO の期間を指定する必要があります。たとえば、1 日で有効になる 99% の可用性目標と、1 か月で有効になる同じ目標は異なります。1 日で有効になる 99% の可用性目標では、14 分 (24 時間 × 1%) を超える継続的なダウンタイムは許可されません。1 か月で有効になる 99% の可用性目標では、最大約 7 時間 (30 日 × 1%) の継続的なダウンタイムが許可されます。
構成を簡素化するために、コンプライアンス期間は 7 日、14 日、28 日、および 30 日のみにすることができます。
エラーバジェット
エラーバジェットは、SLO 内で一定量の障害または技術的負債を許容することを示します。したがって、次の式を使用してエラーバジェットを計算できます。エラーバジェット = 100% - SLO。この式では、SLO は達成するパーセンテージです。
例:
SLI 障害: リクエストに返されるステータスコード
コンプライアンス期間: 30 日
SLO: 99.9%
エラーバジェット: 0.1% (100% - 99.9%)
30 日以内のリクエストの総数: 10000
許可されるエラーリクエストの数: 10 (10000 * 0.1%)
SLO を達成するには、30 日ごとに最大 10 件のエラーリクエストが許可されます。エラーバジェットを参照することで、タスクをより適切に計画および管理できます。たとえば、エラーバジェットに基づいて新しいバージョンをデプロイする時期を決定できます。
エラーバジェットを使い果たそうとしている場合は、新しいバージョンをデプロイしないことをお勧めします。
コンプライアンス期間の終わりにエラーバジェットが十分にある場合は、バージョンアップデートを実行します。この場合、SLO 違反の可能性は低くなります。
エラーバジェットは、コンプライアンス期間と同じ期間のローリングウィンドウで更新されます。
エラーバジェットが 0 以上の場合、コンプライアンス期間に SLO が達成されたことを示します。
エラーバジェットが 0 未満の場合、コンプライアンス期間に SLO 違反が発生したことを示します。
バーンレート
バーンレートは、エラーバジェットが消費される速度を示します。バーンレートは、現在のエラー率と指定されたエラーバジェットの比率です。バーンレートが高いほど、障害が深刻であることを示します。アラートルールは、バーンレートに基づいて構成されます。バーンレートが指定された値に達すると、アラートがトリガーされます。
計算式: バーンレート = エラー率/(1 - SLO)
コンプライアンス期間が 30 日であると仮定します。
バーンレート 1: エラー率が現在のレベルに維持されている場合、コンプライアンス期間全体でエラーバジェットの 100% が使用されます。つまり、エラーバジェットは 30 日以内に使い果たされます。
バーンレート 2: エラー率が現在のレベルに維持されている場合、コンプライアンス期間全体でエラーバジェットの 200% が使用されます。つまり、エラーバジェットは 15 日以内に使い果たされます。
バーンレート 60: エラー率が現在のレベルに維持されている場合、コンプライアンス期間全体でエラーバジェットの 6000% が使用されます。つまり、エラーバジェットは 12 時間以内に使い果たされます。
アラートルール
アラートルールを使用すると、障害の重大度に基づいてさまざまなレベルのアラートを受信できます。これにより、エラーバジェットが過剰に消費されるのを防ぐために、障害にタイムリーに対処できます。
ASM では、さまざまなタイムウィンドウに対してさまざまなバーンレートしきい値を指定するアラートルールを構成できます。この構成方法は、ほとんどのシナリオに適用されます。短期間の高エラー率または長期間の低エラー率の両方でアラートがトリガーされます。一方、短期間の高エラー率または長期間の低エラー率のみでアラートがトリガーされます。これにより、不要なアラートによって注意がそらされるため、O&M 担当者が重要な問題を見逃すのを防ぎます。一定期間のエラー率を計算する場合、短いタイムウィンドウを設定できます。短いタイムウィンドウのエラー率が指定されたしきい値よりも低い場合、アラートは終了します。短いタイムウィンドウを構成すると、アラートをタイムリーにクリアできます。
30 日間の SLO の短いタイムウィンドウの例:
1 時間以内にエラーバジェットの 2% が消費された場合、または 6 時間以内にエラーバジェットの 5% が消費された場合、ページレベルのアラートがトリガーされます。つまり、エラー率が指定されたしきい値の 14.4 倍または 6 倍の場合、ページレベルのアラートがトリガーされます。1 日または 3 日以内にエラーバジェットの 10% が消費された場合、チケットレベルのアラートがトリガーされます。つまり、エラー率がしきい値の 3 倍またはしきい値に達した場合、チケットレベルのアラートがトリガーされます。
短いタイムウィンドウは 1/12 に設定されています。
エラー率が 3 日間しきい値の 2 倍のままであり、3 日目に障害が修正されたと仮定します。短いタイムウィンドウを構成すると、6 時間後にアラートをクリアできます。短いタイムウィンドウが構成されていない場合、障害が存在しない場合でも、アラートは 3 日間持続します。