AWS RDS入門｜マルチAZ・リードレプリカ設定

※本記事にはプロモーション（広告）を含みます。

AWS RDS入門｜マルチAZ・リードレプリカ設定で可用性と拡張性を向上させる

AWS RDSでデータベースの可用性と拡張性を飛躍的に向上させるには、マルチAZ配置とリードレプリカの活用が必須です。障害発生時の自動フェイルオーバーを実現するマルチAZ配置と、読み取り負荷を分散するリードレプリカを適切に設定することで、本番環境の安定稼働を保証します。本記事では、AWS RDSの基本設定から始まり、具体的なマルチAZ配置の手順、リードレプリカの構築方法、そして運用時のベストプラクティスまで、実務で即座に活用できる知識を網羅的に解説します。AWS RDSを初めて触る方でも、このガイドを読み終える頃には、プロダクション環境に適した堅牢なデータベースアーキテクチャを構築できるようになります。

AWS RDSとは何か？メリットと主要機能
マルチAZ配置がもたらす可用性向上の仕組み
リードレプリカで読み取り負荷を分散する方法
マルチAZ・リードレプリカの実践的な設定手順
運用時の監視とパフォーマンス最適化
まとめ：AWS RDSで堅牢なデータベースを構築する

AWS RDSとは何か？メリットと主要機能

AWS RDS（Relational Database Service）は、クラウド上でリレーショナルデータベースを簡単に構築・運用できるマネージドサービスです。従来のオンプレミスデータベースと比較して、運用負荷の大幅な削減とコスト効率の向上が実現されています。RDSが提供する主なメリットと機能を理解することで、なぜ多くの企業がAWS RDSを採用しているのかが明確になります。なお、RDSとNoSQLのDynamoDBのどちらを選ぶべきかは、RDSとDynamoDBの比較ガイドで判断基準を整理しています。

RDSが提供する主要なメリット

AWS RDSを利用することで得られる具体的なメリットは以下の通りです。

メリット	具体的な内容	実務への影響
自動バックアップ	毎日自動的にスナップショットを作成し、指定した保持期間（最大35日間）で保存	データ損失リスクの大幅低減
ソフトウェアパッチ適用	データベースエンジンの自動パッチ適用を実施	セキュリティ脆弱性への迅速な対応
スケーリング	垂直スケーリング（インスタンスタイプ変更）と水平スケーリング（リードレプリカ）が可能	負荷に応じた柔軟なリソース調整
高可用性構成	マルチAZ配置により、障害発生時の自動フェイルオーバーを実現	ダウンタイムの最小化
モニタリングとアラート	CloudWatchとの統合により、パフォーマンスメトリクスをリアルタイム監視	問題発生時の早期検知と対応

サポートされているデータベースエンジン6種の特徴

AWS RDSでは、複数のリレーショナルデータベースエンジンをサポートしています。用途に応じて最適なエンジンを選択できます。このうち高性能なAmazon Auroraの特徴と使いどころについては別記事で詳しく解説しています。

データベースエンジン	主な用途	特徴
Amazon Aurora	高性能・高可用性が求められるアプリケーション	MySQL/PostgreSQL互換で、5倍のスループットを実現
MySQL	オープンソースの汎用データベース	コスト効率に優れ、幅広い用途に対応
PostgreSQL	高度な機能が必要なアプリケーション	JSONサポートや地理空間データなど豊富な機能
MariaDB	MySQL互換でパフォーマンスを重視	MySQLよりも高速な処理が可能
Oracle Database	企業システムやミッションクリティカルなアプリケーション	Oracle固有の機能をフル活用可能
SQL Server	Windows環境や.NETアプリケーション	Microsoft製品との高い親和性

RDSの料金体系とコスト最適化

AWS RDSの料金は、以下の要素で構成されます。

DBインスタンス料金：稼働時間に応じた課金（秒単位）
ストレージ料金：プロビジョンドIOPS SSD（io1/io2）はGB単位、汎用SSD（gp2/gp3）はGB+IOPS単位
データ転送料金：リージョン間のデータ転送に応じた課金
バックアップストレージ料金：自動バックアップの保存期間に応じた課金

