DevOps & SRE

SRE の基本（2021 年版）: SLI、SLA、SLO の比較

2021年5月31日

Google Cloud Japan Team

※この投稿は米国時間 2021 年 5 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

アプリケーションの可用性を確保するために重要なのは、サービスレベルの指標を確立してモニタリングすることです。これは、サイト信頼性エンジニアリング（SRE）チームが Google Cloud で毎日実施している内容です。SRE 原則の最終目標はサービスを改善し、さらにユーザーエクスペリエンスを向上させることです。

SRE の概念は、指標がビジネスの目標と密接に結び付いたものであるべきだという考えから始まりました。ビジネスレベルの SLA に加えて、SRE の計画と実践に SLO や SLI も使用します。

サイト信頼性エンジニアリングの用語を定義する

こうしたツールは、単なる便利な抽象概念ではありません。これらのツールがなければ、システムの信頼性、可用性、有用性は評価できません。ツールがビジネス目標に関連付けられていない場合、お客様の選択がビジネスに有益であるのか、損害をもたらすのかを評価するデータが不足することになります。

ここでは、復習の意味もかねて SLO、SLA、SLI についてご説明します。詳しくは、カスタマー信頼性エンジニアリングチームのブログ投稿、SLO、SLI、SLA について考える: CRE が現場で学んだことをご覧ください。

1. サービスレベル目標（SLO）

SRE は、可用性が成功の前提条件であるという考えが発端になっています。可用性のないシステムはその機能を実行できず、デフォルトで失敗します。SRE 用語における可用性の定義は、システムがある時点で目的の機能を実行できるかどうかです。可用性測定の履歴は、レポートツールとしてだけでなく、システムが将来的に予想どおりのパフォーマンスを発揮する確率を示す指標としても使用できます。

Google は SRE の用語を定義するにあたり、システムの可用性を正確な数値目標として設定したいと考えました。この目標をシステムの可用性サービスレベル目標（SLO）と呼びます。将来、システムが安定して稼働しているかどうか、システムの設計やアーキテクチャの変更が必要かどうかについて検討する際には、システムがこの SLO を引き続き満たすという観点から考慮する必要があります。

サービスの信頼性が高いほど、運用コストが高くなることに注意してください。各サービスのユーザーが許容できる最低レベルの信頼性を定義し、それを SLO として規定します。すべてのサービスには可用性 SLO が必要です。これがなければ、チームや関係者はサービスの信頼性を高める（コストを増やして開発を遅らせる）必要があるのか、あるいは信頼性を下げる（開発速度を上げる）必要があるのかを、原則に基づいて判断できません。過剰な可用性が期待されるようになり、それが問題になることがあります。ユーザーエクスペリエンスにとって必要でなければ、システムの信頼性を過度に高くしないでください。常にそのレベルに到達することを確約するつもりがない場合はなおさらです。詳細については、The Art of SLOs トレーニングにご参加ください。

Google Cloud 内では、サービスの可用性を過度に高めないように、一部のサービスで定期的にダウンタイムを実施しています。また、Google が自社の内部システムで実施したように、お客様のフロントエンドサーバーでときどき計画的なダウンタイムの演習を行ってみることも可能です。こうした演習により、フロントエンドサーバーを不適切に使用しているサービスを検出できることがわかりました。このような情報を利用して、ワークロードをより適切な場所に移動し、サーバーを適切な可用性レベルに維持できます。

2. サービスレベル契約（SLA）

Google Cloud では、SLO とサービスレベル契約（SLA）を区別しています。通常 SLA では、サービス可用性 SLO が一定期間に特定のレベルを満たすことをサービスユーザーに約束する契約が規定されています。これを怠った場合は、なんらかのペナルティが課せられます。たとえば、その期間に顧客が支払ったサービス利用料金の一部払い戻しや、利用時間の無料延長などがあります。サービスチームにとって、SLO からの逸脱は損害の発生につながるため、SLO を遵守するように努力するようになります。顧客に料金を請求する場合は、おそらく SLA が必要になります。

このような理由から、そして SLO に比べて可用性を過度に高めるべきではないという原則から、SLA の可用性 SLO は、内部の可用性 SLO よりも目標が緩いことが一般的です。このことは可用性の数値で説明できます。たとえば、1 か月間の可用性 SLO が 99.9% に対して、内部の可用性 SLO は 99.95% です。また、SLA は内部 SLO を構成する指標のサブセットのみを指定する場合があります。

内部 SLO とは異なる SLO が SLA にある場合（ほとんどの場合）、モニタリングで SLO コンプライアンスを明示的に測定することが重要です。SLA カレンダー期間中のシステムの可用性を表示し、SLO から逸脱する恐れがあるかどうかを簡単に確認できるようにする必要があります。

また、通常はログ分析から、コンプライアンスを正確に測定する必要もあります。Google は有料ユーザーに対しては追加の義務（SLA に記載）があるため、有料ユーザーから受け取ったクエリを他のクエリとは別に測定する必要があります。これは SLA を確立するもう一つのメリットであり、トラフィックの優先順位を明確にすることができます。

SLA の可用性 SLO を定義する際は、正当なものとしてカウントするクエリの判断を慎重に行ってください。たとえば、顧客がバグのあるバージョンのモバイルクライアントをリリースしたために割り当てを超えてしまった場合は、SLA アカウントからすべての「割り当て不足」のレスポンスコードを除外することを検討します。

3. サービスレベル指標（SLI）

サービスレベル指標（SLI）はサービスの動作を直接測定したもので、システムのプローブが成功した頻度として定義されます。Google は、システムが過去 1 週間に SLO 内で実行されているかどうかを評価する際に、SLI を調べてサービス可用性の割合を取得します。指定された SLO を下回る場合は、問題が生じているため、なんらかの方法でシステムの可用性を高める必要があります。たとえば、別の都市でもう 1 つのサービスのインスタンスを実行したり、2 つのサービスの間で負荷分散を行ったりします。サービスの信頼度を把握するには、SLI として成功したクエリと失敗したクエリの割合を測定できる必要があります。

システムをゼロから構築する場合は、SLI と SLO を必ずシステム要件に含めてください。すでに本番環境システムがあり、SLI と SLO を明確に定義していない場合は、それを定義する作業が最優先になります。