Google CloudのAlloyDB for PostgreSQLを性能検証してみた

はじめに

Google Cloudから新しくリリースされるDB、AlloyDB for PostgreSQLについてスパイクリクエストを与え性能を検証をしてみた記事になります。
また単体検証だけでなく、他サービスとの比較検証を実施しました。

AlloyDB for PostgreSQLとは

「AlloyDB for PostgreSQL」（以下、AlloyDB）は、Google Cloudで新たにリリースされたデータベースサービスです。

AlloyDB は、業界トップのパフォーマンス、可用性、スケーラビリティを備えた、フルマネージド PostgreSQL 互換データベース サービスです。
（中略）
AlloyDB は標準の PostgreSQL の 4 倍以上の速度です。高いトランザクション スループット、大きなデータサイズ、複数のリードレプリカなど、最も要求の厳しいエンタープライズ ワークロードに適しています。読み取り接続は、低レイテンシのスケールアウト リードレプリカ プールによって水平スケーリングされます。　AlloyDB for PostgreSQL

検証実施条件

それぞれの製品の性質上、共通する項目が無い部分は「-」としています。

項目	AlloyDB	他サービス
クラスタタイプ	高可用性（読み取りプールあり）を指定 その他の選択肢：高可用性	-
Database	PostgreSQL 14 互換	PostgreSQL 14.3 互換
リージョン	asia-northeast-1（東京）	-
読み取りプールインスタンス	ワークロードを分割する必要がないため、追加なし	-

テーブル定義

テーブル名：test_1

カラム名	型	デフォルト値	制約	主キー
id	BIGSERIAL	-	-	o
hash	UUID	uuid_generate_4()	-
val	BIGINT	-	NOT NULL
txt	TEXT	NULL	-
created_at	TIMESTAMP	current_timestamp	NOT NULL
updated_at	TIMESTAMP	current_timestamp	NOT NULL

※ update_atには自動更新するトリガーを設定しています

データ件数

1,000,000レコードを登録する想定です。

検証内容

Locustを使った下記クエリの一定時間実行時のパフォーマンスをAlloyDB/他サービスで比較する

1. Databaseに直接接続し、create table文でtest_1テーブルを作成する
2. Locustにてinsert文を10分程度実行してパフォーマンス、登録件数等を計測する。
   
   INSERT INTO test_1 (val) VALUES ({rnd});
3. test_1テーブルにレコードを1,000,000件登録し、Locustにてselect文を10分程度実行してパフォーマンスを計測する（INDEXでSELECT）
   
   SELECT * FROM test_1 WHERE id={rnd};
4. Locustにてupdate文を7分程度実行してパフォーマンスを計測する（INDEXでUPDATE）
   
   UPDATE FROM SET txt='update-test' WHERE id={rnd};

※ {rnd}はunixtimestamp/100や1-10,000など範囲指定の数など対象クエリによって変更する。

検証環境

負荷試験ツールは、Locustを使用します。

Master/Worker構成にし、秒間100ユーザずつ追加し最終的に10,000ユーザを生成する設定
リクエスト間のwait_timeは0に設定します。

・Google Cloud環境
GKEクラスターにLocustのサービスを追加
クラスターはAutoPilotモードを指定し、リソースは4vcpu相当をリクエストするよう設定
デプロイメントのレプリカセットを16に指定してWorkerを拡張

検証結果

Insertの実行結果

実施時間：10分間

結果：
開始から6分ほどは、両者とも同程度のRPS(=Request per Second)で、エラーを除外すると基本的に他サービスの方が安定していましたが、時間経過とともに高負荷になると他サービスのレスポンスタイムのブレが発生してきました。反対に、AlloyDBは高負荷になればなるほど安定し始め、今回のテストでは平均RPS、リクエスト数、登録レコード数ともに他サービスより上回りました。

Index Selectの実行結果

実施時間：10分間

結果：
数値や推移の傾向はほとんど同じでしたが、わずかながらRPS、リクエスト数共に他サービスの方が高く平均レスポンスタイムも速いという結果になり、Insertや後述のUpdateとは異なる傾向となりました。DBのCPU使用率はどちらも100%近くに張り付いていました。

Index Updateの実行結果

実施時間：7分間

結果：
開始3分程度まではどちらも安定して同程度のRPSを出していましたが、3分以降は、AlloyDBはRPSが変わらず安定している一方で、他サービスは極端なブレが出始め、不安定になっていきました。

まとめ

他サービスは、負荷が少ない場合のレスポンスタイムは良い傾向があるが、ブレが大きい傾向があるのに比べ、
AlloyDBは、低負荷の場合は他サービスよりもレスポンスが悪い様に見えるが、ブレが少なく安定している傾向があると分かりました。
AlloyDBに関しては、DBのコネクション数のエラーがあり、そこをもっとあげればエラーなく捌いた可能性もあります。

今回は中程度のインスタンスタイプで行いましたが、さらに負荷を上げるとまた違った結果が出るかもしれないです。