コスト最適化のための具体的な戦略として、以下のポイントがあります。

適切なインスタンスタイプの選択：ワークロードに応じたサイズを選定（例：t3.microからr5.2xlargeまで）
ストレージタイプの最適化：汎用SSD（gp3）はコストパフォーマンスに優れ、io1/io2は高いIOPSが必要な場合に適切
マルチAZ配置の検討：高可用性が求められる場合は必須だが、開発環境ではシングルAZでコスト削減
リードレプリカの活用：読み取り負荷が高い場合はリードレプリカを活用し、メインインスタンスの負荷を軽減
予約インスタンスの活用：1年または3年の予約により最大75%のコスト削減が可能

実際のコスト試算例として、MySQLをシングルAZで運用する場合、t3.mediumインスタンス（4vCPU、4GiB RAM）で月額約30米ドル程度から利用できます。一方、マルチAZ配置の場合は約2倍のコストがかかりますが、高可用性を確保できます。

マルチAZ配置がもたらす可用性向上の仕組み

AWS RDSのマルチAZ配置は、データベースの可用性を飛躍的に向上させる機能です。障害発生時の自動フェイルオーバーを実現し、ダウンタイムを最小限に抑えることができます。マルチAZ配置の仕組みと具体的なメリットを理解することで、なぜこれが重要なのかが明確になります。

マルチAZ配置の基本概念

マルチAZ配置では、プライマリDBインスタンスとスタンバイDBインスタンスが異なるアベイラビリティーゾーン（AZ）に配置されます。以下は、その基本的な構成です。

プライマリAZ：実際の読み書き処理を実行するDBインスタンス
スタンバイAZ：プライマリAZと同期されたスタンバイDBインスタンス
同期レプリケーション：プライマリからスタンバイへのデータ同期が常に行われる
自動フェイルオーバー：プライマリAZで障害が発生した場合、スタンバイAZが自動的にプライマリに昇格

この構成により、AZ障害が発生してもサービスを継続できる高可用性が実現されます。

マルチAZ配置のメリット

マルチAZ配置を導入することで得られる具体的なメリットは以下の通りです。

DBエンジンのアップグレードやパッチ適用時に、フェイルオーバーが発生しサービスへの影響を最小化

メリット	具体的な内容	実務への影響
高可用性	AZ障害時の自動フェイルオーバーにより、99.95%の可用性を実現	サービス停止リスクの大幅低減
データ durability	自動バックアップと同期レプリケーションにより、データ損失リスクを最小化	災害時のデータ回復が迅速かつ確実
メンテナンス時の影響軽減	計画的なメンテナンス時のダウンタイム削減
透過的な運用	アプリケーション側の変更不要で、自動的にフェイルオーバーが実行される	運用負荷の軽減

マルチAZ配置の仕組みと動作フロー

マルチAZ配置の動作フローを具体的に解説します。

データ書き込み処理：
1. アプリケーションから書き込み要求が発生
2. プライマリDBインスタンスがデータを書き込み、同時にスタンバイDBインスタンスへ同期レプリケーションを実行
3. 両方のDBインスタンスでデータが書き込まれたことを確認後、アプリケーションにレスポンスを返す
AZ障害発生時のフェイルオーバー：
1. プライマリAZで障害が発生（例：AZ停止、ネットワーク障害）
2. AWS側で障害を検知し、自動的にフェイルオーバーを開始
3. スタンバイDBインスタンスが新しいプライマリに昇格し、DNSエントリが更新される
4. アプリケーションは新しいプライマリDBインスタンスに接続し、処理を再開
フェイルオーバー後の動作：
1. 元のプライマリAZが復旧すると、新しいスタンバイDBインスタンスとして再構築される
2. データの同期が再開され、プライマリとスタンバイ間のレプリケーションが再確立される

フェイルオーバーにかかる時間は、通常1〜2分程度です。この間、アプリケーションからの接続が一時的に失敗する可能性がありますが、RDSのエンドポイントを使用することで、自動的に新しいプライマリDBインスタンスに接続が再確立されます。

