サービスレベル目標（SLO）を選択する

Last reviewed 2024-03-29 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、どのようにユーザー エクスペリエンスによって信頼性が定義されるか、およびそのレベルの信頼性を達成するための適切なサービスレベル目標を選択する方法について説明します。このドキュメントは、SLO のコンポーネントで定義されているコンセプトに基づいています。

サイト信頼性エンジニアリング（SRE）の文化では、信頼性の高いサービスと顧客幸福度（つまり顧客満足度）が重視されます。サービスレベルと指標収集方法が定義されていない状態では、改善のためにどこにどれだけ投資するかを決定することは、不可能ではないにしても困難です。

サービスレベルの測定に使用する最優先の指標がサービスレベル目標（SLO）です。SLO は次の値で構成されます。

  • サービスレベル指標（SLI）: SLI を選択するで説明されている、サービスの特定の側面の指標。
  • 期間: SLI を測定する期間。これは、カレンダー ベースにすることも、ローリング ウィンドウにすることもできます。
  • ターゲット: 正常なサービスで所定の期間に達成される必要のある SLI の値（または値の範囲）。例としては、そのサービスが達成すると期待される、イベント総数に対する良好なイベントの割合（たとえば 99.9%）があります。

サービスの適切な SLO を選択することは一つのプロセスです。まずユーザー ジャーニーを定義し、これによって信頼性と、最終的に SLO が定義されます。選択する SLO はシステム全体を測定するものであることが必要ですが、機能開発のニーズと運用の安定性のバランスを取ることも求められます。SLO を選択した後は、その反復的な改善と、エラー バジェットを使用した管理の両方を行う必要があります。

ユーザー ジャーニーを定義する

SLI と SLO は、クリティカル ユーザー ジャーニー（CUJ）に基づいていることが理想的です。CUJ では、ユーザーのゴールと、そのゴールの達成にサービスがどのように役立つかが考慮されます。CUJ を定義するときは、サービスの境界は考慮しません。CUJ が満たされているときは顧客は幸福であるため、これはサービスが成功したことを示すものといえます。

顧客の幸福度、さらに言えば不満は信頼性を左右するものであり、どのサービスにおいても最も重要なポイントです。

したがって、SLO は、ほとんどのユーザーがサービスに満足する程度に設定し、それ以上は高くしないでください。可用性 100% が適切なゴールではないのと同様に、SLO の「9」を増やしてもコストが上がるだけであり、顧客は関心すら持たないこともあります。

稼働時間やその他の重要な指標については、100% より低く、ただし 100% に近いターゲットを設定するようにしてください。サービスのパフォーマンスと可用性について、求められる最小レベルを評価します。外部との契約のレベルに基づいてターゲットを設定しないでください。

CUJ を使用して SLO を作成する

会社にとって最も重要な CUJ を選択し、次の手順に沿って SLO を作成します。

  1. SLI 仕様（可用性、鮮度など）を選択します。
  2. SLI 仕様の実装方法を定義します。
  3. 計画にすべての CUJ が含まれていることを確認します。
  4. 過去のパフォーマンスまたはビジネスニーズに基づいて SLO を設定します。

CUJ を単一のサービスに、または単一の開発チームまたは組織に制約することは避けてください。サービスが、他の多数のサービスに依存していることもあります。これらのサービスについても、99.5% で運用されることが期待されるでしょう。しかし、エンドツーエンド（システム全体）のパフォーマンスが追跡されていない場合は、信頼性の高いサービスの実行は困難です。

ターゲットと期間を定義する

ターゲットと期間（前述の SLO の定義を参照）の定義は、簡単ではないこともあります。このプロセスを始める方法の一つは、SLI を特定し、その SLI を時系列でグラフ化するというものです。前述のとおり、SLO は最初から完璧である必要はありません。SLO についての作業を反復して、顧客満足度に整合するとともにビジネスニーズを満たすものとなるようにしてください。

デプロイ、停止、毎日のトラフィック パターンなどのイベント中の SLO 準拠状況を追跡すると、ターゲットに関する分析情報が得られます。これらの分析情報を利用すると、ターゲットと期間についての良い点、悪い点、許容できる点がさらに明確になります。

機能開発、コードの改善、ハードウェアのアップグレード、その他のメンテナンス タスクは、サービスの信頼性向上に役立ちます。このような小さな変更を頻繁に実施できれば、機能をより迅速に、より高い品質で提供できます。ただし、サービスの変更頻度は信頼性にも影響します。達成可能な信頼性目標が設定されていれば、顧客が許容でき、恩恵を受けることができる変更のペースと範囲（機能ベロシティと呼ばれます）がそれによって定義されます。

顧客体験を測定してそれに関する目標を定義することができない場合は、外部のソースとベンチマーク分析を利用することができます。比較できるベンチマークがない場合は、まだ目標を定義できないときでも、顧客体験を測定してください。時間の経過とともに、顧客満足度の妥当なしきい値に到達できます。このしきい値が SLO となります。

システム全体を理解する

