AWS 29：可用性と災害対策

一言でいうと：お店の「営業の約束」と「火事の備え」

この章の2つのテーマを、お店にたとえてみます。

可用性は「使える時間の割合」です。1年のうち、利用者が使えた時間が何%かで表します。

災害対策は、ふだんの小さな故障ではなく、地域まるごとのような大きな障害から立ち直る計画です。

この2つは、つながっています。可用性を高くするには、まず小さな故障（サーバー1台、AZ 1つ）に強くします。それでも防げない大きな障害には、災害対策で備えます。

第2章で見たように、AWS ではサーバーがレジ、AZ（アベイラビリティゾーン、独立したデータセンターの集まり）が店、リージョン（東京・大阪などの地域）が町にあたります。この本ではここまで、「レジ」と「店」の故障に備えてきました。この章では、「町」の単位まで考えを広げます。

可用性の数字：「9 がいくつ」で止まってよい時間が決まる

可用性は、よく 99.9% のように「9 がいくつ並ぶか」で表します。「スリーナイン」「フォーナイン」と呼ぶこともあります。

止まってよい時間に直すと、次のようになります（1年＝365日、1か月＝30日で計算）。

計算は簡単です。たとえば 99.9% なら、止まってよいのは 0.1%。1か月は 30日×24時間×60分＝43,200分なので、その0.1%で約43分です。

表からわかる大事なことは、9 が1つ増えるごとに、許される時間が10分の1になることです。99.9% と 99.99% は数字の見た目はほとんど同じですが、「月に43分」と「月に4分」はまったく違います。4分では、人が障害に気づいて画面を開いている間に過ぎてしまいます。つまり 99.99% 以上を目指すなら、人の手を待たずに自動で切り替わる仕組みが要ります。

そして、9 を1つ増やすたびに、費用と手間はたいてい大きく増えます。フォトログのような写真の SNS なら 99.9% でも十分なことが多く、決済や医療のように止まると大きな損害が出るサービスなら、もっと上を目指します。

なお、AWS の各サービスにも SLA（サービスレベル契約）として可用性の約束があります。値や条件はサービスごとに違うので、公式の SLA のページで確認してください。

直列につなぐと、可用性は掛け算で下がる

では、いくつもの部品を組み合わせたシステム全体の可用性は、どうなるでしょうか。

図のように、利用者のリクエストが ALB → EC2 → RDS の順に通る構成を考えます。どれか1つでも止まれば、利用者から見るとサービスは止まります。このように全部が動いていないと働かない並び方を直列と呼びます。

直列のとき、全体の可用性は、それぞれの可用性の掛け算になります。説明のため、どの部品も 99.9% だとしてみます（実際の値ではなく、計算のための例です）。

99.7% を時間に直すと、1か月に約2.2時間止まりうることになります。1つ1つは「月に43分」でも、3つ並べると、そのほぼ3倍です。

ここから、設計の大事な教訓が1つ出てきます。部品を足すほど、どこかが止まる確率は上がるということです。キャッシュを足す、キューを足す、外部の API を呼ぶ。どれも便利ですが、それが直列に入る（それが止まると全体が止まる）なら、全体の可用性は下がります。

では、どうすれば上げられるのでしょうか。次に見る並列がその答えです。

並列に並べると、可用性は大きく上がる

今度は EC2 を2台にして、ALB がどちらにでも送れるようにします（第11章）。どちらか1台が動いていれば、サービスは続けられます。このようにどれか1つが動いていればよい並び方を並列と呼びます。

並列のとき、その段が止まるのは全部が同時に止まったときだけです。計算のため、EC2 1台の可用性をわざと低めの 99% としてみます。

99% の部品を2つ並べるだけで、99.99% になりました。これが冗長化（同じ役目の部品を複数置くこと）の力です。

ただし、この計算には大事な前提があります。2台が「別々の理由で」壊れることです。

最後の例のように、サーバーを並列にしても、その後ろに直列の部品が残っていれば、そこが全体を止めます。次に、その「残った1か所」を探します。

