Amazon RDS マルチ AZ

Amazon RDS マルチ AZ は、RDS for PostgreSQL、RDS for MySQL、RDS for MariaDB、RDS for SQL、RDS for Oracle、および RDS for Db2 でご利用いただけます。2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ は、RDS for PostgreSQL と RDS for MySQL で利用できます。Amazon Aurora が 3 つのアベイラビリティーゾーンにわたってデータの耐久性を向上させることで可用性を高める方法については、「Aurora レプリカをによるマルチ AZ 配置」をご覧ください。

シングル AZ 配置、1 つのスタンバイインスタンスを使用するマルチ AZ 配置、および 2 つの読み取り可能なスタンバイを使用するマルチ AZ 配置の場合、料金は、DB インスタンスが起動されてから停止または削除されるまでに消費された DB インスタンス時間あたりで発生します。DB インスタンスクラスの作成、起動、変更などの請求対象となるステータス変更に続いて、1 時間未満の DB インスタンス時間は 10 分を最小料金として、秒単位で請求されます。

Amazon RDS マルチ AZ の料金の詳細については、Amazon RDS の料金ページを参照してください。

以下のユーザーガイドとチュートリアルを使用して、Amazon RDS マルチ AZ をすぐに使用開始できます。

セッション、オンラインセミナー、その他の動画を視聴して、Amazon RDS マルチ AZ の詳細を知ってください。

Amazon RDS マルチ AZ の最新の改善点を読み、Amazon RDS のユースケースでどのように使用できるかを詳しく調べてください。 

2 つの読み取り可能スタンバイを備えた Amazon RDS マルチ AZ 配置をアップグレードする場合、ProxySQL を使用して 1 秒以内のダウンタイムを実現

PostgreSQL 用の 2 つの読み取り可能スタンバイを備えた Amazon RDS マルチ AZ 配置での PgBouncer による迅速なスイッチオーバー

Amazon RDS マルチ AZ DB クラスターをアップグレードする場合、Advanced JDBC Wrapper Driver で 1 秒以下のダウンタイムを実現

Amazon RDS Proxy と 2 つの読み取り可能スタンバイを備えた Amazon RDS マルチ AZ 配置では、1 秒以下のダウンタイムでマイナーバージョンアップグレードを実行

Amazon RDS マルチ AZ クラスターの論理レプリケーションを使用した分析アプリケーションのデータ統合

マルチ AZ DB クラスターを使用して Amazon RDS for MySQL で高パフォーマンスと高可用性を実現するための最適戦略

最適化された書き込みにより、Amazon RDS for MySQL インスタンスと MariaDB インスタンス、および MySQL マルチ AZ DB クラスターのアプリケーションパフォーマンスが向上

適切な Amazon RDS デプロイオプション (シングル AZ インスタンス、マルチ AZ インスタンス、またはマルチ AZ データベースクラスター) を選択

SQL サーバー用 Amazon RDS Custom によるマルチ AZ の設定

Terraform モジュールを使用して Amazon RDS for PostgreSQL と MySQL マルチ AZ DB クラスターをデプロイ

新しい Amazon RDS for MySQL および PostgreSQL マルチ AZ 配置オプション: 書き込みパフォーマンスの向上とフェイルオーバーの高速化

マルチ AZ 配置として実行するように DB インスタンスを作成または変更すると、Amazon RDS では、同期 "スタンバイ" レプリカが別のアベイラビリティーゾーンで自動的にプロビジョニングされ、維持されます。DB インスタンスに対する更新は、別のアベイラビリティーゾーンにあるスタンバイに同時にレプリケートされるため、同期が維持されるとともに、最新のデータベース更新が DB インスタンスの障害から保護されます。

特定の種類の計画的なメンテナンスの期間中や、DB インスタンスの障害もしくはアベイラビリティーゾーンの障害といった予期せぬイベントが発生した際には、Amazon RDS はスタンバイに対して自動的にフェイルオーバーし、スタンバイが昇格したら直ちにデータベースの読み込みと書き込みを再開できるようにします。DB インスタンスの名前レコードは変化しないため、アプリケーションによるデータベースオペレーションは、管理者による手動での介入なしで再開できます。マルチ AZ 配置のレプリケーションは透過的です。スタンバイと直接やり取りすることはできません。また、スタンバイを読み取りトラフィックの処理に使用することはできません。マルチ AZ 配置の詳細については、「Amazon RDS ユーザーガイド」をご覧ください。

アベイラビリティーゾーンとは、別のアベイラビリティゾーンで発生した障害から隔離するために作られたリージョン内の場所です。各アベイラビリティーゾーンは、その独自の、物理的に区分され独立したインフラストラクチャ上で稼動しています。また高い信頼性を保つように設計されています。発電機や冷却装置などの障害対策用装置がアベイラビリティーゾーン間で共有されることはありません。さらに、これらは物理的にそれぞれ別々の場所にあるため、火災、竜巻、または洪水などの極めてまれな災害が発生しても、影響を受けるのは単一のアベイラビリティーゾーンのみです。同一リージョンにあるアベイラビリティーゾーンには、ネットワーク接続のレイテンシーが低いという利点があります。

