Amazon EBS io2 Express ボリュームを最大 64 TiB まで使用する Amazon RDS for SQL Server のベストプラクティス

Amazon Relational Database Service (Amazon RDS) for SQL Server が、Amazon Elastic Block Store (Amazon EBS) io2 Block Express ボリュームをサポートするようになりました。これらのボリュームは、高性能、高スループット、そして一貫して低レイテンシーを必要とするあらゆる重要なデータベースワークロードに対応するように設計されています。io2 Block Express ボリュームは、99.999% の耐久性、最大 64 TiB のストレージ、最大 4,000 MiB/s のスループット、最も要求の厳しいデータベースニーズに対して最大 256,000 の Provisioned IOPS をサポートしており、EBS io1 ボリュームと同じ価格で提供されます。

この投稿では、Amazon RDS for SQL Server DB インスタンスで io2 Block Express ボリュームを使用するためのベストプラクティスを共有します。

io2 Block Express ボリュームを使用した適切な RDS DB インスタンスクラスの選択

RDS DB インスタンスのパフォーマンスは、インスタンスタイプとストレージタイプの組み合わせによって決まります。したがって、RDS DB インスタンスレベルと EBS ボリュームレベルの両方で適用される最大 IOPS とスループットの制限を知ることが重要です。高パフォーマンスなワークロードの場合は、プロビジョンド IOPS SSD ストレージ (io2) と高性能の DB インスタンスクラスタイプ (X2iedn、R6i、R5b など) を組み合わせることをお勧めします。負荷の低いワークロードの場合は、汎用インスタンスクラスタイプ (m5i/m6i) とストレージ (gp2/gp3) で十分かもしれません。

ワークロードに最適な組み合わせを決めるには、次の手順を実行してください。

アプリケーションのワークロードの IOPS とスループット要件を特定します。
CPU、メモリー、ネットワークパフォーマンス要件を満たす適切な RDS DB インスタンスクラスを選択します。
IOPS とスループット要件に基づいて、汎用ストレージまたはプロビジョニングされた IOPS ストレージのいずれかの適切なストレージタイプを選択します。

次の図は、IOPS スループット、およびキャパシティの要件に基づいて RDS DB インスタンスストレージの決定ツリーを示しています。

次のいずれかの条件が当てはまる場合は、io2 ボリュームを選択する必要があります。

アプリケーションには高い IOPS (16,000 IOPS 以上) が必要
一貫したパフォーマンスを実現するため、低レイテンシと高スループット (1,000 MiB/s 以上) が必要
ストレージ容量の要件は 16 TiB を超えている
アプリケーションには高い耐久性と可用性 (99.999% の耐久性 SLA) が必要
ミッションクリティカルなデータベースまたは高パフォーマンスが持続的に必要なアプリケーションを実行している

AWS リージョンでの io2 Block Express ボリュームの可用性を確認するには、このドキュメントを参照してください。

io2 Block Express ボリュームの組み合わせのパフォーマンスは、選択した RDS DB インスタンスクラスとサイズによって異なります。次の表は、サポートされているさまざまな RDS インスタンスクラスにおける最大の RDS DB インスタンスサイズと、対応する io2 Block Express のパフォーマンス制限を示しています。

DB Instance Class	Max throughput limit (MiB)	Max IOPS limit (16 KiB I/O)	Max DB instance size
X2iedn	10,000	260,000	db.x2iedn.32xlarge
R5b	7,500	260,000	db.r5b.24xlarge
R6i/M6i	5,000	160,000	db.r6i.32xlarge
R5d/M5d/Z1d	2,375	80,000	db.r5d.24xlarge db.m5d.24xlarge db.z1d.12xlarge
R5/M5	2,375	80,000	db.r5.24xlarge db.m5.24xlarge

Amazon RDS for SQL Server でサポートされている DB インスタンスクラスについては、「Microsoft SQL Server の DB インスタンスクラスサポート」を参照してください。サポートされているインスタンスレベルのベースラインスループット、最大 IOPS、最大スループットの詳細については、「Amazon EBS 最適化インスタンス」を参照してください。

