SLO、SLI、SLAとは何か?

サービスレベルとは、特定期間中にユーザーに提供されたサービスを、測定可能な表現方法で言い表したものです。

• サービスレベル目標（SLO）とは、システムから期待される可用性に関して設定された目標です。
• サービスレベル指標（SLI）とは、システムの可用性を特定するための主要な測定値およびメトリクスです。
• サービスレベル契約（SLA）とは、合意された内容およびシステムがSLOを満たさなかった場合の対応を説明した法的契約です。

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

サイト信頼性エンジニアリング（SRE）は、サービスのパフォーマンスと信頼性の測定法にフォーカスした、分散システムのアップタイムおよび信頼性維持に関するベストプラクティスを普及させました。GoogleのeBook「サイト信頼性エンジニアリング：Googleが本番システムを実行する方法」では、SLOから始め、メトリクスのモデリング、選択、分析に関するフレームワークを説明しています。

SLO、SLI、SLA：それぞれの違い

SLO、SLI、SLAはさまざまな点で異なりますが、組み合わせると、効果的な運用と顧客満足につながるように設計された一貫したスタックを形成します。それぞれについて詳しく見ていきますが、この表ではこれら3つの柱の概要を示します。

SLAは通常、ビジネスチームや法務チームが顧客と連携して作成されます（特定の契約の場合）。プロバイダーは、さまざまなインスタンスタイプに合ったクラウドサービスプロバイダーなど、サービスに関する一般的なSLAも提示します。SLAには、複数のSLO、対象となるサービスの範囲、パフォーマンス測定に使用するSLIを含めることができます。

SLO、SLI、SLAは、一連のテクノロジーからサービスの品質を確保する上で有益です。目標が達成可能で、顧客が満足していることを確認するために、SLO、SLI、SLAのすべての影響者に助言を求める必要があります。

サービスレベル目標（SLO）とは何か？

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

サービスレベル目標は、チームが協力し、「可用性」および「アップタイム」の意味について共通見解をもつうえで役立ちます。SLOは、信頼性および可用性を測定するための基準として使用されます。上記の例でも説明したように、SLOには、1週間の99％においてウェブアプリケーション内の動画の再生を2秒以内に開始しなければならない、と定められています。

SLOの例

前述のように、SLOは技術的なメトリクスと、顧客と合意したより広範なサービスレベル契約（SLA）との間の橋渡しとして機能します。さらにいくつかの例を見てみましょう。

SLOのアップタイム／可用性

• 30日間のアップタイムは99.9%
• いずれの週でも、システムエラーが原因で失敗するリクエストは0.1%未満

SLOのレイテンシ

• 95%のウェブページの読み込みが2秒以内に完了する
• 99%のAPIリクエストが300ミリ秒以内に返される

SLOのエラー率

• すべてのトランザクションでエラーが発生するのは0.05%未満
• データベース書き込みの失敗は1%未満

SLOのスループット

• ピーク時に、システムは1秒あたり10,000件のリクエストを処理できる
• 1日あたり5TBのデータ取り込み速度（低下しない）

SLOの容量と使用率

• 重要なシステムのディスク使用率は、常に80%未満
• どのサービスインスタンスでも、RAM使用量の合計は70%を超えない

SLOデータの整合性と一貫性：

• クラスタ間のデータレプリケーションは5分以内に完了する
• プライマリストレージシステムとセカンダリストレージシステム間のデータ不整合は0.01%未満

SLOの耐久性：

• 1年間で99.9999999%（9/9）のデータの耐久性
• バックアップ復元の成功率は99.5%

SLOの変更管理と導入率：

• 98%の導入をロールバックなしで実施する
• 99%の変更による計画外停止は発生しない

SLOの設定方法

適切なSLOを設定することは戦略的なプロセスですが、正しく行うとサービスの信頼性が向上し、素晴らしい顧客体験が実現します。

1. ユーザーの期待とニーズを理解します。顧客や社内チームなど、すべての関係者と連携して、アプリケーションのパフォーマンスと信頼性に何が重要かを把握する必要があります。
2. システムのパフォーマンス履歴を分析して、現在の動作を理解し、繰り返し発生する問題や懸念事項を特定します。この情報により、レイテンシ、エラー率、アップタイムなど、サービスの健全性を正確に表す具体的で測定可能な指標を設定できます。
3. これらの指標を設定したらすぐに目標を定義します。これらは、挑戦的でありながら達成可能で、より広範なビジネス目標と一致するものでなければなりません。