単一障害点を探す：「これが止まったら全部止まる」はどこ？

単一障害点（SPOF：Single Point Of Failure）とは、そこが1つ止まるだけで、全体が止まってしまう部品のことです。可用性を上げる作業の多くは、この単一障害点を見つけて潰すことです。

図は、フォトログの途中の構成です。EC2 は2つの AZ に1台ずつあり、ALB も両方の AZ にまたがっています。一見、冗長化できていそうです。

ところが、赤い部品を見てください。

単一障害点を探すには、構成図の部品を1つずつ指さして、「これが止まったら、利用者に何が起きる？」と聞いていくのが確実です。

最後の行のとおり、単一障害点は機械だけではありません。

見つけたら、2つにするか「止まっても待てる」形にする

見つけた単一障害点には、2つの対策があります。

図では、RDS の待機系を AZ c に置き（第13章の Multi-AZ）、NAT ゲートウェイも AZ ごとに1つずつ置きました。NAT については、各 AZ のプライベートサブネットのルートテーブル（第6章）を、同じ AZ の NAT に向けるようにします。こうしないと、NAT を2つ置いても、片方の AZ に通信が集まったままになります。

RDS の Multi-AZ では、主の DB が止まると、AWS が自動で待機系に切り替えます。切り替えには通常1〜2分ほどかかり、その間は DB に接続できません。アプリは接続が切れたら、少し待って再接続するように作っておきます。

気をつけたいのは、機械以外の単一障害点です。

何が壊れるのか：障害の大きさで、備え方が変わる

ここまでの対策は、主にサーバーや AZ の故障への備えでした。障害には大きさがあり、大きさによって効く対策が違います。

AWS のリージョンは、それぞれが独立するように作られています。東京リージョンが丸ごと使えなくなることはとても珍しいですが、ゼロではありません。そこで、サービスによっては、別のリージョン（日本なら大阪など）に備えを置きます。

そして、図の右側のとおり、実際にいちばんよく起きるのは「人の操作」です。AZ やリージョンの障害に比べて、誤削除や設定ミスは、ずっと頻繁に起きます。

ここで注意が要るのは、冗長化は人の操作ミスを防がないことです。Multi-AZ の待機系は、主の DB への変更をすぐに写します。誤って消したデータは、待機系からも消えます。これについては、後で詳しく見ます。

RPO と RTO：「どこまで戻るか」と「何時間で戻るか」

災害対策を考えるときは、まず2つの数字を決めます。

図の例で見てみます。毎晩2時にバックアップを取っていて、朝5時に DB が壊れたとします。

このとき、2時から5時までの3時間分のデータ（その間に投稿された写真やいいね）は失われます。これが RPO にあたります。5時から9時までの4時間、サービスは止まっていました。これが RTO にあたります。

「RPO 3時間・RTO 4時間でよい」と決めてあれば、この結果は約束どおりです。逆に「データは5分以上失いたくない」なら、毎晩1回のバックアップでは足りません。

このように、RPO と RTO が決まると、必要なバックアップの間隔や、予備をどこまで用意すべきかが決まります。数字が先、部品は後です。

RPO と RTO を小さくするほど、費用は増える

RPO と RTO は、小さいほど利用者にとってはうれしい数字です。ただし、小さくするには費用がかかります。図では、赤と青の区間が縮みました。

たとえば RDS の自動バックアップを使うと、保存期間の中の好きな時点に戻せるポイントインタイムリカバリ（PITR）ができ、RPO は数分程度にできます（第13章）。一方、戻すには新しい DB を作るので、RTO はそのぶんかかります。

大事なのは、この数字を技術の側だけで決めないことです。

「止まったときの損」が「備えの費用」より大きければ、備える価値があります。データの種類ごとに数字を変えるのもよい考えです。フォトログでは、後でデータごとに RPO と RTO を分けます。

