公開日:2022年5月1日
サービスレベル目標(SLO)とは、テクノロジー製品やサービスの信頼性に関する目標を指します。サービスレベル指標(SLI)とは、その信頼性目標が守られているかどうかを評価するための測定値を指します。この2つは「SLO/SLI」とまとめて表現されることが多く、さまざまな主要業績評価指標(KPI)の達成状況を判断して、組織全体のパフォーマンスや信頼性を監視するために役立ちます。SLOとSLIはインシデント管理でも、特に問題発生時のトラブルシューティングで(理想的には予防対策として)活躍します。SLOとSLIはサービスレベル契約(SLA)の管理に欠かせません。SLAには、サービスプロバイダーが顧客に保証する最低限のサービスレベルが定義されます。たとえばWebサービスの場合は、通常、稼働率や最小応答時間が指定されます。
SLO、SLI、SLAの管理は、ネットワークとサービスの品質保証を担うサイトリライアビリティエンジニア(SRE)にとって特に重要です。可用性と信頼性はSREの最優先事項です。SREは、100%に近い稼働率の達成と、そのサービスレベル達成のコストとのバランスをとる必要があります。ほかにSLOの対象として一般的なものには、エラー率、スループット、サービス対応(サービスデスク運用など)などがあります。
以下では、SLO、SLI、SLAの違い、SLOとSLIの計算方法、組織に適したSLOの設定方法について説明します。
サービスレベル目標(SLO)とサービスレベル指標(SLI)の違い
サービスレベル目標(SLO)は、特定のメトリクスに関する目標を指し、サービスレベル指標(SLI)は、そのメトリクスの継続的な測定値を指します。この2つは関連が深く、混同されがちです。具体的に言えば、SLOはサービスで達成すべきゴールまたは好ましい状態を率で表した数値です(稼働率99.999%、障害によるダウンタイム率0.0001%など)。ダッシュボードに0~100%を示すメーターがある場合、たとえば99.999%の位置がSLOに該当します。そして、時間とともに変わるメーターの針の位置がSLIに該当します。針が99.999%よりも下を指した場合、パフォーマンスのしきい値を下回ったことになります。これによりアラートが生成され、SREは対応を求められます。サービスレベル管理エコシステムのさまざまな活動の中で、SLOとSLIは分かちがたい関係です。
SLIの計算方法
SLIは、全イベントのうち許容可能とみなすイベントの割合として計算できます。たとえば、HTTPリクエストの成功率を測定する場合、SLIの計算式は次のようになります。
(成功したリクエスト数 / 全リクエスト数) x 100
同様に、サーバーの処理速度の低下を測定するためのSLIについて考えてみましょう。遅延の最小許容時間を400ミリ秒とした場合、SLIは次のように計算できます。
(400ミリ秒以内に完了したリクエスト数 / 全リクエスト数) x 100
SLIは、特定の時間単位(1分ごと、1時間ごと、1カ月ごとなど)で計算します。一方、SLOは通常、比較的長い単位で設定します。たとえば、Amazon Computeサービスでは月間で95%以上の稼働率が保証され、それを下回った場合はその月の料金が全額返還されます。問題のトラブルシューティングには短い時間単位のSLIが役立ちますが、SLAコンプライアンスを確保する目的では長い時間単位でSLIを評価する必要があります。
適切なSLOの特性
適切なSLOの特性は、Rick Sturm氏、Wayne Morris氏、Mary Jander氏による2000年の共著『Foundations of Service Level Management』(邦題『標準サービスレベルマネジメント』)で初めて明確化されました。同書では、適切なSLOに重要な特性として以下のものが挙げられています。
- 達成可能であること:100%というSLOは現実的に達成が不可能であり、理論上は目指すべきゴールではあっても、実用的な目標とは言えません。SLOは、許容可能な最低限のパフォーマンスレベルに設定すべきで、不可能と考えられる目標であってはなりません。
- 有意義であること:組織にとってあまり意味のないメトリクスにSLOが設定される例はよくあります。CPU使用率はSLOとして意味がないとよく言われますが、それは通常、ユーザーと組織のどちらにも直接影響しないためです。
- 測定可能であること:正確に測定できないメトリクスはSLOに適していません。
- 制御可能であること:たとえば、データセンターへの落雷数は制御できないため、SLOにはふさわしくありません。
- 理解しやすいこと:メトリクスの中には、IT管理とは直接関係ないものもあります。たとえば、パケットの衝突率はシステムのパフォーマンス指標としてよく使われますが、ユーザーにとっては具体的なメリットがないため、SLOには適していません。
- 無理がないこと:稼働率99.99%でも許容可能なら、無理に99.9999%を目指す必要はありません。データセンターを冗長化し、フェイルオーバープロトコルを導入して、スタッフを追加しなければそのSLOを達成できないのであれば、稼働時間を52分延ばすためにそれだけのコストを費やすのは割に合わないでしょう。
- 相互の同意があること:すべてのSLOには、そのすべての関係者、一般的にはサービスのプロバイダーと利用者の双方の同意が必要です。
SLOの対象が決まったら、適切な値を設定する必要があります。これは基本的にはサービスプロバイダーと利用者(組織内または外部)との間で交渉して決めるものですが、多くの場合、プロバイダーが提示して利用者がそれを受け入れるか利用をやめるかになります。
可用性は有意義かつ測定可能であるためSLOの対象として適切ですが、理想的な数値や最大限のしきい値を設定するのは避けます。
大切なのは、どのメトリクスでもSLOには、理想的な数値や最大限のしきい値ではなく、組織がビジネス目標を達成するために許容可能な最低限のレベルを設定するように心掛けることです。
SLIのエラー率
SLIのエラー率とは、SLOの下限のしきい値を下回るアクティビティ範囲を指します。言い換えればSLIの逆で、「1 – SLI」の式で求められます。
このエラー率は、エラーバジェットとも呼ばれ、パフォーマンスメトリクスに対する別の捉え方です。月間稼働率が99%であれば、これを1カ月あたりに許容されるダウンタイムが1%というエラー率で捉えるとより理解しやすく、注意しやすくなるでしょう。稼働率99.999%の場合はエラー率が0.001%です。また、このエラー率を1カ月あたり7.2時間と表すこともできます。
エラーバジェットという概念が生まれたのは、それによりIT管理者がダウンタイムや遅延についてより戦略的判断ができると考えられるためです。たとえば、バックアップ機がないサーバーをどうしてもオフラインにしなければならない場合、エラーバジェットとして1カ月あたりに7.2時間のダウンタイムが許容されるとわかっていれば、その時間内ならオフラインにしても問題ないと判断できます。
サービスレベル契約(SLA)の概要
サービスレベル契約(SLA)は、組織と外部または組織内のサービス利用者との間で交わされる、SLOに関する正式な契約です。SLAによってSLOが正式な取り決めになります。サービスプロバイダー(一般的にはクラウドサービスプロバイダー)とのSLAでは、通常、プロバイダーがSLOを達成できなかった場合の罰則も定められます。
外部とのSLAにはほかに、請求や返金に関する仕組み、SLOの対象外の事象(顧客によるミスなど)、SLIの正式な計算方法、SLA終了または変更の手順などの契約条項も含まれます。
組織内のSLAは、法務部、インシデントレスポンスチーム、エンジニアリングチームが、サービスデスクの運用状況、社内ネットワークのパフォーマンスと稼働率、さらには不正行為によるチャージバック率など、業務運用の効果を測定するために役立ちます。
KPIとSLAの関係
主要業績評価指標(KPI)は、実際のビジネスプロセスのパフォーマンスを測定するためのメトリクスです。KPIは、プロセス、システム、さらには個々の従業員にまで幅広く適用できます。IT運用では、社内外のネットワーク上にあるシステムのパフォーマンスを把握するためにKPIがよく使われます。KPIとしては、ビジネス成果に直接つながるメトリクスが理想的です。たとえば、eコマースWebサイトの稼働率は、そのWebサイトが生み出す収益に直接関係するため、稼働率と収益のどちらもKPIとして使用できます。
KPIとSLIには深い関係があり、この2つの言葉はSLAで区別なく使われることがよくあります。ただし一部では、KPIには定量的な指標を設定し、SLIには、単なるパフォーマンス指標ではなく、カスタマーエクスペリエンスや戦略的な見通しをある程度反映した、より抽象的な指標を設定すべきだという考え方もあります。
SREにとってのSLO、SLI、SLA
サイトリライアビリティエンジニア(SRE)にとって、SLO、SLI、SLAの目的は明確です。SREは主にネットワークとサービスの可用性を確保する責任を担うため、サービスレベルに関するこれらのメトリクスでは特に稼働率と信頼性に重点を置きます。稼働率の低いシステムは信頼性が低いため、SLAでは最大限の稼働率を確保することを目指します。SREは、SLIをリアルタイムで監視してシステムの状況を把握し、過去のSLIを分析してシステム障害の予兆を捉え、対策を講じます。この分析にはAIツールが特に役立ちます。
いずれのSLOでも、目標とする稼働率を高く設定すればコストが上がります。SREは、稼働率100%が実現不可能であることをよくわかっているはずです。そもそも多くの場合、稼働率100%は求められず、適切な目標ではありません。ほとんどのサービスでは、ダウンタイムが計画的に設けられます。これにより、過度な信頼性目標の設定を避け、単一のサービスの可用性に対する期待が高まりすぎるのを防ぐことができます。また、不適切な使用やセキュリティ違反を発見、防止するためにも役立ちます。
SLOとSLIの設定対象
SLOとSLIは、社内外のさまざまなビジネス用途、技術用途に使われます。SLOは、SaaS製品のパフォーマンスと信頼性の評価基準として幅広く利用されています。たとえば、Webホストの稼働率、クラウドストレージの可用性、クラウドアプリケーションホスティングサービスの遅延や応答時間などにSLOが設定されます。SLOは通常、クラウドサービスプロバイダーとのベンダー契約書に明記されていますが、SLIを監視してそのSLOが守られているかどうかを確認するのは利用者の責任になるのが一般的です。
SLIの主な設定対象を以下に示します。
- サーバーの稼働率:サーバーまたはWebサービスが利用可能で応答する時間の割合
- サーバーの遅延:サーバーまたはサービスがリクエストに応答するまでの時間
- エラー率:Webサーバーなどへのリクエストに対してエラーが返される割合
- スループット/パフォーマンス:特定のチャネルでデータが配信される速度
- 使用率:サービスが利用中になっている時間の割合
- データの鮮度:ユーザーに配信されるデータのうち最新であるデータの割合
SLIの設定対象には、遅延、エラー率、スループットなどがあります。
SLIは労働のパフォーマンスを測定するためにも使用できます。以下に例を挙げます。
- サービスデスクの対応:ヘルプデスクへの問い合わせの対応または解決にかかる時間
- エスカレーションレベル:ヘルプデスクへの問い合わせの重大度が高いと判断されてエスカレーションされる頻度
実用的なSLOを設定するには、SLIを特定の期間測定し、対応するSLOの基準を評価して、対象となるメトリクスの最低限のしきい値を設定することが大切です。
SLOが必要な理由
SLOは、利用しているサービスがその利用コストに見合った価値を提供していることを確認するために重要です。また、組織内でSLOを使用すれば、システムや従業員のパフォーマンスを評価し、さらには顧客の期待や満足度を定量化できます。逆にSLOがないと、これらのパフォーマンスメトリクスの監視基準がわからず、現状の良し悪しや今後状況が改善するか悪化するかを判断できません。
今日、Webサービスやアプリケーションに対するエンドユーザーの期待はかつてないほど高まっています。短時間のダウンタイムやわずかな遅延は、サービスの提供側にとっては些細な問題に見えても、サービスを日常的に利用するユーザーにとっては非常にわずらわしく感じます。実際、遅延が1秒を超えるとユーザーは実行中の操作に集中力できなくなります。さらに10秒を超えると、ユーザーは不満を感じ、実行中の操作を断念する可能性があります。
応答が速くエラーのないエクスペリエンスを提供することは、ビジネスのあらゆる面で重要になっています。SLIを監視し、SLOと比較して検証することは、組織が特に必要とする、顧客向けサービスの状況に関する定量化可能なインサイトを獲得するために最も有効な方法です。
SLOとSLIの導入方法
SLOとSLIは、ほぼすべての組織にとって重要です。導入時には、まず、組織内の各種システムがどのように構成され、従業員や顧客がそれらのシステムをどのように使用しているかをよく理解する必要があります。システムのアーキテクチャとそのカスタマーエクスペリエンスとの関係を把握することは欠かせません。
全体として最善の方法は、基本から始めることです。ネットワークとサービスの可用性や遅延に関するシンプルなSLOは、簡単に算出でき、理解しやすく、ユーザーへの影響が明確で大きいため、最初に導入するには最適なSLOです。SLOの適切な値を決めるのは容易ではありませんが、SLIを継続的に監視、分析し、微調整を繰り返すことで、組織にとって最大の効果をもたらすSLOの値を特定できます。
SLOとSLIは、組織が作成するよりも、ベンダーが作成したSLAに組み込まれている場合が多いことに注意が必要です。小規模な組織ではSLOの交渉は難しいかもしれませんが、それらが監視すべき重要なメトリクスであることは確かです。
SLOとSLIの重要なガイドライン/ベストプラクティス
SLOとSLIの設定と管理に関する重要なベストプラクティスをいくつかご紹介します。
- 重要なメトリクスに集中する:顧客との関連が深く影響の大きいメトリクスにSLOを設定します。
- わかりやすさを重視する:SLOは、ITチーム以外の関係者も簡単に理解できる必要があるため、ビジネスニーズや顧客のニーズに沿ったSLOを選びます。
- SLIが検証可能であることを確認する:SLIが適切に測定されていることを確認するために定期的な監査が必要な場合があります。可用性に関するSLOがダッシュボード上では達成されているのに、サービスがオフラインになるとユーザーから苦情が寄せられる場合は、メトリクスの生成方法を確認する必要があります。
- SLOの数を最小限に抑える:管理しきれないほど多くのSLOをダッシュボードに表示するのは避けましょう。関連が深く重複しないメトリクスを監視して、シンプルに管理しながらシステムの価値を最大限に引き出しましょう。
- SLOに違反したときは早急に対処する:SLIが想定を下回った原因をすばやく究明し、ただちに対策を打つことが重要です。
- すべてのSLOを定期的に見直す:ビジネスもテクノロジーも変化します。ときには劇的に変化します。そのため、昨年重要だったSLOが今日では重要でなくなり、もはや不要になることもあります。
顧客の期待がかつてないほど高まる中、SLOとSLIはカスタマーエクスペリエンスの品質を測定するために効果的な方法です。SLOとそのSLIに細心の注意を払えば、期待に沿ったシステムパフォーマンスを維持し、顧客満足度を高めて、最大限の利益につなげることができます。
IT/オブザーバビリティに関する予測
驚きに勝るものはありません。すべてを受け止める準備を整えておきましょう。Splunkのエキスパートが予測する、来年の重要なトレンドをご確認ください。