サービスは、アップストリームとダウンストリームの両方の処理を含む、互いにつながった多数のサービスの一部ということもあります。分散システムのパフォーマンス測定を部分的に（サービス別に）行っても、顧客の体験が正確には反映されず、過剰に敏感な解釈の原因となる可能性があります。

代わりに、プロセスのフロントエンドで SLO を基準としてパフォーマンスを測定することによって、ユーザーの体験を理解する必要があります。ユーザーは、あるコンポーネントのエラーが原因でクエリが失敗しても、そのクエリが自動的に再試行されて正常に完了すれば、そのエラーを気にすることはありません。

共有される内部サービスがある場合は、関連付けられた SLO を基準として各サービスのパフォーマンスを別々に測定でき、このときはユーザー向けサービスが顧客としての役割を持ちます。これらの SLO は個別に処理します。

高可用性サービス（たとえば 99.99%）を、それよりも低可用性のサービス（たとえば 99.9%）の上に構築することも可能であり、これには復元力を高める要素（スマート再試行、キャッシュ保存、キューイングなど）が使用されます。統計学の実用的な知識があれば、コンウェイの法則で説明されるような基盤となるサービスや組織のレイアウトを理解していなくても SLO を読んで理解できるはずです。

適切な SLO を選択する

プロダクトの開発速度と運用の安定性との間には、自然の緊張関係があります。システムを変更すればするほど、壊れる可能性が高くなります。モニタリングとオブザーバビリティのツールは、機能ベロシティを上げていくときの運用の安定性に不可欠です。このようなツールはアプリケーション パフォーマンス管理（APM）ツールと呼ばれ、SLO の設定にも使用できます。

SLO が適切に定義されていれば、安定性を犠牲にすることなく開発ベロシティを上げるという、運用に関する意思決定をデータに基づいて下すことができます。また、SLO があれば、開発と運用のチームが単一の合意された目標に基づいて協調することもできます。単一の目標を共有することによって、前述の自然な緊張関係（プロダクトの作成とイテレーションを行う開発チームの目標と、システムの完全性を維持する運用チームの目標との関係）を緩和できます。

このドキュメントと、アーキテクチャ フレームワーク内のその他の信頼性に関するドキュメントを使用して、SLO を理解して作成してください。これらの記事を読み終えて理解したら、SLO（およびその他の SRE プラクティス）に関するさらに詳しい情報を SRE ブックと SRE ワークブックでご覧ください。

厳格な内部 SLO を使用する

外部 SLA よりも厳格な内部 SLO を使用することをおすすめします。SLA に違反すると金銭的クレジット発行または顧客への払い戻しが必要になる傾向があるため、問題が発生した場合は財務上の影響に至る前に対処する必要があります。

このような厳格な内部 SLO を、非難のない事後分析プロセスとインシデント レビューとともに使用することをおすすめします。詳細については、アーキテクチャ センターの信頼性のカテゴリに含まれる共同インシデント管理プロセスを構築するをご覧ください。

SLO を反復的に改善する

SLO の設定を固定しないでください。SLO の見直しを定期的に（四半期ごと、または少なくとも年に 1 回）行い、ユーザーの満足度が正確に反映されていることと、サービス停止との相関関係があることを確認します。現行のビジネスニーズと新しいクリティカル ユーザー ジャーニーが確実にカバーされているようにしてください。これらのレビューの後に、必要に応じて SLO の改訂と拡大を行います。

エラー バジェットを使用して開発ベロシティを管理する

エラー バジェットとは、特定の期間でのそのサービスの信頼性が、必要とされる水準を上回っているか下回っているかを示すものです。エラー バジェットは、所定の期間（たとえば 30 日）について「100% – SLO」として計算されます。

エラー バジェットの残りがまだあるときは、引き続き改善または新機能を速くリリースできます。エラー バジェットがゼロに近い場合は、サービス変更の速度を落とすか停止して、信頼性に関する機能の向上にエンジニアリング リソースを投入します。

Google Cloud Observability には、SLO モニタリングが含まれていて、SLO とエラー バジェットを設定する手間を最小限に抑えることができます。オペレーション スイートには、SLO の手動構成に役立つグラフィカル ユーザー インターフェース、SLO をプログラムで設定できる API、エラー バジェットのバーンレートをトラッキングするための組み込みダッシュボードが含まれています。詳細については、SLO の作成をご覧ください。

SLO に関する推奨事項のまとめ

  • 顧客中心の SLI（サービスの可用性やレイテンシなど）を定義して測定します。
  • 外部 SLA よりも厳格な、顧客中心のエラー バジェットを定義します。違反した場合の結果（プロダクション フリーズなど）を含めます。
  • レイテンシ SLI を設定して外れ値（90 パーセンタイルや 99 パーセンタイルなど）をキャプチャし、最も遅いレスポンスを検出します。
  • 少なくとも年に 1 回は SLO を見直し、ユーザーの満足度とサービス停止との間に十分な相関関係があることを確認します。

次のステップ