AWS RDSのマルチAZとリードレプリカで可用性を高めるデータベース設計入門

この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）

ＨＯＭＥ＞ Linux技術リナックスマスター.JP（Linuxマスター.JP）＞ AWS(Amazon Linux) ＞ AWS RDSのマルチAZとリードレプリカで可用性を高めるデータベース設計入門

「本番DBが落ちたらサービス全体が止まる」「読み取りが遅くてユーザーが離脱している」
AWSでシステムを構築していると、こうした問題に直面することがあります。

原因のほとんどは、データベース設計の段階でマルチAZとリードレプリカを検討していないことです。

この記事では、AWS RDSのマルチAZ配置とリードレプリカの仕組みを解説し、
止まらないデータベース設計の基本を実践的に説明します。
RHEL 9 / Amazon Linux 2023 環境での動作確認例も含めています。

この記事のポイント

・マルチAZはスタンバイDBへの自動フェイルオーバーで高可用性を実現する
・リードレプリカは読み取り専用の複製で参照負荷を分散する設計パターン
・2つは用途が異なる。可用性=マルチAZ、スケール=リードレプリカが基本
・フェイルオーバー時間は1～2分が目安。ダウンタイムゼロにはならない

「このままじゃマズい」と感じていませんか？

参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。

図解60P／登録10秒／解除も3秒／詳細はこちら

RDSで「1台構成」を避けるべき理由

RDS（Relational Database Service）をシングルインスタンスで運用していると、
AWSのメンテナンスやインスタンス障害が発生した瞬間に、DBへのアクセスが完全に止まります。

EC2をマルチAZで冗長化しても、DBがシングルポイントでは意味がありません。
以下のシナリオは、現場でよく起きる障害パターンです。

・ap-northeast-1a のハードウェア障害 → 同一AZのRDSが停止
・マイナーバージョンの自動アップグレード → 再起動で数分間ダウン
・ストレージ容量オーバー → DBが応答不能になりフロントも巻き込み停止

これらに対応するのがマルチAZ配置です。

マルチAZの仕組みとフェイルオーバーの流れ

マルチAZ配置を有効にすると、RDSはプライマリインスタンスとは別のAZに
スタンバイインスタンスを自動で作成します。
プライマリとスタンバイはAWS内部で同期レプリケーションを行い、
データの一貫性を常に保ちます。

1. フェイルオーバーのトリガー

フェイルオーバーが発生する主なトリガーは以下のとおりです。

・プライマリインスタンスのホスト障害
・ネットワーク接続の喪失
・プライマリのストレージ障害
・DBインスタンスのOSメンテナンス

フェイルオーバーが発動すると、RDSのDNSレコード（エンドポイント）が
スタンバイインスタンスに向け直されます。
アプリケーション側のDB接続文字列を変更する必要はありません。

2. フェイルオーバーにかかる時間

マルチAZフェイルオーバーは完全自動ですが、ゼロダウンタイムではありません。

・標準的なフェイルオーバー時間: 60秒～120秒
・DNSのTTL（通常は5秒）によるキャッシュが残る場合はさらに数秒～数十秒

アプリケーション側で接続リトライ処理（Connection retry）を実装しておくことが必須です。

3. マルチAZ構成のイメージ

# マルチAZ構成図（概念） ap-northeast-1a ap-northeast-1c ┌─────────────────┐ ┌─────────────────┐ │ RDS Primary │──同期────┤ RDS Standby │ │ (読み書き可) │ レプリ │ (待機中・参照不可)│ └─────────────────┘ ケーション └─────────────────┘ ↑ エンドポイント（DNSで解決） mydb.cluster-xxxx.ap-northeast-1.rds.amazonaws.com

スタンバイインスタンスは通常の運用中は参照もできません。
「2台あるから2倍の性能」というわけではなく、純粋な可用性のための冗長構成です。

リードレプリカの仕組みと使いどころ

リードレプリカはマルチAZとは別の機能です。目的が根本的に違います。

マルチAZ: プライマリの障害に備えるための「保険」
リードレプリカ: 読み取り負荷を分散するための「増強」

リードレプリカはプライマリからの非同期レプリケーションで複製されます。
プライマリへの書き込みは即座にレプリカに反映されますが、
非同期のため若干のレプリケーション遅延（レプリカラグ）が生じます。

1. リードレプリカの主な用途

・レポーティングや集計クエリをレプリカに向ける（本番DBへの負荷分散）
・読み取りが多いアプリケーションでAPI応答速度を改善する
・同じリージョン内だけでなく別リージョンにも作成可能（クロスリージョンレプリカ）
・リードレプリカをスタンドアロンDBへ昇格させることも可能（DR用途）

2. リードレプリカのエンドポイント分離

アプリケーション側では、書き込み用と読み取り用のエンドポイントを分けて管理します。

# アプリケーション側の接続先イメージ（Rails等のDB設定例） # 書き込み（INSERT/UPDATE/DELETE） DB_WRITE_HOST=mydb.xxxx.ap-northeast-1.rds.amazonaws.com # 読み取り（SELECT） DB_READ_HOST=mydb-ro.xxxx.ap-northeast-1.rds.amazonaws.com