災害対策の4つの戦略：安くて遅い ⇔ 高くて速い

リージョンまるごとの障害に備える方法として、AWS の災害対策のホワイトペーパー（公式の解説文書）は、次の4つの戦略を紹介しています。違いは、予備のリージョンに「何を」「どれだけ動かしておくか」です。

右へ行くほど（表の下へ行くほど）、速く戻れますが、費用も作る手間も増えます。

目安の数字は、あくまで目安です。実際の RPO と RTO は、構成と、どれだけ手順を自動化し、練習しているかで決まります。

次から、東京リージョンを普段使い、大阪リージョンを予備にする例で、4つを順に見ます。同じ舞台で、大阪側の部品が少しずつ「起きて」いく様子を追ってください。

どの戦略でも共通して要るのが、構成をコードにしてあること（IaC、第18章）です。予備のリージョンに同じ構成を作るとき、手作業では時間がかかり、間違いも入ります。

戦略1 バックアップと復元：予備はデータだけ

いちばん基本の戦略がバックアップと復元（Backup and Restore）です。

普段は、東京で取ったバックアップを、大阪リージョンにも複製しておくだけです。大阪にはサーバーも DB も動いていません。

RPO は、バックアップの間隔で決まります。1日1回なら最大1日分、1時間ごとなら最大1時間分を失います。

この戦略の成否は、IaC があるかどうかでほぼ決まります。コンソールで手作業で作った構成を、災害の混乱の中で、別のリージョンに思い出しながら作り直すのは、とても難しいからです。

多くのサービスにとって、まずはこの戦略から始めるのが現実的です。

戦略2 パイロットライト：データは常に複製、サーバーは消してある

パイロットライトは、ガス器具の種火（口火）という意味です。種火だけは常に燃やしておき、必要なときにすぐ大きな火をつけられるようにしておきます。

災害対策では、種火にあたるのがデータです。

DB の複製には、たとえば Aurora のグローバルデータベース（別リージョンに読み取り用の複製を持つ仕組み）や、RDS の別リージョンのリードレプリカ（第13章）を使います。データが常に流れているので、RPO は数分程度にできます。

災害のときは、次の順で動きます。

RTO は数十分ほどです。「バックアップと復元」との違いは、一番時間のかかるデータの復元を、前もって済ませてあることです。

戦略3 ウォームスタンバイ：小さく、でも動く予備

ウォームスタンバイは「温めて待っている」という意味です。予備のリージョンに、小さいけれど全部そろった構成を、常に動かしておきます。

図では、大阪の Web サーバーが1台起きました。まだ台数は少ないですが、リクエストを受ければ、ちゃんと応えられます。

ウォームスタンバイには、もう1つ大きな利点があります。予備が本当に動くかを、普段から確かめられることです。パイロットライトでは、予備のサーバーを起動するまで、本当に動くかどうかはわかりません。ウォームスタンバイなら、予備に少しだけ試しのリクエストを流して、確かめ続けられます。

注意点は、災害のときに予備を増やせるかどうかです。大阪で急に何十台も起動しようとして、アカウントの上限（Service Quotas）に引っかかることがあります。上限は前もって確認し、必要なら引き上げを申請しておきます。

戦略4 マルチサイト（アクティブ/アクティブ）：両方で本番

いちばん強い戦略がマルチサイト アクティブ/アクティブです。東京と大阪の両方が本番として動き、両方が同時に利用者に応えます。図では、Route 53 から両方のリージョンへ太い矢印が出ています。

いちばん難しいのはデータです。両方のリージョンで同時に書き込みを受けると、「東京で A に変えた」と「大阪で B に変えた」が同時に起きたとき、どちらを正しいとするかを決めなければなりません。

マルチサイトは、止まると大きな損害が出るサービス（決済、大規模な通販など）で選ばれます。フォトログのような規模では、ほとんどの場合、ここまでは要りません。

要件の数字が、ここまでを求めているかを必ず確かめてから選びます。

複製では守れないもの：誤削除と壊れたデータ

