Amazon RDS for SQL Server における大規模データベースのバックアップおよびリストア戦略

2023 年 7 月: この投稿の内容について正確性の確認をしました。

私たちのお客様の多くは、大規模なミッションクリティカルな SQL Server データベースに Amazon Relational Database Service (Amazon RDS) for SQL Server を使用しています。お客様は、Amazon RDS for SQL Server における大規模なデータベースを保護するための最適なソリューションを求めています。これにより、データ損失の許容範囲であるリカバリポイント目標 (RPO) と、サービスの中断からサービスの復旧までの最大許容遅延時間であるリカバリ時間目標 (RTO) の要件を満たすことができます。

データベース管理者の責任の 1 つは、会社のデータを保護することです。Amazon RDS for SQL Server には、データのバックアップとリストアに役立つ複数のオプションがあります。Amazon RDS for SQL Server を使用して大規模データベースのバックアップ戦略を立てる際には、次の点を考慮する必要があります。

データベースのサイズはどのくらいなのか？
RDS DB インスタンス上の個々のデータベースまたは複数のデータベースのどちらをリストアするのか?
バックアップとリカバリの戦略には、リージョン内およびリージョン間の保護が必要なのか?

通常、Amazon RDS for SQL Server のデータを保護するには、自動バックアップまたは手動スナップショットの使用、AWS Backup、ネイティブバックアップとリストア、またはその組み合わせなど、複数の方法から選択できます。ただし、(5 TB を超える) 大規模な SQL Server データベースを管理すると、何テラバイトもの情報が含まれることがあり、面倒な場合があります。

この投稿では、Amazon RDS for SQL Server でホストされている大規模な SQL Server データベースの 2 つのバックアップとリストアのオプションについて説明します。

ネイティブバックアップ/リストアアプローチ

Amazon RDS は SQL Server データベースのネイティブバックアップとリストアをサポートしています。RDS for SQL Server データベースのフルバックアップを作成し、そのファイルを Amazon Simple Storage Service (Amazon S3) に保存できます。その後、そのバックアップファイルを既存の RDS for SQL Server DB インスタンスにリストアできます。このバックアップファイルをオンプレミスサーバーまたは別の RDS for SQL Server DB インスタンスにリストアすることもできます。SQL_SERVER_BACKUP_Restore オプショングループを追加することで、Amazon RDS for SQL Server のネイティブ SQL バックアップとリストアを有効にできます。

次の図は、ネイティブバックアップおよびリストアソリューションのアーキテクチャを示しています。

前提条件

始める前に、次の前提条件が必要です。

Amazon RDS for SQL Server インスタンス
Amazon RDS for SQL Server へのアクセス許可を持つ S3 バケット

データベースを複数のバックアップファイルにバックアップする

次のコマンドを使用して、RDS for SQL Server データベースのネイティブバックアップを実行します。

exec msdb.dbo.rds_backup_database
	@source_db_name='database_name',
	@s3_arn_to_backup_to='arn:aws:s3:::bucket_name/file_name.extension',
	[@kms_master_key_arn='arn:aws:kms:region:account-id:key/key-id'],	
	[@overwrite_s3_backup_file=0|1],
	[@type='DIFFERENTIAL|FULL'],
	[@number_of_files=n];

@number_of_files は、バックアップが分割 (チャンク) されるファイルの数を示します。最大数は 10 です。

複数ファイルへのバックアップは、フルバックアップと差分バックアップの両方でサポートされています。値 1 を入力するかパラメータを省略すると、単一のバックアップファイルが作成されます。

大規模なデータベースのバックアップを生成する場合は、バックアップファイルを複数に分割して生成することをお勧めします。このプロセスにより、バックアップの生成時間が短縮されます。ビジネス要件が Amazon S3 から大規模なデータベースのバックアップをダウンロードすることである場合、複数のバックアップファイルをダウンロードする方が 1 つの大きなバックアップファイルをダウンロードするよりも高速です。

次のスクリプトは、gp2 ストレージと r5b.4xlarge インスタンスを使用してサンプルの RDS for SQL Server データベース (10 TB) を単一のバックアップファイルにバックアップします。

exec msdb.dbo.rds_backup_database
@source_db_name='TPCC',
@s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBSingleFile.bak',
@overwrite_s3_backup_file=1;

単一のバックアップファイルを使ったとき、個々の Amazon S3 オブジェクトのサイズは最小 0 バイトから最大 5 TB までの範囲であるためバックアップは次のエラーで失敗しました。

