SLAとは?SLOとの違いや制定時のポイントを解説
ITサービスの提供においては、SLAとしてサービス水準を定め、サービス利用者側と事前合意の上で契約することが一般的です。SLAとはどのような概念であり、どのような項目をSLAとして定めるべきなのでしょうか。また、クラウドサービスを提供する際や、個別に開発したシステムのSLA運用を受託する際など、SLAをどのような観点で制定すればよいのでしょうか。
この記事では、SLAの概要やSLOとの違い、SLAの定め方についてご紹介します。
SLAとは
まず、SLAとはどのような概念であるか、その概要をご紹介します。
SLAはサービスの提供水準を契約で定めたもの
SLAは「Service Level Agreement」の略称であり、日本語では「サービスレベル契約」と訳されます。SLAを端的に説明すると、サービス提供者側とサービス利用者側で、サービス水準を契約で定めたものです。
たとえば、年間365日の中でサービスダウンを1日(24時間)以内に抑えたい場合は、年間稼働日数を364日(サービス稼働率:約99.7%)としてSLAを締結します。合意された水準でサービスを提供できなければ、一般的には返金などの対応が行われます。
通常、サービス提供者側のメンテナンス作業に伴う停止時間はSLAのサービス停止時間には含まれないことが多く、サーバー障害やネットワーク障害などの不測の事態によるサービス停止をどの程度抑えるかがSLAの基準となります。
SLAはIT分野で多く利用される概念ではありますが、その有用性からコールセンターやBPOなど幅広い分野で利用されています。
なぜSLAが必要なのか
なぜSLAを明示して契約を締結する必要があるのでしょうか。ポイントは、「ITサービスの提供において100%を保証することは極めて難しい」という点にあります。
システムを運用する上では、不具合が発生することは避けられません。サーバーやネットワークなどを冗長化したとしても、システム障害は避けられないケースがあります。また、どれだけテストを行ったとしても、アプリケーション側で発生するバグを0にするのは困難です。
ただ、このようにシステムの不具合を完全に防ぐことは不可能であるとはいえ、サービス利用者側としてはシステム停止が頻繁に発生するようでは困ってしまいます。そこで、どの程度の水準でサービスを利用できるか担保する基準をSLAとして明文化し、サービス提供者側とサービス利用者側の双方で合意します。これにより、双方の認識齟齬やトラブルの発生を防ぐことができます。
SLAとSLOとの違い
SLAと似た概念にSLOと呼ばれる指標が挙げられます。両者はどのように違うのでしょうか。
SLOとは「Service Level Objective」の略称であり、日本語では「サービスレベル目標」と訳されます。SLOは、SLAを実現するためにサービス提供者側が目標値として設定するものです。一般的には、SLAを確実に順守するためにも、SLAよりも厳しい条件で設定されます。たとえば、SLAではサービス稼働率を99.5%としていたとしても、SLOではサービス稼働率を99.9%に設定したりします。また、SLAには定義されていないもののSLAを達成するために有効となる目標値を定めることで、SLAを確実に達成するような取り組みに意識的に繋がります。
SLOはあくまでサービス提供者側で定めた目標値であり、達成できなかったとしても返金などのペナルティが発生するわけではありません。サービスの利用契約を締結する際には、SLAとSLOの違いについて注意する必要があります。サービス利用条件においてSLOと記載されている場合には、あくまで目標値でありその水準でのサービス提供が担保されるとは限りません。
SLAの主要項目
クラウドサービスを利用する場合など、既存のサービスを利用する場合には、あらかじめ定められたSLAに基づき契約を行うことが一般的です。ここでは、サービス利用契約において定められることが多いSLA項目についてご紹介します。
サービス稼働率
サービス稼働率は、SLAにおいて最も一般的に定められる項目といってもよいでしょう。多くの場合、サービス稼働率は99.9%や99.95%といったパーセンテージで定められます。また、年間サービス稼働率と月間サービス稼働率を別途定めるなど、細分化されて定義されることもあります。
たとえば年間サービス稼働率が99.9%と定められている場合、年間で約9時間程度の停止時間に抑えるという条件となります。一方で、年間サービス稼働率が99.99%であれば、約1時間の停止時間に抑えられることになります。このように、サービス稼働率は「9」がいくつ並んでいるかによって大まかな水準を把握できます。たとえば、99.999%はファイブナインと呼ばれ、高い稼働率を示す表現として用いられます。
一方で、高いサービス稼働率を実現するためにはサーバーやネットワークの冗長化など、コストがかかります。過剰なSLAを求めすぎないこともポイントです。
<参考>エラーバジェットとは
サービス稼働率という表現を裏返すと「どの程度サービスの停止が許容されるか」ということになります。このとき、許容されるサービス停止の割合をエラーバジェットとして定義することがあります。エラーバジェットはサービス提供者側で定める目標値であり、外部に公開することは少ない指標です。
年間サービス稼働率が99.9%である場合、最大のエラーバジェットは0.1%となります。エラーバジェットを定義しておくことで、システムの品質水準を定めやすくなるというメリットがあります。システムの信頼性を高めようとすればするほど、インフラ面・アプリケーション面双方に負荷がかかります。どの程度の品質を目指すかを定めることで、過剰投資を避けることにも繋がります。
サービス提供時間
サービス提供時間も一般的なSLAの一つです。サービス停止を全く行わない場合は、24時間365日のサービス提供時間となりますが、このようなサービス提供を行うためには、その分コストもかかります。業務システムなど日中帯しか利用しないシステムであれば、夜間はシステムを停止させ運用コストを抑えることが一般的です。
また、サポートの提供時間についても併せて定められることがあります。緊急度が低い一般的な内容の問い合わせ対応については平日9時から17時などで定義しつつ、緊急度が高い障害対応は夜間も対応するようなケースがよく見られます。
故障回復時間
システムの停止後、どの程度の時間内で復旧させるかを定めたものが故障回復時間です。たとえば、故障回復時間を5営業日と定めた場合、最長で1週間サービスが利用できなかったとしても返金等の対応は行われないことになります。
レイテンシー
レイテンシーとはデータ転送における遅延時間を指す言葉です。SLAにおいては、主にネットワーク回線の利用契約で用いられます。通信の遅延に対して定められる指標であり、たとえば、「ネットワーク通信において50msecの遅延が24時間以上継続した場合には返金対応を行う」といった内容で定められます。
帯域保証
ネットワーク回線の利用においては、(「ベストエフォート型として)利用できる通信量を保証しない形式」と、(「帯域保証型として)一定の通信量の利用を保証する形式」の2種類があります。帯域保証型においては、たとえば「100Mbps以内のデータ量であれば必ず通信できる」ように保証されます。
SLAの定め方におけるポイント
クラウドサービス提供事業者としてSLAを設定する場合や、個別に開発したシステムの運用・保守契約を締結する場合などにおいて、どのようにSLAを定めていけばよいのでしょうか。ここでは、SLAの定め方におけるポイントをご紹介します。
障害範囲を定義化する
SLAを定める際には、障害の範囲の定め方が一つのポイントとなります。部分的な停止においても補償対象とするか、システムの全停止のみを保証対象とするかによって、システム運用設計全体に大きな影響が生じます。
SLAとSLOの明確な区別
契約上、どこまでをSLAとして相手先に保証し、どこまでをSLOとして目標とするかを明確にする必要があります。SLAは契約条件となるため、必達の目標となります。
そのため、サービス提供者側においては、SLOをターゲットとしてサービス提供をしつつ、SLOを緩和した条件でSLAを締結するような、バッファを設けた運用が必要です。
サービス利用者側においては、上述のとおり条件として提示されている指標がSLAなのかSLOなのかよく理解しておかなければなりません。
過剰なサービスレベルは避ける
SLAを高く設定しすぎると、過剰なサービスとなります。クラウドサービス等の提供において、過剰なSLAはコスト高の原因となり、結果的に収益性が悪化します。他社が設定しているSLAの事例や、利用者に対する調査などを通して、適切なSLAを設定する必要があります。
また、個別契約においてSLAを定める場合、運用委託側が高いSLAを求めすぎてしまうことがよくあります。過剰なSLAは委託側にとっても無駄なコストとなってしまうため、受託側からもノウハウや経験などを基に、適切な水準を設定していくことが重要となります。
例外ケースを定める
SLAの契約においては、大規模災害やテロ行為などの例外ケースが定められることが一般的です。これらは「不可抗力」と呼ばれ、一般的な契約条件としてよく見られるものです。
例外ケースにおいてはSLAが適用されず、返金等の対応もされないこととなります。例外ケースが妥当なものであるかは、自社の法務担当者とも相談の上、必ず確認すべきでしょう。
ゴールデンシグナルを参考にする
SLAを定める際に参考になるのがGoogle社により提案された「ゴールデンシグナル」と呼ばれる指標です。ゴールデンシグナルとは信頼性の高いサービスを提供するために注目すべき4つの指標であり、具体的には以下のとおりです。
- レイテンシー:リクエストの処理にかかる時間
- トラフィック:システムに対してかかる負荷
- エラー:リクエストの失敗率
- サチュレーション:各リソースの利用状況
これらの指標も踏まえつつSLAやSLOを検討することが有効となります。
まとめ
この記事では、SLAについてご紹介しました。SLAはサービスの利用や運用の委託などにおいて一般的に用いられる契約条件であり、サービスの提供側・利用側双方が理解しておかなければならない概念です。適正な水準でSLAを制定することにより、過剰なコストを避けることにつながります。
サービス提供者側においては、SLAを順守していくために安定的な運用体制が求められます。当社では、サービスの安定運用を実現するために効果的なSaaS型IT統合運用監視サービス「LogicMonitor」を提供しています。AIOps機能による障害の根本原因分析機能やネットワークトポロジーの可視化によるネットワーク構造の把握など、様々な機能を備えるLogicMonitorにより、障害発生の早期認知や迅速な原因究明が可能に。障害復旧時間の短縮によるサービス稼働率向上を実現できます。
LogicMonitorの詳細についてご興味のある方は、ぜひ一度お問い合わせください。