Amazon RDS for SQL Server の Single-AZ リードレプリカの利用

Amazon Relational Database Service (Amazon RDS) for SQL Server では、リージョン内リードレプリカとクロスリージョンリードレプリカの 2 つの一般的な読み取りスケール可用性オプションがあります。Amazon RDS のお客様はリードレプリカを使用して、分析ワークロードや読み取り目的のトランザクションワークロードをプライマリデータベースインスタンスからオフロードします。以前は、リードレプリカにはプライマリデータベースインスタンスが Multi-AZ 構成になっている必要がありました。ただし、お客様の中にはプライマリデータベースインスタンスの高可用性についてはあまり懸念していないものの、分析アプリケーションを低コストで提供するためにリアルタイムに近いデータレプリケーションを必要とするお客様もいます。プライマリインスタンスに対して分析クエリを実行すると時間がかかる傾向があり、その結果、他のトランザクション (OLTP) タイプのクエリがブロックされたりタイムアウトしたりする可能性があります。読み取り目的の分析クエリをプライマリインスタンスからオフロードすることで、ロックやブロッキング、クエリタイムアウトなどを減らし、プライマリインスタンスのパフォーマンスを向上させることができます。このようなお客様のニーズを考慮して、Amazon RDS for SQL Server は 2024 年 4 月 1 日に Single-AZ インスタンス用のリードレプリカを発表しました。

Multi-AZ 用の既存のリードレプリカ機能と同様に、Single-AZ 用の新しいリードレプリカ機能でも、Single-AZ インスタンスの読み取り可能なコピーを作成できます。Single-AZ のリードレプリカは、同じ AWS リージョン内またはリージョン間で作成できます。Single-AZ のクロスリージョンリードレプリカをクロスリージョンのディザスターリカバリーインスタンスとして使用することもできます。

この投稿では、Single-AZ のリードレプリカのアーキテクチャ、作成、監視について説明します。

Single-AZ のリードレプリカを使用するメリット

Single-AZ リードレプリカには次の利点があります。

リードレプリカを使用して、Single-AZ プライマリインスタンスから分析ワークロードや読み取り目的のワークロードをオフロードできます。
リードレプリカを Single-AZ インスタンスに昇格させて、リージョン内またはリージョン間のディザスターリカバリーに役立てることができます。
Single-AZ のリードレプリカインスタンスの総コストは、Multi-AZ のリードレプリカインスタンスのコストに比べて低くなります。
同じ Single-AZ インスタンスに対して最大 15 個のリードレプリカを作成できます。

Single-AZ のリードレプリカを使用する場合の制限事項

Single-AZ リードレプリカを使用するときは、次の制限に注意してください。

複数のリードレプリカを作成することは可能ですが、挿入、更新、削除を受け入れることができるのはプライマリ Single-AZ インスタンスのみです。
リードレプリカへの自動フェイルオーバーはできません。ただし、必要に応じてリードレプリカをスタンドアロンの Single-AZ インスタンスに昇格させることはできます。一度リードレプリカを昇格させると、元のプライマリ Single-AZ インスタンスのリードレプリカには戻すことはできません。
アベイラビリティグループのデータ同期モードは非同期であるため、特にリソース競合が発生してプロビジョニングが不十分なインスタンスでは、リードレプリカで同期レイテンシーが発生する可能性があります。SQL Server の設計上、REDO スレッドが対応するログレコードをリードレプリカに適用するまで、データ変更はリードレプリカに反映されません。
リードレプリカ内のデータベースのバックアップは作成できません。
プライマリ Single-AZ インスタンスで作成されたテーブルやデータベースユーザーなどのデータベースレベルのオブジェクトは、自動的にリードレプリカにレプリケートされます。ただし、リードレプリカインスタンスの作成後にプライマリ Single-AZ インスタンスに追加されたログインや SQL エージェントジョブなどのサーバーレベルまたはインスタンスレベルのオブジェクトは、リードレプリカインスタンスで手動で作成する必要があります。

ソリューション概要

リードレプリカを含む Single-AZ インスタンスは、プライマリアベイラビリティーゾーンの 1 つのノードとセカンダリアベイラビリティーゾーンの 2 番目のノードで構成されます。これらのノードにはそれぞれ独自の Always On アベイラビリティグループがあります。これらのインスタンス間の可用性グループにまたがる分散型可用性グループが作成されます。プライマリ Single-AZ インスタンスでコミットされたトランザクションは、非同期的にリードレプリカにレプリケートされます。プライマリ Single-AZ インスタンスとリードレプリカインスタンスには、フロントエンドアプリケーションの接続文字列に使用できる独自の RDS エンドポイントがあります。

次の図は、同じリージョン内の Single-AZ インスタンスのリードレプリカのアーキテクチャを示しています。

Single-AZ インスタンスのリージョンとは異なる別のリージョンにリードレプリカを作成することもできます。次の図は、クロスリージョンリードレプリカを備えた Single-AZ インスタンスのアーキテクチャを示しています。

同じ Single-AZ インスタンスに対して最大 15 個のリードレプリカインスタンスを作成できます。より多くのリードレプリカを作成するビジネス上の理由がある場合は、プライマリインスタンスのリソース使用率を監視することが非常に重要であることに注意してください。ログレコードの読み取り、ログストリームの圧縮、および各レプリカへの送信を担当するバックグラウンドスレッドでは、リソースの競合 (CPU、スレッド、ネットワークなど) が発生し、パフォーマンスが低下する可能性があります。次の例は、2 つのリードレプリカを持つ Single-AZ インスタンスを示しています。RDS オートメーションは、作成したリードレプリカインスタンスごとに分散型可用性グループを作成します。

このアーキテクチャでは、OLTP タイプのトランザクションワークロードを Single-AZ エンドポイントに送信し、分析または読み取り目的のワークロードをリードレプリカエンドポイントに送信できます。

予期せぬ状況でリードレプリカの Single-AZ インスタンスがダウンし、回復不能な損傷を受けたり、アクセスできなくなったりした場合は、リードレプリカを Single-AZ インスタンスに昇格させて、アプリケーションのダウンタイムを減らすことができます。その後、Single-AZ インスタンス (プライマリに昇格したリードレプリカ) から新しいリードレプリカインスタンスを作成し、その新しいリードレプリカを指すように分析アプリケーションを再構成できます。

アプリケーションに同じ RDS Single-AZ またはリードレプリカインスタンスを指す接続文字列が複数ある場合は、対応する RDS エンドポイントを指す DNS レコードを作成することを検討してください。障害が発生した場合は、適切な RDS エンドポイントを指すように DNS レコードを更新できるため、1 つ以上のアプリケーションサーバーで複数の接続文字列を更新するオーバーヘッドを回避できます。

Single-AZ インスタンスに複数のリードレプリカを作成することは可能ですが、リソースの競合を避けるためにインスタンスのサイズ (インスタンスクラス、ストレージ IOPS、スループットなど) を適切に設定することが重要です。1 つ以上のリードレプリカの同期遅延は、SQL Server がプライマリデータベースレプリカのログファイルにログレコードを保持する原因になるためです。定期的なトランザクションログバックアップでは、ログレコードが送信されてリードレプリカにコミットされるまでログレコードをトランケートすることはできません。ログをトランケートできない場合、ログファイルは (設定されている場合) 自動的に拡張され、最終的にディスク領域がいっぱいになり、プライマリインスタンスが停止する可能性があります。

以下のセクションでは、AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して Single-AZ インスタンスのリードレプリカを作成する方法を示します。

前提条件

このソリューションを設定するには、次の前提条件を満たす必要があります。

Microsoft SQL Serverの分散型可用性グループに関する基本的な知識。
サポート対象バージョンの SQL Server Enterprise エディションを実行しているアクティブな Single-AZ インスタンス (サポートされているマイナーバージョンの詳細については、「RDS for SQL Server を使用したクロスリージョンリードレプリカ」を参照してください)。Standard エディションでは現在、リードレプリカはサポートされていません。手順については、「DB インスタンスの作成」を参照してください。
バックアップ保持期間が 0 日を超えるプライマリ Single-AZ インスタンスで自動バックアップが有効になっていること。

コンソールを使用した Single-AZ のリードレプリカの作成

コンソールを使用してリードレプリカを作成するには、次の手順を実行します。

