〜「クラウドだから障害は起きない」と思っていたら、データセンター単位で落ちることもあると知った話〜
こんにちは！ハンズオンラボ運営のえむです。
「クラウドに乗せているから、もう障害の心配はしなくていい」——そう思っていませんか？
実は、AWSのようなクラウドでもデータセンター単位の障害は起こり得ます。1つのデータセンターに全部のサーバーを集約していると、そのデータセンターが停止した瞬間にサービス全体が止まってしまいます。
この記事では、この弱点を解消するマルチAZ構成を、「支店を分けて災害に備える」 というたとえで解説します。
この記事を読むと、以下のことができるようになります
- リージョン・AZ（アベイラビリティゾーン）の違いが説明できる
- なぜ複数AZにサーバーを分散させる必要があるのか理解できる
- 実際の構成イメージ（ALB＋マルチAZ）がわかる
リージョンとAZ：地図で理解する
AWSのインフラは、世界中にリージョン（例：東京リージョン）という単位で存在し、さらに各リージョンの中に**複数のAZ（アベイラビリティゾーン）**という単位で物理的に離れたデータセンター群が存在します。
会社の拠点で例えると、
- リージョン → 「東京都」という大きなエリア
- AZ → 「渋谷支店」「新宿支店」「池袋支店」という、それぞれ独立した建物の支店
同じ東京都内でも、支店ごとに建物・電源・ネットワークが分かれています。渋谷支店が停電しても、新宿支店には影響しません。AWSのAZも同様に、電源・空調・ネットワークが独立した物理的に離れたデータセンターとして設計されています。
マルチAZ構成とは何か
「渋谷支店だけに全社員・全システムを集中させる」会社を想像してください。渋谷支店で火災や停電が起きれば、会社の業務は完全に止まってしまいます。
賢い経営者は、業務を複数の支店に分散させます。渋谷支店が使えなくなっても、新宿支店・池袋支店で通常業務を続けられるようにしておくのです。
これがマルチAZ構成です。サーバーやデータベースを複数のAZに分散配置することで、1つのAZで障害が起きても、他のAZが処理を引き継ぎ、サービス全体は止まりません。
渋谷支店（AZ-a）が使えなくなっても、案内係（ロードバランサー）が自動的に新宿支店（AZ-c）へお客さんを案内し続けてくれるイメージです。
データベースのマルチAZ：もう一段深い備え
サーバーだけでなく、データベース（RDSなど）もマルチAZ配置にすることができます。
本店（プライマリDB）の帳簿を、常にリアルタイムで支店（スタンバイDB）にコピーしておくイメージです。本店が火災で使えなくなっても、支店の帳簿がそのまま本店代わりを引き継いでくれます。利用者側は接続先の切り替えを意識する必要がなく、数十秒〜数分程度のダウンタイムで復旧します。
Terraformで設定する場合、multi_az = trueの1行を追加するだけで有効化できます。
resource "aws_db_instance" "main" {
identifier = "app-db"
engine = "mysql"
instance_class = "db.t3.medium"
allocated_storage = 20
multi_az = true # これだけでスタンバイAZに自動複製される
}
ポイント：マルチAZは「同時に2つ稼働」ではない
よくある勘違いとして、「マルチAZにすればスタンバイ側にもアクセスが振り分けられ、性能が2倍になる」というものがあります。実際には、通常時はプライマリのみが処理を受け持ち、スタンバイはあくまで障害時の引き継ぎ役です。性能向上が目的なら、後述する「リードレプリカ」など別の仕組みを検討する必要があります。
マルチAZとリードレプリカの違い：目的が違う「もう1台」
「サーバーやDBをもう1台増やす」という点で似ている仕組みにリードレプリカがあります。しかし目的はマルチAZとまったく異なります。
- マルチAZ（スタンバイ）：本店が使えなくなったときの代役。普段は表に出てこない
- リードレプリカ：本店の混雑を分散するための支店。普段から読み取り専用の接客を担当し、性能向上が目的
スーパーのレジで例えるなら、マルチAZは「閉店後のバックアップレジ（普段は使わない）」、リードレプリカは「混雑時に開ける追加のレジ（普段から接客する）」です。両方を組み合わせることも可能で、「プライマリ＋マルチAZスタンバイ＋複数のリードレプリカ」という構成にすれば、可用性と性能の両方を確保できます。
マルチAZとマルチリージョンの違い
「支店を分ける」発想をさらに広げると、**東京都内で分ける（マルチAZ）**のか、**大阪にも支店を作る（マルチリージョン）**のかという選択肢もあります。
| 観点 | マルチAZ | マルチリージョン |
|---|---|---|
| 想定する障害の規模 | データセンター単位の障害 | リージョン全体（広域災害等）の障害 |
| 実装の複雑さ | 比較的シンプル（設定変更レベル） | データ同期・DNS切り替えなど複雑 |
| コスト | 比較的抑えられる | 高くなりやすい |
| 一般的な採用ケース | ほとんどの本番システムで基本セット | 金融・社会インフラなど極めて高い可用性が必要な場合 |
多くのシステムでは、まずマルチAZ構成を基本セットとして採用し、それでも足りない極めて高い可用性が求められる場合にマルチリージョンを検討する、という段階を踏みます。
支店は2つで十分か、3つ必要か
「支店を分ける」と決めても、いくつに分けるべきかは意外と悩ましい問題です。
2つのAZに分散する場合、片方のAZが停止すると、残った1つのAZだけで全アクセスを受け止める必要があります。普段から余裕を持った台数（キャパシティ）を確保していないと、障害時に残った支店がパンクしてしまうリスクがあります。
3つ以上のAZに分散していれば、1つが停止しても残り2つで分担できるため、1店舗あたりの負荷増加は相対的に緩やかになります。これは「N+1（もしくはN+2）冗長設計」と呼ばれる考え方で、「いくつ壊れても事業を継続できるか」を先に決めてから、必要な店舗数を逆算するという設計思想です。
東京リージョンのように利用可能なAZ数が多いリージョンでは、コストと相談しつつ3つのAZに分散する構成が信頼性重視のシステムでは一般的に採用されます。
アプリケーション側にも「支店対応」の設計が必要
マルチAZはインフラ側の設定だけで完結すると思われがちですが、実はアプリケーション側の設計も無関係ではありません。
たとえば、サーバー内の一時ファイルやセッション情報をそのサーバーのローカルディスクだけに保存していると、別のAZのサーバーに切り替わった瞬間にその情報が失われてしまいます。支店を分けても、支店間で情報を共有する仕組み（外部のセッションストアやデータベースへの保存）がなければ、利用者から見て「切り替わった瞬間にログイン状態が消える」といった不具合につながります。
インフラをマルチAZ化するだけでなく、**「どの支店で対応しても同じ情報にアクセスできるか」**をアプリケーション側でも意識することが、実務では見落とされがちな重要なポイントです。
よくある勘違い：「クラウドだから自動でマルチAZになる」わけではない
「AWSを使っている時点で自動的に複数AZに分散されている」と思われがちですが、これは誤りです。サーバーを1つのAZだけに配置することも技術的には可能であり、マルチAZ化するかどうかは利用者側の設計・設定次第です。「クラウドを使う＝自動的に高可用性になる」わけではなく、支店を分ける判断は自分で行う必要があることを覚えておいてください。
ビフォーアフター
【ビフォー】
- クラウド → 「使っていれば自動的に障害に強くなる」と思っていた
- AZ → 「なんとなく地域を表すラベル」程度の認識
- データベース障害 → 「バックアップから手動で復元するしかない」
【アフター】
- クラウド → 「複数AZに分散する設計を自分でしないと高可用性にはならない」
- AZ → 「電源・ネットワークが独立した、物理的に離れたデータセンターの単位」
- データベース障害 → 「マルチAZ設定で数十秒〜数分の自動フェイルオーバーが可能」
まとめ
この記事では、マルチAZ構成による高可用性設計の考え方を整理しました。
- AZは「渋谷支店・新宿支店」のように、物理的に独立したデータセンターの単位
- 複数AZにサーバーを分散させることで、1つのAZの障害でもサービスを止めない
- RDSなどのデータベースも
multi_az = trueでスタンバイ側への自動フェイルオーバーが可能 - マルチAZは基本セット、マルチリージョンはさらに高い可用性が必要な場合の選択肢
- クラウドを使うだけで自動的に高可用性になるわけではなく、設計判断が必要
自分のシステムが「1つのAZに全部乗っている」状態になっていないか、まずはロードバランサーの配下にあるサーバー一覧やRDSの設定画面から確認してみてください。設定を1つ変えるだけで直せることも多いはずです。
ハンズオンラボでは、未経験からでも「作って覚える」をモットーにしたITハンズオンイベントを定期開催しています。
面白かったら
「👇いいね」で応援