Aiven for PostgreSQL® 13 performance on GCP, AWS and Azure [Benchmark]の翻訳です。
2021年9月16日
GCP、AWS、Azureにおける# Aiven for PostgreSQL® 13のパフォーマンス[ベンチマーク
AWS、GCP、MS Azure上でのAiven for PostgreSQLの最新のベンチマーク数値へようこそ。Aivenのサービスがクラウド上でどのようなパフォーマンスを発揮するのかをご確認ください。
Aivenでは、2016年からさまざまなPostgreSQLクラウドパフォーマンスベンチマークを実施してきました。今回の更新では、Amazon Web Services（AWS）、Google Cloud Platform（GCP）、Microsoft Azureの4つのベンチマークで、PostgreSQL 13.4の書き込みパフォーマンス指標を比較しました。
4つのベンチマークでは、以下の4つのAiven managed PostgreSQLプラン構成のそれぞれで、AWS、GCP、Azure上で動作するPostgreSQL 13.4のパフォーマンスを測定し、比較しました：
メソッド
パフォーマンスを調べるため、ノードを垂直方向にスケールアップしながら、1秒あたりのデータベース・トランザクション数を計測した。この方法では、ノードの数は変わらないが、各ノードのCPU、RAM、ストレージの量は増加した。
pgbenchを使用して負荷を生成し、同じクラウドとリージョンの別のVM上で実行した。各プランの負荷生成コマンドは以下の通り：
pgbench --client=<startup_plan> --jobs=2 --report-latencies --time=3600 --log --aggregate-interval=1 keepalives='1' keepalives_count='12' keepalives_idle='180' keepalives_interval='10' sslmode='require'``Copy to clipboard
テストする起動プランの変数は--clientスイッチであった。4つのスタートアッププランの値は、十分に説明できるように、4、16、32、64であった。
使用したロードジェネレーターのインスタンスタイプは以下の通りである：
- AWS: m4.large
- GCP: n2d-standard-2
- Azure: standard_DS2
本番環境のPostgreSQL（PG）セットアップと同様に、PGを実行するローカルSSDは、WALアーカイブを有効にしてLUKSフルディスク暗号化を使用した。テスト対象のPGインスタンスは以下のように初期化された（ここでは接続パラメータなしで表示）：
`$ pgbench --initialize --scale=<scale> --quiet keepalives='1' keepalives_count='12' keepalives_idle='180' keepalives_interval='10' sslmode='require'`Copy to clipboard
scaleパラメータは、各プランに対応するように調整した。この場合、DBサイズはRAMサイズのおよそ2倍で、500、1500、2500、4500の値が可能だった。
この場合、DBサイズはRAMサイズのほぼ2倍で、500、1500、2500、4500の値が可能である。ベンチマークにおけるレイテンシーの変動の影響を最小限に抑えるため、各プロバイダーには同等の中央ヨーロッパ地域を使用した：
- AWS: eu-central-1
- GCP: europe-west3
AWS: eu-central-1 * GCP: europe-west3 * Azure: germany-westcentral (* westeurope; 下記結果参照)
最後に、公開されている価格情報に従って、PGプランごとの平均mTPS/$を計算し、ベンチマークを終了しました。
トランザクション/秒
Aiven Startup-4 プラン
スタートアップ-16計画
スタートアップ32計画
スタートアップ64の計画
ドイツ-西中央リージョンのAzure上のstartup-64プランでは、パフォーマンスが異常に低かった。Westeuropeで同じテストを行ったところ、インスタンスタイプはstandard_l8s_v2で、CPUコアは少なかったが、RAMは多かった。
mTPS/$ 平均サービスプランサイズあたり
パフォーマンス値は、各クラウド・プロバイダーについて、1 ドル当たり毎秒何百万トランザク ションの平均値（mTPS/$）として計算した。
全体として、クラウド・プロバイダー間のパフォーマンス／コストの差は、かなり大幅にグーグルに有利であることがわかった。前回と同様、Startup-4 プランは例外であった：
まとめ
PostgreSQLの性能には、リージョン間のレイテンシの違いなど多くの要因が影響しますが、このベンチマークでは区別しませんでした。また、考慮すべきもう1つの要因として、作業負荷の大きさのばらつきがあります。このベンチマークの基本的な考え方は、多数の並列クライアント接続を使用することで、テストしたサービスに大きな負荷を発生させることでした。
スタンドアロンのPostgreSQLユーザには、性能のボトルネックを特定し、データベース構成、ワークロード、ハードウェア構成を最適化するように調整することを常に推奨しています。しかし、私たちのマネージドPostgreSQLサービスでは、PostgreSQLシステムパラメータは典型的なワークロードのためにあらかじめ設定されています。
また、独自のベンチマークを実行することをお勧めします。同様のパフォーマンステストを簡単に繰り返すことができるTerraformベンチマークスクリプトを近日公開する予定です。
近いうちにこのようなベンチマークをさらに公開する予定ですので、ご期待ください！
次のステップ
次のステップとして、Aiven for PostgreSQLをチェックしてみてください。
まだAivenのサービスをご利用でない方は、https://console.aiven.io/signupから無料トライアルにお申し込みください！
それまでは、changelogとblogのRSSフィード、またはLinkedInとTwitterのアカウントをフォローして、製品や機能関連の最新情報をご確認ください。