Amazon RDS コンソールのナビゲーションペインで [データベース] を選択します。
データベース一覧から Single-AZ インスタンスを選択します。
[アクション] メニューで [リードレプリカの作成] を選択します。
注意 : DB インスタンスは、SQL Server バージョン 2016 Enterprise Edition (またはそれ以降のバージョン) を実行する Single-AZ インスタンスである必要があります。サポートされているマイナーバージョンの詳細については、リンクを参照してください)。
[DB インスタンス識別子] に、新しいリードレプリカインスタンスの名前を入力します。
[インスタンスの設定] セクションで、リードレプリカに適したインスタンスクラス (たとえば、db.m5.xlarge) を選択します。
特定の可用性グループでは、リソースの競合や同期のレイテンシーを避けるためにすべてのレプリカは同じワークロードを処理できる同等のインスタンスクラスとボリュームタイプで実行する必要があります。詳細については、「可用性レプリカをホストするコンピューターに関する推奨事項 (Windows システム)」を参照してください。
[AWS リージョン] では、アプリケーションのビジネス要件に基づいて適切なリージョンを選択します。
[ストレージタイプ] で、適切なストレージタイプ (gp2/gp3/io1/io2) を選択します。ストレージがいっぱいにならないように、ストレージの自動スケーリングを有効 / 無効にすることもできます。
1. io1/io2 を選択した場合は、プロビジョンド IOPS にも適切な値を指定してください。
2. gp3 を選択した場合は、プロビジョンド IOPS とストレージスループットに適切な値を指定してください。
[接続] セクションで、DB サブネットグループ、パブリックアクセス、VPC セキュリティグループ、およびアベイラビリティーゾーンの適切な値を選択します。要件に応じて、デフォルトまたは既存の値を選択できます。デフォルトのポート番号は 1433 です。別のポート番号を使用する場合は、「追加設定」で変更できます。
必要に応じて、インスタンスの Microsoft Windows 認証を選択します (詳細については、「RDS for SQL Server による AWS Managed Active Directory の操作」を参照してください)。ソースの Single-AZ インスタンスが既に Windows Active Directory ドメインの一部になっている場合は、適切なディレクトリを選択できます。
Single-AZ インスタンスが暗号化されている場合は、リードレプリカインスタンスの [暗号を有効化] をチェックします。暗号化されていない Single-AZ インスタンスから暗号化されたリードレプリカインスタンスを作成することはできません。
Performance Insights では、新しいリードレプリカの作成時に Amazon RDS Performance Insights を有効にすることも、後で有効にすることもできます。
無料で 7 日間のパフォーマンス履歴を保存できます。詳細については、「Amazon RDS での Performance Insights を使用したDB 負荷のモニタリング」を参照してください。
[拡張モニタリングの有効化] をチェックすることも、後で有効にすることもできます。
拡張モニタリングは OS 関連の指標をキャプチャし、サーバーのリソース消費量やキャパシティプランニングなどの分析に使用できます。詳細については、「Enhanced Monitoring の概要」を参照してください。最大 7 日間の保存期間に対する拡張モニタリングは無料です。
ログ記録を長期間保存するビジネス上の理由があるかもしれません。[ログのエクスポート] で [エージェントログ] と [エラーログ] をチェックして、ログが Amazon CloudWatch にエクスポートされるようにします。
IAM ロールには、CloudWatch にログを公開するために使用する AWS Identity and Access Management (IAM) ロールを入力します。
設定値を確認し、[リードレプリカの作成] をクリックします。

AWS CLI を使用した Single-AZ のリードレプリカの作成

AWS CLI の create-db-instance-read-replica コマンドを使用して、Single-AZ インスタンスのリードレプリカを作成することもできます。構文の例を以下に示します。

aws rds create-db-instance-read-replica 
—db-instance-identifier <RR_INSTANCE_NAME> \ 
—source-db-instance-identifier <SOURCE_SINGLEAZ_INSTANCE_NAME> \ 
—region us-west-2

たとえば、リージョン内の Single-AZ リードレプリカの場合は、次のコードを使用します。

aws rds create-db-instance-read-replica 
--db-instance-identifier singleaz-inst1-rr1 \ 
--source-db-instance-identifier singleaz-inst1 \ 
--region us-west-2

クロスリージョン Single-AZ リードレプリカの場合は、次のコードを使用します。

aws rds create-db-instance-read-replica \
--db-instance-identifier singleaz-inst1-rr2 \
--source-db-instance-identifier arn:aws:rds:us-west-2:<CUSTOMER_ID>:db:singleaz-inst1 \
--endpoint-url https://rds-siteb.us-east-1.amazonaws.com \
--region us-east-1 
--source-region us-west-2

Single-AZ インスタンスのリードレプリカインスタンスを監視

他のタイプのリードレプリカと同様に、リソース消費量 (CPU、メモリ、I/O) を監視し、インスタンスのリソースを適切なサイズにすることが重要です。このキャパシティプランニングには、過去のベースライン消費量と将来のワークロード予測を使用できます。この目的には、拡張監視やパフォーマンスインサイトなどのツールを使用することも、サードパーティ製のツールを使用することも、SQL Server の組み込みの動的管理ビューと動的管理関数を使用してカスタム監視スクリプトを作成することもできます。リソースの使用状況を監視するだけでなく、同期レイテンシーも定期的に監視することをお勧めします。Amazon RDS ReplicaLag メトリクスを表示するか、T-SQL クエリを使用して定期的にラグ情報を収集することで、CloudWatch を使用してレプリケーションラグをモニタリングできます。

SELECT AR.replica_server_name
     , DB_NAME (ARS.database_id) 'database_name'
     , AR.availability_mode_desc
     , ARS.synchronization_health_desc
     , ARS.last_commit_time
     , ARS.last_hardened_lsn
     , ARS.last_redone_lsn
     , ARS.secondary_lag_seconds
     , ARS.redo_queue_size
