こんにちは。クラウドエース編集部です。 はじめに 2023 年 7 月 13 日から新たに Enterprise と Enterprise Plus のエディションが 一般公開（以下、GA）となりました。 これらのエディションは、既存の Cloud SQL の機能を継承しつつ、さらなる拡張が施されています。 この記事では、ベンチマークテストツールである HammerDB と Sysbench を使用し、Cloud SQL Enterprise Plus（以降、Enterprise Plus と記載）に焦点をあてつつ、Amazon Aurora（以降、Aurora と記載）や Cloud SQL Enterprise（以降、Enterprise と記載）と性能を比較します。また、機能、運用コスト、そして具体的なユースケースにおける適用性についても評価します。 目次 Toggle はじめに検証環境構成や負荷テスト設定について最低でも 1.5 倍、最高で 3 倍以上の性能向上が見られました！ベンチマークテスト結果テスト結果から導くユースケース別 DB 選択まとめ ▼ Cloud SQL Editions の詳細はこちらの記事をチェック ▼ https://cloud-ace.jp/column/detail429/ 主な機能比較 スペック Enterprise Plus Enterprise Aurora データベース エンジン MySQL: 8.0 PostgreSQL: 15, 14 MySQL: 8.0, 5.7, 5.6 PostgreSQL: 15, 14, 13, 12, 11, 10, 9.6 MySQL: 8.0, 5.7 PostgreSQL: 15, 14, 13, 12, 11 コンピューティング 最大 128 vCPU 最大 864 GB コア:メモリ 1:8 (最大のみ 1:6.5) 最大 96 vCPU 最大 624 GB コア:メモリ 1:6.5 最大 128 vCPU 最大 1024 GB コア:メモリ 1:8 データキャッシュ 最大 9000 GB （ GA 時点では MySQL のみ） 非対応 最大 2560 GiB 可用性 SLA 99.99 % 99.95 % 99.99 % メンテナンスRTO 10 秒未満 60 秒未満 20~30 秒 PITR 保持期間 最大 35 日間 最大 7 日間 最大 35 日間 検証環境構成や負荷テスト設定について ベンチマーク環境構成 Enterprise、Enterprise Plus、Enterprise Plus（SSD）、Aurora のベンチマークテストを行いました。 Enterprise Plus はローカル SSD キャッシュの有無を選択できるため、SSD キャッシュ有りの構成と SSD キャッシュ無しの構成でそれぞれベンチマークテストを実施しました。 可能な限り公平な比較となるように、DB と VM のスペックは CPU・メモリが同等になるようにしました。（Enterpriseは 8 vCPU・64 GB メモリのインスタンスが無いため、8 vCPU・32 GB メモリのインスタンスを使用） また、テストを実行するクライアント VM は十分なスペックに設定し、いずれのケースでもクライアントの性能がテストのボトルネックにならないように配慮しています。 Enterprise Enterprise Plus Enterprise Plus （SSD） Aurora DB インスタンス クラス db-n1-highmem-8 db-perf-optimized-N-8 db-perf-optimized-N-8 db.r6i.2xlarge vCPU 8 vCPU 8 vCPU 8 vCPU 8 vCPU メモ 32 GB 64 GB 64 GB 64 GB SSD キャッシュ – – 375 GB – ネットワーク 帯域 16 Gbps 16 Gbps 16 Gbps 10,000 Mbps ゾーン asia-northeast1-a asia-northeast1-c asia-northeast1-c ap-northeast-1a エンジン MySQL 8.0.31 MySQL 8.0.31 MySQL 8.0.31 MySQL 8.0.26 VM インスタンス クラス e2-highcpu-8 e2-highcpu-8 e2-highcpu-8 c4.2xlarge vCPU 8 vCPU 8 vCPU 8 vCPU 8 vCPU メモリ 8 GB 8 GB 8 GB 15 GB ゾーン asia-northeast1-a asia-northeast1-c asia-northeast1-c ap-northeast-1a テスト設定 今回ベンチマーク実行用に、事前に変更したパラメータは以下となります。 データセットは 3 種類（小、中、大）用意しました。 これ以外で、選択したシェイプ・インスタンスタイプによって自動調整されるパラメータ値は原則そのままとしています。 HammerDB ベンチマーク種別 TPC-C テスト パラメータ vu 32 mysql_partition true warehouse* データサイズ 小：100 (100) 18.99 GB 中：25000 (25k) 172.35 GB 大：75000 (75k) 458.17 GB * warehouse：生成するデータベースのサイズ、括弧内は本検証結果における表記 Sysbench tables 4 threads 32 time 300 table-size * データサイズ 小：9000000 (8G) 36.75 GB 中：240000000 (200G) 212.37 GB 大：720000000 (600G) 628.73 GB * table-size：生成するデータベースの行数、括弧内は本検証結果における表記 最低でも 1.5 倍、最高で 3 倍以上の性能向上が見られました！ Enterprise Plus vs Enterprise 性能比較 以下のグラフは、HammerDB および Sysbench を使用して行われたベンチマークテストの結果です。それぞれテストを 10 回実施し、その中央値を取っています。 Enterprise の性能を 1 として、Enterprise、Enterprise Plus、Enterprise Plus（SSD）の各エディションと Aurora の性能比をグラフで示しました。 ここでは性能を測る指標として、HammerDB は TPM を、Sysbench は queries/s を採用しています。 HammerDB Enterprise を 1 とした相対値をグラフ化 Sysbench Enterprise を 1 とした相対値をグラフ化 Enterprise Plus が良好な性能を持っている事が見て取れます。 Enterprise Plus が搭載している新型のマシンと最適化されたワークロード、増設されたメモリが有効に働いているものと考えられます。 一方で、 SSD キャッシュの有無による大きな違いは見られませんでした。 ディスクの Read 処理がほぼ 0 になっているのですが、クエリ内容に大規模な Read が無いため速度に反映されにくかったと考えられます。 また、ところどころで SSD キャッシュが無い方が性能が良い結果が出ていますが、キャッシュが追加された分、書き込み先が増えることによる影響だと考えられます。 ▼右上のディスク Read のグラフを参照 どのようなケースで SSD キャッシュが有効なのか検証 これらのベンチマークテストでは、データベースインスタンスの DRAM に収まる大きさのデータしかクエリしていなかったため、SSD キャッシュの影響がなかったと仮説を立て、追加検証しました。 通常の OLTP とは異なる、より大規模なクエリを想定したテストを追加で実施しました。 DRAM 容量を超える大きさになるよう JOIN 句を多用して、巨大な一時テーブルが必要なクエリを用意して読み取り時間の計測を行いました。 中、大のデータセットに 9 種類のクエリをそれぞれ 10 回ずつ実行し、完了時間を測定しました。 以下のグラフは、大規模クエリテストの結果を集計し、Enterprise Plus の値を 1 とした相対値をグラフ化したものです。 数値が低いほど高速であることを意味します。（完了までの時間が短い） データサイズ：中 Enterprise Plus を 1 とした相対値をグラフ化 データサイズ：大 Enterprise Plus を 1 とした相対値をグラフ化 SSD キャッシュの優位性が確認できた テストの結果、DRAM に収まらない大規模なデータを扱う場合、明らかに SSD キャッシュの効果が確認できました。 データセットが大きいほど、SSD キャッシュ有りの場合のクエリ速度が向上しています。 特にデータサイズ：大の場合、SSD キャッシュありの環境はキャッシュ無しの環境と比べて約 1.27 倍のスピードでクエリを実行できています。 通常の OLTP 用途では SSD キャッシュのメリットは限定的ですが、大量のデータを扱う分析用途などでは存分に性能向上効果を発揮できそうです。 そもそも Enterprise Plus 自体の性能が高いため、小規模なクエリでは SSD キャッシュの影響は少ないものの、 大規模なクエリをするケースでは SSD キャッシュの使用によりさらにパフォーマンスを引き上げることができると考えられます。 Enterprise と Enterprise Plus の値段比は 約 1.3 倍ですが、大規模なクエリでは 2.5 倍以上のパフォーマンス向上の結果となり、Enterprise Plus のコストパフォーマンスの高さがうかがえる結果となりました。 ベンチマークテスト結果 HammerDB（TPM） HammerDB の TPC-C は、データベースのパフォーマンスを評価するためのベンチマークテストです。 TPC-C (Transaction Processing Performance Council Benchmark C) とは、業界標準のベンチマークで、オンライントランザクション処理（OLTP）システムのパフォーマンスを評価します。 下のグラフでは、TPM（Transactions Per Minute）、つまり 1 分あたりに処理されるトランザクションの数を計測し、比較しています。 TPMの値が大きいほど、データベースが高い負荷を処理できることを示し、低レイテンシと高スループットを意味します。 Enterprise を 1 とした相対値をグラフ化 Sysbench Sysbench は、シナリオに基づいてワークロードをカスタマイズし、ベンチマークテストを行うことができるツールです。 読み取り専用のクエリや書き込み専用のクエリ、混在したクエリなど、さまざまな条件でテストを実施できます。 OLTP DELETE データベースからランダムに選択した行を削除する操作をシミュレートすることで、DELETE の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP INSERT データベースに新しい行を挿入する操作をシミュレートすることで、データベースの挿入操作の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP POINT SELECT データベースから特定の行を選択する操作をシミュレートすることで、データベースの単一行選択の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP READ ONLY データベースからデータを読み取るだけの操作をシミュレートすることで、データベースの読み取り専用の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP READ WRITE データベースからデータを読み取り、書き込む操作をシミュレートすることで、データベースの読み書き性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP UPDATE INDEX データベースのインデックス付き列を更新する操作をシミュレートすることで、データベースのインデックス更新の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP UPDATE NON INDEX データベースの非インデックス列を更新する操作をシミュレートすることで、データベースの非インデックス更新の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 OLTP WRITE ONLY データベースにデータを書き込むだけの操作をシミュレートすることで、データベースの書き込み専用の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 SELECT RANDOM POINTS データベースからランダムに行を選択する操作をシミュレートすることで、データベースのランダム選択の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 SELECT RANDOM RANGES データベースからランダムな範囲の行を選択する操作をシミュレートすることで、データベースの範囲選択の性能を確認できます。 Enterprise を 1 とした相対値をグラフ化 テスト結果から導くユースケース別 DB 選択 今回のベンチマークテスト結果から、以下のユースケース別 DB 選択が考えられます。 より高い性能が求められるアプリケーション => Enterprise Plus Enterprise Plus は、従来の Cloud SQL の性能では十分対応できなかった高負荷のアプリケーションに対応できます。例えば、大量のリアルタイムデータを処理したり、高度な分析を行うアプリケーションなどに対する適用が考えられます。 また、大規模なクエリが想定されるハードなワークロードに対応するために SSD キャッシュを活用したい場合も、Enterprise Plus が適切です。 より高い可用性が必要なアプリケーション => Enterprise Plus Enterprise Plus は 99.99% の SLA を提供し、計画メンテナンス中のダウンタイムも 10 秒未満に抑えられます。24 時間 365 日稼働する場合や、ダウンタイムによるビジネスへの影響を最小限に抑える必要がある場合に最適です。 MySQL の移行先として => Enterprise Plus、Enterprise MySQL との完全な互換性を持っているため、既存の MySQL データベースをスムーズに移行し、運用することが可能です。 これまでの、Google Cloud におけるRDBMS の選択肢は、Cloud SQL、AlloyDB、Spannerの3つでした。しかし、 AlloyDB や Spanner は MySQL との互換性がなく、基本的には Cloud SQL for MySQL を選択する必要がございます。 Enterprise Plus という選択肢が増えたことで、これまで性能やメンテナンス時間の非機能要件が厳しく採用しづらかったユースケースにも適用可能になっています。 PostgreSQL の移行先として => Enterprise Plus、AlloyDB AlloyDB は BigQuery Federation をサポートしていないため、PostgreSQL の移行を検討しているお客様の中には、この点で移行を躊躇している方も多いでしょう。一方で、Cloud SQL は BigQuery Federation に対応しており、従来の Cloud SQL では対応できなかった一部の要件も、Enterprise Plus では十分に満たせることから、PostgreSQL の移行先として優れた選択肢となります。 BigQuery Federation を利用しない場合、AlloyDB が適切な選択肢となります。 まとめ 本記事では、Cloud SQL に新たに登場した Enterprise と Enterprise Plus のベンチマークを比較しました。 HammerDB および Sysbench を使用して行われたベンチマークテストでは、従来の Enterpriseと比較して 最低でも 1.5 倍、最高で 3 倍以上の性能向上が見られました。 性能比較やコスト比較の結果、基本的には Enterprise Plus を選択し、要件に応じて AlloyDB や Cloud Spanner、Enterprise を選ぶのがいいと感じました。 クラウドエースは、お客様一社一社のビジネス要件を理解し、ニーズに合った最適なクラウドソリューションをご提案しております。 Google Cloud をご検討中でしたら下記よりお問い合わせいただけましたら幸いです。 クラウドエースへのお問い合わせはこちら また、こちらより AWS、Microsoft Azure、Google Cloud の比較表もダウンロードできますので、ご活用いただけましたら幸いです。 ▼ダウンロード資料▼ 『3大クラウドプラットフォーム比較表（Amazon・Microsoft・Google）2023.07 ver』 ※Google Cloud 及び Cloud Spanner、BigQuery は Google LLC の商標です。