ユーザーの期待、システムの動作、ビジネスの優先順位の変化を反映するためにSLOを定期的に確認し、場合によっては調整する必要があることを念頭に置いてください。また、バランスを取ることも重要です。高い信頼性は重要ですが、SLOが厳しすぎると俊敏性と革新性が損なわれる可能性があります。New Relicなどのコラボレーションツールとオブザーバビリティプラットフォームは、システムとビジネスの進化に合わせてSLOを継続的に監視および調整するのに役立ちます。

積極的なSLOと現実的なSLOの設定のバランスをどのように取ればよいか？

バランスを取るには、ユーザーの期待とシステムの技術的機能を理解する必要があります。ビジネス側と技術側の両方の関係者が連携して、挑戦的でありながら実現可能なSLOを設定することが重要です。

SLOが一貫して達成されていない場合はどうなるか？

SLOが一貫して達成されていない場合は、サービスに根本的な問題がある可能性があります。チームが根本原因分析を実施して問題を特定し、改善に取り組む必要があります。SLAでは、SLOが達成されない場合、契約で定義されているペナルティやその他の結果が発生する可能性があります。

サービスレベル指標（SLI）とは何か？

SLIは、システムの可用性に関するユーザー体験を対象とした定量的測定値です。サービスレベルについて、正常なアウトプットの割合をパーセンテージの形で表します。

SLIはSLOとの関連で記載されますが、SLIはシステムの信頼性にリアルタイムのシグナルを組み込みます。SLIは、閾値より速かったリクエストの割合、もしくはパイプラインに入って来る記録の中で正しい出力値をもたらす記録の割合を測定できます。上記の例で説明したように、SLIはウェブサイト上で2秒以内に再生を開始した動画の割合を測定します。SLIでは、SLOの目標からどの程度の乖離があるかが分かります。

SLIの例

SLIは、SLOとSLAの基盤として機能します。いくつか例を見てみましょう。

可用性／アップタイム

• 成功したリクエストの割合と合計リクエストの割合
• 合計期間に対するシステムアップタイムの比率

レイテンシ

• APIリクエストが応答を返すのにかかる時間
• エンドユーザーがウェブページを読み込むのにかかる時間

スループット

• 1秒あたりに処理されるリクエスト数
• 特定の時間枠内に処理されるデータの量

エラー率

• 失敗したリクエストの割合と合計リクエストの割合
• 返される4xxまたは5xxのHTTPステータスコードの数

サチュレーション（飽和度）

• CPUやRAMなどのリソース使用率
• 使用可能なストレージの合計に対する使用済みストレージの量

カバレッジ

• 特定の期間内に新機能のアップデートを受け取ったユーザーの割合
• キャッシュされた応答と配信された応答の合計の比率

鮮度

• 読み取られるデータの書き込み時と比較した経過時間
• 複数のデータベースまたはシステム間でのデータ複製にかかる時間

容量

• システムが同時に処理できるユーザーまたはセッションの最大数
• システムを低下させることなく処理できる最大データ量

サービスに適切なSLIを選択するにはどうすればよいか？

ユーザー／顧客に最も重要なことに基づいて、SLIを選択する必要があります。一般的なSLIには、レイテンシ、エラー率、スループット、可用性などがあります。ユーザーの期待とビジネスの優先順位を理解することが重要です。

SLIを正確に測定するにはどうすればよいか？

正確な測定には、多くの場合、監視とログ記録システムの実装が必要です。関連するデータポイントをキャプチャし、SLIに関するインサイトが得られるツールを使用します。精度を確保するには、測定システムを定期的に検証、調整します。

サービスレベル契約（SLA）とは何か？

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

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

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

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

オブザーバビリティにおいてSLI、SLO、SLAは重要です。今すぐNew Relicサービスレベルを使い始めましょう。

SLAの例

企業や顧客に応じて、また提供されるサービスによって、SLAは異なります。ビジネスリーダーによるSLAの例へのリンクをいくつかご紹介します。

• AWSの一般的なSLA
• セキュリティサービス向けHP Enterprise SLA
• インターネット専用サービス向けVerizon Business SLA

大手企業の既存SLAの優れた例は他にも多数あるため、独自のSLAを作成する際に評価できます。

優れたSLAを作成する方法

SLAを作成するには、顧客、プロバイダーの法律顧問、事業部門、信頼性チームなど、さまざまな関係者からのあらゆる分野にわたる意見が必要です。これは法的拘束力のある契約であるため、SLAの項目についてチームの全メンバーで徹底的かつ率直に議論する必要があります。

