データベース

マルチAZ配置まるちえーぜっとはいち

可用性フェイルオーバーRDSAWS冗長化ディザスタリカバリ

マルチAZ配置について教えて

簡単に言うとこんな感じ！

データベースを「離れた場所にある複数のデータセンター」に同時に置いておく仕組みだよ。1か所が火事や停電になっても、もう1か所がすぐ引き継いでくれるから、サービスが止まらない！保険みたいなものだね。

マルチAZ配置とは

マルチAZ配置（Multi-AZ Deployment） とは、クラウド上のデータベースを複数のアベイラビリティーゾーン（AZ）に跨って配置し、障害時にも自動的に切り替えを行う高可用性アーキテクチャのことです。AZ（Availability Zone）とは、同一リージョン（地域）内にある物理的に独立したデータセンター群のことで、電源・ネットワーク・冷却設備がそれぞれ独立しています。

代表的な使われ方はAWSの Amazon RDS（Relational Database Service） における「マルチAZ配置」オプションで、プライマリ（主）データベースのデータをスタンバイ（待機）インスタンスに同期的にレプリケーション（複製）しておき、プライマリに障害が起きると自動でスタンバイに切り替わります。この切り替えを フェイルオーバー と呼びます。

システム発注の現場では、「このDBはマルチAZにしますか？」という選択肢が出てきます。コストは増えますが、基幹業務システムや決済系など「止まると困る」サービスには事実上必須の選択肢です。

マルチAZ配置の仕組みと構成要素

要素	内容
プライマリインスタンス	通常時にアプリからの読み書きを受け付けるメインのDB
スタンバイインスタンス	別のAZに配置された待機用DB。通常はアクセス不可
同期レプリケーション	プライマリへの書き込みをリアルタイムでスタンバイに複製
自動フェイルオーバー	障害検知から自動切り替えまで通常1〜2分以内
エンドポイント	アプリが接続するURLは変わらない（切り替えは透過的）

覚え方のポイント

「AZ＝安全ゾーン」と覚えると直感的！複数の安全ゾーンに分散させるから「マルチ安全ゾーン」＝マルチAZ配置。1か所が壊れてももう1つの安全ゾーンが守ってくれる、という感じです。

フェイルオーバーの流れ

① プライマリAZ（東京AZ-a）で障害発生
        ↓
② RDSが自動検知（数十秒以内）
        ↓
③ DNSがスタンバイAZ（東京AZ-c）のIPへ切り替え
        ↓
④ アプリは同じエンドポイントに接続し続けるだけでOK
        ↓
⑤ 旧スタンバイが新プライマリとして稼働開始

歴史と背景

2000年代初頭 — オンプレミス時代のDB冗長化は「ホットスタンバイ」と呼ばれ、高価な専用サーバーと専門エンジニアが必要だった
2006年 — AWSがEC2・S3を開始。クラウド上での冗長化が現実的な選択肢になり始める
2010年 — AWS RDSが正式リリース。マルチAZ配置オプションが登場し、ボタン一つで冗長化できる時代へ
2013年頃〜 — GCP（Cloud SQL）やAzure（Azure SQL Database）も同様の複数ゾーン冗長構成を提供開始
2020年代 — クラウド利用の一般化に伴い、「重要なDBはマルチAZが当たり前」という設計常識として定着

シングルAZ vs マルチAZ vs マルチリージョン

項目	シングルAZ	マルチAZ	マルチリージョン
冗長化	なし	同一リージョン内	地理的に離れた場所
フェイルオーバー時間	―	約1〜2分	数分〜十数分
コスト	基本料金	約2倍	約3倍以上
想定障害	―	AZ障害・ハードウェア障害	リージョン全体の災害
主な用途	開発・検証	本番環境全般	金融・政府・超高可用性

実務での判断ポイント

マルチAZを選ぶべきケース：

ECサイト・予約システムなど、数分の停止でも売上・信頼に影響するサービス
社内の基幹業務システム（受発注・勤怠・会計など）
SLA（サービス品質保証）で99.95%以上の稼働率を求められる場合

シングルAZで済むケース：

開発・テスト・ステージング環境
社内の非重要業務ツール（一時的なデータ集計など）
コストを極力抑えたい PoC（概念実証）段階

💡 発注時のヒント： ベンダーから「DBはマルチAZにしますか？」と聞かれたら、「そのシステムが1〜2分止まったとき、業務への影響はどの程度か？」を基準に判断しましょう。止まったら困るなら迷わずマルチAZを選ぶのが鉄則です。