サポートされているインスタンスとボリュームの組み合わせについては、AWS のアップデートと機能強化により制限が変更される可能性があるため、常に最新の AWS ドキュメントを参照してください。

SQL Server データベースの io2 Block Express ボリュームを使用した Amazon RDS への移行

io2 Block Express ボリュームを使用する RDS for SQL Server DB インスタンスへの移行プロセスは、gp2、gp3、io1 などの他のボリュームとよく似ています。主な違いは、io2 ボリュームでは、最大 64 TiB の大規模なデータベースワークロードを移行できることです。オンプレミスまたは Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上で実行されている SQL Server データベースを Amazon RDS for SQL Server に移行する最も一般的な方法は、Amazon Simple Storage Service (Amazon S3) を使用した SQL Server ネイティブのバックアップと復元です。詳細については、「Amazon S3 を使用したバックアップと復元」を参照してください。

大規模なデータベースの復元は時間がかかるプロセスです。しかし、フル \ 差分 \ ログバックアップ戦略を使用することで、カットオーバー時間を短縮できます。さらに、バックアップ圧縮と複数のバックアップファイルを使用すれば、バックアップと復元のパフォーマンスが向上します ( 詳細は、Amazon RDS for SQL Server のネイティブバックアップと復元のパフォーマンスの改善を参照 )。復元パフォーマンスを改善するには、RDS DB インスタンスのネットワークと EBS の帯域幅使用状況を監視することが重要です。ボトルネックが発生した場合は、インスタンスサイズを拡張するか、追加のストレージ IOPS とスループットをプロビジョニングして、より速く復元を完了させることを検討してください。

Amazon RDS for SQL Server の Volume タイプを io2 Block Express に変更

Amazon RDS for SQL Serverでは、汎用 (gp2/gp3) とプロビジョンド IOPS (io1/io2) ボリュームを切り替えることができ、パフォーマンス要件の変化に合わせて柔軟に対応できます。ボリュームタイプを切り替えることで、アプリケーションの要求に応じてコストとパフォーマンスのバランスを取ることができます。AWS マネジメントコンソールまたは AWS コマンドラインインターフェイス (AWS CLI) を使用して、RDS for Server インスタンスのストレージタイプを gp2、gp3、io1 から io2 Block Express に変更できます。

ただし、io2 ボリュームを使用する場合は、1 つ重要な点を考慮する必要があります。io2 ボリュームを使用し、ストレージサイズが 16 TiB を超える場合、gp2、gp3、または io1 に戻すことはできません。このシナリオで gp2、gp3、または io1 に戻すには、gp2、gp3、または io1 ボリュームを持つ新しいインスタンスを作成し、SQL Server のネイティブバックアップとリストアを使用してデータベースを移行する必要があります。既存の RDS for SQLServer インスタンスのボリュームタイプを変更する際の技術的な詳細と手順については、「Amazon RDS DBインスタンスのストレージを使用する」を参照してください。

大規模な io2 ボリュームを使用した自動バックアップの管理

最初の RDS DB スナップショットは、DB インスタンスのストレージボリュームの完全なバックアップを取得します。同じインスタンスでの後続のバックアップは増分 DB スナップショットになり、最新のバックアップ以降に変更されたデータのみを保存します。ほとんどの場合、DB インスタンスの日次バックアップは迅速に完了します。これは、日次バックアップが増分であるためです。ただし、自動バックアップが無効になっていて、大量の作業負荷があるか、数日間バックアップが行われていない特定の状況では、増分 DB スナップショットに蓄積されたデータのために、次のバックアップの完了に長時間を要する可能性があります。データ変更量が 64 TiB に達すると、バックアッププロセスには最大 4 日かかる可能性があります。この間、インスタンスは完全に機能し利用可能な状態が維持されますが、インスタンスタイプの変更やシングル AZ からマルチ AZ への変換などのインスタンスレベルの変更は制限されます。