マルチAZ配置の制限事項とコスト増

マルチAZ配置を導入する際には、以下の制限事項と注意点を理解しておく必要があります。

リージョン間の制限：マルチAZ配置は同一リージョン内のAZ間でのみ実行可能。リージョン間のマルチリージョン配置は別の機能（クロスリージョンリードレプリカ）で実現
エンジン固有の制限：
- Amazon Aurora：マルチAZがデフォルトで有効
- MySQL/PostgreSQL：明示的に有効化が必要
- Oracle/SQL Server：一部のバージョンでのみマルチAZがサポート
パフォーマンスへの影響：同期レプリケーションにより、書き込み処理のレイテンシが若干増加する可能性あり
コスト増加：スタンバイDBインスタンス分のコストが発生するため、シングルAZと比較して約2倍のコストがかかる
ストレージサイズの制限：マルチAZ配置時のストレージサイズは最大64TiB（2023年12月現在）

これらの制限を踏まえ、マルチAZ配置が本当に必要かどうかを検討することが重要です。例えば、開発環境やテスト環境ではシングルAZで十分な場合もあります。

リードレプリカで読み取り負荷を分散する方法

AWS RDSのリードレプリカ機能を活用することで、読み取り負荷の高いアプリケーションのパフォーマンスを大幅に向上させることができます。リードレプリカは、プライマリDBインスタンスから非同期でデータを複製し、読み取り専用のエンドポイントを提供します。この機能により、データベースの負荷分散とスケーラビリティの向上が実現されます。

リードレプリカの基本概念とメリット

リードレプリカは、以下のような特徴を持ちます。

非同期レプリケーション：プライマリDBインスタンスからリードレプリカへのデータ複製は非同期で行われる
読み取り専用：リードレプリカは読み取り専用であり、書き込み処理はできない
独立したエンドポイント：リードレプリカごとに独立したエンドポイントが提供される
リージョン間複製：リードレプリカは同一リージョン内だけでなく、異なるリージョンに配置することも可能

リードレプリカを活用することで得られる具体的なメリットは以下の通りです。

メリット	具体的な内容	実務への影響
読み取り負荷の分散	複数のリードレプリカに読み取り処理を分散することで、プライマリDBインスタンスの負荷を軽減	データベースのパフォーマンス向上とレスポンス時間の短縮
スケーラビリティの向上	リードレプリカを追加することで、読み取り処理のスケールアウトが可能	トラフィックの増加に柔軟に対応
地理的な負荷分散	リージョン間リードレプリカを活用することで、地理的に離れたユーザーへのレスポンスを向上	グローバルなアプリケーションのパフォーマンス最適化
障害時の影響軽減	リードレプリカがプライマリDBインスタンスの負荷を分担するため、障害発生時の影響を軽減	システム全体の安定性向上

リードレプリカの使用シーン

リードレプリカは、以下のようなシーンで特に有効です。

レポートや分析処理：
- 大量のデータを扱うレポート作成や分析処理をリードレプリカ上で実行することで、プライマリDBインスタンスの負荷を軽減
- 例：毎月の売上レポート、顧客分析、ログ集計など
読み取り負荷の高いWebアプリケーション：
- ECサイトやSNSなど、読み取り処理が多いアプリケーションでリードレプリカを活用
- 例：商品検索、ユーザープロフィールの表示、ニュースフィードの取得など
グローバルなアプリケーション：
- リージョン間リードレプリカを活用することで、地理的に離れたユーザーへのレスポンスを向上
- 例：世界各国にユーザーがいるSaaSアプリケーション
バッチ処理：
- 夜間のバッチ処理など、大量の読み取り処理を実行する際にリードレプリカを活用
- 例：データの集計、バックアップ処理、データ移行など

リードレプリカの設定方法

リードレプリカの設定は、AWS Management Console、AWS CLI、またはAWS SDKを使用して行うことができます。以下では、AWS Management Consoleを使用したリードレプリカの設定手順を解説します。

