🔦

Cloud SQLと比較したAlloyDBのパフォーマンス

2024/01/24に公開

今回はアクセンチュア株式会社テクノロジー コンサルティング本部 マネジャー Tsujikawa, Takayukiさんに2022/9に執筆いただいた記事をご紹介します。記事内容は執筆当時のものです。

https://www.accenture.com/jp-ja/blogs/technology-diaries/alloydb-performance-compared-to-cloud-sql


はじめに

テクノロジーコンサルティング本部の辻川です。

これまではGoogle CloudでRDBMSを利用する場合は、Cloud SQLやCloud Spannerが主な選択肢でした。これらのサービスの利用にあたり、Cloud SQLのメンテナンスタイムやCloud Spanner特有の設計など考慮しなければならないこともあり、利用を躊躇される方もいらっしゃるのではないかと思います。

本エントリーでは、Google CloudにおけるRDBMSの第三の選択肢として、2022年5月にGoogle I/Oで発表されたPostgreSQLと完全な互換性を持つAlloyDBをCloud SQLと性能の観点で比較しながら紹介します。

AlloyDBの特徴

高いスケーラビリティを備えた高性能なRDBMS

従来のPostgreSQLでは、コンピューティングリソースとストレージリソースをまとめて単一のマシンに配置していました。このような構成では、I/Oがボトルネックになったり、リードレプリカを利用したとしてもレプリケーションのラグが大きくなることがあり、スケーラビリティを充分に備えることが難しくなる場合があります。

AlloyDBはスケーラビリティやパフォーマンスを向上させるために、コンピューティングリソースとストレージを分離し、I/OをストレージレイヤーにオフロードすることでI/Oのボトルネックをなくし、高いスループットが実現できるように設計されています。また、AlloyDBを構成する、Primary(書き込み/読み取り用インスタンス)とRead Pool(読み取り専用インスタンス)でストレージが共有されているため、Read Poolへのレプリケーションも高速にできるようになっています。


図1:AlloyDBのアーキテクチャ概要

アーキテクチャの詳細については、Google Cloudの公式ブログで解説されていますので、興味のある方はこちらも参照いただければと思います。

SLAの向上

Cloud SQLでは、メンテナンス時間の調整はできるものの、Googleのメンテナンスによって定期的に数分程度のダウンタイムが発生します。メンテナンスによるダウンタイムを加味したCloud SQLのSLAは99.95%ですが、AlloyDBでは無停止でのメンテナンスに対応しており、SLAは99.99%に向上しています。

性能検証

AlloyDBは一般的なPostgreSQLと比較して、OLTPでは4倍以上の性能が出るとされています。実際にどの程度の性能差があるのかを確認するため、Cloud SQLとAlloyDBでベンチマークを取得しましたので、簡単に共有します。なお、具体的な数値についてはGoogle Cloudの規約上、触れることができないのでご了承ください。性能は環境や構成に依存ため、実際のワークロードに応じた検証を実施することを推奨します。

検証構成・計測方法

東京リージョンで、Cloud SQLとAlloyDBを構築し、HammerDBをインストールしたGCEをDBクライアントとして利用します。①プライマリインスタンスで書き込み/読み取りの双方のトランザクション処理する構成、②プライマリインスタンスで書き込みトランザクションを、レプリカで読み取りトランザクションを処理する構成の2パターンで、時間当たりに処理できるトランザクションや、トランザクションごとのレイテンシを計測します(HammerDBを利用して、RDBMSの一般的なOLTPのベンチマークの規格である、TPC-Cをベースにした計測)。
※サービス仕様上、Cloud SQLとAlloyDBでメモリサイズが異なっていますが、実際の測定においてAlloyDBのメモリ使用量は20GB程度であるため、メモリサイズの差異は性能には大きな影響は与えないと考えます。


図2:プライマリインスタンスで書き込み/読み取りの双方のトランザクション処理する構成(①)


図3:プライマリインスタンスで書き込みトランザクション、レプリカで読み取りトランザクションを処理する構成(②)

計測結果

性能

コンピューティングエンジンとストレージが分離され処理が最適化されていることに起因して、同様のスペックであってもAlloyDBがパフォーマンスに優れる結果となっています。また、書き込み処理方式の違いにより、書き込み処理で性能差が顕著に現れています。

利用料

執筆時点での東京リージョンにおけるCloud SQL/AlloyDBのオンデマンド利用料は以下のようになります(Cloud SQLはシングル構成)。双方のサービスで同量のリソースを利用した場合、AlloyDBの方が1.5倍程度コストがかかることになりますが、上記の性能測定の結果から、コストあたりの性能はCloud SQLよりAlloyDBが優れます。

まとめ

OLTPにおいては公表値通り、AlloyDBはCloud SQL(PostgreSQL)と比較して数倍程度性能に優れることが確認できています。AlloyDBは、Cloud SQLと同じように構築することができ、PostgreSQLと完全な互換性を持つので、Google Cloudで新規にRDBMSを利用する場合はAlloyDBは有力な選択肢になるかと思います。一方で、Cloud SQLではリードレプリカを別リージョンに配置することで、リージョンを跨いだ読み取り処理の分散やDR構成を取ることができますが、AlloyDB単体ではこのような構成は現時点では取り得ないので少し工夫が必要になります。続編では、このような観点を含む運用面に関する考え方や今回触れていないOLAPに関するご紹介ができればと思います。

参考
https://cloud.google.com/blog/ja/products/databases/alloydb-for-postgresql-intelligent-scalable-storage

https://cloud.google.com/compute/docs/tutorials/load-testing-sql-server-hammerdb?hl=ja

https://www.hammerdb.com/blog/uncategorized/hammerdb-v4-0-new-features-pt4-connect-pooling-for-clusters/

Accenture Japan (有志)

Discussion