DB インスタンスをマルチ AZ 配置として実行する場合、"プライマリ" はデータベースに読み込みと書き込みの機能を提供します。さらに、Amazon RDS は、背後で「スタンバイ」を設定して管理します。これはプライマリの最新レプリカになります。スタンバイはフェイルオーバー時に（プライマリに）「昇格」します。フェイルオーバー後、スタンバイはプライマリとなり、お客様のデータベースオペレーションを受け付けるようになります。昇格前には、どの時点においても、スタンバイと直接やりとり (例: 読み込みオペレーション) することはありません。単一の DB インスタンスの容量制限を超えて読み込みトラフィックをスケーリングする方法に関心のあるお客様は、リードレプリカのよくある質問をご覧ください。

DB インスタンスをマルチ AZ 配置として実行することの主な利点は、データベースの耐久性と可用性が向上することです。マルチ AZ 配置によって高められる可用性と耐障害性は、本番環境に最適です。

DB インスタンスをマルチ AZ 配置として実行すると、万一 DB インスタンスコンポーネントに障害が発生した場合や、特定のアベイラビリティーゾーンで可用性が失われた場合でも、データの安全が守られます。例えば、プライマリ上のストレージボリュームが障害を受ける場合、Amazon RDS はスタンバイに対して自動的にフェイルオーバーを開始し、お客様のデータベース更新はそのスタンバイですべて完全な状態に保たれます。これは、単一の AZ における標準配備と比較した場合、さらなるデータ堅牢性を提供するものです。単一の AZ における標準配備では、ユーザーによって開始される復元オペレーションが必要で、復元可能な最新時刻 (一般的には過去５分以内) 後に発生した更新は利用できません。

データベースの可用性を向上できることも、DB インスタンスをマルチ AZ 配置として運用する場合の利点の 1 つです。アベイラビリティーゾーンの障害または DB インスタンスの障害が発生した場合、可用性が影響を受けるのは、自動フェイルオーバーが完了するまでの間のみです。Multi-AZ の可用性に対する恩恵は、計画されたメンテナンスにも拡大されます。

例えば、自動バックアップでは、バックアップがスタンバイから取得されるため、お好みのバックアップウィンドウで、プライマリ上での I/O アクティビティが中断されることはありません。パッチの適用や DB インスタンスクラスのスケーリングを行う場合、これらのオペレーションは、自動フェイルオーバーの前にスタンバイで最初に行われます。結果的に、可用性が影響を受けるのは、自動フェイルオーバーが完了するのに必要な時間に限定されます。

DB インスタンスをマルチ AZ 配置として実行することによる暗黙の利点は他にもあります。それは、DB インスタンスのフェイルオーバーが自動で行われ、手動管理が必要ないことです。Amazon RDS のコンテキストでは、これはアベイラビリティゾーンや DB インスタンスの障害時に、(RestoreDBInstanceToPointInTime または RestoreDBInstanceFromSnapshot API を使用して) DB インスタンスのイベントをモニタリングし、手動で DB インスタンスの復旧を開始する必要がないことを意味します。
 

自動的に実行される同期的データレプリケーションの結果として、シングルアベイラビリティーゾーンにおける標準 DB インスタンス配置と比較した場合、レイテンシーが増加する可能性があります。

マルチ AZ DB インスタンス配置を作成するには、AWS マネジメントコンソールで DB インスタンスを起動する際に、[マルチ AZ 配置] で [はい] のオプションをクリックするだけです。

代わりに、Amazon RDS API を使用している場合は、CreateDBInstance API を呼び出して "マルチ AZ" パラメータの値を "true" に設定することもできます。 既存の標準 (シングル AZ) DB インスタンスをマルチ AZ に変換するには、AWS マネジメントコンソールで DB インスタンスを変更するか、ModifyDBInstance API を使用してマルチ AZ パラメータを true に設定します。
 

RDS for PostgreSQL、RDS for MySQL、RDS for MariaDB、RDS for SQL Server、RDS for Oracle、および RDS for Db2 データベースエンジンでは、Amazon RDS インスタンスをシングル AZ からマルチ AZ に変換することを選択すると、次のようになります。

• プライマリインスタンスのスナップショットが取得されます。
• そのスナップショットから新しいスタンバイインスタンスが別のアベイラビリティーゾーンに作成されます。
• 同期レプリケーションがプライマリインスタンスとスタンバイインスタンスとの間に構成されます。
  

結果として、インスタンスがシングル AZ からマルチ AZ に変換される際には、ダウンタイムは発生しません。ただし、スタンバイのデータがプライマリと一致するように処理されている間は、レイテンシーが増加することがあります。

Amazon RDS では、マルチ AZ 配置における一般的な障害シナリオが検出され自動的に復旧されるので、管理者の介入は不要でデータベース操作を可能な限りすみやかに再開できます。Amazon RDS によって自動的にフェイルオーバーが実行されるのは、次のことが発生したときです。

