SLO、SLI、SLAとは何か?

SLO、SLI、SLAとは何か?

サービスレベルとは、一定の期間内にユーザーに提供されたサービスを、測定可能な手法で表したものです。サービスレベル目標（SLO:Service Level Objectives）とは、外部からシステムに対して期待される可用性に関して設定された目標です。サービスレベル指標（SLI:Service Level Indicators）とは、システムの可用性を特定するための主要な測定値およびメトリクスです。サービスレベル契約（SLA:Service Level Agreements）とは、合意された内容およびシステムがSLOを満たさなかった場合の対応を説明した契約です。

たとえば、ウェブアプリケーションに関するSLOでは、1週間のうち99％の割合で、動画は2秒以内に再生開始しなければならないと取り決められている場合があります。SLIは、ウェブサイト上で2秒以内に再生開始した動画の割合を測定します。SLAには、このSLOおよび顧客とサービス提供者で合意した他の多くのSLO、対象となるサービス範囲、そしてSLI、すなわちパフォーマンス測定に使用されるメトリクスが含まれます。

サイトリライアビリティエンジニアリング（SRE）は、サービスのパフォーマンスと信頼性の測定手法にフォーカスした、分散システムのアップタイムおよび信頼性維持に関するベストプラクティスを普及させました。Googleは2016年月にSite Reliability Engineering: How Google Runs Production Systems を公開し、そこでサービスレベル目標から始め、メトリクスのモデリング、選択、分析に関するフレームワークを説明しています。

では、SLO、SLI、SLAは相互に、そしてユーザーが期待するサービスレベルを管理する方法にどのように関係しているのでしょうか？各々を、さらに詳しく見てみましょう。

An SLA is typically created by the business and legal teams, working with the customer (for specific contracts). Providers also present general SLAs for their services, such as cloud service providers for their different instance types. SLAs can include multiple SLOs, the scope of services that will be covered, and the SLIs used to measure performance.

SLOs, SLIs, and SLAs help ensure a quality of service from a set of technologies. All influencers of SLOs, SLIs, and SLAs should be consulted to help be sure goals are attainable and customers are satisfied.

SLOとは

SLOは、外部からシステムに対してどのくらいの可用性を期待するかの目標で、ある一定期間におけるパーセンテージの形で表されます。

サービスレベル目標を設定することで、"可用性 "や "稼働率 "の定義をチーム内で共有し、協働するのに役立ちます。SLOは、信頼性および可用性を測定するための基準として使用されます。上記の例では、SLOは、1週間のうち99％の割合で、ウェブアプリケーションの動画を2秒以内に再生を開始することになります。

SLIとは

SLIは、システムの可用性に関するユーザー体験を対象とした定量的な測定値です。サービスの水準に対して、成功したと見なされるアウトプットの割合をパーセンテージの形で表します。

これらのサービスレベル指標はSLOと関連付けられながら記載されますが、SLIはシステムの信頼性にリアルタイムの動向を反映させるものです。SLIは、閾値より速いリクエストの割合、もしくはパイプラインに入って来るレコードの中で、正しい値が出る割合を測定できます。上記の例であれば、SLIはウェブサイト上で2秒以内に再生開始した動画の割合を測定します。それにより、SLOの目標からどの程度の乖離があるか分かります。

SLAとは

SLAは、ユーザーがサービスを利用する際に期待するサービスレベルを規定するものです。

これらのサービスレベル契約はサービスプロバイダーと顧客の間で締結され、プロバイダーがどのようなサービスを提供するかが記載されるとともに、プロバイダーが満たす義務があるサービス水準が規定されています。SLAには、SLOの公約が守られなかった際に適用される救済手段またはペナルティが記載されています。

上記の例の場合、SLAにはウェブアプリケーションに関するすべてのSLO、対象となるサービス範囲、そしてすべてのSLI、すなわちSLOに基づくパフォーマンス測定に使用されるメトリクスが含まれます。この契約にはサービスプロバイダーと顧客双方の責任事項が含まれます。

以下は、SLOと比較したリアルタイムのユーザー体験を測定した別のSLIの例です。

サービスレベル、SLO、SLI、SLAを使うのは誰か?

SREチーム、リライアビリティエンジニア、機能横断型チームは、しばしばサービスの「信頼性」を定義し測定するうえで苦労することがあります。機能横断型チームは、アップタイムとパフォーマンスを容易に測定できるよう、サービスまたはシステムのあらゆる側面に関する重要なメトリクスを集計した包括的ビューを取得する必要があります。

サービスレベルは、SREチームとリライアビリティエンジニアがアプリケーションとインフラの重要なコンポーネントを特定できるようにする際に関係してきます。特に、どの一つまたは複数のコンポーネントが、いつ外部の顧客に直接機能を提供しているのか知る必要があります。これらの交点は システム境界と呼ばれます。システム境界から得られるメトリクスは、システムのパフォーマンスと信頼性に関する本当の状況を知るために、サイトリライアビリティエンジニアがサービスレベル指標と目標を適用する必要が生じるポイントとなります。

