Amazon Web Services ブログ

新しい Amazon RDS のマルチ AZ 配置オプション – MySQL および PostgreSQL データベースでご利用可能

2022 年 3 月 2 日(米国時間)、Amazon Relational Database Service (RDS) のマルチ AZ 配置オプションを発表しました。トランザクションコミットのレイテンシーが最大で 2 倍の速度になり、フェイルオーバーが自動化され (通常 35 秒未満)、スタンバイインスタンスが読み取り可能になります。

Amazon RDS は、可用性とパフォーマンスを向上させるための 2 つのレプリケーションオプションを提供します。

  • マルチ AZ 配置により、高可用性が実現され、自動フェイルオーバーが可能になります。Amazon RDS は、2 番目のアベイラビリティーゾーンにデータベースのストレージレベルのレプリカを作成します。その後、高可用性を実現するために、プライマリ DB インスタンスからスタンバイ DB インスタンスにデータを同期的にレプリケートします。プライマリ DB インスタンスがアプリケーションリクエストを処理しますが、スタンバイ DB インスタンスでは障害発生時に引き継ぐ準備が整っています。Amazon RDS は、障害検出、フェイルオーバー、修復アクションのあらゆる側面を管理し、データベースを使用するアプリケーションの可用性を高めます。
  • リードレプリカを使用すると、アプリケーションは複数のデータベースインスタンスにわたって読み取りオペレーションをスケールできます。データベースエンジンは、リードレプリカにデータを非同期的にレプリケートします。アプリケーションは書き込みリクエスト (INSERTUPDATEDELETE) をプライマリデータベースに送信し、読み取りリクエスト (SELECT) は複数のリードレプリカでロードバランスできます。プライマリノードに障害が発生した場合は、リードレプリカを新しいプライマリデータベースに手動で昇格させることができます

マルチ AZ 配置とリードレプリカの目的は異なります。マルチ AZ 配置は、アプリケーションの高可用性、耐久性、および自動フェイルオーバーを実現するためのものです。リードレプリカは、アプリケーションの読み取りスケーラビリティを向上させるためのものです。

しかし、自動フェイルオーバー機能を利用する高可用性と読み取りスケーラビリティの両方を必要とするアプリケーションについてはどうすればよいでしょうか?

読み取り可能なスタンバイインスタンスを 2 つ備えた、新しい Amazon RDS マルチ AZ 配置オプションをご紹介します。
2022 年 3 月 2 日(米国時間)より、RDS データベースをデプロイするための新しいオプションが追加されます。このオプションは、自動フェイルオーバーとリードレプリカを組み合わせたものです。すなわち、2 つの読み取り可能なスタンバイインスタンスを備えた Amazon RDS マルチ AZ です。このデプロイオプションは MySQL および PostgreSQL データベースでご利用いただけます。これは、1 つのプライマリインスタンスと 2 つの読み取り可能なスタンバイインスタンスを持つデータベースクラスターです。トランザクションコミットのレイテンシーが最大 2 倍の速度になり、フェイルオーバーが自動化されます (通常 35 秒未満)。

次の図は、このようなデプロイを示しています。

3 つの AZ RDS データベース

新しい マルチ AZ DB クラスターのデプロイオプションを有効にすると、RDS は 3 つの異なるアベイラビリティーゾーンに 1 つのプライマリデータベースと 2 つのリードレプリカを設定します。その後、モニタリングが実行され、プライマリノードに障害が発生した場合にフェイルオーバーが有効にされます。

従来のリードレプリカと同様に、データベースエンジンはプライマリノードとリードレプリカの間でデータをレプリケートします。また、マルチ AZ の 1 つのスタンバイデプロイオプションと同様に、RDS はフェイルオーバーを自動的に検出して管理し、高可用性を実現します。

高可用性とスケーラビリティのいずれかを選択する必要はありません。2 つの読み取り可能なスタンバイを備えたマルチ AZ DB クラスターは両方を実現します。

利点
この新しいデプロイオプションには、コミットレイテンシーの改善、フェイルオーバーの高速化、読み取り可能なスタンバイインスタンス、最適化されたレプリケーションという、従来のマルチ AZ 配置に比して 4 つのメリットがあります。

まず、マルチ AZ DB クラスターを使用すると、書き込みオペレーションの速度が向上します。新しいマルチ AZ DB クラスターインスタンスは、M6gd と R6gd のインスタンスタイプを活用します。これらのインスタンスは、AWS Graviton2 プロセッサを利用します。ローカルストレージ用に高速 NVMe SSD を搭載し、高速かつ低レイテンシーのストレージに最適です。同等の x86 ベースのインスタンスと比べて、vCPU あたりのコストパフォーマンスが最大 40% 改善され、ローカルストレージ (GB) が 50% 増加します。

マルチ AZ DB インスタンスは、Amazon Elastic Block Store (EBS) を使用してデータとトランザクションログを保存します。新しいマルチ AZ DB クラスターインスタンスは、インスタンスが提供するローカルストレージを使用してトランザクションログを保存します。ローカルストレージは、低レイテンシーかつ高い I/O オペレーション/秒 (IOPS) をアプリケーションに提供するように最適化されています。書き込みオペレーションは、まずローカルストレージトランザクションログに書き込まれ、その後にデータベースストレージボリューム上の永続ストレージにフラッシュされます。

次に、通常、マルチ AZ DB インスタンスのシナリオの場合と比較して、フェイルオーバーオペレーションがより高速に実行されます。新しいマルチ AZ DB クラスターによって作成されたリードレプリカは、本格的なデータベースインスタンスです。このシステムは、35 秒 (これに加えて保留中のトランザクションログを適用する時間) という速さでフェイルオーバーするよう設計されています。フェイルオーバーが発生した場合、システムは完全に自動化されて、新しいプライマリを昇格させ、古いプライマリを新しいリーダーインスタンスとして再構成します。

