Amazon Web Services ブログ
AWS Graviton3 で Amazon RDS を稼働: ベンチマーク
AWS は 2023年4月に Amazon Relational Database Service (Amazon RDS) で AWS Graviton3 プロセッサを搭載したインスタンスを発表しました。AWS Graviton3 は2022年5月に発表されています。ARM Neoverse コアを使用したカスタム設計のARMアーキテクチャを使用して構築されており、高パフォーマンスと高いエネルギー効率の実現のために最適化されています。AWS Graviton3 は、Graviton2 と比較して最大 25% 優れたコンピュート性能を提供します。
お客様からAmazon RDS のワークロードを AWS Graviton3 への移行を検討される際に一般的なリレーショナルデータベース管理システム(RDBMS)のワークロードにおいて、AWS Graviton2 よりも優れたパフォーマンスを実現できるのかという質問が多く寄せられます。
この投稿では、 Amazon RDS によってサポートされているオープンソースデータベースエンジンにおいて AWS Graviton2 とAWS Graviton3 インスタンスのパフォーマンスの比較や、データベースを中心とした観点で検証します。ベンチマーク時の構成例では、RDS でオープンソースデータベースを使用する際に Graviton2 ベースのインスタンスに対して、AWS Graviton3 のインスタンスは最大 27 ％ コストパフォーマンスが改善 (オンデマンド価格ベース) が得られることが示されています。
概要
Amazon RDS で実行したベンチマークとしては、記事投稿時点での AWS Graviton がサポートされているエンジンの最新バージョンを使用して実施しました。ベンチマークは eu-west-1 リージョンにて、 AWS Graviton2 と AWS Graviton3 プロセッサを使用するそれぞれのインスタンスタイプ(m6g・m7g)を使用し行っています。そして、データベースインスタンス毎のベンチマーク結果を比較しています。
このテストで使用するデータベースエンジン及びバージョンとしては、Amazon RDS for MySQL 8.0.32, Amazon RDS for PostgreSQL 15.2, Amazon RDS for MariaDB 10.6.10 を用いており、以下のインスタンスタイプを用います。
| db.m6g.xlarge (AWS Graviton2) | db.m7g.xlarge (AWS Graviton3) | |
| vCPU | 4 | 4 |
| Memory (GiB) | 16 | 16 |
ベンチマークとテストフレームワーク
ベンチマークは sysbench を使用し、ベンチマーク結果を収集します。 sysbench は LuaJIT がベースとなっているオープンソースツールです。マルチスレッドでの実行やスクリプトで操作が可能であり、主としては OLTP データベースへのベンチマークシナリオがこのツールで提供されています。
Amazon Elastic Compute Cloud (Amazon EC2) インスタンス (m6g.4xlarge) でテストセッションを起動します。ネットワーク帯域幅、 CPU やメモリに関連する潜在的なボトルネックを避けること目的に4xlarge インスタンスを選択しています。また、レイテンシ最小化のために、全インスタンスは同一アベイラビリティゾーンで稼働させています。ベンチマーク環境はイメージは以下の図のようになります。
上記ベンチマーク環境のセットアップは手動で作成可能ですが、こちらで公開している AWS CloudFormation テンプレートを使用し作成できます。
sysbenchが提供する組み込みのテスト準備機能を用いて、各々が 200 万レコードを持つ 2 つのテーブルを作成しています。MySQL と MariaDB のインスタンスでは以下のスクリプトを実行しています：
PostgreSQL インスタンスでは以下を実行しています:
RDS インスタンスのセットアップ
次にベンチマークが実行する RDS インスタンスのセットアップを行います。各エンジンに対して、1つのdb.m6g または m7g.xlarge インスタンスを作成しました。これらは、1つはAWS Graviton2 ( db.m6g.xlarge 用)、1つは AWS Graviton3用 ( db.m7g.xlarge 用)です。
設定は基本的にデフォルト値を使用しておりますが、例外的に以下の変更を加えています：
- EC2 インスタンスと同一アベイラビリティゾーンで起動させ、レイテンシを最小限に抑制
- Single-AZ構成
- Amazon Elastic Block Store (AmazonEBS) io1 ボリュームの IOPS とストレージ容量は、10,000 IOPSと200 GBを選択。これは、EBS ストレージによるパフォーマンスボトルネックの回避を目的としております。なお、ストレージ容量である 200 GB は 10,000 IOPS を得るのに必要最小限なストレージ容量です。
max_prepared_stmt_countパラメータを MySQL および MariaDB エンジンで許容される最大値に設定。更新方法の詳細については、「How do I modify the values of an Amazon RDS DB parameter group?」を参照ください。この設定により、sysbench は必要な数のスレッドを起動可能になります。
ベンチマークテスト
テストは 30分間連続実行しています。テスト中はデータベースの CPU 使用率を 99％ 以上に維持させることを目的に、 2 つのテーブルと 200 万レコードに対して 300 スレッドを実行するように sysbench のコマンドを実行しています。
デフォルトの sysbench 動作モードを使用しており、テスト時間が終了するまで次のような内容のクエリを繰り返し実行しています： 5 つの SELECT クエリ、2 つの UPDATE クエリ、1 つの DELETE クエリ、1 つの INSERT クエリ。
MySQL 及び MariaDBのインスタンスでは以下のスクリプトを実行しています：
PostgreSQL インスタンスでは以下のスクリプトを実行しています:
一貫したベンチマーク結果を得るために、テストスクリプトを 5 回実行しています。
パフォーマンス結果
AWS Graviton3 ベースのインスタンス (db.m7g)は、すべてのテストにおいて AWS Graviton2 ベースのインスタンスより優れたパフォーマンスを示しています。db.m7g インスタンスは db.m6gより １秒当たり平均 29% 多くクエリを実行しています。その結果として、RDBMS エンジン毎に改善度合いは異なるものの、db.m7g は db.m6g の結果に比べて 19% から 34% の改善が見られています。
レイテンシテストでも同様の傾向が見られており、db.m7g は db.m6g に比べて平均26%の削減された結果となっています。 db.m7g と db.m6g を、エンジン別の結果を元に比較すると、MariaDB で 34%、MySQL で 29%、PostgreSQL で 19% のレイテンシ削減が見られています。
ドルあたりのパフォーマンス
AWS Graviton3 ベースのインスタンスは、AWS Graviton2 ベースのインスタンスと価格が異なります。そのため、価格を考慮した際のパフォーマンスがどうなるかを確認してみます。以下の表は、翻訳元記事執筆時点( 2023 年 11 月 1 日)の eu-west-1 リージョンでの RDS Single-AZ 構成時の価格です。
| DB エンジン | インスタンスタイプ | 1時間あたりの料金 (USD) |
| MariaDB | db.m6g.xlarge (AWS Graviton2) | 0.336 |
| MariaDB | db.m7g.xlarge (AWS Graviton3) | 0.372 |
| MySQL | db.m6g.xlarge (AWS Graviton2) | 0.336 |
| MySQL | db.m7g.xlarge (AWS Graviton3) | 0.372 |
| PostgreSQL | db.m6g.xlarge (AWS Graviton2) | 0.352 |
| PostgreSQL | db.m7g.xlarge (AWS Graviton3) | 0.372 |
公平にドルあたりのパフォーマンスベンチマークを実施するために、テスト結果を時間あたりの価格に正規化しました。 db.m6g の正規化結果としては、db.m6g の価格が安価なこともあり db.m7g インスタンスに近い結果となっています。しかしながら、db.m7g は db.m6gより平均 22 % 多くクエリを実行しており、db.m6g のコストパフォーマンス面での優位性は、MariaDBでは27%に達しています。
また、 db.m7g は、db.m6g よりレイテンシが 20 ％ 短縮されており、ドルあたりのレイテンシが最も低くなっています。
クリーンアップ
テスト後は、ベンチマーク結果を保存し、作成したリソースを削除します。 CloudFormation テンプレートを使用している場合は、 AWS Console で CloudFormation に移動し、本記事で紹介しているテンプレートから作成したスタックを選択し、Delete を選択します。
最後に
RDBMS ワークロードを実行する際に Amazon RDS を採用する場合、数多くのインスタンスタイプから選択することができ、その提供範囲は年々拡大しています。
Graviton3 ベースの RDS インスタンスは、オープンソースデータベースのデータベースエンジン、バージョンおよびワークロードに応じて Graviton2 ベースのインスタンス比で、最大30％の性能向上と最大27％のコストパフォーマンス(オンデマンド価格)を提供します。
db.m7g および db.r7g データベースインスタンスは、Amazon RDS for PostgreSQL バージョン 15.2 以降、 14.3 以降、 13.4 以降、Amazon RDS for MySQL バージョン 8.0.28 以降、 Amazon RDS for MariaDB バージョン 10.11.4 以降、 10.6.10 以降、 10.5.17 以降、 10.4.26 以降でサポートされています。これらのデータベースインスタンスは現在、次のリージョンの Amazon RDS で利用可能です。米国東部(バージニア北部、オハイオ)、米国西部(オレゴン州)、アジア太平洋(ムンバイ、シンガポール、シドニー、東京)、ヨーロッパ(フランクフルト、アイルランド)。Amazon RDSの価格と提供地域については、Amazon RDSの料金ページをご覧ください。
Amazon RDS を始めましょう。
この記事はアマゾン ウェブ サービス ジャパンの畠泰三が翻訳を担当しました。 (オリジナルはこちら)
著者について
Davide Coccia は Amazon Web Services のテクニカルアカウントマネージャーとして、AWS 上でセキュアで弾力性があり、コスト効率の高いワークロードの構築、デプロイ及び実行への支援に従事しています。彼はアナリティクスコンサルティングのバックグラウンドを持っています。仕事以外では、ランニング、フットボール(サッカー)や、日々新たなことを熱心に学習しています。
Stefano D’Alessio は Amazon Web Services のテクニカルアカウントマネージャーで、リレーショナルデータベースサービス ( Amazon RDS と Aurora )を担当しています。ベストプラクティスとイノベーションを活用し、AWS でのワークロードに関するガイダンスや提案をお客様と一緒に実施しています。仕事以外では、ランニング、テニス、パデルを楽しんでいます。
Francesco Martini は Amazon Web Services のテクニカルアカウントマネージャーです。彼は AWS のお客様が信頼性が高くコスト効率の高いシステムを構築し、AWS 上で実行するワークロードの優秀な運用を達成することを支援しています。また、フルスタック開発者としての経歴を持つビルダーであり、テクノロジー愛好家でもあります。スポーツ全般、特にサッカーとテニスに熱中しています。