大規模なデータベースの長時間実行される DB スナップショットのリスクを軽減するには、次の手順を実行できます。

RDS DB インスタンスの自動バックアップを常に有効にしておくことを検討してください。これにより、最後の DB スナップショットからデータの増分変更が長期間蓄積することがなくなります。
大規模な RDS DB インスタンスの日次自動バックアップスナップショットの完了には時間がかかる場合があります。そのため、バックアップ保持期間を少なくとも 7 日間に設定することをお勧めします。これにより、次のバックアップウィンドウを逃した場合でも、DB インスタンスのバックアップが利用可能になり、ポイントインタイムリカバリ (PITR) が可能になります。
マルチ AZ インスタンスの場合、1 〜 2 か月ごとに計画的な手動フェイルオーバーを実行することをお勧めします。この予防措置により、マルチデプロイメントの健全性が維持され、予期しないフェイルオーバー後に発生する可能性のある長いバックアップ時間を回避できます。予期しないフェイルオーバーが発生した場合に、新しいプライマリがキャッチアップする必要があり、長いバックアップ時間が発生するリスクを最小限に抑えます。定期的にフェイルオーバーを実行することで、プロセスが円滑かつ効率的であることが確認でき、フェイルオーバー戦略を検証し、高可用性設定に自信を持つことができます。

自動バックアップ時間と手動スナップショットを使用した PITR の最適化

大量のデータロード直後に手動でスナップショットを取ることで、次の自動バックアップが最後のスナップショット以降の変更のみをキャプチャするだけで済むようになります。この予防措置により、その後の自動バックアップに必要な時間が大幅に短縮されます。これは、バックアップする必要があるデータ量が最小限に抑えられるためです。全体のバックアップ時間を短縮することで、ピーク時の RDS インスタンスのパフォーマンスと可用性を維持することができます。手動スナップショットの作成手順の詳細については、「シングル AZ DB インスタンスの DB スナップショットの作成」を参照してください。

さらに、この方法により PITR (Point In Time Recovery) のパフォーマンスも向上することがわかっています。PITR 機能を使用すれば、SQL Server インスタンスを EBS io2 Block Express ボリュームに特定の時点まで復元することができます。

DBスナップショットからの復元

コンソール、AWS CLI、または Amazon RDS API を使用して DB スナップショットからRDS DB インスタンスを復元できます。復元された DB インスタンスのステータスが使用可能になると、すぐに使用を開始できます。ただし、復元された DB インスタンスはバックグラウンドでデータの読み込みを続けます。このプロセスは遅延ロードと呼ばれます。

まだロードされていないデータにアクセスした場合、DB インスタンスは即座に Amazon S3 から要求されたデータをダウンロードし、その後バックグラウンドで残りのデータのロードを続行します。この遅延ロード処理中は、ボリュームが Amazon S3 から完全に再ハイドレートされるまで、レイテンシの上昇とパフォーマンスへの影響が発生する可能性があります。

遅延ロードとフルテーブルスキャン (SELECT *など) のような回避策の詳細については、「DB スナップショットからの復元」を参照してください。

大規模なボリュームでストレージを拡張するための計画的なメンテナンス時間枠を設定

ストレージ容量を拡張する必要がある場合は、既存の DB インスタンスのストレージを拡張できます。これは Amazon RDS コンソール、Amazon RDS API、または AWS CLI を使用して行うことができます。ただし、ストレージのスケーリング中に Amazon EBS がストレージの最適化を行うため、ボリュームのサイズによっては長時間かかる可能性があります。そのため、ストレージのスケーリングは計画されたメンテナンスウィンドウ中に手動で実行し、自動ストレージスケーリング操作の頻度を最小限に抑えることをお勧めします。

Amazon RDS 上の SQL Server の大規模な読み取りレプリカの最適化

プライマリインスタンスの負荷状況によっては、Amazon RDS の SQL Server のリードレプリカの作成に時間がかかる場合があります。大量の作業負荷が予想される場合は、リードレプリカの作成前に手動でスナップショットを取得することをお勧めします。この予防措置により、リードレプリカの作成に必要な時間を最小限に抑えることができます。