ここまでの戦略は、どれも「データを別の場所に写す」ことを土台にしていました。ところが、複製には弱点があります。

複製は、間違いもすぐに写すのです。図のように、誰かが誤って本番の DB のデータを全部消すと、その削除は待機系にも、別リージョンの複製にも、すぐに伝わります。アプリのバグで壊れたデータを書き込んだときも同じです。

ですから、時点を選んで戻せるバックアップが必要です。RDS の PITR（第13章）、S3 のバージョニング（上書き・削除しても前の版を残す機能、第15章）がその例です。

さらに、攻撃者にアカウントを乗っ取られると、バックアップごと消されるおそれがあります。そこで、次の2つが有効です。

作り方：AWS Backup で、毎日のバックアップを大阪にも複製する

バックアップは、RDS・EBS・DynamoDB・S3 など、サービスごとに設定することもできますが、AWS Backup を使うと1か所でまとめて管理できます。

AWS Backup では、次の3つを作ります。

図の JSON は、バックアップ計画の例です。

CLI で作る場合は、次のようになります。

aws backup create-backup-plan --backup-plan file://plan.json
aws backup create-backup-selection --backup-plan-id <計画ID> \
  --backup-selection file://selection.json

selection.json には、対象を選ぶタグと、AWS Backup が使う IAM ロール（第3章）を書きます。

作ったら、必ず一度、大阪の保管庫から実際に戻してみます。次にその練習の話をします。

復旧の練習：試していない復旧手順は、動かないと思え

災害対策でいちばん大事で、いちばん忘れられがちなのが練習です。「バックアップはあった。でも戻し方がわからなかった」「戻したら、アプリが古い設定のまま動かなかった」という事故はとてもよく起きます。

第28章で出てきたゲームデー（本番さながらの練習日）を、図の順で行います。

AWS には練習を助ける道具があります。

わざと壊すのは怖く感じます。でも、本番の障害は、練習より都合の悪いときに来ます。夜中に初めて手順書を開くより、昼間に練習で詰まるほうがずっと安全です。

フォトログで決める：データごとに RPO と RTO を分ける

では、フォトログ（会社のサービスとして運営している想定）で、実際に数字を決めてみます。ポイントは、全部を同じ強さで守らないことです。

リージョンまるごとの災害には、バックアップと復元の戦略を選びました。理由は次のとおりです。

この判断は、利用者が増えたら見直します。決めた理由は、第28章で見たように書き残しておきます。

お金：何に課金されるか

災害対策のお金は、予備として何をどれだけ動かしておくかに比例します。

戦略ごとに、費用の傾向は次のとおりです。

細かい単価は、各サービスの料金ページで確認してください。戦略を決めるときは、Pricing Calculator（第4章）で戦略ごとの月額を出して並べ、「止まったときの損」と比べるのがおすすめです。

よくある落とし穴

災害対策で、実際によく起きる失敗です。

最後の行は特に見落としがちです。ACM の証明書（第14章）や、AMI（第10章）、Secrets Manager の秘密（第20章）などは、リージョンごとに用意が要ることが多い部品です。練習で予備リージョンに実際に作ってみると、こうした抜けが見つかります。

片付け：練習で作った計画・保管庫・予備を消す

この章の練習で作ったものを片付けます。AWS Backup は、計画 → 復旧ポイント → 保管庫の順に消します。保管庫は、中に復旧ポイント（バックアップ1つ1つ）が残っていると消せません。

Vault Lock には注意してください。Vault Lock には「確定」させる段階があり、確定させた後は、決めた保存期間が過ぎるまで、復旧ポイントも保管庫も誰にも消せません。練習では、確定させずに試すだけにします。

また、コンソールは画面の右上でリージョンを切り替えて表示します。東京で片付けても、大阪に残っていることがよくあります。予備リージョンに切り替えて、残っていないか確認しましょう。第4章の Cost Explorer で、リージョン別の料金を見るのも有効です。