サービス境界を規定し、どのメトリクスをSLIとすべきか、そして何をSLOのコンプライアンス要件とすべきかを決めるには、多くの作業と考察を要します。これは、あまりに複雑であるため、チームが作業を放棄してしまうこともよくあります。リライアビリティエンジニアとSREチームは、全てのスタックと全チームを対象に、可用性とアップタイムのベースラインを迅速に設定できるようにするため、システムのパフォーマンス履歴に基づく正確かつカスタマイズされたSLIとSLOが必要になります。

SREチームと信頼性エンジニアは必ずしも常にサービスレベルの管理責任を担うわけではありませんが、それは、往々にして彼らの管轄下に置かれることになります。SLIを追跡しSLOと結び付けることにより、システムのパフォーマンスに関する目標を設定できるようになります。GoogleのSREブックでは、サービスレベルの4つのゴールデン・シグナル を、レイテンシ、トラフィック、エラー、サチュレーション（飽和）と定義しています。そのため、たとえばAPIコールをチェックし、成功/不成功のリクエストの数（SLI）を、顧客が良好な体験を得るために必要とされる一般的な成功リクエストのパーセンテージ（たとえば95％のSLO）と比較して追跡することができます。

SREチームは、顧客とどのくらい厳しいSLAに合意できるかをより理解するために、しばしば自分達のアプリケーションとサービス内で、重要なコンポーネントに対して厳しいSLOを設定します。ここでチームは、SLOに違反しないためには、どのくらい迅速に問題を解決する必要があるかを理解する方法として、エラーバジェットを適用できます。サービスレベルがあると、チームはメトリクスを集計し、組織全体を対象にアップタイム、パフォーマンス、信頼性に関する透明性のあるビューを取得できます。ビジネスリーダーたちはサービスレベルを利用すれば、複数のチーム、アプリケーション、サービスなどを対象に、一目でコンプライアンスの状況をモニターし、システムの健全性に関する包括的な理解を得ることができます。

サービスレベル管理とは何か？

サービスレベル管理とは、顧客に提供されたサービスのレベルに関するすべてのプロセスおよび運用上の合意事項が、適切であることを確実にすることを意味します。これには、サービスレベルのモニタリングと報告、SLOの設定と調整、SLIの決定、SLAを満たしていることの確認、顧客レビューの実施が含まれます。

ここで本当に重要なのは、あらゆるチーム、SLOの中、そして顧客とのSLAで使われる「可用性」が共通の意味をもつということです。ビジネスがこれらのサービスレベル契約を満たしている、またはそれを逸脱していることを確実にするには、機能横断型のチームが社内のSLOを管理することが重要です。

添付のビデオでは、New Relicのサービスレベル管理機能の使用方法を説明しています。

サービスレベル管理がもたらすメリット

す

すべてのチームを対象にSLOのベストプラクティスを導入するのは容易ではありません。すべてのチームに共通の言葉を定義するには、適切なデータが必要になります。

リライアビリティエンジニアは、すべてのスタックとチームを対象に、可用性とアップタイムのベースラインを迅速に設定する必要があります。顧客に提示するSLAをより良い形で満たすために、サービス境界およびサービスの信頼性に関する統合的で透明性のあるビューを定義するには、SLOとSLIが必要です。環境全体を改善できるようになるには、信頼性とSLOコンプライアンスに関するメトリクスおよびエラーバジェットに関する報告ができなければなりません。

SLI、SLO、SLAに関する優れたプラクティス、そしてサービスレベル管理のためのプラットフォームがあれば、次のようなメリットが得られます。

• 容易な設定: あらゆるサービスについて、クリック一つの操作で自動的にパフォーマンスと信頼性のベースラインが設定され、ガイド付きの簡単なフローで推奨事項が得られ、カスタマイズが可能になります。
• 全チームを対象に信頼性を定義する: サービス境界を明らかにするうえで役立つSLOおよびSLIの推奨値を調整するための困難なプロセスを回避できます。あらゆるエンティティ(サービスの構成要素)に対して、最近のパフォーマンスメトリクスに基づく信頼性ベンチマークを自動的に設定します。
• 継続的な見直しと改善:フルスタック・コンテキストと Terraformなどオープンソースのinfrastructure-as-codeのツールを使った自動化により、チームは特定のノードまたはサービスがシステムの信頼性にどのような影響を与えるかに関するインサイトを得、迅速にパフォーマンスをコントロールできるようになります。サービスオーナーとビジネスリーダー双方を対象とするカスタマイズされたビューにより運用効率が高まり、その結果、より良いレポート、アラート、インシデント管理プロセスがもたらされます。

• 標準化された信頼性: 機能横断型チームは、サービスの信頼性に関する統合的で透明性のあるビューを得られるので、顧客に対応するSLAをより良い形で満たせるようになります。SLO遵守状況とエラーバジェットにより、会社はアプリケーション、インフラ、チームを対象に一貫性のある方法で信頼性に関する報告を行い、変更作業を実施できるようになります。

当社のブログ Best practices for setting SLOs and SLIs for modern, complex systems（最新の複雑なシステム向けにSLOとSLOを設定するためのベストプラクティス） および Introducing service level management（サービスレベル管理の導入）に書いてある、他のアドバイスについてもお読みください。