3 つ目に、2 つのスタンバイインスタンスはホットスタンバイです。アプリケーションは、クラスターリーダーエンドポイントを使用して、読み取りリクエスト (SELECT) をこれらのスタンバイインスタンスに送信できます。これにより、アプリケーションはデータベースクラスターのインスタンス間でデータベースの読み取り負荷を均等に分散できます。

最後に、トランザクションログにローカルストレージを活用することで、レプリケーションが最適化されます。既存のマルチ AZ DB インスタンスは、すべての変更をストレージレベルでレプリケートします。新しいマルチ AZ DB クラスターはトランザクションログのみをレプリケートし、クォーラムメカニズムを使用して、少なくとも 1 つのスタンバイが変更を承認したことを確認します。トランザクションログがローカルディスクに書き込まれたことを、いずれかのセカンダリインスタンスが確認すると、データベーストランザクションは同期的にコミットされます。

既存のデータベースの移行
既存の RDS データベースがあり、この新しいマルチ AZ DB クラスターのデプロイオプションを利用する場合には、データベースのスナップショットを作成して、既存のデータベースインスタンスのストレージレベルのバックアップを作成することができます。スナップショットの準備ができたら、このスナップショットに基づいてマルチ AZ DB クラスターのデプロイオプションを使用して、新しいデータベースクラスターを作成できます。新しいマルチ AZ DB クラスターは、既存のデータベースの完全なコピーになります。

実際に機能しているところを見てみましょう。
まず、ブラウザで AWS マネジメントコンソールをポイントし、RDS に移動します。マルチ AZ DB クラスターのデプロイオプションは、MySQL バージョン 8.0.28 以降、PostgreSQL バージョン 13.4 R1 および 13.5 R1 で使用できます。いずれかのデータベースエンジンを選択し、バージョンが最小要件に一致していることを確認します。以降の手順は、標準的な Amazon RDS のデータベースの起動と同じです。

[Deployment options] (デプロイオプション) で [PostgreSQL]、バージョン [13.4 R1] の順に選択し、[Availability and Durability] (可用性と耐久性) で [Multi-AZ DB cluster] (マルチ AZ DB クラスター) を選択します。

3 つの AZ RDS 起動コンソール

必要に応じて、クラスター用に RDS が使用するアベイラビリティーゾーンのセットを選択できます。選択するには、DB サブネットグループを作成し、このサブネットグループにクラスターを割り当てます。

起動したら、3 つの DB インスタンスが作成されたことを確認します。また、Amazon RDS が提供する 2 つのエンドポイント (プライマリエンドポイントと、2 つの読み取り可能なスタンバイインスタンス用の負荷分散されたエンドポイント) にも留意します。

RDS の 3 つのインスタンスの AZ リスト

新しいクラスターをテストするために、データベースと同じセキュリティグループ内の同じ VPC で Amazon Linux 2 EC2 インスタンスを作成し、AmazonSSMManagedInstanceCore マネージドポリシーを含む IAM ロールをアタッチしていることを確認します。これにより、SSH ではなく SSM を使用してインスタンスに接続できます。

インスタンスが起動したら、SSM を使用してインスタンスに接続します。PostgreSQL クライアントツールをインストールします。

sudo amazon-linux-extras enable postgresql13
sudo yum clean metadata
sudo yum install postgresql

プライマリ DB に接続します。テーブルを作成してレコードを INSERT します。

psql -h awsnewsblog.cluster-c1234567890r.us-east-1.rds.amazonaws.com -U postgres

postgres=> create table awsnewsblogdemo (id int primary key, name varchar);
CREATE TABLE

postgres=> insert into awsnewsblogdemo (id,name) values (1, 'seb');
INSERT 0 1

postgres=> exit

レプリケーションが想定どおりに動作することを確認するために、読み取り専用レプリカに接続します。エンドポイント名に含まれている -ro- に着目してください。テーブル構造をチェックし、SELECT ステートメントを入力して、データがレプリケートされたことを確認します。

psql -h awsnewsblog.cluster-ro-c1234567890r.us-east-1.rds.amazonaws.com -U postgres

postgres=> \dt

              List of relations
 Schema |      Name       | Type  |  Owner
--------+-----------------+-------+----------
 public | awsnewsblogdemo | table | postgres
(1 row)

postgres=> select * from awsnewsblogdemo;
 id | name
----+------
  1 | seb
(1 row)

postgres=> exit

フェイルオーバーのシナリオでは、アプリケーションはプライマリデータベースインスタンスから切断されます。その場合は、アプリケーションレベルのコードがネットワーク接続の再確立を試みることが重要です。しばらくすると、エンドポイントの DNS 名がスタンバイインスタンスをポイントし、アプリケーションは再接続できるようになります。

マルチ AZ DB クラスターの詳細については、ドキュメントを参照してください。

料金と利用可能なリージョン
2 つの読み取り可能なスタンバイを備えた Amazon RDS マルチ AZ 配置は、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (アイルランド) の各リージョンで一般的にご利用いただけます。今後、さらに多くのリージョンで利用可能になる予定です。

MySQL バージョン 8.0.28 以降、または PostgreSQL バージョン 13.4 R1 もしくは 13.5 R1 でご利用いただけます。

料金はインスタンスタイプによって異なります。米国のリージョンのオンデマンド料金は、M6gd インスタンスが 1 時間あたり 0.522 USD、R6gd インスタンスが 1 時間あたり 0.722 USD です。いつものように、Amazon RDS の料金ページには MySQLPostgreSQL の詳細が記載されています。

2022 年 3 月 2 日(米国時間)よりご利用いただけます。

原文はこちらです。