シングル AZ DB インスタンスをマルチ AZ DB インスタンスに変換

io2 Block Express を使用している RDS for SQL Server インスタンスをシングル AZ からマルチ AZ に変換できます。シングル AZ インスタンスをマルチ AZ インスタンスに変換するのに必要な時間は、RDS DB インスタンスのプライマリノードの負荷によって異なります。大量の作業負荷が予想される場合は、作業負荷が完了した後に手動でスナップショットを取ることをお勧めします。これにより、マルチ AZ に変換する前に増分 DB スナップショットが最新の状態になり、変換時間が最小限に抑えられます。

結論

IOPS とストレージの比率の制限、および IOPS とスループットのスケーリング方法を理解することで、パフォーマンス要件に合わせて io2 Block Express ボリュームを使用した RDS for SQL Server インスタンスのサイズを適切に設定できます。AWS Nitro System インスタンスは、最大 IOPS とスループットの能力が高くなっています。

SQL Server インスタンスで大規模な io2 ボリュームを使用する場合は、次のことをお勧めします。

自動バックアップを有効にしたままにしておき、移行中でも DB スナップショットが 20TiB を超えないようにしてください。
バックアップが数日かかる可能性があるため、バックアップ保持期間を最低 7 日に設定して、十分な DB スナップショット履歴が確保できるようにしてください。
大量の作業負荷の後に DB スナップショットを手動で取得し、自動の日次バックアップでキャプチャされるインクリメンタル DB スナップショットのサイズを最小限に抑えてください。
大量の作業負荷がある場合のマルチ AZ の構成では、計画外のフェイルオーバー後に非常に大きなスナップショットが発生するのを避けるため、1 〜 2 か月ごとにフェイルオーバーを実行してください。
DB スナップショットから復元した後は、他のボリュームタイプと同様に、アプリケーションスクリプトを実行してハイドレーション (遅延ロード) を迅速化してください。
スケジューリングされたメンテナンスウィンドウ中に手動でストレージのスケーリングを行い、64TiB ボリュームの最適化には長い時間がかかるため、自動ストレージスケーリング操作の頻度を最小限に抑えてください。

これらの推奨事項に従うことで、EBS io2 Block Express ボリュームを使用して大容量の RDS for SQL Server インスタンスのパフォーマンス、バックアップ、メンテナンスを効果的に管理および最適化できます。本番環境で使用する前に、io2 Block Express ボリュームを使用した RDS for SQL Server DB インスタンス上の SQL Server ワークロードに対して、徹底的なパフォーマンステストとベンチマークを実施することを強くお勧めします。

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

著者について

Sudhir Amin は、Amazon Web Services のシニアソリューションアーキテクトです。ニューヨークを拠点に、さまざまな業界のお客様にアーキテクチャガイダンスと技術支援を提供し、クラウド導入を加速させています。彼はスヌーカーの大ファンで、ボクシングや UFC などの格闘技も好きです。また、世界で最も雄大な動物を間近で見られる、豊かな野生動物の生息地がある国々を旅行するのが大好きです。

Toby Xu は、Amazon Web Services の RDS チームでシニアプロダクトマネージャーを務めています。AWS に入社する前は、Oracle と Informatica でソリューションアーキテクトチームを率いていました。16 年以上にわたりデータベースとミドルウェア技術に携わってきた経験から、この分野に関する豊富な知識を有しており、ソフトウェアエンジニアリングの修士号を持っています。彼はクラウド技術に興味があり、革新的なソリューションを活用してお客様の目標達成を支援することに尽力しています。

Swarndeep Singh は、AWS のシニアソリューションアーキテクトです。彼は Amazon RDS チームで働き、商用データベースエンジンと SQL Server を専門としています。彼は　Amazon RDS での技術的課題に取り組むことを楽しみ、AWS のお客様と協力してカスタマイズされたソリューションを構築し、チームメイトと知識を共有することに注力しています。

Amazon Web Services ブログ