“[2022-09-09 13:26:22.083] タスクの実行が開始されました。 [2022-09-09 13:26:22.300] タスクの失敗または RDS 自動バックアップの優先バックアップウインドウとの重複のため、タスクが中止されました。 [2022-09-09 13:26:22.303] タスクは中止されました [2022-09-09 13:26:22.310] S3 にアップロードするための 524288000 バイトを超える S3 チャンクを生成できません。”

この制限を回避するために、データベースを複数のファイルにバックアップする別のアプローチを採用します。この方法は、RPO と RTO を削減するためにも推奨されます。

4 つのバックアップファイルを使用して同じスクリプトを実行できます。

exec msdb.dbo.rds_backup_database
@source_db_name='TPCC',
@s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc10TBMultiFile*.bak',
@number_of_files=4;

次のスクリーンショットに示すように、バックアップは正常に完了しました。

さまざまなデータベースサイズで同様のテストを実行しました。

たとえば、5 TB データベースの単一ファイルのバックアップを作成するには、次のコマンドを使用します。

exec msdb.dbo.rds_backup_database
@source_db_name='TPCC',
@s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak',
@overwrite_s3_backup_file=1;

次のスクリーンショットはバックアップを実行した結果を示しています。 1 つのファイルを使用した 5TB データベースのバックアップは 602 分で完了しました。

複数のバックアップファイルからデータベースをリストアする

単純なスクリプトをプロシージャとして作成、コンパイルして、それを T-SQL ツールとして使用することで大きなデータベースバックアップファイルをいくつかの小さなファイルに分割できます。

バックアップファイルからデータベースをリストアするには、restore Database コマンド用のすべてのバックアップファイルが必要であることに注意してください。

この手順は、SQL Server バージョン 2014 以降で機能します。

複数ファイルのバックアップを使用して 10 TB データベースをリストアするには、次のリストアコマンドを使用します。アスタリスク (*) は、S3 ARN の file_name 部分のどこにでも使用できます。アスタリスクは、生成されたファイル内で一連の英数字の文字列に置き換えられます。

exec msdb.dbo.rds_restore_database
@restore_db_name='TPCC',
@s3_arn_to_restore_from='arn:aws:s3:::sqlbackup-tpcc/backup/10TB/TPCC10TBbackup*';

次のスクリーンショットは、リストアが 470 分で正常に完了したことを示しています。

次のリストアコマンドを使用して、単一のデータベースファイルバックアップを使用して 5 TB データベースをリストアします。

exec msdb.dbo.rds_restore_database
@restore_db_name='TPCC',
@s3_arn_to_restore_from='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB.bak';

次のスクリーンショットは、リストアが 1008 分で正常に完了したことを示しています。

テスト結果

次の表は、r5b.4xlarge インスタンスを使用して Amazon RDS for SQL Server のさまざまなデータベースサイズで実行されたテストをまとめたものです。 1 TB および 5 TB のデータベースサイズのバックアップとリストアにかかる時間は、単一ファイルと比較して 4 つのマルチファイルを使用することで改善されることがわかりました。 1 つのファイルで S3 にアップロードできる最大オブジェクトは 5 TB であるため、現時点では 5 TB を超えるデータベースサイズ (例: 10 TB) を 1 つのファイルでバックアップおよびリストアすることはできません。

Test Instance	Activity Type	Single File (minutes)	Four Files (minutes)	Performance Improvement (%)

1 TB (gp2, 3 TB storage allocated)	Backup	151	56	62.91
1 TB (gp2, 3 TB storage allocated)	Restore	200	57	71.50

1 TB (i01-40000 IOPS)	Backup	140	52	62.86
1 TB (i01-40000 IOPS)	Restore	154	54	64.93

5TB (gp2, 10 TB storage allocated)	Backup	602	235	60.96
5TB (gp2, 10 TB storage allocated)	Restore	1008	291	71.23

5 TB (io1-40000 IOPS)	Backup	601	212	64.73
5 TB (io1-40000 IOPS)	Restore	991	208	79.01

10TB (gp2,16TB storage allocated)	Backup	N/A	663	N/A
10TB (gp2,16TB storage allocated)	Restore	N/A	681	N/A

10 TB (io1-40000 IOPS)	Backup	N/A	590	N/A
10 TB (io1-40000 IOPS)	Restore	N/A	470	N/A

影響を確認するために、バックアップファイルの数を 8 に増やして同様のテストを実行しました。

