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