【AWS】RDSのレプリケーションについて解説します。

最終更新日:2026年8月6日

目次

要注意:本記事では執筆時の用語「マスター」「スレーブ」を使用していましたが、AWS公式ドキュメントでは現在「プライマリ(Primary)」「スタンバイ(Standby)」「ライターインスタンス/リーダーインスタンス」という用語に統一されています。本記事でも以下、現行用語で記載します。

世の中の多くのシステムは、データベースが壊れるとシステム全体が止まってしまいます。そのため、データベースが止まらないように設計・運用する必要があります。Amazon RDSはAWSが提供しているデータベースサービスです。サービスと付くのには理由があり、それはRDSが高可用性や耐障害性を実現しているためです。ここでは、RDSのレプリケーションについて解説していきます。

■そもそもレプリケーションとは

レプリケーションとは、「複製(レプリカ)を作る」という意味です。同じネットワーク内や遠隔地にサーバーを設置して、リアルタイムでデータをコピーする技術のことを指します。プライマリのデータベースと全く同じ内容のデータベースを作成できるため、負荷分散やホットスタンバイに有効な手段として普及しています。万が一障害が起こっても、システムを停止させることなく継続でき、予備を遠隔地に置くことで広域災害時の対策としても有効です。その反面、予備にほぼ同じシステムが必要になるため、初期投資がかかるという欠点もあります。また、ウイルスなどに感染してデータが破壊されると、その破壊されたデータもそのままレプリケートされてしまうというリスクもあります。

■バックアップとの違い

バックアップは、ある時点(静止点)のファイルやアプリケーション、またはそれらを含むシステム全体を別の場所に保存することです。バックアップは静止点を記録する関係上、業務が動いていない夜間帯や、時期を設定して定期的に行われることが多く、用途やニーズに合わせて一定期間を保持します。バックアップでは、サーバーやストレージなど対象となるハードウェアとは別のバックアップ専用ハードウェアにデータをコピーするのが一般的です。

◇メリット比較◇

レプリケーション
・システム復旧までの時間を最小限にすることが可能
・バックアップで対応できない大容量でも、複製を置くことができる

バックアップ
・任意の時点を指定してシステム復旧できる

◇デメリット比較◇

レプリケーション
・任意の時点を指定したシステムを復旧できない

バックアップ
・最終バックアップ以降の更新データは復元不可
・バックアップのための作業負荷が継続的に発生する
・日単位でシステム停止を余儀なくされる場合がある

■RDSのレプリケーション

AWSのRDSでは、マルチAZ構造と言いプライマリと呼ばれる実際にデータ処理が行われるRDSインスタンスと、そのインスタンスがあるAZとは別のAZにスタンバイと呼ばれる別のRDSインスタンスが自動的に用意され、そこにデータを複製することで可用性を高めています。細かな設定をせずとも、このようなレプリケーションが利用できるのは、RDSの特徴のひとつです。

■同期レプリケーション

RDSのマルチAZは、データベースの障害時の影響を最小化するために同期レプリケーションを行っています。これは、プライマリへの変更後にスタンバイを変更し確定してから反応するという流れです。よって、プライマリとスタンバイ間の通信の分だけ遅くなってしまいますが、RDSはデータセンター間を高速な回線で繋ぐことで数msの遅延と非常に高速です。RDSのようなマルチAZ構造において同期レプリケーションは非常に便利なシステムです。

■リードレプリカ(Read Replica / 非同期レプリケーション)

そもそもリードレプリカとは、読み込み専用として利用することができるプライマリの複製データベースを指します。Amazon RDSでは、プライマリのDBインスタンスのデータを非同期にレプリケーションする機能としてこのリードレプリカを提供しています。リードレプリカの場合、DBインスタンスに対して直接アクセスすることが可能です。

読み込みが多いアプリケーション等に有効ですが、非同期のため常にプライマリと完全に内容が一致しているわけではなく、常に最新のデータが取得できるということはできません。しかし、プライマリの読み取りにかかる負荷を軽減でき、これによりプライマリのパフォーマンスが向上するため、プライマリの負荷分散として多く利用されています。

【様々なパフォーマンスの向上オプション】
・レプリカDBで読み取り処理をスケールアウト(リードレプリカは5台まで増設可能)
 ※Auroraは15台まで