exec msdb.dbo.rds_backup_database
@source_db_name='TPCC',
@s3_arn_to_backup_to='arn:aws:s3:::sqlbackup-tpcc/backup/Tpcc5TB8files*',
@number_of_files=8;

この特定のインスタンスでは、テストしたインスタンスサイズで 4 つのバックアップファイルを使用した場合と比較して、結果にタイミングの違いはありませんでした。

最適なファイル数はインスタンスのサイズによって異なります。たとえば、インスタンスに 32 vCPU がある場合、インスタンスを 8 つのファイルに分割する方が 4 つのファイルよりも高速になります。

スナップショットアプローチ

Amazon RDS for SQL Server では、自動バックアップに加えて手動スナップショットを取得できます。これらは DB インスタンスのストレージボリュームスナップショットであり、個々のデータベースだけでなく DB インスタンス全体をバックアップします。スナップショットバックアップにかかる時間は、DB インスタンスのサイズとクラスによって異なります。このテストでは、r5b.4xlarge インスタンスを使用しました。

私たちが気づいた興味深い結果の 1 つは、16 TB のストレージが割り当てられた 10 TB のデータベースの場合、最初の手動スナップショット (バックアップ) に約 11 時間かかったということです。ただし、スナップショットからのリストアにはわずか 23 分しかかかりませんでした。これは、データベースの RTO を短縮するのに役立ちます。

データベースインスタンスの最初のスナップショットには、データベースインスタンス全体のデータが含まれています。同じデータベースインスタンスの後続のスナップショットは増分です。つまり、最新のスナップショットの後に変更されたデータのみが保存されます。

最初の手動スナップショットの後、次のスナップショット取得にかかる時間はわずか 5 分、リストア時間は 20 分でした。スナップショットによるリストアアプローチは、他のデータベースの RPO と RTO を短縮するのにも役立ちます。

リストアされたデータベースインスタンスのステータスが利用可能になるとすぐに使用できます。 DB インスタンスはバックグラウンドでデータの読み込みを続けます。これは遅延読み込みとして知られています。迅速なアクセスが必要なテーブルに対する遅延読み込みの影響を軽減するには、SELECT * などのテーブル全体のスキャンを伴う操作を実行できます。これにより、RDS for SQL Server インスタンスはバックアップされたテーブルデータを Amazon S3 からダウンロードできるようになります。

次の表は、初期スナップショットバックアップとリストアに関する調査結果をまとめたものです。

Test Instance	Activity Type	Duration (Minutes)
1 TB (gp2, 3 TB storage allocated)	Snapshot_Backup	109
1 TB (gp2, 3 TB storage allocated)	Snapshot_Restore	16
5 TB (gp2, 10 TB storage allocated)	Snapshot_Backup	480
5 TB (gp2, 10 TB storage allocated)	Snapshot_Restore	20
10 TB (gp2, 16 TB storage allocated)	Snapshot_Backup	635
10 TB (gp2, 16 TB storage allocated)	Snapshot_Restore	23

後片付け

この投稿のリソースの使用が終了したら、不要な料金が発生しないように AWS リソースをクリーンアップしてください。具体的には、このテストで使用した RDS for SQL Server インスタンスと S3 バケットからすべてのオブジェクトを削除します。

結論

この投稿では、Amazon RDS for SQL Server でホストされている大規模な SQL Server データベースを最小限の RTO と RPO でバックアップおよびリストアする方法に関する 2 つのアプローチについて説明しました。まず、SQL Server のネイティブバックアップを使用して複数のファイルにバックアップとリストアを最適化する方法を説明しました。この方法は、単一ファイルにバックアップする場合と比較して、バックアップ時間とリストア時間を短縮するのに役立ちます。次に、手動スナップショットのアプローチとパフォーマンステストから得られた結果を示しました。

著者について

Yogi Barot は、AWS のマイクロソフトスペシャリストプリンシパルソリューションアーキテクトです。さまざまな Microsoft テクノロジを扱った 22 年の経験があり、専門は SQL Server およびさまざまなデータベーステクノロジです。 Yogi は、AWS での Microsoft ワークロードの実行に関する深い AWS の知識と専門知識を持っています。

Vikas Babu Gali は、アマゾンウェブサービスの Microsoft ワークロードを専門とするシニアスペシャリストソリューションアーキテクトです。インド出身の Vikas は、クリケットをしたり、屋外で家族や友人と時間を過ごすことを楽しんでいます。

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

Amazon Web Services ブログ