SLAは法的契約であるため、包括的な文書です。したがって、SLAには次の議題を含めることができます。

• 概要（導入情報、法的用語の定義、契約の範囲、目的、レビュー期間、契約パラメーターなど）
• サービス契約自体（顧客が期待できるサービス品質、それらの品質を提供する目的、監視および追跡されるメトリクスの特定）。重要な条件では、発生する可能性のある問題の種類と解決に必要なレスポンスタイムを特定します
• 例外や制限事項には、契約から除外される項目またはイベントが記載されます。たとえば、レスポンスタイムには顧客の応答による遅延は含まれません
• 責任は、SLAを満たすために誰が何を行うかを特定します。これには、問題に対処するためのプロバイダーと顧客の両方の対応が含まれます
• サービスの可用性は、サービス担当者が対応できる時間、利用可能なサービスの種類（オンサイト、電話サポート、オンライン／チャットサポートなど）、およびレスポンスタイムに影響するその他の側面を定義します
• 概要に含まれる法的用語に加えて、参考資料と用語集は、用語の意味を定義するのに役立ちます
• 価格設定も含まれ、さまざまなサービスが対象になる場合があります
• 救済措置では、SLAが満たされなかった場合に顧客に提供される補償が特定されます。これらはよくクレジットで対応されます
• その他の議題をカバーするために付属書類が含まれる場合があります

SLAに違反するとどうなるか？

SLAは法的拘束力のある契約であるため、一方または両方の当事者が義務を果たせなかった場合には結果が伴います。こうした救済措置はSLAで定義する必要があります。違反が疑われる場合は、まず顧客から信頼性エンジニアリングチームまで、関係するすべての当事者間で、明確で頻繁な専門的なコミュニケーションが必要です。

SLA違反を管理する上での最初のルールは、人を責めるのではなく、問題を非難することです。問題を解決できれば、危機を回避できます。

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

法務、ビジネス、信頼性エンジニアリングなどの機能横断型チームは、サービスレベル、SLO、SLI、SLAを利用して、質の高いサービスを定義し提供しています。一方、顧客はSLAを、期待されるサービスレベルに関してプロバイダーが行った約束と見なしています。このような利害関係者の組み合わせにより、サービスレベルスタックの定義が難しくなります。利害関係者は、サービスの「信頼性」を定義し測定する上で苦労することがよくあります。

サービスレベルがあると、チームはメトリクスを集計し、組織全体を対象にアップタイム、パフォーマンス、信頼性に関する透明性のあるビューを取得できます。ビジネスリーダーたちはサービスレベルを利用すれば、複数のチーム、アプリケーション、サービスなどを対象に、一目でコンプライアンスの状況をモニターし、システムの健全性に関する包括的理解を得ることができます。

サービスレベルは、SREチームとSREエンジニアがアプリケーションとインフラの重要なコンポーネントを特定するのに役立ちます。一つまたは複数のコンポーネントが外部の顧客にどの時点で機能を提供するのかを知る必要があります。こうした共通領域はシステム境界と呼ばれています。

SLIを使用する場合

確立されたSLOに対してサービスを定量化する必要がある場合はいつでも、SLIを使用します。目標を設定する場合は、パフォーマンスを実証するためにそれを検証できる必要があります。これを念頭に置いて、SREエンジニアとSREチームは、スタック全体の可用性とアップタイムのベースラインSLOを設定できるようにするため、システムのパフォーマンス履歴に基づく正確なSLIが必要です。

システム境界では、SREはシステムのパフォーマンスと信頼性に関する実際の状況を知るために、自分のメトリクスにSLIと目標を適用する必要があります。

SLOを使用する場合

システムの望ましいサービスレベルを達成する必要がある場合に、SLOをいつでも適用できます。小規模企業からエンタープライズの運用まで、通常は最低限のサービスレベルが求められます。SLOはそのサービス品質を達成する方法を定義します。

SREチームは、顧客とどのくらい厳しいSLAに合意できるかに関する理解を深めるため、しばしば自分達のアプリケーションとサービス内で、重要なコンポーネントに対して厳しいSLOを設定します。ここでチームは、SLOに違反しないためには、どのくらい迅速に問題を解決する必要があるかを理解する方法として、エラーバジェットを適用できます。

SLAを使用する場合

支払顧客に対しては必ずSLAを使用してください。一部のSLAは顧客に固有であり、必要なサービスによって異なります。クラウドやその他のITサービスなどの一般的なSLAは、顧客がプロバイダーのシステムに期待できる内容を定義します。SLAを提供せず、顧客に同意を求めない場合、曖昧さが生じ、顧客の不満や法的問題につながる恐れがあります。

