Amazon RDSマルチAZ とリードレプリカの違い、高可用性と読み取りスケーリングの違いを理解する

AWS RDSとそのメリット

AWS RDS (Amazon Relational Database Service) は、Amazon Web Services (AWS) が提供するクラウド上のリレーショナルデータベースサービスです。PaaS（Platform as a Service）という形式で提供されており、自動バックアップ、パッチ管理、スケーリングなどの一般的なデータベース管理タスクをAWSが代わりに行ってくれます。

また、MySQLやPostgreSQLのようなオープンソースのデータベースエンジンだけでなく、OracleやSQLサーバーといったエンタープライズのデータベースも利用することが可能です。RDSの最大のメリットとしては、手軽にデータベースを設定できることです。数クリックでデータベースのレプリケーションや冗長構成を設定することが可能です。

本記事では、RDSにおけるレプリケーションや冗長構成について、具体的にはマルチAZ（高可用性対策）とリードレプリカ（読み取りスケーリング）の違いを深堀して説明していきます。

レプリケーションとは

レプリケーション（replication）とは、その単語の意味のとおり『複製する』という意味です。データベースにおけるレプリケーションとは、データベースの内容を他の場所やシステムにコピーするプロセスのことを指します。例えるならば、大切な書類や写真をパソコンからUSBメモリにコピーする行為に似ています。

レプリケーションの難しさ

データベースのレプリケーションは、システムの高可用性を確保するための強力なツールですが、実装と運用にはいくつかの難しさが伴います。具体的には下記のような項目です。

• 同期方法
  一方のデータベースでデータが更新された際には、レプリカ対象のデータベースにもデータを更新しないと、データの整合性が崩れてしまいます。加えて、遠隔地にあるデータベース間のレプリケーションでは、ネットワークの遅延が発生する可能性があり、これがデータの一貫性やアプリケーションのパフォーマンスに影響を及ぼす可能性があります。
• 誤った更新の防止
  誤ったデータや不正なトランザクションがレプリカに伝播する前にそれを検出・修正するメカニズムが不足していると、問題が全てのレプリカに広がるリスクもあります。
• バージョン管理
  データベースのソフトウェアが更新されると、レプリケーション対象のデータベースも一斉に更新をかける必要があります。この更新を怠ると、データベースのエラーや動作に影響が出る可能性があります。
  このように、データベースのレプリケーションを1から十分に実装することは非常に難しいという特徴があります。

AWSにおけるレプリケーション

AWSが提供しているRDSにおいては、データベースのレプリケーションに関する設定が数クリックでできるようになっています。そのため、上記のようなレプリケーションの実装はオンプレミスのシステムと比較して非常に簡単になっています。

一方で、レプリケーションの形式には『マルチAZ』と『リードレプリカ』の2種類が存在しています。これらの使い分けを理解することで、アプリケーションのパフォーマンスや可用性を大幅に向上させることができます。
『マルチAZ』と『リードレプリカ』について、具体的にどのような機能なのか、見ていきましょう。

マルチAZとは

「AZ」は「Availability Zone」の略で、AWSのデータセンターが存在する独立した物理的な場所を指します。各AZ同士は物理的に独立しており、それぞれ異なる電源、冷却装置、ネットワークを持つことで、障害が発生したとしても他のAZには影響が及びにくい設計となっています。

マルチAZとは、その言葉のとおり、データベースを異なる物理的な場所にある複数のデータセンター (AZ) に配置する仕組みのことを指します。具体的には、ユーザーが選択するプライマリDBインスタンスと、それとは異なるAZに自動的に作成されるスタンバイDBインスタンスといった、2つ以上のDBインスタンスが作られます。

これらのインスタンス間でデータは常に同期されています。この仕組みは、一つのAZがダウンした際にもデータベースが動作し続けることを保証します。

マネージドデータベースを活用して運用コストを引き下げるスタイルズのAWS導入・移行サービスはこちら→

障害時には？

プライマリDBインスタンスに何らかの障害やメンテナンスが発生した場合、RDSは自動的にトラフィックをスタンバイDBインスタンスにフェイルオーバーさせます。これにより、アプリケーションのダウンタイムを最小限に抑えることができます。

フェイルオーバーが発生すると、DBの接続先を示すDNSレコードがスタンバイDBインスタンスを指すように更新されます。

リードレプリカとは？

リードレプリカは、メイン（プライマリ）データベースから非同期でデータをコピーするセカンダリ（またはレプリカ）データベースを作成する機能です。このレプリカデータベースは、読み取り専用として使用されるため、「リードレプリカ」と呼ばれます。マルチAZと違って、レプリケーションを行っているデータベースを同一AZに置くことも可能です。

同期方法の違い

マルチAZは同期でレプリケートされますが、リードレプリカは非同期でレプリケートされる仕様となっています。同期・非同期の違いは電話とメールをイメージするといいでしょう。

あなたが友人に電話をかけると、友人が電話に出るまで待機します。友人が電話に出たら、リアルタイムでやり取りが行われ、要件がすんだあと電話が終了します。

このように、データベースにおける同期レプリケーションは、一方のデータ更新がレプリケーション先に反映されるまで、データの読み取りや更新は行われないようになっています。
一方で、あなたが友人にメールを送ると、友人がそのメールを確認するまで待たなくても、あなたは次の作業に移ることができます。

このように、非同期のレプリケーションは片方のレプリケーション処理が終わらなくても、読み取りの処理が行われます。したがって、極端な場合、プライマリデータベースとリードレプリカの間にわずかな期間の間、データの差分が生じる可能性があります。

マネージドデータベースを活用して運用コストを引き下げるスタイルズのAWS導入・移行サービスはこちら→

目的の違いを理解する

マルチAZとリードレプリカは、どちらもデータベースのレプリケーション技術ですが、その目的が異なります。それぞれの目的は下記のようになります。

• マルチAZ…主な目的は「高可用性」です。一つの場所で問題が発生した場合も、他の場所でサービスが継続されるようにするためのものです。
• リードレプリカ…主な目的は「読み取りスケーリング」です。データベースへの読み取り要求を分散させることで、パフォーマンス（読み取り応答性能）を向上させるためのものです。
  したがって、ユースケースとしては下記のようなものが考えられます。

マルチAZのユースケース

• 高可用性を担保する目的…一つのAZやハードウェアに問題が発生しても、自動的に別のAZのスタンバイDBインスタンスに切り替わるため、サービスの中断時間を大幅に短縮することができます。
• データ保護…マルチAZはデータベースのデータを自動的にバックアップし、それを異なるAZに保持するため、データの損失リスクを大幅に低減します

リードレプリカのユースケース

• パフォーマンスの向上…アプリケーションが大量の読み取りクエリを発行する場合、プライマリデータベースだけに頼ると、パフォーマンスに影響を及ぼす可能性があります。リードレプリカを使用することで、全体の読み取り性能を向上させることができます。
• 負荷分散…レポートやデータ分析を行う際に、プライマリデータベースに負荷をかけたくない場合、リードレプリカを使用してこれらのクエリを実行することができます。

このように、マルチAZとリードレプリカを使い分けたり、組み合わせたりすることで、データベースのレプリケーションを簡単に、効率よく導入することができます。
ユースケースや導入方法に迷った場合には専業のベンダーに相談するのもいいでしょう。