SLA の読み方と「9」の意味
可用性を語るうえで欠かせないのが SLA（Service Level Agreement）の「9」の数だ。 「ファイブナイン（99.999%）」「フォーナイン（99.99%）」などと言われるが、 実際の意味を年間ダウンタイムに換算すると直感的に理解できる。
| 可用性 SLA | 年間ダウンタイム | 月間ダウンタイム |
|---|---|---|
| 99% （2ナイン） | 約 87.6 時間 | 約 7.3 時間 |
| 99.9% （3ナイン） | 約 8.76 時間 | 約 43.8 分 |
| 99.95% | 約 4.38 時間 | 約 21.9 分 |
| 99.99% （4ナイン） | 約 52.6 分 | 約 4.4 分 |
| 99.999% （5ナイン） | 約 5.26 分 | 約 26.3 秒 |
⚠️ SLA はプロバイダーの賠償基準であり、システムの実際の可用性ではない
SLA を達成できなかった場合のクレジット補償が規定されているだけで、 実際のシステム可用性はアーキテクチャ設計・構成・運用に依存します。 シングルAZ構成では SLA に基づいた補償が得られても、システムが長時間停止する可能性があります。
各プラットフォームの SLA 比較
| サービス | AWS | OCI | Azure |
|---|---|---|---|
| コンピュート（VM） | 99.99%（マルチAZ時） | 99.99%（マルチAD時） | 99.99%（可用性セット/ゾーン） |
| コンピュート（シングル） | 99.5% | 99.9%（シングルAD） | 99.9%（Premium SSD使用時） |
| オブジェクトストレージ | S3: 99.99% | Object Storage: 99.9% | Blob Storage: 99.9〜99.99% |
| マネージドDB（マルチAZ） | RDS Multi-AZ: 99.95% | Autonomous DB: 99.995% | SQL DB: 99.99%（Business Critical） |
| Kubernetes（マネージド） | EKS: 99.95% | OKE: 99.95% | AKS: 99.95%（Uptime SLA使用時） |
| ロードバランサー | ALB/NLB: 99.99% | Load Balancer: 99.99% | Load Balancer: 99.99% |
注目すべきは OCI の Autonomous Database の 99.995% という高い SLA だ。 これは月間換算で約 2.2 分のダウンタイムしか許容しないという数字で、 クラウドのマネージドDB では最高水準の一つだ。 Oracle がデータベースの可用性を自社の最優先事項としていることが数字に現れている。
AZ・リージョン設計の考え方
クラウドの可用性はリージョン（地理的な拠点）と AZ（Availability Zone / Availability Domain）の 概念に基づいて設計する。AZ は同一リージョン内の独立した物理的な拠点で、 電力・ネットワーク・冷却が分離されている。
| 設計要素 | AWS | OCI | Azure |
|---|---|---|---|
| 日本リージョン | 東京・大阪（2リージョン） | 東京・大阪（2リージョン） | 東日本・西日本（2リージョン） |
| AZ 数（日本） | 東京: 3AZ / 大阪: 3AZ | 東京: 3AD / 大阪: 1AD | 東日本: 3AZ / 西日本: 3AZ（一部） |
| AZ 間レイテンシ | 1〜2ms | 1〜3ms | 1〜2ms |
| リージョン間レイテンシ（東京−大阪） | 約 10〜15ms | 約 10〜15ms | 約 10〜15ms |
| グローバルリージョン数 | 30+ リージョン | 40+ リージョン（46+、急拡大中） | 60+ リージョン（最多） |
💡 OCI のリージョン数は急速に拡大中
OCI は後発ながらリージョン数を急速に増やしており、 一部の地域では AWS・Azure よりも先にリージョンを展開しています。 また OCI は「リージョンペア」の概念で常に DR ペアを用意しており、 大阪リージョンが東京のDRサイトとして機能します。
DR 戦略の4パターン
AWS が定義した DR 戦略の分類は業界標準的に使われる。コストと RTO/RPO のトレードオフで 4つのパターンがある。
| 戦略 | 概要 | RTO | RPO | コスト |
|---|---|---|---|---|
| Backup & Restore | 定期バックアップをDRサイトに保存。障害時にリストア | 数時間〜 | 数時間〜24時間 | 最低 |
| Pilot Light | 最小限のコアシステムをDRサイトで常時稼働させておく | 数十分〜数時間 | 数分〜数時間 | 低 |
| Warm Standby | 縮退版システムをDRサイトで常時稼働。障害時にスケールアップ | 数分〜数十分 | 数秒〜数分 | 中 |
| Active-Active（Hot Standby） | 2サイト以上でフル稼働。トラフィックを分散 | ゼロ〜秒単位 | ゼロ〜秒単位 | 最高（2倍以上） |
RTO/RPO 目標と実現方法
RTO（Recovery Time Objective：目標復旧時間）と RPO（Recovery Point Objective：目標復旧時点）は DR 設計の二大指標だ。 目標が厳しいほどコストが増加する。
| RTO 目標 | RPO 目標 | 推奨アプローチ | クラウドでの実現例 |
|---|---|---|---|
| 24時間以内 | 24時間 | Backup & Restore | S3 クロスリージョンレプリケーション + スナップショット |
| 4時間以内 | 1時間 | Pilot Light | AMI/SnapshotをDRリージョンへ複製 + Route53 フェイルオーバー |
| 30分以内 | 15分 | Warm Standby | マルチリージョン RDS + Auto Scaling グループ |
| 秒単位・ゼロ | ゼロ | Active-Active | マルチリージョン ALB + DynamoDB Global Tables / Aurora Global DB |
オンプレの DR 課題
オンプレミスで DR を実現するには、物理的に離れた第2データセンターの確保・ ストレージレプリケーション機器・専用線の敷設など、多大なコストがかかる。 「DR サイトの構築費用だけで数億円」というケースも珍しくない。
一方でクラウドでは、DR サイトのハードウェアをリザーブする必要がなく、 必要なときにのみスケールアップできる Pilot Light や Warm Standby が 現実的なコストで実現できる。これはオンプレからクラウドへの移行を後押しする 強力な理由の一つだ。
| DR コスト要素 | オンプレ | クラウド |
|---|---|---|
| 第2サイト確保 | 物理的DC 数億円〜 | 別リージョン すぐ利用可 |
| レプリケーション装置 | ストレージレプリ設備 数千万〜 | マネージドサービス 使った分だけ |
| 専用線 | 月額数十万〜 | VPC Peering / Transit Gateway |
| テスト切替コスト | 高（実環境に影響リスク） | 低（CloudFormation等で再現容易） |
| フェイルオーバー時間 | 手動設定多く数時間〜 | 自動化で分〜秒オーダー |
可用性軸のまとめ
| 観点 | オンプレ | AWS | OCI | Azure |
|---|---|---|---|---|
| 単一サービス SLA | 設計次第 | ◎ 最高水準 | ◎（Autonomous DB が最高） | ◎ 高水準 |
| マルチAZ 設計 | — 独自構築 | ◎ 成熟・事例豊富 | ◎ 3AD | ◎ AZ+可用性セット |
| DR コスト | × 非常に高い | ◎ 安価 | ◎ 安価 | ◎ 安価 |
| DR 自動化 | △ 手動多い | ◎ AWS Elastic DR | 〇 Full DR サービス | ◎ Azure Site Recovery |
| グローバルリージョン | — 自社拠点限定 | ◎ 30+ | ◎ 40+（急拡大） | ◎ 60+（最多） |
✅ 次の章では…
PART 06 では 運用・管理 を比較します。 必要なスキルセット・IaC（Infrastructure as Code）の充実度・ 監視ツール・サポート体制を各プラットフォームで解説します。