Amazon Web Services ブログ
Amazon FSx で SQL Server のパフォーマンスを毎分 100 万トランザクション以上に拡張する
この記事は Alex Zarenin(プリンシパルソリューションアーキテクト)、Sudhir Amin(シニアソリューションアーキテクト)と Vikas Babu Gali(シニアスペシャリストソリューションアーキテクト)によって執筆された内容を日本語化したものです。原文はこちらを参照してください。
このブログ記事では Amazon Web Services(AWS)上の Microsoft SQL Server デプロイメントをスケーリングするための戦略について紹介します。この戦略ではクラウド上でフルマネージドの高性能なファイルシステムを提供する Amazon FSx を使用します。この戦略により、AWS 上での SQL Server のパフォーマンスが大幅に改善され、1 分あたりのトランザクション数(TPM)は従来比で 2~3 倍になります。また、トランザクションあたりのコストが低減されるため、コスト効率も向上します。
全体としてこの戦略は、最高性能の SQL Server データベースをクラウドで実行するコスト効率の高い方法をお探しのお客様にご利用いただけます。
1. はじめに
2021 年、私たちのチームは、AWS 上の SQL Server のパフォーマンスについて新たなベンチマークを記録し、ブログ記事としてリリースしました。著者は、メモリ最適化された Amazon Elastic Compute Cloud (Amazon EC2) r5b.24xlarge インスタンスを使用し、最大 60,000 Mbps の Amazon Elastic Block Store (EBS) 帯域幅と、毎秒 26 万回の Input/Output Operations(IOPS)を実現しました。このインスタンスの IO 機能を最大限に活用するため、3.5 TB の HammerDB TPCC テストデータベースを 2 つの io2 Block Express (io2-BE) ボリュームに格納し、RAID-0 構成で実装しました。この構成で HammerDB を使用したパフォーマンステストでは、約 83 万 TPM を達成しました。
同じブログ記事で、著者は Amazon EC2 のインスタンスストアボリュームにデータベースをホスティングすることで、パフォーマンスが約 20 % 向上することを示しました。しかしながら、インスタンスストアボリュームは一時的なブロックストレージであり、インスタンスを停止すると失われます。そのため、インスタンスストアボリュームは tempdb のストレージに適しています。一方で EBS ボリュームと Amazon FSx ファイルシステムは、データベースをホスティングするための耐久性と拡張性のあるストレージソリューションを提供します。
x2iedn や r6idn といった新しいインスタンスファミリーは、ブログ記事で使用した r5b.24xlarge よりも大幅にパフォーマンスが向上しています。これにより、パフォーマンスが約 30 % 向上し、100 万 TPM に近い結果が得られました。ただし、こうしたパフォーマンスの向上にはコストを伴います。仮想 CPU(vCPU)数の増加により、SQL Server の追加ライセンスが必要となります。また、インスタンスのスループットを使い切るには、3 つの io2-BE ボリュームにわたって RAID-0 を構成して使用する必要があるため、EBS ストレージのコストも増加します。
このブログ記事では、SQL Server について、EBS またはインスタンスストアボリュームだけでは不可能な高いパフォーマンスを実現するための Amazon FSx の革新的な使用方法をご紹介します。
2. テスト構成
Windows 上での SQL Server のパフォーマンステストでは、Windows と互換性のある Amazon FSx ファイルシステム、つまり Amazon FSx for NetApp ONTAP (FSx for ONTAP) と Amazon FSx for Windows File Server (FSx for Windows File Server) を使用しました。それぞれの Amazon FSx ファイルシステムを、26 TB の SSD ストレージ、80,000 IOPS、2 GBps のスループットで構成しました。FSx for ONTAP は、最大 4 GBps、160,000 IOPS のスループットを提供し、FSx for Windows File Server は、最大 12 GBps、350,000 IOPS のスループットを提供しますが、本ブログ記事の執筆時点では特定の AWS リージョンでのみ利用可能であるため、これらの構成は今回のテストから除外しました(これらのパフォーマンステストは、より高いスループットキャパシティレベルを使用してフォローアップする予定です)。
パフォーマンステストでは、AWS バージニア北部リージョン(us-east-1)で、Amazon のライセンス付き Microsoft Windows Server 2019 with SQL Server 2019 Enterprise edition を使用しました。EC2 インスタンスには、768 GB の RAM、96 個の vCPU、100 Gbps のネットワーク帯域幅、4 個の 900 GB NVMe SSD インスタンスストアボリュームを備えた r5dn.24xlarge EC2 インスタンスを使用しました。このインスタンスを選択した理由は、元のブログ記事で使用した r5b.24xlarge EC2 インスタンスと同等の vCPU と RAM を備えながら、より高いネットワークスループットを提供するためです。データベースの格納場所としてネットワーク接続ストレージを使用しているため、ネットワークスループットはパフォーマンスを大きく左右します。
tempdb を格納する場所として、r5dn.24xlarge EC2 インスタンスで利用可能な 4 つのインスタンスストアボリュームにわたって、RAID-0 ボリュームを作成しました。また、SQL Server データベースのログファイルを保管する場所として、64,000 IOPS でプロビジョニングされた io2-BE EBS ボリュームを使用しました。データベースのデータファイルは Amazon FSx ファイルシステムに格納しました。
今回、データベースのワークロードをシミュレートするために、幅広く使用されているベンチマークツール HammerDB を使用しました。HammerDB の OLTP ワークロードは、SQL Server の AWS への移行において一般的であるため、私たちのパフォーマンステストのベースとしました。約 3 TB で 30,000 のデータウェアハウスを含むテストデータベースを作成しました。
HammerDB の仮想ユーザーは、パフォーマンステストのためにデータベースに負荷をかけるシミュレートされたユーザーです。システムのピークパフォーマンスを測定するには、少数の仮想ユーザーから始め、データベースの TPM が臨界点に達するまで徐々にこの数を増やすことをお勧めします。仮想ユーザーの数を増やすと、パフォーマンスメトリクスは臨界点に達するまで増加し、その後は増加が止まるか、あるいは減少に転じます。
各テストの構成では、仮想ユーザー数として 256、362、512、724、1,024 を選択しました。結果の信頼性と一貫性を確保するため、仮想ユーザー数で定義されたそれぞれの負荷について、3 回のテストを実施しました。そして、これらのテストの平均を算出しました。
3. FSx for ONTAP を使用したパフォーマンステスト
FSx for ONTAP は、iSCSI と SMB の 2 つのプロトコルを提供しています。パフォーマンステストでは、両方のプロトコルを使用しました。
3.1. FSx for ONTAP を iSCSI プロトコルで使用
4 つの FSx for ONTAP インスタンスが提供する iSCSI 接続のドライブを EC2 インスタンスにアタッチしました。これらのドライブは、Windows Storage Spaces 機能を使用して、RAID-0 構成でストライピングしました。iSCSI ドライブのパフォーマンスを引き出すため、MPIO を有効にして、各ドライブに 4 つのパスを割り当てました。このシナリオの構成を図 1 に示します。
この構成での HammerDB パフォーマンステストの結果を表 1 と図 2 に記載します。結果が示すように、この構成では、元のブログ記事で説明したパフォーマンスの 2 倍のパフォーマンスを達成することができました。この構成では、 724 の仮想ユーザーで臨界点に達し、それ以上負荷が増加するとパフォーマンスが低下しました。
3.2. FSx for ONTAP を SMB プロトコルで使用
FSx for ONTAP は SMB プロトコルもサポートしています。SMB プロトコルは、ネットワーク上でファイルへのアクセスを共有するために使用されるクライアントサーバ通信プロトコルです。iSCSI プロトコルとは異なり、SMB は仮想ドライブを提供しませんが、代わりにファイル共有を提供します。このため、前のシナリオのように RAID-0 ストライピングを使用してパフォーマンスを向上させることはできません。
ボリュームをストライピングする代わりに、ファイルグループ内のデータベースファイルを複数のボリュームまたはファイル共有に分散する SQL Server の機能を使用しました。プライマリファイルグループを、4 つの FSx for ONTAP ファイルシステムが提供する 4 つのファイル共有に分散しました。
RAID-0 シナリオでは、テーブルの各レコードは複数のドライブに分割されます。しかし、プライマリファイルグループを複数の共有に分散させると、このファイルグループに割り当てられた各テーブルレコードは、それぞれ単一の SMB 共有に保存されます。テーブルのすべてのレコードは、複数の共有に均等に分散されます。この構成は RAID-0 の場合と類似しています。この構成を図 3 に示します。
この構成での HammerDB パフォーマンステストの結果を表 2 と図 4 に記載します。結果から明らかなように、この構成は、前述のセクション 3.1 で説明した構成よりも優れた値を記録しました。負荷が増加するに従ってパフォーマンスは徐々に向上し、1,024 仮想ユーザーで臨界点に達しました。
4. FSx for Windows File Server を使用したパフォーマンステスト
FSx for Windows File Server は SMB プロトコルのみをサポートしています。そのため、テストでは FSx for ONTAP の代わりに FSx for Windows File Server を使用している点を除き、図 3 で示したものと同様の構成を使用しました。この構成を図 5 に示します。
ストレージにこの構成を使用して SQL Server を実行し、表 3 と図 6 に示すパフォーマンステスト結果を得ました。
パフォーマンステストでは、200 万 TPM を上回る結果を達成しました。これは、元のブログ記事で紹介した io2-BE EBS ボリュームで達成した最高記録の約 3 倍です。
5. コストとパフォーマンス観点の比較
表 4 は、先に説明した 3 つの構成と、io2-BE EBS ボリュームを使用した元の構成(元のブログ記事に記載)に対するパフォーマンステストの結果をまとめたものです。また、各構成の試算コストも記載しています。Amazon FSx のコスト試算においては、バックアップのコストや重複の削減はデータベースワークロードには当てはまらないため、考慮していません。
FSx for ONTAP を使用した構成のパフォーマンスとしては、安定状態のパフォーマンス値を使用しました。SQL Server などの動的なワークロードでは、通常、表 1 と表 2 の結果よりも 10~15 % 低くなります。コンピュートのコストは、AWS リージョン us-east-1(バージニア北部)の EC2 インスタンス r5dn.24xlarge(ライセンス付き Microsoft Windows Server 2019 with SQL Server 2019 Enterprise edition)に基づいており、原文が執筆された 2023 年 8 月 28 日時点のものです。
Amazon FSx ファイルシステムを 4 つ追加したことで、システムのトータルコストは増加しました。しかし、パフォーマンスも向上したため、トランザクションあたりの総コストは減少しました。
FSx for ONTAP を SMB 接続で使用した場合、コストパフォーマンスが最も優れていました。FSx for Windows File Server は、全体的なパフォーマンスは最も高いですが、トータルコストも最も高くなりました。ただし、この構成で達成した SQL Server の優れたパフォーマンスを考慮すると、1,000 TPM あたりのコストは、SMB 接続を使用した FSx for ONTAP とほぼ同等です。
6. パフォーマンステストのスコープを拡大
AWS の新しいインスタンスタイプ、特にメモリを大量に消費する大規模アプリケーションに幅広く使用されている x2iedn メモリ最適化 EC2 インスタンスファミリーを考慮しなければ、分析は不完全なものになります。このファミリーではすべてのサイズで、メモリと vCPU が 32:1 の比率で提供され、RAM を最大 4 TB までスケールアップできるため、SQL Server のワークロードに適しています。これまでのテストで使用した r5dn.24xlarge インスタンスと比較するため、それぞれ 2 TB と 4 TB の RAM を搭載した x2iedn.24xlarge と x2iedn.32xlarge を選択しました。
3.5 TB のデータベースを、データベースのサイズに近いかそれを超える RAM を搭載した EC2 インスタンスで使用した場合、IO サブシステムをテストするための十分な負荷を与えられない可能性があります。そのため、8.5 TB で 75,000 のデータウェアハウスを含む HammerDB データベースを作成しました。8.5 TB では IO サブシステムに負荷をかけることができます。また、仮想ユーザー数を 2,048 に増やすことで、SQL Server の負荷をさらに高めることを目指しました。
ストレージサブシステムについては、FSx for Windows File Server を 4 つ使用し、図 5 と同じ構成で、最もパフォーマンスの良い構成を選択しました。テストの結果を表 5 と図 7 に記載します。
r5dn.24xlarge インスタンス上の SQL Server は、8.5 TB のデータベースでは約 150 万 TPM でピークに達しました。x2iedn ファミリーの RAM の増加は、SQL Server が 200 万 TPM を超えることを可能にした決定的な要因でした。8.5 TB のデータベースでは、r5dn.24xlarge で利用可能な 768 GB と比較して、x2iedn ファミリーはメモリ容量が増えているため、大きな違いが生じました。
この一連のテストのコストパフォーマンス分析を表 6 に記載します。x2iedn.24xlarge EC2 インスタンスは、1,000 TPM あたりのコストという点では明らかに優れていました。ただし、より大きな x2iedn.32xlarge EC2 インスタンスと比べ、性能はわずかに低くなっています。x2iedn.32xlarge の EC2 インスタンスで利用可能な 4 TB の RAM を最大限に活用するには、さらに大きなデータベースを検討する必要があるかもしれません。
図 8 に示したもう 1 つの興味深い点は、RAM の大きいインスタンスほど、基盤となる FSx for Windows File Server で消費される IOPS とスループットが減少したことです。これは、SQL Server がキャッシュ内でより多くのオペレーションを完了し、ファイルシステムに対する負荷が減少したためです。
7. まとめ
複数の Amazon FSx ファイルシステムを革新的に使用することで、単一のファイルシステムよりもはるかに高いストレージパフォーマンスを達成することができました。これにより、SQL Server のパフォーマンスが大幅に向上しました。複数の Amazon FSx ファイルシステムを使用することで、実行するリソースのコストは増加しますが、結果として SQL Server のパフォーマンスが向上します。そのため、トランザクションあたりのコストは、他の構成と同等か、それ以下の水準まで減少します。
FSx for ONTAP を iSCSI で使用した場合、SQL Server のテストではやや低いパフォーマンスを示しましたが、RAID-0 を構成することで、プライマリファイルグループを 4 つのボリュームに分散する必要がないため、よりシンプルな導入方法を提供します。
4 つの Amazon FSx ファイルシステムを使用してテストを実施しましたが、「4」は「マジックナンバー」ではありません。SQL Server をホストする EC2 インスタンスと、お客様固有のパフォーマンスおよびコスト要件によっては、2 つまたは 3 つの Amazon FSx ファイルシステムを使用するだけでも、SQL Server のパフォーマンスを大幅に向上させることができます。
この方法は、お客様が高性能な SQL Server ワークロードを管理するための新たな選択肢を提供します。特に今回ご紹介した戦略は、最高性能の SQL Server データベースをクラウドで実行するコスト効率の高い方法をお探しのお客様にご利用いただけます。
AWS は、どのクラウドプロバイダーよりも多くのサービスと機能を備えています。そのため、既存のアプリケーションをより速く、より簡単に、よりコスト効率の高い方法でクラウドに移行でき、想像できるほとんどすべてのものを構築することができます。Microsoft アプリケーションに必要なインフラストラクチャを提供し、お客様が望むビジネス成果を実現することができます。Microsoft ワークロードに関する詳しいガイダンスとオプションについては、.NET on AWS と AWS データベースのブログをご覧ください。移行とモダナイゼーションの検討を今すぐ開始するには、こちらへお問い合わせください。
翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの宮城が担当しました。
著者紹介