Aurora（Amazon Aurora）を使う場合は、クラスターエンドポイントとリーダーエンドポイントが
最初から分離されているため、より管理が楽になります。

マルチAZとリードレプリカを組み合わせた設計パターン

本番環境の推奨構成は「マルチAZ＋リードレプリカ」の組み合わせです。
どちらか一方だけでは対応できないシナリオがあるためです。

1. 基本の構成パターン（読み取り分離＋高可用性）

# 推奨構成の概念図 EC2 Application Server │ ├── 書き込み → RDS Primary（マルチAZ有効） │ │ │ 同期レプリ │ ↓ │ RDS Standby (別AZ) │ └── 読み取り → RDS Read Replica ※プライマリからの非同期レプリ

2. Aurora を採用した場合の利点

通常の RDS MySQL/PostgreSQL と Aurora では、レプリケーション方式が異なります。

・通常のRDS: プライマリのデータをバイナリログで転送
・Aurora: 共有ストレージ（6コピー、3AZ分散）を複数インスタンスで参照

Auroraはストレージ自体が冗長化されているため、フェイルオーバーが30秒程度と高速です。
書き込み量が多い本番環境では Aurora MySQL / Aurora PostgreSQL の採用を検討してください。

3. 接続先切り替えのトラブルシュート

フェイルオーバー後に「DBに接続できない」と報告が来る場合の確認手順です。

# RDSエンドポイントのDNS解決を確認（Amazon Linux 2023 / RHEL9で実行） $ dig mydb.xxxx.ap-northeast-1.rds.amazonaws.com +short 10.0.1.45 # 少し時間をおいてから再確認（フェイルオーバー後は別IPになる） $ dig mydb.xxxx.ap-northeast-1.rds.amazonaws.com +short 10.0.2.88 # ← IPが変わっていればフェイルオーバーが完了している # アプリの接続が戻らない場合はDNSキャッシュが残っている可能性がある # mysql クライアントで直接接続確認 $ mysql -h mydb.xxxx.ap-northeast-1.rds.amazonaws.com -u admin -p Enter password: Welcome to the MySQL monitor. Commands end with ; or \g.

RDS設計でよく犯すミスとその対策

1. リードレプリカをマルチAZの代わりに使う

「リードレプリカがあるから冗長化できている」と誤解する現場があります。
リードレプリカは非同期レプリカのため、プライマリ障害時にデータが失われる可能性があります。
高可用性の目的にはマルチAZを有効にしてください。リードレプリカは別用途です。

2. マルチAZ有効化を後回しにする

「コストを抑えたいから開発初期はシングルで」という判断は理解できますが、
本番移行時にマルチAZを後から有効にするとDBの再起動が発生します。
本番相当のステージング環境から最初にマルチAZで構築しておく方が安全です。

3. フェイルオーバーテストをしない

マルチAZは設定するだけでは不十分です。
RDSのコンソールから「フェイルオーバーを実行」ボタンで手動テストができます。
本番稼働前に必ず実施し、アプリケーションが自動で再接続できることを確認しましょう。

# AWS CLI でフェイルオーバーのテスト実行 $ aws rds reboot-db-instance \ --db-instance-identifier mydb-prod \ --force-failover \ --region ap-northeast-1 # フェイルオーバー後のステータス確認 $ aws rds describe-db-instances \ --db-instance-identifier mydb-prod \ --query 'DBInstances[0].{Status:DBInstanceStatus,AZ:AvailabilityZone}' \ --output table

本記事のまとめ

AWS RDSのマルチAZとリードレプリカについて、仕組みと使いどころをまとめます。

機能	目的	レプリカの参照	フェイルオーバー
マルチAZ	可用性（障害対策）	不可（待機専用）	自動（60～120秒）
リードレプリカ	スケール（負荷分散）	可（SELECT専用）	手動昇格が必要
Aurora	可用性＋スケール	リーダーEPで可能	自動（30秒程度）

RDSのマルチAZ設計は、AWS上でシステムを運用する上での基本中の基本です。
次のステップとして、EC2のAuto Scaling・ELBとRDSマルチAZを組み合わせた
アプリ層からDB層まで全体を冗長化するアーキテクチャを設計してみてください。

AWSのインフラ設計をLinuxエンジニアとして体系的に学びたい方は、
AWSをLinuxエンジニアが学ぶためのロードマップもご覧ください。

RDSマルチAZを含む冗長設計の実践については、
AWSの冗長設計を体系的に学ぶ上級ガイドでさらに詳しく解説しています。

AWSのDB設計を「実務の型」として身につけませんか？

マルチAZやリードレプリカの設定方法は調べれば分かります。でも「なぜその構成を選ぶのか」を説明できますか？
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。

今すぐ無料でダウンロード（登録10秒）＞＞図解60P『Linux入門マニュアル』を受け取る

※ 「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は1分、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

登録10秒／合わなければ解除3秒／詳細はこちら

Linux無料マニュアル（図解60P）名前とメールで30秒登録

この記事を書いた人

宮崎智広（みやざきともひろ）

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。

前のページへ：AWS IAM権限設計入門｜最小権限の原則でロール・ポリシー・グループを設計する方法
この記事の属するカテゴリ：AWS(Amazon Linux)へ戻る