SLA
エスエルエー
サービス提供者が顧客に約束する品質水準の契約。違反時の補償まで含む合意。
概要
SLA(Service Level Agreement、サービスレベル契約)は、サービス提供者が顧客に対して「この水準の品質を守ります」と約束する契約です。代表的なのは稼働率の保証で、「月間稼働率99.9%を保証し、下回った場合は利用料金の10%を返金する」のような形を取ります。品質の目標値だけでなく、測定方法・除外条件・違反時の補償までを含んだ「合意文書」である点が特徴です。
クラウドサービスを使ったことがあれば、AWS や Google Cloud の料金ページの片隅で SLA という言葉を見かけたことがあるはずです。企業間のシステム開発・運用委託でも、ホスティングでも、SaaS の法人契約でも、「どこまでの品質を、何を根拠に、いくらの責任で約束するか」を定める共通言語として使われています。
似た言葉に SLO がありますが、両者は性質が異なります。SLO は自分たちの運用のための「内部目標」、SLA は顧客への「対外的な契約」です。SLA 違反には返金などの実害が伴うため、通常は内部の SLO を SLA より厳しく設定し、契約違反に至る前に対処できる余裕を確保します。
なぜ生まれたか
システムの構築・運用を外部に委託したり、通信回線やホスティングを借りたりする形態が広がると、「サービスの品質」をめぐる紛争が避けられなくなりました。障害が起きたとき、提供者は「一時的な不具合で契約の範囲内」と言い、顧客は「業務が止まった、責任を取れ」と言う — 事前に品質の基準と責任の範囲を数値で合意していなければ、この対立に決着をつける方法がありません。SLA は、1990年代の通信・IT アウトソーシングの拡大の中で、この「品質の言った言わない」を防ぐ契約実務として定着しました。
さらにクラウドコンピューティングの普及が SLA を一般化させました。自社サーバなら品質は自己責任ですが、インフラを他社から借りるとなれば、「借りているものがどれくらい信頼できるか」は契約で担保するしかありません。クラウド事業者が公開する SLA は、不特定多数の顧客と個別交渉なしに品質水準を約束するための標準文書として機能しています。
詳細
稼働率と「9の数」— 数字の実感を持つ
SLA の中心にあるのが稼働率(アベイラビリティ)です。「99.9%」と「99.99%」は一見わずかな差ですが、許容される停止時間に換算すると印象が大きく変わります。
9がひとつ増えるごとに許容停止時間は10分の1になり、それを達成するためのコスト — 冗長構成、自動フェイルオーバー、複数リージョン展開 — はおおむね桁で増えていきます。クラウド大手の仮想マシン単体の SLA が99.9%前後、複数の可用性ゾーンにまたがる構成で99.99%といった水準になっているのは、この構造の反映です。
SLA を構成する要素
実務の SLA は稼働率の数字だけでは成立しません。まず「稼働」の定義が要ります。全機能が使えることか、主要 API が応答することか。エラー率が何%を超えたら「停止」と数えるのか。次に測定方法です。誰が・どこから・どのメトリクスで測るのかを決めなければ、違反かどうかの判定で揉めます。多くのクラウド SLA は「事業者側の計測を正とし、顧客が申請して初めて補償される」建て付けです。
そして除外条件があります。計画メンテナンス、顧客側の設定ミス、不可抗力(天災など)は通常カウント外です。最後に補償条項で、一般的には返金ではなく将来の利用料に充当されるサービスクレジットの形を取り、違反の程度に応じて10%・25%のように段階づけられます。ここで注意したいのは、補償はあくまで利用料の一部であって、障害でビジネスが被った損失を穴埋めするものではないという点です。SLA は「損害保険」ではなく、品質水準の表明と誠意の証明に近いものです。
SLO との関係 — 契約と目標の二層運用
SLA を守る側の内部では、SLO との二層運用が基本になります。たとえば顧客に99.5%を契約したら、内部目標は99.9%に置く。内部目標を割り込んだ時点でアラートが上がり、インシデント対応が始まるので、契約違反に至るまでに猶予があります。SLA だけを目標にしてしまうと、割り込みに気づいた時点ですでに補償が発生している、という後手の運用になります。この二層構造と、SLO の残量を管理するエラーバジェットの考え方は、SRE の実践としてセットで整備されるのが一般的です。
実務での落とし穴
SLA を読む側・書く側の双方に典型的な落とし穴があります。読む側の代表例は「SLA の数字=実際の信頼性」という誤解です。SLA は補償の発生条件であって稼働実績の保証ではなく、99.99%の SLA を掲げるサービスが大規模障害を起こすことは普通にあります。また、複数のサービスを直列に組み合わせたシステム全体の稼働率は、各サービスの稼働率の掛け算で下がっていきます。99.9%のサービスを3つ直列に依存すれば、全体は約99.7%です。書く側の代表例は、測定も運用もできない水準を営業的な事情で約束してしまうことです。守れる根拠(アーキテクチャと運用体制)のない SLA は、補償リスクと信用毀損を先送りしているにすぎません。