9を一つ足すのに掛かる値段
一言でいうと
可用性は買えば手に入ります。問題は、「9」を1つ増やすたびに、コストがおおよそ1桁ずつ跳ね上がることです。そのため、「できるだけ安全に」ではなく「どれだけ必要か」を先に決める必要があります。
なぜ必要なのか
すべてのサービスを同じ可用性にすると、重要でない機能にまで、冗長化と待機リソースを過剰に投資することになります。中断時間とデータ損失がビジネスに与える被害をRTOとRPOに分けて書いてはじめて、復旧戦略の追加コストが、実際に避けられる損失より小さいかどうかを比較できます。
どう動くのか
「9」の意味
| 可用性 | 年間の許容中断時間 | 月間 |
|---|---|---|
| 99% | 約3.65日 | 約7時間 |
| 99.9% | 約8.8時間 | 約43分 |
| 99.95% | 約4.4時間 | 約22分 |
| 99.99% | 約52分 | 約4.3分 |
| 99.999% | 約5分 | 約26秒 |
99.99%は年間52分です。デプロイ1回で5分ずつ止まるなら、年10回のデプロイで予算を使い切ります。そのため、高い可用性の目標は、自動的に無停止デプロイを要求します。目標を決めた瞬間に、付随してやるべきことが生まれるのです。
RTOとRPO
| 意味 | 問い | |
|---|---|---|
| RTO(復旧時間目標) | どれだけ早くサービスが再開されるか | 何分、何時間以内に復旧するか |
| RPO(復旧時点目標) | どれだけ最近のデータまで救えるか | 何分、何時間分のデータを失ってもよいか |
2つは独立しています。「10分以内に復旧するが、1日分のデータを失う」構成も、「データは1秒も失わないが、復旧に6時間かかる」構成も可能です。サービスごとに異なる値を決めます。決済の元帳のRPOは0に近くなければなりませんが、レコメンドのキャッシュは1日分を失ってもかまいません。
戦略と値
| 戦略 | RTO | RPO | 相対的なコスト |
|---|---|---|---|
| バックアップからの復旧 | 数時間から1日 | バックアップの間隔 | 最も安い |
| パイロットライト | 数十分 | 分単位 | 低い |
| ウォームスタンバイ | 数分 | 分単位 | 中程度 |
| アクティブ-アクティブ | ほぼ0 | ほぼ0 | 最も高い |
パイロットライトは、DBのレプリケーションだけを起動しておき、残りは停止しておく方式です。いざというときに残りを起動します。従量課金の価値が最もよく表れる戦略で、費用対効果が高いため、実務でよく選ばれます。
決める順序
- サービスごとに等級を分けます: すべてが最高等級ということはありえません。たいてい3段階で十分です(中核 / 重要 / 一般)。
- 各等級のRTO/RPOを数字で決めます: ビジネス側と合意する必要があります。「中断したら時間あたりいくら失うか」が根拠になります。
- その数字を満たす最小の構成を選びます: よりよいものではなく、十分なものです。
- 検証します: リハーサルをしていないRTOは、希望的観測です。
4つ目が、実際には最もよく省略されます。そして、本当の障害のときにRTOが計画の3倍になります。
リハーサルが明らかにすること
復旧訓練をすると、ドキュメントになかった問題が出てきます。
- 復旧手順書が最新ではありません
- 必要な権限を担当者が持っていません
- バックアップはあるのに、復号用の鍵が見つかりません
- 依存するサービスの復旧順序が決まっていません
- DNSや証明書が新しい環境を指していません
これを障害の最中に発見すると、RTOは守れません。
コストとのバランスを取る
可用性への投資額が期待損失を上回れば、過剰投資です。
기대 손실 = 연간 예상 중단 시간 × 시간당 손실
時間あたりの損失が100万ウォンのサービスで、99.9%(年8.8時間)を99.99%(年52分)に上げると、約8時間を節約でき、その価値は年800万ウォンです。その構成に年3,000万ウォンかかるなら、過剰投資です。逆なら、当然やるべきです。
可用性を買う代わりに、復旧を速くするという選択
「99.99%を目標にする」という言葉は、たいてい予算の話なしに出てきます。「9」を1つ増やすコストは線形ではなく指数的なので、どこまで買うかを決めるには、反対側も一緒に見る必要があります。
停止時間の価値を先に計算します。時間あたりの売上、離脱するユーザー、違約金、復旧にかかる人の時間を足します。この数字が出てはじめて、「冗長化に月200万ウォン」が高いか安いかを言えます。ほとんどの社内システムは、計算してみると99.9%(月43分)で十分という結論になります。
同じお金なら、復旧を速くするほうがたいてい有利です。冗長化は、特定の種類の障害しか防ぎません(機器の故障、AZの障害)。実際に経験する障害のかなりの部分は、誤ったデプロイと設定変更であり、冗長化されたシステムは、その変更も両側に同じようにデプロイします。ロールバックを5分以内に行える能力のほうが、冗長化より広い範囲をカバーします。
復旧時間を測ったことがなければ、その数字は希望です。バックアップから復元するのに何分かかるか、別のリージョンで起動するのにどれだけかかるかは、やってみなければわかりません。たいてい、ドキュメントに書かれた値の2、3倍になります。DNSのTTL、イメージのダウンロード、キャッシュが空の状態での最初のトラフィックが、すべて時間を食います。
単一障害点は、インフラよりも人と手順にあるほうが多いです。そのシステムを復旧できる人が1人だけだったり、復旧手順がその人の頭の中にしかなかったり、緊急用アカウントのパスワードを誰も知らなかったりする状態がよくあります。冗長化の予算を使う前に、平日の昼間に、その人抜きで復旧訓練を1回やってみるほうが、価値が大きいです。
測定していない可用性は管理されません。内部で測る可用性と、ユーザーが体験する可用性は違います。サーバーは200を返しているのに、ユーザーは画面を見られない状況があるからです。外部から実際のユーザーの流れを測る合成モニタリングを1つ置くだけでも、「私たちは99.95%でした」と「私は3回失敗しました」の隔たりが小さくなります。
現場での姿
- 「可用性99.99%を目標」と決めて、手動デプロイを続けています → デプロイで予算を使い切ります。
- バックアップは毎日動いているのに、復旧を試したことがありません → RTOが未知数です。
- すべてのサービスをアクティブ-アクティブにしました → コストに耐えられず、結局元に戻します。
次に見ること
この決定を、あとの人が読めるように残す方法です。