• プライマリ利用可能ゾーンの可用性損失
• プライマリに対するネットワーク接続の喪失
• プライマリ上でのコンピューティングユニット障害
• プライマリ上でのストレージ障害

注: DB インスタンスのスケーリングやシステムアップグレード (OS のパッチ適用など) のオペレーションがマルチ AZ 配置に対して行われるときは、可用性を高めるために、これらが最初にスタンバイに適用されて、その後で自動フェイルオーバーが実行されます。したがって、可用性への影響が現れるのは自動フェイルオーバーを完了するのに必要な時間までとなります。なお、Amazon RDS マルチ AZ 配置での自動フェイルオーバーは、データベース操作におけるエラー (長時間実行クエリ、デッドロック、データベース破損など) の発生に対しては行われません。

はい。Amazon RDS では DB インスタンスイベントが発行され、自動フェイルオーバーの発生が通知されます。Amazon RDS コンソールの [イベント] セクションをクリックするか、DescribeEvents API を使用して、DB インスタンスに関係のあるイベントについての情報を返すことも可能です。また、Amazon RDS Event Notifications を使用して、特定の DB イベントが発生したときに、通知を受け取ることも可能です。

フェイルオーバーは Amazon RDS によって自動的に処理されるため、管理者の介入なく、可能な限り迅速にデータベース操作を再開することができます。フェイルオーバーの際には、Amazon RDS は単純に DB インスタンスの正規名レコード (CNAME) を反転させ、スタンバイをポイントします。そしてこのスタンバイが今度は新しいプライマリになります。ベストプラクティスに従い、アプリケーションレイヤーでデータベース接続のリトライを実施することを推奨いたします。

フェイルオーバーは、プライマリで障害が検出されてからスタンバイでトランザクションが再開されるまでの間隔として定義され、通常 1 ～ 2 分以内に完了します。コミットされていない大きなトランザクションを回復させる必要があるかどうかによっても、フェイルオーバー時間は異なります。最適の結果を得るには、マルチ AZ では十分に大きなインスタンスタイプを使用することをお勧めします。また、高速かつ予測可能で、安定したスループットパフォーマンスを得るには、マルチ AZ インスタンスとともにプロビジョンド IOPS を使用することをお勧めします。

Amazon RDS は、さまざまな障害状態のときにユーザーが介入しなくても、自動的にフェイルオーバーを行います。さらに、Amazon RDS ではインスタンスが再起動されたときにフェイルオーバーを開始することもできます。この機能にアクセスするには、AWS マネジメントコンソールを使用するか、RebootDBInstance API コールを使用してください。

マルチ AZ 配置を使用するには、"Multi-AZ" パラメータを true に設定するだけです。スタンバイ、同期的レプリケーションおよびフェイルオーバーの作成は、すべて自動的に処理されます。つまり、スタンバイが配置されているアベイラビリティーゾーンを選択したり、利用可能なスタンバイ数を変更したりすることはできません (Amazon RDS は、DB インスタンスプライマリごとに 1 つの専用スタンバイを設定します)。また、スタンバイは、データベースの読み取りアクティビティを許可するよう設定できません。マルチ AZ 配置の詳細はこちら。

はい。スタンバイは、DB インスタンスプライマリと同一のリージョンの異なるアベイラビリティーゾーンに自動的にプロビジョニングされます。

はい。AWS マネジメントコンソールまたは DescribeDBInstances API を使用することで、現在のプライマリの場所を確認できます。

アベイラビリティーゾーンは、同一リージョンの別のアベイラビリティーゾーンに対して低レイテンシーでネットワーク接続できるように設計されています。さらに、1 つのアベイラビリティーゾーンでサービスに障害が発生してもお客様のアプリケーションが柔軟性を保てるよう、複数のアベイラビリティーゾーン全体で冗長性を持つようにアプリケーションや他の AWS リソースのアーキテクチャーを設計することも検討できます。マルチ AZ 配置は、お客様サイドでの管理作業なく、データベース層に対するこのニーズを解決します。

自動バックアップと DB スナップショットの機能の扱い方は、シングル AZ での標準的な配置とマルチ AZ 配置のどちらで実行するかにかかわらず同一です。マルチ AZ 配置で実行している場合は、自動バックアップと DB スナップショットはスタンバイから取得されます。これは、プライマリでの I/O 中断を避けるためです。なお、単一 AZ とマルチ AZ のどちらの配置の場合も、バックアップ取得中は I/O レイテンシーが増加する可能性があることにご注意ください（一般的には数分で元に戻ります）。

復元操作（特定時点への復元または DB スナップショットからの復元）についても、マルチ AZ 配置での機能は標準の単一 AZ 配置の場合と同じです。新しい DB インスタンスの配置は、RestoreDBInstanceFromSnapshot または RestoreDBInstanceToPointInTime API のどちらかで作成できます。これらの新しい DB インスタンスの配置は、ソースバックアップが標準配置で開始されていても、マルチ AZ 配置で開始されていても、それとは無関係に標準またはマルチ AZ のどちらかに設定できます。