クラウドのSLAでよく見る「99.9%」「99.99%」などの“9の数”。数字が増えるほど安心してしまいがちですが、実際の月間停止時間や補償の条件を正しく理解しないと、想定外のダウンで業務が止まったり、期待した補償が受けられなかったりします。本稿では、誤解しやすいポイントを平易に整理し、現実的な設計と運用のヒントを提案します。
なぜ「9の数」に惑わされるのか
「9」が増えると、ほぼ止まらないように見えます。しかしSLAは“理論上の上限”に近い表現で、実運用は仕様の除外条件や構成の弱点に大きく左右されます。大切なのは数字そのものより、どのように計測し、どの範囲に適用される約束なのかを読み解くことです。
「月間停止時間」の目安と落とし穴
一般に30日（43,200分）を目安にすると、
- 99%＝約432分（7.2時間）
- 99.9%＝約43.2分
- 99.99%＝約4.32分
- 99.999%＝約0.432分（約26秒）
ただし、提供事業者の「計算期間（暦月／請求月）」「対象区間（リージョン／ゾーン）」「計測点（外形監視か内部メトリクスか）」で結果は変わります。計画メンテナンスや顧客側原因は“停止時間に含まれない”規定も多く、「止まったのにSLA違反ではない」ケースが起きます。
SLAは約束ではなく条件付きの「取り決め」
SLA達成を保証してくれるのは“サービスクレジット”であり、損害賠償ではありません。しかも申請期限や証跡の提示、複数条件の同時充足など、適用には細かな要件があります。「止まらない権利」ではなく、「止まった時に一定のクレジットが出る可能性がある」取り決めだと捉えるのが現実的です。
合成可用性：足し算ではなく掛け算
あなたのシステムが複数の外部サービスに依存するなら、全体の可用性は掛け算で小さくなります。例：5つの依存先が各99.9%でも、全体は約99.5%まで低下します。ひとつの“9”の不足が、体感停止時間を大きく押し上げることを忘れないでください。
設計で埋めるべきギャップ
- 冗長化の粒度：単一AZで満足しない。マルチAZ、必要ならマルチリージョンを検討。
- 依存の分散：DNS、アイデンティティ、ストレージなど基盤系の単一障害点を排除。
- フォールバック：キュー・キャッシュ・読み取り専用モード・段階的劣化で“完全停止”を避ける。
- クライアント耐障害性：再試行（指数バックオフ）やサーキットブレーカーで瞬断を吸収。
- 監視と定義：自社のSLO/アラート閾値を明確化し、ユーザー体験に直結する外形監視を持つ。
現実的な期待値を作るSLOという視点
SLAはベンダーの約款、SLOはあなたのサービスの目標です。「ユーザーが体感する可用性」を定義し、許容できるエラー率や復旧時間（RTO）、許容データ損失（RPO）をチームで合意しましょう。ベンダーSLAが満たされていても、あなたのSLOが満たされないことは珍しくありません。
誤解しないためのチェックリスト
- どの範囲のSLAか（単一サービスか、リージョン単位か）
- 除外条件は何か（計画メンテ、DDoS、サードパーティ障害など）
- 計測方法は誰基準か（ベンダー内部か外形監視か）
- 複数依存の合成可用性を計算したか
- クレジットの申請条件と期限を把握しているか
- 設計・運用で“9の差”を埋める仕組みがあるか
まとめ：9の数はスタート地点
“9”は安心の記号ではなく、設計と運用の出発点にすぎません。月間停止時間の目安を鵜呑みにせず、あなたのユーザー体験を守るSLOとアーキテクチャでギャップを埋めましょう。最後に残る信頼性は、SLAの数字ではなく、あなたが選び取った冗長化と運用の習慣が作ります。
この記事へのコメントはありません。