FROM sys.dm_hadr_database_replica_states ARS
INNER JOIN sys.availability_replicas AR ON ARS.replica_id = AR.replica_id
WHERE is_local <> 1
     -- AND DB_NAME(ARS.database_id) = '<REPLACE WITH SPECIFIC DB NAME>'
ORDER BY AR.replica_server_name;

リードレプリカに関する一般的な運用上の考慮事項

リードレプリカを使用するときは、次の点に注意してください。

Single-AZ インスタンスとそのリードレプリカインスタンスには、さまざまなインスタンスクラスとボリュームタイプを使用できます。リードレプリカインスタンスを過少プロビジョニングすることは可能ですが、CPU やメモリの圧力、I/O レイテンシーによるクエリパフォーマンスの低下やデータ同期の問題を避けるため、リソース消費量を定期的に監視し、インスタンスクラスとストレージタイプのサイズを適切に決定することが重要です。
リードレプリカを初めて作成するとき、RDS オートメーションは Single-AZ インスタンスにアタッチされた Amazon Elastic Block Store (Amazon EBS) ボリュームのスナップショットバックアップを作成します。このスナップショットから新しいボリュームが作成され、リードレプリカインスタンスにアタッチされます。基盤となるストレージが Amazon Simple Storage Service (Amazon S3) のスナップショットバックアップから新しく作成された EBS ボリュームに対してストレージブロックをウォームアップするバックグラウンドプロセスである S3 ハイドレーションと呼ばれるプロセスを実行するため、新しく作成されたリードレプリカでは I/O レイテンシーが若干長くなります。その結果、最初の数時間は Always On レプリケーションラグとクエリ実行時のレイテンシーも大きくなることが予想されます。データがロードされていない場所でボリュームにアクセスすると、データがロードされている間、ボリュームにアクセスするトランザクションのレイテンシが通常よりも長くなります。ボリュームサイズが大きいほど、ハイドレーションが完了するまでの時間が長くなります。
リードレプリカを使用して Single-AZ インスタンスでデータベースを作成またはリストアすることができます。Amazon RDS のオートメーションにより、リードレプリカ内のデータベースが自動的にリストアおよびペアリングされます。ただし、Single-AZ インスタンスで作成したログインや SQL Agent ジョブなどのサーバーレベルのオブジェクトは、既存のリードレプリカに自動的にレプリケートされません。
リードレプリカは、分析タイプのワークロードをオフロードするためによく使用されます。分析ワークロードは tempdb データベースリソースを大量に消費する傾向があります。tempdb の競合によるクエリのパフォーマンスの低下を避けるには、リードレプリカ内の tempdb データベースを監視し、適切なサイズを設定することが重要です。
Single-AZ インスタンスのアップグレード (メジャーバージョンまたはマイナーバージョン) を開始すると、Amazon RDS オートメーションは Single-AZ インスタンスのアップグレードとともにすべてのリードレプリカをアップグレードします。アップグレード中はインスタンスとデータベースにアクセスできないため、スケジュールされたメンテナンスウインドウ内でアップグレードを実行する必要があります。さらに、Single-AZ インスタンスとリードレプリカインスタンスに異なるバージョンの SQL Server を使用することはできません。
Single-AZ インスタンスからリードレプリカインスタンスへのデータ同期では、適切でないボリュームによる IOPS とスループットがボトルネックになる可能性があります。Single-AZ インスタンスとリードレプリカインスタンスに関連するボリュームを定期的に監視し、適切なサイズを設定することが不可欠です。
リードレプリカインスタンスはいつでも削除できます。1 つ以上のリードレプリカインスタンスを持つ Single-AZ インスタンスを削除すると、そのリードレプリカインスタンスは自動的に Single-AZ インスタンスに昇格します。昇格した Single-AZ インスタンスは必要に応じて削除できます。

結論

この投稿では、Amazon RDS for SQL Server Single-AZ インスタンスのリードレプリカが、Single-AZ インスタンスのスケーリングと、ソースの Single-AZ インスタンスからの読み取り集中型ワークロードのオフロードにどのように役立つかについて説明しました。さらに、ソースの Single-AZ インスタンスが使用できなくなった場合のディザスターリカバリーにも使用できます。過去のリソース消費量と将来のトランザクションリソースの予測に基づいて、リードレプリカインスタンス (CPU、メモリ、I/O) のサイズを適切に設定することが重要です。

翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文はこちらです。

著者について

Junu Thankappan は、アマゾンウェブサービスのシニアデータベースエンジニアです。AWS RDS チームで主に商用データベースエンジンと SQL Server を担当しています。

Amazon Web Services ブログ