リードレプリカの作成手順

AWS Management Consoleにログイン：
- AWSアカウントにログインし、AWS Management Consoleにアクセス
- RDSサービスを選択
リードレプリカを作成するDBインスタンスを選択：
- 「データベース」セクションから、リードレプリカを作成するDBインスタンスを選択
- 「アクション」メニューから「リードレプリカの作成」を選択
リードレプリカの設定を指定：
- DBインスタンス識別子：リードレプリカの名前を入力
- DBインスタンスタイプ：リードレプリカに使用するインスタンスタイプを選択（プライマリと同じか、それよりも小さなサイズを推奨）
- アベイラビリティーゾーン：リードレプリカを配置するAZを選択（同一リージョン内）
- セキュリティグループ：リードレプリカに適用するセキュリティグループを選択
- パブリックアクセス：リードレプリカへのパブリックアクセスを有効化するかどうかを選択
リードレプリカを作成：
- 設定を確認し、「リードレプリカの作成」ボタンをクリック
- リードレプリカの作成が開始され、数分で利用可能な状態になる

リードレプリカの接続方法

リードレプリカは読み取り専用のエンドポイントを提供します。アプリケーションからリードレプリカに接続するには、以下の手順に従います。

リードレプリカのエンドポイントを取得：
- AWS Management ConsoleのRDSダッシュボードからリードレプリカを選択
- 「接続とセキュリティ」タブからエンドポイント（読み取りエンドポイント）を取得
アプリケーションの接続設定を更新：
- リードレプリカを使用するようにアプリケーションのデータベース接続設定を更新
- 例：MySQLの場合は接続文字列のホスト名をリードレプリカのエンドポイントに変更
読み取り処理をリードレプリカに振り分ける：
- アプリケーション側で読み取り処理をリードレプリカに振り分けるロジックを実装
- 例：特定のクエリをリードレプリカに送信するように設定

リードレプリカのパフォーマンス

リードレプリカのパフォーマンスを最適化するための具体的な方法を解説します。

リードレプリカのサイジング

リードレプリカのインスタンスタイプは、処理する読み取り負荷に応じて適切に選択する必要があります。以下は、一般的なワークロードに対する推奨インスタンスタイプです。

ワークロードタイプ	推奨インスタンスタイプ	用途
軽負荷（例：小規模Webサイト）	db.t3.micro	月間数千PV程度のWebサイト
中負荷（例：中規模ECサイト）	db.t3.medium / db.t3.large	月間数万PV程度のECサイト
重負荷（例：大規模SNS）	db.r5.large / db.r5.xlarge	高トラフィックなSNSや分析処理
高IOPSが必要な場合	db.io1.2xlarge / db.io2.4xlarge	大量のランダムI/Oが発生する処理

リードレプリカの監視とスケーリング

リードレプリカのパフォーマンスを監視し、必要に応じてスケーリングを行うことが重要です。以下は、リードレプリカの監視に使用できる主なメトリクスです。

CPU使用率：リードレプリカのCPU使用率を監視し、過負荷状態を検知
接続数：リードレプリカへの接続数を監視し、接続制限に近づいていないか確認
レイテンシ：リードレプリカへのクエリ実行時間を監視し、パフォーマンス低下を検知
ストレージ使用量：リードレプリカのストレージ使用量を監視し、容量不足を防ぐ
レプリケーション遅延：プライマリDBインスタンスとリードレプリカ間のレプリケーション遅延を監視

これらのメトリクスをCloudWatchで監視し、以下のようなアラートを設定することを推奨します。

CPU使用率が80%以上で継続的に推移している場合
接続数が最大接続数の80%に達した場合
レプリケーション遅延が1秒以上発生している場合
ストレージ使用量が80%を超えた場合

これらのアラートが発生した場合は、リードレプリカのインスタンスタイプをアップグレードするか、新しいリードレプリカを追加することを検討してください。

リードレプリカのメンテナンス

リードレプリカのメンテナンスは、以下のような手順で行います。

