SLA
Service Level Agreement ・ エスエルエー
サービス提供者が顧客に約束する品質水準の契約。違反時の補償まで含む合意。
✦ 30秒で試す — 航海「99.9%」と「99.99%」の差は、年に8時間か53分かショップ全体で注文できない時間は、1か月に約何分？予想してみる概要
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 もこの構造を反映しています。執筆時点の公開 SLA では、仮想マシン1台だけなら AWS の EC2 と Google Cloud の Compute Engine が99.5%、Azure は Premium SSD を使った場合に99.9%で、複数の可用性ゾーンに分けて置いた構成になってはじめて99.99%になります。1台のサーバに4つ目の9は約束できず、台数と置き場所を増やして初めて届く、ということです。
SLA を構成する要素
実務の SLA は稼働率の数字だけでは成立しません。まず「稼働」の定義が要ります。全機能が使えることか、主要 API が応答することか。エラー率が何%を超えたら「停止」と数えるのか。次に測定方法です。誰が・どこから・どのメトリクスで測るのかを決めなければ、違反かどうかの判定で揉めます。多くのクラウド SLA は「事業者側の計測を正とし、顧客が申請して初めて補償される」建て付けです。
そして除外条件があります。計画メンテナンス、顧客側の設定ミス、不可抗力（天災など）は通常カウント外です。最後に補償条項で、一般的には返金ではなく将来の利用料に充当されるサービスクレジットの形を取り、違反の程度に応じて10%・25%のように段階づけられます。ここで注意したいのは、補償はあくまで利用料の一部であって、障害でビジネスが被った損失を穴埋めするものではないという点です。SLA は「損害保険」ではなく、品質水準の表明と誠意の証明に近いものです。
SLO との関係 — 契約と目標の二層運用
SLA を守る側の内部では、SLO との二層運用が基本になります。たとえば顧客に99.5%を契約したら、内部目標は99.9%に置く。内部目標を割り込んだ時点でアラートが上がり、インシデント対応が始まるので、契約違反に至るまでに猶予があります。SLA だけを目標にしてしまうと、割り込みに気づいた時点ですでに補償が発生している、という後手の運用になります。この二層構造と、SLO の残量を管理するエラーバジェットの考え方は、SRE の実践としてセットで整備されるのが一般的です。
依存の掛け算 — 約束できる SLA はどう決まるか
自分のサービスの SLA を決めるとき、避けて通れないのが依存先の稼働率です。1回のリクエストがロードバランサ、アプリ、データベース、外部の決済 API を順に通るなら、どれか1つが落ちただけでリクエストは失敗します。故障が互いに独立なら、全体の稼働率は各部品の稼働率の掛け算です。99.9%の部品を3つ直列に依存すれば、全体は約99.7%（0.999³）まで下がります。部品を足すたびに、全体は弱い方へ引っ張られていきます。
これに対抗する手段が並列の冗長化です。同じ部品を2台並べ、どちらか1台が生きていれば処理できるようにすると、その段が落ちるのは2台が同時に落ちたときだけになり、稼働率は 1 −（1 − 0.999）² ≈ 99.9999% まで上がります。ただし台数の分だけ費用がかかり、しかも「同時に落ちない」ことが前提です。同じゾーン、同じ電源、同じ設定ミスを共有する2台は一緒に落ちるので、置き場所を分けなければ掛け算の効果は出ません。そして、他社の決済 API のように自分では台数を増やせない依存先がある限り、全体の稼働率はその相手の SLA を超えられません。
部品で確かめてください。部品を経路へ運ぶと直列につながり、同じ部品をもう一度運ぶと並列の冗長化になります。30日の帯では、直列の段が増えるほど全体の網掛けが増え、冗長化した段の網掛けは「2台が重なって落ちた時間」だけになって消えていきます。
下の部品をつかんで、上の経路の囲みへドラッグしてください。依存が1つ増えるたびに、全体の稼働率がどう変わるかを見てください。
稼働率は各部品の公開 SLA 程度の値。故障は互いに独立と仮定しています（同じゾーン・同じ電源にいる台は同時に落ちるので、実際の冗長化の効果はこれより小さくなります）。帯は30日、網掛け1本 ≒ 5分の停止。
実務での落とし穴
SLA を読む側・書く側の双方に典型的な落とし穴があります。読む側の代表例は「SLA の数字＝実際の信頼性」という誤解です。SLA は補償の発生条件であって稼働実績の保証ではなく、99.99%の SLA を掲げるサービスが大規模障害を起こすことは普通にあります。また、クラウドの SLA の多くは「複数ゾーンに分けて置いた場合」のような利用者側の条件つきで、条件を満たさない構成には適用されません。書く側の代表例は、測定も運用もできない水準を営業的な事情で約束してしまうことです。守れる根拠（アーキテクチャと運用体制）のない SLA は、補償リスクと信用毀損を先送りしているにすぎません。
試問
ユーザーの注文は、経路にある部品をすべて通って完了します。部品（ロードバランサ 99.99%・アプリ 99.9%・データベース 99.95%・他社の決済API 99.9%）を経路の囲みへドラッグすると直列につながり、同じ部品をもう一度運ぶと2台目が並列に並びます（冗長化。どちらか1台が動いていれば通れる）。囲みの外へ引き出すと1台外せます。今はアプリが1台だけです。
下の部品をつかんで、上の経路の囲みへドラッグしてください。依存が1つ増えるたびに、全体の稼働率がどう変わるかを見てください。
稼働率は各部品の公開 SLA 程度の値。故障は互いに独立と仮定しています（同じゾーン・同じ電源にいる台は同時に落ちるので、実際の冗長化の効果はこれより小さくなります）。帯は30日、網掛け1本 ≒ 5分の停止。