SLA、SLO、SLIの課題

SLA、SLO、SLIの課題に関する認識は、より効果的なサービスレベルの作成に役立ちます。それぞれについて、積極的に取り組むべき課題は以下の通りです。

SLOの課題

• 賢明なメトリクスの選択：メトリクス（SLI）は、ビジネス目標（SLO）と一致し、顧客の期待（SLA）を満たす必要があります。そのため、適切なメトリクスを選択することは重要であり、難しい場合があります
• バランスを取る：バランスの取れたSLOを定義するのは困難な場合があります。測定可能なSLOを定義します。実現可能性を証明するSLIで明確に定義されていないSLOに時間を浪費しないでください。逆に、簡単に達成できるSLOでは、競合他社との差別化が図れない可能性があります
• 外部依存関係を把握する：サービスの信頼性が依存するサードパーティのサービスをすべて把握します。外部サービスに障害が発生すると、内部コンポーネントが完全に機能していても、SLOに準拠する能力が低下する可能性があります

SLIの課題

• 多すぎるメトリクス：測定を複雑にする大量のデータを信頼性チームに送信しないでください。各メトリクスを評価して、チームが監視、解釈、維持するために費やす投資収益率を確認してください
• 測定が難しいメトリクス：ユーザーエンゲージメント、リアルタイムアプリケーションのレイテンシ、ユーザー満足度など、一部のパフォーマンスメトリクスは、正確に測定するのが困難です。機械学習やその他のAIツールなどの自動化された方法を利用すると、これらのメトリクスをより正確に定義、測定できるかもしれません。

SLAの課題

• 全利害関係者が関与していない：コラボレーション、協力、連携あるのみ。関係者がSLAを実現する内容、理由、方法を定義し、理解するために必要な時間を取ってください。SLAは、お客様との関係を定義します。SLAを提供する際に、信頼性エンジニアリングからお客様まで、すべての利害関係者が関与しない場合、非現実的なSLOになり、期待されるサービス品質を提供できなくなる可能性があります
• 顧客の要望と新しいテクノロジーへの適応：技術の進化は急速に進んでおり、信頼性エンジニアリングの新しいツールに追いつくのは困難です。顧客のニーズの変化についても同様で、頻繁な調整や再交渉が必要になる場合があります
• コスト：コストと利益のバランスは常に課題となっています。あらゆる観点からSLAを検討する必要があり、これは機能横断型チームに人材を投入することを意味します。この領域を軽視すると、よりコストのかかる訴訟や、さらに悪いことに、顧客信頼の損失にもつながりかねません

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

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

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

次にお見せするビデオは、チームによるNew Relicのサービスレベル管理の使用方法を説明しています。

サービスレベル管理のメリット

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

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

SLI、SLO、SLAに関するグッドプラクティスとサービスレベル管理のためのプラットフォームを持つことで、以下のようなメリットが得られます。

• 容易な設定： あらゆるサービスについて、クリック一つの操作で自動的にパフォーマンスと信頼性のベースラインが設定され、ガイド付きの簡単なフローで推奨事項が得られ、カスタマイズが可能になります。
• 全チームを対象に信頼性を定義する： サービス境界を明らかにするうえで役立つSLOおよびSLIの提案事項を調整するための困難なプロセスを回避できます。あらゆるエンティティについて、最近のパフォーマンスメトリクスに基づく信頼性ベンチマークを自動的に設定します。
• 反復と改善：フルスタック・コンテキストとTerraformなどオープンソースのインフラストラクチャー・アズ・コードのツールを使った自動化により、チームは特定のノードまたはサービスがシステムの信頼性にどのような影響を与えるかに関するインサイトを得、迅速にパフォーマンスをコントロールできるようになります。サービス所有者（オーナー）とビジネスリーダー双方を対象とするカスタマイズされたビューにより運用効率が高まり、その結果、より良い報告、アラート、インシデント管理プロセスがもたらされます
• 標準化された信頼性：機能横断型チームは、サービスの信頼性に関する一体化され透明性があるビューを得られるので、顧客に対応するSLAをより適切に遵守して、SLA違反を回避できます。SLOコンプライアンス・メトリクスとエラーバジェットにより、会社は信頼性に関する報告を行い、アプリケーション、インフラ、チームを対象に一貫性のあるかたちで変更を導入できるようになります。

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