DBエンジンのアップグレード：
- リードレプリカのDBエンジンをアップグレードする場合は、まずプライマリDBインスタンスをアップグレード
- リードレプリカは自動的にアップグレードされる
パラメータグループの更新：
- リードレプリカのパラメータグループを更新する場合は、プライマリDBインスタンスと同じパラメータグループを使用
- リードレプリカはプライマリと同じパラメータで動作する
セキュリティパッチの適用：
- リードレプリカは自動的にセキュリティパッチが適用される
- 手動での適用は不要

マルチAZ・リードレプリカの実践的な設定手順

AWS RDSでマルチAZ配置とリードレプリカを実際に設定する手順を、具体的な画面操作と共に解説します。このセクションを読み終える頃には、実際のAWSコンソール上でこれらの機能を設定できるようになります。

マルチAZ配置の設定手順

マルチAZ配置を設定するには、以下の手順に従います。ここでは、Amazon RDS for MySQLを例に解説しますが、他のエンジンでも基本的な手順は同様です。

1. RDSインスタンスの作成（シングルAZ）

まず、シングルAZでRDSインスタンスを作成します。その後、マルチAZ配置に切り替えます。

AWS Management Consoleにログイン：
- AWSアカウントにログインし、AWS Management Consoleにアクセス
- 「RDS」サービスを選択
データベースの作成を開始：
- 「データベースの作成」ボタンをクリック
- 「標準作成」を選択
エンジンの選択：
- 「エンジンの種類」で「Amazon Aurora」または「MySQL」を選択
- 「バージョン」で使用するバージョンを選択（例：MySQL 8.0）
テンプレートの選択：
- 「テンプレート」で「プロダクション」または「開発/テスト」を選択
- プロダクション環境では「プロダクション」を選択し、高可用性を確保
設定の指定：
- DBインスタンス識別子：任意の名前を入力（例：my-mysql-db）
- マスターユーザー名：管理者ユーザー名を入力
- マスターパスワード：強力なパスワードを入力（8文字以上、大文字・小文字・数字・記号を含む）
- DBインスタンスタイプ：用途に応じたインスタンスタイプを選択（例：db.t3.medium）
- ストレージタイプ：汎用SSD（gp2）またはプロビジョンドIOPS（io1）を選択
- ストレージサイズ：必要なストレージ容量を入力（例：20GB）
- アベイラビリティーゾーン：シングルAZを選択（例：ap-northeast-1a）
- パブリックアクセス：踏み台経由でのみ接続する構成であれば「なし」を選択（インターネットに直接公開しない）
- VPCセキュリティグループ：DBインスタンスへの接続元を制限するセキュリティグループを指定
- バックアップ保持期間：自動バックアップの保持日数を指定（本番環境では7日以上を推奨）
データベースの作成を実行：
- 設定内容を確認し、「データベースの作成」ボタンをクリック
- DBインスタンスの作成には数分〜十数分かかる（インスタンスタイプ・エンジンにより変動）

2. シングルAZからマルチAZへの切り替え手順

すでに稼働中のシングルAZ構成をマルチAZに切り替える場合は、コンソールから「変更」を選択し、「マルチAZ配置」を有効化します。AWS CLIを使う場合は以下のコマンドで実行できます。

# シングルAZ構成のDBインスタンスをマルチAZに変更
aws rds modify-db-instance \
  --db-instance-identifier my-mysql-db \
  --multi-az \
  --apply-immediately

--apply-immediatelyを付けない場合、変更は次回のメンテナンスウィンドウまで適用が保留されます。本番環境で即時反映したい場合のみ付与してください。マルチAZへの切り替え自体はサービスを止めずに実行できますが、内部的にはスナップショット取得とスタンバイインスタンスの構築が行われるため、完了まで時間がかかる点に注意が必要です。

3. リードレプリカ作成手順（AWS CLI）

コンソールでの作成手順は前章で解説した通りですが、複数環境で再現性を持たせたい場合はAWS CLIでの作成が実務的です。

