SLO の方法論から実践へ：Part1 効果的な SLO の確立¶
近年、組織はサービスレベル目標（SLO）をサイト信頼性エンジニアリング（SRE）の実践における基本的な要素として採用することが増えています。Google は SLO に関するベストプラクティスを開拓しました——Google SRE の書籍ではこの概念がよく紹介されています。本質的に、SLO はサービスの信頼性とユーザーの満足度が密接に関連しているという考えに根ざしています。具体的で測定可能な信頼性目標を設定することで、組織は製品開発と運用業務の間で適切なバランスを取ることができ、最終的にはポジティブなエンドユーザーエクスペリエンスをもたらします。
SLO を理解するために、3 つのパートに分けて学習します。
SLO の方法論から実践へ：Part1 効果的な SLO の確立
SLO の方法論から実践へ：Part3 Guanceを使用した SLO 管理のベストプラクティス
主要用語¶
先に進む前に、このシリーズ全体で使用するいくつかの主要な用語を分解してみましょう。
- サービスレベル指標（SLI） は、エンドユーザーに提供されるサービスレベルを測定するために使用される指標です（例：可用性、レイテンシー、スループット）。
- サービスレベル目標（SLO） は、SLI によって測定される目標のサービスレベルです。通常、一定期間におけるパーセンテージとして表されます。
- サービスレベル契約（SLA） は、エンドユーザーがサービスプロバイダーから得られるサービスレベルを概説した契約上の合意です。これらの約束が守られなかった場合、ベンダーは重大な結果（通常は金銭的なもの、例：サービス credit、サブスクリプション延長）に直面する可能性があります。
- エラーバジェット は、サービスが SLO に違反する前に許容される信頼性の低さの水準です。簡単に言えば、100% の信頼性と SLO 目標との差です。エラーバジェットは財務予算と考えることができます——ただし、この場合、開発者は新しい機能の構築、システムアーキテクチャの再設計、またはその他の製品開発作業に予算を使用します。
サービスレベル目標は誰にとって重要なのか？¶
組織全体の主要なステークホルダーに SLO を採用してもらうためには、ビジネスの優先順位や彼らが実施したいプロジェクトを考慮した上で、実際に達成可能な信頼性目標について合意してもらう必要があります。このセクションでは、エンドユーザー、開発者、運用エンジニアが何を重視しているのか、そして SLO を設定する際に彼らの目標や優先順位をどのように考慮すべきかを詳しく見ていきます。
エンドユーザー¶
どのような製品であっても、エンドユーザーは受けるサービス品質に期待を持っています。彼らはアプリケーションがいつでもアクセス可能で、素早くロードされ、正しいデータを返すことを望んでいます。サポートチケットやインシデントページを使用して顧客の不満度を測定することはできますが、製品の意思決定をこれらだけに依存すべきではありません。なぜなら、それらはエンドユーザーエクスペリエンスを完全に捉えているわけではないからです。例えば、すべての障害チケットを解決したとしても、必ずしもエンドユーザーが期待するサービスレベルに達しているとは限りません。
実際には、常に 100% の信頼性を達成することは不可能です。SLO は、製品イノベーション（これはエンドユーザーにより大きな価値を提供するのに役立ちますが、物事を壊すリスクもあります）と信頼性（これによりユーザーを満足させます）の間の適切なバランスを見つけるのに役立ちます。エラーバジェットは、エンドユーザーがサービス品質の低下を経験する可能性がある前に、開発作業が許容できる信頼性の低さの程度を決定します。
開発者と運用エンジニア¶
伝統的に、開発者と運用エンジニアの間の対立は、彼らの相反する目標と責務に起因していました。開発者はサービスにさらなる機能を追加することを目指し、運用エンジニアはこれらのサービスの安定性を維持する責任を負っていました。SLO は、ポジティブなビジネス成果を促進するだけでなく、開発チームと運用チームがアプリケーションの信頼性に対して共通の責任感を持つという文化の変革を促進します。
SLO とそれに伴うエラーバジェットがあれば、チームはどのプロジェクトや計画を優先すべきかを客観的に決定できます。エラーバジェットが残っている限り、開発者は製品全体の品質を向上させる新機能をリリースでき、運用エンジニアはデータベースメンテナンスやプロセス自動化などの長期的な信頼性プロジェクトに集中できます。しかし、エラーバジェットが枯渇し始めると、開発者は機能開発を遅らせるか凍結し、運用チームと緊密に連携して、SLA や SLO に違反する前にシステムを再安定化する必要があります。簡単に言えば、エラーバジェットは、開発者と運用エンジニアの作業と目標を調整するための定量化可能な方法です。
SLI から SLO へ¶
ここまでで SLO に関連するいくつかの主要な概念を定義しました。次は、それらをどのように作成するかを考え始める時です。ユーザーがどのように製品を体験しているか、そしてどのユーザージャーニーが最も重要かを深く理解することは、有用な SLO を作成するための最初で最も重要なステップです。以下は、検討すべきいくつかの質問です。
- ユーザーはアプリケーションとどのように相互作用しますか？
- アプリケーションを通じたユーザーのジャーニーはどのようなものですか？
- これらのジャーニーは、インフラストラクチャのどの部分と相互作用しますか？
- ユーザーはシステムに何を期待し、何を達成しようとしていますか？
このシリーズでは、お客様が E コマース企業で働いていると仮定し、そのような企業がどのように SLO を設定するかを検討します。お客様は、顧客がウェブサイトとどのように相互作用するか、そして最初にサイトに入ってから退出するまでの経路を把握する必要があります。基本的なレベルでは、顧客はログイン、商品の検索、個々の商品の詳細の表示、カートへの商品の追加、チェックアウトができる必要があります。このような主要なユーザージャーニーはユーザーエクスペリエンスに直接関連しているため、SLO を設定することが重要です。
この演習が完了したら、これらの主要なユーザージャーニーにおいて提供されるサービスレベルを定量化するための指標、すなわち SLI の選択に進むことができます。
適切な SLI の選択¶
インフラストラクチャが複雑になるにつれて、すべてのデータベース、メッセージキュー、ロードバランサーに外部 SLO を設定することはますます面倒になります。代わりに、システムコンポーネントをいくつかの主要なカテゴリ（例：応答/リクエスト、ストレージ、データパイプライン）に整理し、各カテゴリ内で SLI を指定することをお勧めします。
SLI の選択を始める際には、簡潔ですが重要な言葉を覚えておいてください。「すべての SLI は指標ですが、すべての指標が優れた SLI であるとは限りません。」これは、あなたが何百もの指標を追跡しているかもしれませんが、最も重要な指標、つまりユーザーエクスペリエンスを最もよく捉える指標に焦点を当てるべきであることを意味します。
以下の表（Google の SRE 書籍より）を参考にしてください。
さて、あなたのショッパーがチェックアウトページで立ち往生し、遅い支払いエンドポイントが応答を返すのを待っているところを想像してみてください。待つ時間が長ければ長いほど、彼らはあなたのビジネスに対してネガティブな印象を持つ可能性が高くなります。風評被害に加えて、顧客がカートを放棄すると、高額な結果を招く可能性があります。実際、最大かつ最も成功している組織のいくつかは、1 秒の遅延が収益の顕著な減少と相関することを発見しています。この例から、応答レイテンシーは、オンライン小売業者が顧客が重要なビジネストランザクションを迅速に完了できるようにするために追跡する、特に重要な SLI であることがわかります。
これを、優れた SLI になる可能性がほぼ確実にない指標と比較してみましょう。CPU 使用率です。たとえサーバーが CPU 使用率の急上昇を経験しており、インフラストラクチャチームがこの高使用率のアラートをより頻繁に受け取っていたとしても、エンドユーザーは依然としてシームレスにチェックアウトできるかもしれません。ここでのポイントは、指標が内部チームにとってどれほど重要であっても、その値がユーザー満足度に直接影響を与えないのであれば、SLI としての有用性はないということです。
適切な SLI を特定したら、監視システムのデータを使用してそれらを測定する必要があります。同様に、ユーザーに最も近いコンポーネントからデータを抽出することをお勧めします。例えば、チェックアウトサービスの一部として、クレジットカード取引を受け付け承認するために支払い API を使用できます。このサービスを構成する他の多くの内部コンポーネント（例：サーバー、バックグラウンドジョブプロセッサ）が存在する可能性がありますが、これらは通常ユーザーの視点からは抽象化されています。SLI はエンドユーザーエクスペリエンスを定量化するために使用されるため、支払いエンドポイントからのみデータを収集すれば十分です。なぜなら、それはユーザーに機能を公開しているからです。
SLI を SLO に変換する¶
最後に、SLI を SLO に変換するために、SLI に目標値（または値の範囲）を設定する必要があります。最良および最悪のケースの基準は何か、そしてその条件がどの程度の期間有効であるべきかを明記する必要があります。例えば、リクエストレイテンシーを追跡する SLO は、「30 日間において、認証サービスリクエストの 99% のレイテンシーが 250 ミリ秒未満であること」となります。
SLO の作成を開始する際には、以下の点に留意する必要があります。
現実的に SLO を 100% に設定することはどれほど魅力的であっても、実際には基本的に達成不可能です。エラーバジェットを考慮しないと、開発チームは新機能を試す際に過度に慎重になり、製品の成長を阻害する可能性があります。一般的な業界標準は、SLO 目標を複数の 9（例：99.9% は「スリー ナイン」、99.95% は「スリー アンド ハーフ ナイン」と呼ばれます）に設定することです。
一般的な経験則として、SLO は SLA で詳述されている内容よりも厳格に設定する必要があります。SLA を確実に満たすためには、常に控えめに設定し、一貫して過小評価しないようにする方が良いでしょう。
実験する SLO を洗練させるための厳格なルールはありません。各組織の SLO は、製品の性質、それらを管理するチームの優先順位、エンドユーザーの期待によって異なります。目標は、最適な値が見つかるまで最適化を続けられることを忘れないでください。例えば、チームが一貫して目標を大幅に上回っている場合は、これらの値を引き締めるか、未使用のエラーバジェットを活用して製品開発への投資を増やすことを検討してもよいでしょう。逆に、チームが一貫して目標を達成できていない場合は、より達成しやすいレベルに引き下げるか、製品の安定化により多くの時間を割くことが賢明かもしれません。
複雑にしない 最後に、SLO 目標を定義する際には、SLO を設定しすぎたり、SLI の集約を複雑にしすぎたりする誘惑に抵抗してください。重要なジャーニーを構成するすべてのクラスター、ホスト、コンポーネントに個別の SLI を設定するのではなく、意味のある方法でそれらを単一の SLI に集約するようにしてください。通常、SLO と SLI は、エンドユーザーエクスペリエンスにとって重要なものに限定する必要があります。これにより、ノイズを排除し、本当に重要なことに集中できます。
これで SLO がわかりました¶
このブログ投稿では、適切な SLI を選択し、それを明確に定義された SLO に変換することで、組織を成功へと導く方法を探求しました。SLI を使用してユーザーに提供するサービスレベルを測定し、実際の SLO に照らしてパフォーマンスを追跡することで、機能速度とシステム信頼性を向上させるためのより良い意思決定ができるようになります。このガイドを、SLO の作成を開始し、より多くのチームメンバーを参加させる際に参照できるシンプルなチェックリストとしてまとめました。
このシリーズの次のパート に進み、技術チームとビジネスチームが Guance を使用して SLO とその他の監視データを管理することで、より効果的に連携する方法を学んでください。