・マルチAZとの併用やクロスリージョン対応も可能
・インスタンスやストレージをプライマリと異なるタイプに設定可能
・リードレプリカはスタンドアロンのDBインスタンスに昇格可能
・MySQL、MariaDBではパラメータ設定で書き込みも可能
・MySQL、MariaDB、PostgreSQL、Auroraに対応
・AWS Database Migration Service(DMS)によりOracle、SQL Serverでも実現可能

■論理レプリケーションと物理レプリケーション

RDSのマルチAZは、プライマリとスタンバイ間で物理レプリケーションを行っています。これは、トランザクションが完了する前のプライマリへのページ書き込みが起こったタイミングでスタンバイにも並行で書き込みを行うため高速で、DRBDの仕組みに似ています。RDSは、InnoDBを使用しており、電源やネットワーク障害が発生した場合にデータの整合性を保ちます。また、論理レプリケーションは、プライマリに対するSQL文等のトランザクションレベルの操作をスタンバイにも行います。

【物理レプリケーション】
・データべースエンジンがMySQL、MariaDB、PostgreSQL、Oracleの時に選べるのは物理レプリケーション
・スタンバイのデータをプライマリに合わせて最新の状態に維持
・AWSが提供している機能
・データベース作成時にマルチAZ配置にするか選択することで適用される

【論理レプリケーション】
・データべースエンジンがSQLServerの場合は論理レプリケーション
・スタンバイしているデータをプライマリに合わせて最新の状態に維持、という機能は物理レプリケーションと同じ
・SQLServerが提供しているミラーリングテクノロジーという方法で実現している
 。ミラーリングの場合はプライマリ/スタンバイをプリンシパルサーバー/ミラーサーバーと呼ぶ
 。コミット済みのトランザクションのデータをスタンバイに反映

~参考~

DRBD
DRBD (Distributed Replicated Block Device)とは、ネットワークを通じてハードディスク(ブロックデバイス)をリアルタイムに複製(レプリケート)するソフトウェアの総称。クラウド上なので、ラック設置などの物理的な運用はもちろん、パッチ更新やレプリケーション、リードレプリカの作成、さらに作成後にサーバのスペックを変更できたり、ストレージの容量を増やせるなどの特徴がある。

InnoDB
MySQL ABが配布している全てのバイナリに標準搭載されている、MySQLのためのデータベースエンジン。

この記事のポイント

  • AWS公式では「マスター/スレーブ」から「プライマリ/スタンバイ」という用語に統一されている
  • RDSのマルチAZ構成は同期レプリケーションで障害時の影響を最小化し、リードレプリカは非同期レプリケーションで読み取り負荷を分散する
  • リードレプリカはRDSで最大5台、Auroraでは最大15台まで増設可能

よくある質問

Q. マルチAZとリードレプリカ、両方同時に使えますか?
A. 併用可能です。マルチAZで高可用性を確保しつつ、リードレプリカで読み取り負荷を分散するという構成もよく採用されます。
Q. レプリケーションとバックアップ、どちらを優先すべきですか?
A. 目的が異なるため、両方の運用が推奨されます。レプリケーションは障害時の即時切り替え、バックアップは誤操作やデータ破損時に特定時点へ復旧するために使います。
Q. リードレプリカで書き込みはできますか?
A. 基本的には読み取り専用ですが、MySQLやMariaDBではパラメータ設定により書き込みを有効にすることが可能です。ただし通常はプライマリへの書き込みを前提とした設計が推奨されます。

■まとめ

バックアップと目的は近いものはありますが、それぞれの仕様によりメリットやデメリットがあるため、システム構築時は用途の精査も重要になります。同期や非同期、物理や論理レプリケーションについてイメージが掴めましたでしょうか。RDSの特徴をしっかりおさえて、ノンストップでノンメンテナンス、ノンアドミンなデータベース環境を利用しましょう。

▼ アクロビジョンについて

👔

一緒に働きましょう

一人ひとりのキャリアに向き合い、
活躍できる現場をご紹介します。

採用サイトを見る →
💻

システム開発のご依頼・ご相談

コンサルティングから運用保守まで、
ワンストップで対応します。

まずはお気軽にご相談ください →