# プライマリインスタンス（my-mysql-db）からリードレプリカを作成
aws rds create-db-instance-read-replica \
  --db-instance-identifier my-mysql-db-replica-1 \
  --source-db-instance-identifier my-mysql-db \
  --db-instance-class db.t3.medium \
  --availability-zone ap-northeast-1c

リードレプリカの作成が完了すると、独立したエンドポイントが払い出されます。以下のコマンドでエンドポイントを確認できます。

aws rds describe-db-instances \
  --db-instance-identifier my-mysql-db-replica-1 \
  --query "DBInstances[0].Endpoint.Address" --output text

マルチAZ＋リードレプリカを組み合わせた全体構成図

マルチAZ配置とリードレプリカは併用が可能です。可用性はマルチAZ（同期レプリケーション）で担保しつつ、読み取り負荷はリードレプリカ（非同期レプリケーション）で分散する構成が、本番環境の定番パターンです。

[アプリケーション]
      │ 書き込み・読み取り（プライマリエンドポイント）
      ▼
[プライマリDBインスタンス（AZ-a）] ──同期レプリケーション──▶ [スタンバイDBインスタンス（AZ-c）]
      │ 非同期レプリケーション
      ├─────────────▶ [リードレプリカ1（AZ-a）] ◀── アプリケーションから読み取り専用エンドポイントで接続
      └─────────────▶ [リードレプリカ2（別リージョンも可）] ◀── レポート・分析処理などバッチ用途

この構成であれば、AZ障害時はマルチAZのフェイルオーバーでサービスを継続しつつ、通常運用時は読み取りクエリをリードレプリカに逃がしてプライマリの負荷を抑えられます。なお、マルチAZのスタンバイインスタンスはフェイルオーバー用の待機系であり、通常時に読み取りクエリを受けることはできません（読み取り負荷分散が目的であれば、必ずリードレプリカを別途構成する必要があります）。

運用時の監視とパフォーマンス最適化

マルチAZ・リードレプリカ構成を導入した後は、継続的な監視体制の構築が本番運用の要になります。CloudWatchの標準メトリクスに加えて、以下の観点を押さえておくと障害の予兆を早期に捉えられます。

フェイルオーバー発生の検知：CloudWatch Events（EventBridge）でRDSのフェイルオーバーイベントを検知し、Slack・メール等に通知する仕組みを用意しておく。フェイルオーバーは自動で完了するが、発生自体を運用チームが把握できないと原因調査が遅れる
レプリカラグ（ReplicaLag）の継続監視：リードレプリカの遅延がビジネス要件（例：注文直後に自分の注文がすぐ見えるべきか）に影響しないか、閾値を決めてアラート化する
Performance Insightsの活用：スロークエリの特定にはCloudWatchメトリクスだけでは不十分な場合が多い。Performance Insightsを有効化し、待機イベント単位でボトルネックを可視化する
接続プールの見直し：リードレプリカ追加後にアプリケーション側のコネクションプール設定を見直さないと、意図せずプライマリに接続が集中したままになるケースがある

まとめ：AWS RDSで堅牢なデータベースを構築する

AWS RDSのマルチAZ配置とリードレプリカは、目的が異なる別々の機能です。本記事のポイントを整理します。

マルチAZ配置：同期レプリケーションによる高可用性（自動フェイルオーバー）が目的。スタンバイ側は通常時の読み取りには使えない
リードレプリカ：非同期レプリケーションによる読み取り負荷分散・スケールアウトが目的。可用性の担保が目的ではない
本番環境の定番構成：マルチAZ＋リードレプリカを併用し、可用性と読み取りスケーラビリティを両立させる
導入後は監視が本番：フェイルオーバー検知・レプリカラグ・Performance Insightsを組み合わせた継続的な監視体制を構築する

まずは開発環境でシングルAZ構成から始め、要件に応じてマルチAZ・リードレプリカを段階的に追加していくアプローチが、コストと運用負荷のバランスを取りやすい進め方です。Azureのデータベースサービスと比較検討する場合は、AWSとAzureの比較完全ガイドも参考にしてください。

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。
編集ポリシーはこちら

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク