re:Invent 2024: AWSのOptimize CPU機能でSQL Serverコスト削減
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Reduce cost for SQL Server workloads on AWS using Optimize CPU feature (XNT303)
この動画では、SQL Serverのライセンスコストを大幅に削減できるAWS Optimize CPUs機能について解説しています。Virtual ProcessorとPhysical Processorの2つを搭載する最近のマシンで、Hyper-threadingを無効化することでライセンスコストを50%削減できる点や、HammerDBを使用したパフォーマンステストの結果、CPU数を75%削減してもOLTPワークロードのパフォーマンスに影響がないことが示されています。特にSQL Server Enterprise Editionでは、インスタンス全体のコストの82%をソフトウェアライセンスが占めているため、この最適化による削減効果は39%にも及びます。また、re:Invent以前には作成時のみだった設定が、動的に変更可能になった点も紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データベースワークロードのコスト課題とAWS Optimize CPUs機能の紹介
皆様、本日はご参加いただき、誠にありがとうございます。本日は、データベースワークロードを管理する上で最も重要な課題の1つである、コストについてお話しさせていただきます。本日ご出席の皆様とお話しする中で、多くの方がその懸念を共有されていますが、簡単に挙手をお願いできますでしょうか：ワークロードをスケールする必要が生じた際に、ライセンス料金やクラウド料金が上昇する問題を経験された方は何人いらっしゃいますか？ほとんどの方ですね。ありがとうございます。ご存知の通り、最近のマシンの多くは、Virtual ProcessorとPhysical Processorの2つのプロセッサーを搭載しており、Physical Processor1つにつき1つのVirtual Processorが割り当てられます。私たちの調査によると、これによりマシンのCPU使用率は約20%低下しますが、その一方でライセンスコストは50%増加してしまいます。これは決して良い取引とは言えませんね。
本日は、AWS Optimize CPUs機能を使用して、パフォーマンスに影響を与えることなく、ライセンスコストを50%以上削減する方法についてご紹介させていただきます。さらに重要なのは、ワークロードをスケールする必要が生じた際に、ライセンスコストを現状維持するか、より小さな割合に抑えることで、ペナルティを受けることなくワークロードをスケールする方法です。本日は、SQL Server分野で活躍するAlex Zareninと共同で発表させていただきます。私はRafet Ducicと申しまして、AWSのSr. Solutions Architectとして、コスト効率の良いSQL ServerやMicrosoftワークロードの運用を専門としています。
Alexが自己紹介をしました：「私はAlex Zareninと申しまして、AWSのPrincipal Solutions Architectを務めております。AWSでの勤務は7年目になります。この間ずっとMicrosoft技術に焦点を当てており、現在は主にAWS上のSQL Serverを担当しています。」AWS上でSQL Serverを運用されている方は何人いらっしゃいますか？素晴らしいですね。現在AWS上でSQL Serverを運用されていない方も、本セッションで様々なメリットをご覧いただいた後には、きっとAWSでの運用を決断されることでしょう。
本日のセッションは、SQL Server導入時のコスト削減に焦点を当てています。ただし、ここでご紹介する手法は、CPUごとに料金を支払う必要のあるソフトウェアライセンスであれば、どのようなものにも適用できます。私たちが見てきた中では、ほとんどのお客様がIOPS、メモリ、必要なCPUに基づいてインスタンスを選択されますが、実際にはそのインスタンスのCPU構成を頻繁に変更することはありません。IOPSやメモリを増やすためにワークロードをスケールする必要がある場合、CPU数が2倍になるためライセンスも2倍になってしまいます。インスタンスサイズはTシャツのサイズのようなもので、LargeからExtra Largeに上げると全てが2倍になるのです。Optimize CPUs機能はこれらの課題に対処することができ、本日は、パフォーマンスを犠牲にすることなく、このコスト削減を実現する方法をご紹介します。
SQL Serverライセンスコストの現状と最適化の必要性
Optimize CPUsを使用することによるコスト削減のメリットについてご説明し、さらに重要な点として、Optimize CPUsを実装する際のパフォーマンスに関する考慮事項についても説明させていただきます。では、お客様が直面している課題とは何でしょうか？データベースワークロードでは、必要なパフォーマンスを達成するために、高いメモリと高いディスクスループットが要求されることは周知の事実です。また、これらのワークロードを制限するボトルネックは通常、CPUではなくメモリやディスクスループットであるため、CPU数への依存度は比較的低いことも分かっています。お客様が必要なメモリ量やディスクスループット量に基づいてインスタンスサイズを選択する際、そのインスタンスサイズにはデフォルトのCPU数が付随してきます。MicrosoftのSQL Serverライセンスは通常CPU数に基づいて課金されるため、このインスタンス上のCPUが過剰にプロビジョニングされてしまうのです。
このオーバープロビジョニングは、ライセンスコストにも反映される傾向があります。SQL Server Standard EditionとEnterprise Editionを比較した場合の、典型的なコスト分布、平均的なコスト分布を見てみましょう。 Standard EditionではWindowsを含むソフトウェアライセンスが、インスタンス全体のコストの約35%を占めています。右側のグラフはSQL Server Enterprise Editionのコストを示していますが、Enterprise Editionではソフトウェアコストがインスタンス全体のコストの実に82%を占めています。右側のハードウェアコストに対するソフトウェアコストの割合が高いのは、Enterprise Editionが非常に高価だからです。
では、SQL Serverの導入に推奨されるこれらのインスタンスの実際の金額を見てみましょう。 これらのインスタンスはすべて、CPUあたり8〜16ギガバイトのRAMという高いメモリ対CPU比率を持っており、8個のCPUを搭載した2xlargeインスタンスをベースにしています。グラフから分かるように、ローカルに接続されたストレージ、異なるメモリ、異なるIOPSなどの機能の利用可能性によってインスタンスファミリー間でハードウェアコストは異なりますが、ソフトウェアコストはCPU数に基づいているため同じままです。
Enterprise Editionの高いコストにより、 導入の総コストも大幅に高くなり、ハードウェアとソフトウェアのコスト比率も同様です。見ての通り、ソフトウェアコストはハードウェアと比べてインスタンスの総コストの5倍にもなります。これは実際にコスト削減の機会となります。では、先ほど議論したライセンスコストとハードウェアコストの差をどのように解決できるでしょうか？ これは、ライセンスがCPU数に直接紐付いているため、CPU数を減らすことでライセンスコストも削減できるということです。
より小さなインスタンスに移行するだけで済むと言えそうですが、実際にはそのメモリやIOPSは必要です - ワークロードはそれらに依存していますが、必ずしもCPUほどは必要としていません。そこで、 Optimize CPUsが活躍します。まず、仮想CPUであるハイパースレッディングを無効にすることができ、それだけでインスタンスのライセンスコストを50%削減できます。ハイパースレッディングを無効にしてもまだ追加のコアを無効にする余地がある場合は、Optimize CPUsでそれを行うことができます。ただし、SQL Serverには4コアの最小要件があり、Microsoftのライセンスでは最低4コアのインスタンスでSQL Serverを導入する必要があることに注意してください。
この re:Invent以前は、 Optimize CPUsはインスタンス作成時にのみ利用可能でした。インスタンスを作成する際に、CPU数を指定する機会がありました。しかし、多くのユーザーはインスタンスのスケールアップやダウン、あるいはインスタンスファミリーの変更が必要でした。そのためにはAMIを作成してディスクを作成するか、そのAMIからディスクを再接続し、セキュリティグループを変更する必要があり、非常に手間のかかるプロセスでした。おそらくそのため、多くのお客様がこの機能を使用していなかったと思われます。しかし、re:Inventの直前に、インスタンスのCPUオプションを動的に設定できる機能をリリースし、その簡単な使い方をご紹介したいと思います。ここでは、デフォルトで4個のCPUを持つR7iのxlargeインスタンスがあります。このインスタンスに接続して、 オペレーティングシステムから何が見えるかを確認してみましょう。 これにより、必要なソフトウェアライセンスの数が決まります。
Optimize CPUsの実装デモと動的CPU設定
Fleet Managerを通じたRemote Desktopを使用していますが、これは追加のソフトウェアを必要とせずにコンソールから直接インスタンスに接続できる優れたツールです。インスタンスにログインした後、Task Managerを開いてパフォーマンスを確認します。このインスタンスにはExtra Largeインスタンスとして想定通り4つのCPUがあり、32ギガバイトのRAMが搭載されていることがわかります。
では、同じインスタンスでSQL Serverが認識している内容を確認してみましょう。SQL Server Management Studioを開いて、CPUの構成を見てみます。そのインスタンスに接続し、システムストアドプロシージャを実行して、インスタンス上で定義されているプロセッサ数を確認します。想定通り、このインスタンスには4つのプロセッサがあります。
Cyber Mondayや、より多くのメモリ、より高速なCPU、より高いディスクスループットが必要な他のイベントのために、ワークロードをスケールする必要があるとしましょう。インスタンスを次のサイズにスケールアップします。インスタンスを停止した後、インスタンスタイプを変更します。現在Extra Largeで実行しているので、次のサイズは2XLargeになります。4コアと8 vCPUに移行しますが、ここでコツがあります：CPU optionsを指定することで、コアごとに1スレッドを指定してハイパースレッディングを無効にできます。これにより、4つのコアで4つのアクティブなCPUを得ることができます。
この設定は、インスタンスをスケールする際に変更できるほか、インスタンスサイズを変更せずに直接CPU optionsを変更することもできます。では、このインスタンスを起動して再度接続し、オペレーティングシステムの同じビューを確認してみましょう。再度インスタンスに接続してTask Managerを開き、パフォーマンスを確認すると、以前と同じように4つの仮想プロセッサがあることがわかります。ただし、RAMが以前の32ギガバイトから64ギガバイトに増えていることに注目してください。
これがWindowsサイドだけの話ではないことを、SQL Serverの観点から確認してみましょう。 同じシステムストアドプロシージャを実行してプロセッサ数を取得すると、以前と同じように4つのCPUが確認できます。このように、同じプロセッサ数を維持しながらSQL Serverをスケールすることができました。
これは、そのサーバーに必要なライセンス数に影響を与えることなくスケールできることを意味します。では、パフォーマンステストについて話を進めましょう。Alex、説明をお願いできますか？ ありがとうございます。素晴らしい説明でした。
Optimize CPUsのパフォーマンステストと結果分析
Optimize CPUsを使用してプロセッサー数を削減できますが、パフォーマンスには影響するのでしょうか？パフォーマンスに悪影響を与えることなくプロセッサー数を削減できるのでしょうか？パフォーマンスを得るためにインスタンスをアップグレードしたり、大きなインスタンスを選択したりしているわけですが、この質問に答えるには、パフォーマンステストを実施してお見せする以外に方法はありません。そうすることでのみ、Optimize CPUsがパフォーマンスに悪影響を与えるかどうかを証明できます。
お客様固有のワークロードを使用してパフォーマンステストを実行することはできないため、合成ベンチマークツールを使用する必要がありました。私たちは、あらゆるタイプのデータベースに対応した業界標準のベンチマークツールであるHammerDBを選択しました。HammerDBは2つのメトリクスでパフォーマンスを報告します：SQL ServerをPostgreSQLやMySQLなどの異なるデータベースと比較できる普遍的なメトリクスである新規注文数/分、もしくはトランザクション数/分です。今回は理解しやすく、また SQL Server同士の比較のみを行うため、トランザクション数/分を選択しました。HammerDBはOLTPとAPの2種類のワークロードをサポートしています。AWSのお客様の大多数がOLTPタイプのワークロードを使用しているため、私たちはOLTPを使用してテストを実行することにしました。
基本的なパラメータを選択したところで、HammerDBの具体的な設定について説明する必要があります。その1つがデータベースサイズです。HammerDBの用語では、データベースサイズはウェアハウスで測定され、各ウェアハウスは約100メガバイトのデータベース容量を割り当てます。では、データベースのサイズをどのように選択すべきでしょうか？データベースがメモリに完全に収まることは、すべてのデータベースの理想ですが、現実的な解決策とはいえません。そこで、私たちの目標は、利用可能なメモリ量を大幅に超えるようにデータベースサイズを設定することでした。テスト用に2つのデータベースを構築しました：大きなインスタンスをテストするための約8テラバイトの80,000ウェアハウス、そして小さなインスタンスをテストするための約3.5テラバイトの5,000ウェアハウスです。どちらの場合も、データベースサイズは利用可能なメモリ量を大幅に超えています。
最後に、Virtual Usersについて説明する必要があります。Virtual Usersとは、データベースにワークロードを送信する並列プロセスのことです。並列で実行されるVirtual Usersが多いほど、データベースにかかる負荷が大きくなります。一般的な観察から、Virtual Usersの数を増やすと、データベースが生成するトランザクション数/分のパフォーマンスは、ある一定のレベルまで増加し、その後成長が横ばいになって安定します。これは、そのシステムが提供できる最高のパフォーマンスに達したことを意味します。その時点を超えてVirtual Usersの数を増やすと、通常パフォーマンスは
レイテンシーが増加してシステムに過負荷がかかるため、パフォーマンスは低下し始めます。Virtual Userの数を変更した際のパフォーマンスの変化は通常ゆっくりと進むため、グラフでは一般的にVirtual Userの数を対数スケールで表示します。
では、この導入を踏まえて、実際の結果を見ていきましょう。 最初のテストでは、SQL Server向けの最高性能インスタンスの1つであるR6idn.32xlargeを使用しました。このインスタンスは1テラバイトのRAMを提供し、重要なポイントとして、ストレージアクセスの面で最高のパフォーマンスを発揮するインスタンスの1つで、ストレージに対して400,000 IOPSを提供します。このグラフでは2つのテストの結果を示しています。緑の線は、ネイティブインスタンスで達成された1分あたりのトランザクション数を表しており、すべてのvCPUが有効な場合と、Hyper-threadingを無効にした場合を示しています。つまり、CPU数が128から64に減少した場合です。
パフォーマンスはどうなったでしょうか？変化はありませんでした。2本の線を描くために、このグラフを大きなスケールに拡大する必要がありました。そうしないと、線が重なってしまい区別がつかないほどでした。このテストの詳細を見てみましょう。 Hyper-threadingを含む128 CPUから64 CPUに減少させました。当然、CPUの数が少なくなれば各CPUの負荷は増えるため、CPU使用率は上昇しました。しかし、1分あたりのトランザクション数には実質的な変化はありませんでした。見られるわずかな1パーセントポイントの差は、HammerDBが統計的なツールであるため、実験間で1〜2%の差が生じるのが一般的だということに関係しています。
最大インスタンスでは問題なく動作しましたが、ミッドティアのインスタンスに規模を縮小した場合はどうなるでしょうか。 R6idn.32xlargeから16xlargeに移行しました。これは前のインスタンスのちょうど半分のサイズで、RAMは1テラバイトから500ギガバイトに、CPU数も半分に、ストレージのスループットも半分になります。小さいインスタンスなので、より小さなデータベース（35,000ウェアハウス）を使用しました。当然、より少ないVirtual User数で飽和状態に達しましたが、ここでも同じシナリオが見られました - Hyper-threadingを無効にしても、インスタンスのパフォーマンスに変化はありませんでした。
同じ結果を表形式で確認してみましょう。 これらの結果から、R6idnでのHyper-threading無効化はパフォーマンスに影響を与えないことが分かりました。 しかし、他のインスタンスタイプでも同じ結果になるでしょうか？CPU最適化に対して異なる反応を示すかもしれません。AWSは多数のインスタンスファミリーを提供しており、各ファミリー内に複数のサイズがあり、合計で450以上の異なるインスタンスが存在します。もちろん、すべてをテストすることはできませんでした。そこで、まずいくつかの基準を適用してインスタンスを選択しました。
SQL Server のワークロードに推奨されるインスタンス、特にCPUあたりのメモリが多いメモリ最適化インスタンスを選択しました。それらのインスタンスの中から、SQL Serverのパフォーマンスにとって非常に重要なIOPSが、それぞれのファミリーで最も高いものを選びました。また、最新世代のインスタンスのみに絞り込むことにしました。 その結果、テストシナリオに4つの新しいファミリーを追加することになりました。各ファミリーの中から、最大サイズと中間サイズのインスタンスを選択しています。
各インスタンスについて、デフォルト設定での実験と、Hyper-threadingを無効にした実験の2つを実施し、16の追加テストを作成しました。これら4つのテストとR6idnを合わせることで、代表的な数のインスタンスとなりました。この表からわかるように、これらのインスタンスはすべて、R6idnには及びませんが、それでも意味のあるレベルのIOPSを提供しています。ただし、いずれもR6idnよりも多くのRAMを提供しているので、ワークロードがより多くのメモリから恩恵を受けると考えられる場合は、これらのインスタンスファミリーを検討すべきでしょう。
Hyper-threadingを無効にした場合も、同様のシナリオが見られます。これらは各ファミリーの最大インスタンスでHyper-threadingを無効にした結果です。パフォーマンスの変化は見られません。パフォーマンスが100%を超えるケースが1つありますが、これは各テストの統計的な性質によるもので、1～2%の変動は想定内です。これはHyper-threadingを無効にすることでパフォーマンスが向上したわけではなく、単に同じレベルを維持したということです。注目すべき点として、R6idnのCPU使用率が最も高くなっているのは、このインスタンスが他のインスタンスの250,000～260,000に対して400,000というIOPSを提供しているためです。CPUは入出力システムの容量に追いつくためにより懸命に働く必要があるのです。
次に、中間サイズのインスタンスで同じテストを行い、まったく同じシナリオが見られました。このテストセットでは、AMDプロセッサーをベースとしたR7aファミリーも含めました。R7aはHyper-threadingを提供していないため、すべてのコアがそのまま使用可能です。Hyper-threadingを無効にする代わりに、コアの半分を無効にしましたが、それでも同じパフォーマンスを示しました。これらの結果に励まされ、Hyper-threadingの影響を排除するためにR7aに焦点を当てて、CPUの最適化をどこまで進められるか、その限界を探ることにしました。
コア数を段階的に減らし、75%まで削減しました。最大インスタンスで192コアから48コアまで減らしたのです。
中規模インスタンスのコア数を96から24に削減しても、パフォーマンスに変化はありませんでした。その時点でCPU使用率が85-90%に達していたため、そこで止めました。これ以上コアを削減すると、CPUがボトルネックになることは明らかでした。典型的なOLTP SQL Serverワークロードにおいて、CPU数を75%削減してライセンスコストを75%カットしても、パフォーマンスに悪影響を与えないというのは、とても興味深い発見です。
コスト削減効果とOptimize CPUsの実装ベストプラクティス
では、コストに関する具体的な内容について、さらに詳しく見ていきましょう。ここからはRafaに引き継ぎたいと思います。ありがとうございます、Alex。Hyper-threadingやコアの無効化がパフォーマンスに影響を与えないことが分かりましたので、次はコスト削減効果について見ていきましょう。こちらは先ほどと同じSQL Server Standard Editionのチャートです。各バーは最適化前のインスタンスの総コストを表しています。SQL Serverのコストは約1,500ドルです。薄いピンク色の部分は、最適化されたCPUを使用することによるBYOLコストの削減額を示しています。Standard Editionの8 CPUのコストは約700ドルですが、この最適化されたCPUを使用することで50%のコスト削減が可能となり、350ドルまで下げることができます。結果として、インスタンスタイプに応じて、総コストを27%から16%削減できることになります。
次にEnterprise Editionについて見てみましょう。Enterprise Editionははるかに高価なため、コスト削減の機会も大きくなります。削減率は39%から30%の範囲に及びます。Standard Editionと同様に、Hyper-threadingを無効にすることでEnterprise Editionのコストも削減できます。この機能が実装される前は、ESXホストや専用ホストなどの物理コアマシンでEnterprise Editionを使用する場合にのみ、このような最適化が可能でした。そのマシンのすべてのコアにライセンスを適用し、SQL Serverワークロードを可能な限り効率的に配置して活用する必要がありました。
この新機能により、そのような手間は不要になりました。大きなボックスを用意して完全に活用することを心配する必要はありません。Standard Edition、Enterprise Edition、そしてSQL Serverの共有テナンシーやデフォルトテナンシーで使用できます。先ほどのスケーリングイベントのデモを見てみましょう。ここでは2xlインスタンスで実行されているSQL Serverがあり、そのインスタンスのコストは2,800ドルです。ユーザー数の増加によるパフォーマンス要件の変更や、インスタンスの負荷増加を見込んでスケーリングが必要になった場合、どうすればよいでしょうか？4xlにアップサイズすると、メモリとRAMが2倍になりますが、CPUも2倍になります。インスタンスの総コストは5,600ドルになります。
これまでの説明を踏まえると、本当にこれだけのコストが必要なのでしょうか？答えはノーです。最適化されたCPUを使用してHyper-threadingを無効にするか、コアを半分にすることで、総コストを抑えることができます。
ハードウェアとWindowsに対しては同じ金額を支払うことになりますが、最も高額な項目であるSQL Serverのコストは変わりません。これにより、インスタンスの総コストは3,400ドルとなります。特にワークロードをより大きなインスタンスサイズにスケールする際に、このメリットを実感していただけると思います。
ここで、ワークロードをスケールする際のベストプラクティスについてお話ししましょう。先ほど見てきたように、Optimize CPUsを実装すると、パフォーマンスに悪影響を与えることなく、総コストを約35%、SQL Serverのライセンスコストを50%削減できます。SQL Serverには4コアの最小要件があるため、それ以下にコアを無効化してもメリットは得られないことにご注意ください。インスタンスの総コストが削減されることで、サービスのコストも下がり、トランザクションあたりのコストも低減されます。
ワークロードをスケールする際に最も重要なライセンスコストをコントロールすることができます。明日すぐにすべてのコアでハイパースレッディングを無効にする必要はありませんが、スケールが必要になった時には、ハイパースレッディングを無効にすることでパフォーマンスとライセンスにどのような影響があるかを検討してみてください。私たちはお客様のデータを扱うことができないため、HammerDBを使用した合成ワークロードテストを実施していますが、非常に良い結果が得られています。
独自のロードテストツールをお持ちの場合は、それを使用してください。ロードテストツールをお持ちでない場合、トランザクションログに記録された本番環境のトラフィックを取得し、非本番環境で再生してロードをシミュレートし、環境のパフォーマンスを確認するトランザクショナルリプレイが有効です。Always Onでプライマリとセカンダリを構成している場合は、セカンダリ側でこの機能を実装し、フェイルオーバーして影響を確認し、インスタンスを再作成することなく簡単に変更を元に戻すことができます。コンソールでCPU設定を変更するだけです。
Alexとわたしがこの研究を行ったのは、何かを販売するためではなく、コスト削減を実現し、私たちの研究や顧客との取り組みで得た知見を共有するためです。この件に関していくつかのブログを書きました。その一つがOptimize CPUsのベストプラクティスです。Alex、あなたが主導したものですが、説明していただけますか？はい、実際にはより多くのテストシナリオ、チャート、図表が含まれています。パフォーマンスの変化に関する具体的な詳細を確認でき、また複数のインスタンスファミリーでハイパースレッディングの無効化に加えてコアの無効化についても、より多くの例を紹介しています。
もう1つのブログについてですが、スマートフォンでQRコードをスキャンしていただけます。これは、ワークロードをスケールする必要がある際に、Optimize CPUsの設定を維持する方法について解説しています。本日ご紹介した例についても触れています。ここで皆様からのご質問にお答えする時間を設けたいと思いますので、プレゼンテーションはここで終了し、直接お話しさせていただきたいと思います。本日はセッションにご参加いただき、誠にありがとうございました。こちらが私たちの連絡先となります。皆様のご意見とアンケートは私たちにとって非常に重要ですので、ぜひアンケートにご協力ください。後ほど皆様とお話しさせていただきます。ありがとうございました。より詳細な情報をご提供できるよう、良好なCSスコアを維持する必要がございますので、ご協力をお願いいたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion