コンテンツに移動
データベース

AlloyDB のベンチマークと実施方法

2023年6月8日
https://storage.googleapis.com/gweb-cloudblog-publish/images/databases_2022.max-2500x2500.jpg
Google Cloud Japan Team

※この投稿は米国時間 2023 年 5 月 25 日に、Google Cloud blog に投稿されたものの抄訳です。

何度か、AlloyDB を他の Postgres デプロイ(オンプレミスやその他のクラウド環境のデプロイ)と比較するパフォーマンス テストに関する話題を目にしたり、そのような会話に加わることがありました。一部のテストは、ジェレミー クラークソン氏が自動車番組「トップ ギア」のシーズン 12 で行った「Sensible Fiesta Test(フォード フィエスタによる過酷な走行テスト)」に近いように思えます。彼は「そのようなテストを実現できるでしょうか」という問いかけに対して、「1 万 1,000 ポンドのお金を持っていれば間違いなくできるだろうけど、40 ペンスしかない場合には難しいだろうね」と言いました。この課題に対する他のテストや結果はすべて(おそらくすべて)、等しく無価値です。

この自動車番組のエピソードを思い出した理由

テストがどのようなものであれ、その結果を定量化して結論と意思決定につながる目標と指標がなくてはなりません。たとえば、ジャガイモ 1 袋を 40 マイル運搬できるか確認することで、車の有用性をテストしている農家を想像してみましょう。フィアット 500 のように小さな車であっても、フォード F150 トラックと同じタスクを、はるかに低費用で行えるでしょう。これはつまり、すべてのトラックを捨ててしまい、街乗り用の小型車と入れ替えるべきということでしょうか。答えはもちろん「ノー」です。

そうであれば、大型 32 GB 4 コア CPU Postgres のパフォーマンスをテストするために、デフォルトでスケール 1 データセットを持つ pgbench(サイズにして約 24 MB)を使用するのはなぜでしょうか。そして、類似する仕様の AlloyDB に対しても同様のテストを行い、双方がパフォーマンスに明らかな差を生じることなく 24 MB データセットを処理できると結論づけます。この結論は適切だと思いますか。そのとおりです。ではこの結論は役に立つものであり、価値あるものでしょうか。24 MB のデータセットに対して 32 GB 4 コア CPU のサーバーを使用できるか確認したい場合を除けば、おそらくそこまでの価値はないでしょう。

ベンチマーク テストへの適切なアプローチ

では、テストに対してどのようなアプローチであれば適正といえるのでしょうか。これは重要な問いですが、その答えは、皆様も想像のとおり、「状況次第」ということになります。実際のデータと実際のワークロードを使用して行うパフォーマンス テストが最適だということは予測できます。ですが、そのようなテストが常に実現可能なわけではなく、初期段階においてデータベース デプロイのパフォーマンスを別のデプロイのそれと比較したい場合もあるでしょう。普遍的な解決策というものはありませんが、理にかなった方法がいくつか存在します。そのうちの一つを見てみましょう。以下が各段階の概要です。

  • 目標を定義する。対象の環境が、現在の実装環境と同じかより大きな最大負荷に耐えられるのかを確認したいのでしょうか。あるいは、最低限の CPU とメモリを持つシステムで特定のワークロード パラメータを実現するのが目標でしょうか。

  • 目標と現在のシステムにおけるワークロードに基づいて、ベンチマーク テストに関する要件を整備する。ワークロードは OLTP、分析、あるいはその両方を使用できます。これは、将来行う評価で役立ちます。

  • 出力の測定とテストの合否を評価するために重要な指標を特定する。たとえば、毎秒のトランザクションや最長レイテンシなどの条件が挙げられます。

  • ベンチマークに適切なツールを選択する。理想通りのツールでないにしても、目的に沿い、客観的な結果を得られるものでなければなりません。正しく使用するのであれば、標準の pgbench で問題ないかもしれません。ただし、そこは目標と測定対象次第ではあります。

  • CPU、メモリ、ストレージなど、ベースラインとなるシステムのパラメータを選択する。そのようなシステムとしては、オンプレミスのデータベース サーバーやマネージド サービス型プラットフォームが挙げられます。これらが単一のサーバー インストールに限定されないように、ここではシステムと呼ぶこととしましょう。

  • ベンチマーク ツールを搭載したクライアント マシンがベースライン環境と対象の環境で同じ構成と容量を備えており、ネットワーク トポロジが同等であることを確認する。これらが適切でないと、ある種のテストでネットワーク オーバーヘッドが著しく大きくなり、結果の比較が困難になります。

  • システム パラメータに応じて、適切なサイズのデータセットを作成する。

  • 重要な指標の最大値が得られるまでベースラインとなるシステムに対する負荷を段階的に増やしながら、テストを実施する。たとえば、最大スループットまたは規定値以下のレイテンシを伴う最大スループットなどが挙げられます。

  • 信頼性が高く再現性のある結果を得るのに十分なテスト時間であること。短期的な要因によって結果に齟齬が生じる可能性があるため、テストを 5 分間だけ実施するのでは不十分です。

  • ベンチマークを数回繰り返して信頼性の高い結果を得る。

  • 比較したいシステムで同じシーケンスを実行する。

テスト条件は、ベースラインに対する元の条件や適正な比較を行うために計画された実装のそれに近いものである必要があります。条件と影響については後で説明しますが、適切なアプローチによってテストに取り組む重要性について、ここで再度強調しておきます。

データベース インスタンスの内容

先に進む前に、データベース内で行われるデータ処理について全体像を把握しましょう。深掘りせず一般的に考えると、データベースの 1 ページまたは 1 ブロックに存在するデータは、生成されてから削除されるまでその生涯をメモリの中で送ります。これは少し単純すぎるアプローチですが、一般的に、変更を加える際にはブロックをメモリにコピーする必要があります。また、有効なトランザクション ログを持つリレーショナル データベースでは、あらゆる変更はデータブロックに確定される前にログへ書き込まれます。そして、新規データを持つブロックのバージョンが最終的にディスクに返され、古いブロックのバージョンと置き換えられます。これは、すべてのブロック バージョンがメモリから消えるというわけではありません。データベース インスタンスはキャッシュを保持します。キャッシュには、不必要な入出力を減らすために最近使用したブロックが格納されています。キャッシュのサイズや構成はデータベース エンジンにより異なります。標準の Postgres の場合は、共有メモリにバッファ キャッシュがあり、それにファイルシステム キャッシュが続きます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image2_OHeJuzC.max-700x700.max-700x700.png

ストレージ レイヤに潜むコンセプトの違いがあるため、AlloyDB キャッシュはもう少し複雑です。ですが、ブロックが共有バッファにある場合、全プロセスを通してアクセス可能となるでしょう。

では、データを操作するクライアント セッションでレコードを更新する場合、そのセッションはどのようなものになるでしょうか。セッションのサーバー プロセスでは、バッファに存在するブロックに関して実際のバージョンのコピーを取得し、トランザクション ログへの変更を記録して、ブロック内で必要な変更を行い、変更完了をマークします。また、キャッシュが関わる処理以外に目を向けると、主に CPU のアクティビティが占めています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_HTDzEV3.max-600x600.max-600x600.png

このブログの範囲外になるので、AlloyDB データベース エンジンの内部を深掘りするつもりはありません。詳細に関心のある方は、Ravi Murthy が AlloyDB のストレージ レイヤについて書き記したこちらのブログ記事をご覧ください。この章では、ベンチマーク テストの設定が結果に与える影響や、設定の影響によりベンチマーク テストの目標に対して十分に妥当ではない結果となってしまう可能性について説明することを目指しています。

テスト時の要素と設定

まずはテストで使用するデータセットのサイズについてです。スケール係数 1 の標準 pgbench は、大まかに 24 MB のサイズを持つデータセットを生成します。バッファのサイズが GB 単位でファイルシステムのキャッシュも同じサイズであれば、データはほぼ常にキャッシュに格納されます。基本的には、あるシステムの CPU とカーネルを別のシステムのそれらと比較してテストすることになります。有用性はどうでしょうか。データベース上の計画しているデータセットを想定しているでしょうか。24 MB のデータベースしかない状況であれば、AlloyDB は必要ない可能性も十分あるでしょう。現在または将来予想されるデータベースと同等のデータセットを生成するスケール係数を使用することをおすすめします。また、データセットはインスタンス上の有効キャッシュよりも大きくすることをおすすめします。たとえば、システムに 16 GB のメモリを搭載している場合、スケール係数 2000(パラメータ「-s 2000」)で 34 GB のデータセットを生成します。これは、CPU だけでなくストレージ サブシステムなど幅広いテストで十分なサイズです。

ベースラインとなるシステムの特徴について考えると、既存または計画している本番環境システムに近い CPU、メモリ、ストレージ レイヤが必要となるでしょう。これで、耐えられる最大負荷を把握して、システムを AlloyDB と比較してベンチマークできるようになります。ですが、vCPU 2 個の最小基本構成でのテストはおすすめしません。自動車のたとえ話に立ち返ってみますと、高重量のトラックやセミトレーラーは自らを動かすだけでも多くの燃料を消費します。これらの乗りものは複雑で、たとえば何トンもの積み荷に対応できるよう大きく重い骨組みが必要となります。私たちの課題においても、同じことが当てはまるかもしれません。多層キャッシュ サービス、オブザーバビリティ エージェント、ヘルスチェックを始めとする AlloyDB の内部サービスは、動作する際に CPU サイクルとメモリを使用します。そのため、vCPU を 2 個使用する小規模なインスタンスでは、目に見えてわかるオーバーヘッドが発生します。また、16 GB 2 コア CPU インスタンスに適切なワークロードの場合、Cloud SQL など別のサービスも検討すべきです。ただし、その場合もバキューム管理やインテリジェント バッファリングといった AlloyDB のさまざまな機能を心に留めておいてください。ネットワークも重要です。AlloyDB Auth Proxy を使用して接続している場所と同じリージョンにアプリケーションを配置する計画の場合、テストでも同じ構成を使用してください。ベンチマーク ツールを備えたクライアント VM が別のリージョンに存在している場合、ネットワーク オーバーヘッドがテスト結果に著しく大きな影響を与える可能性があります。もちろん、将来予想されるアーキテクチャにそのような配置を想定している場合には、このような構成もまったく理にかなっています。たとえば、オンプレミスでアプリケーションを使用しながら、クラウドで AlloyDB を動作させることを計画している場合です。

読み取りプールについて考えると、プライマリ インスタンス上の pgbench またはスタンドアロン システム上のレプリカと AlloyDB 上の読み取りプールに対してパラメータ -S を使用するなどして、読み取り専用ロードについてもいくつかテストを実施できます。このようなテストによって、混在するワークロードを把握しやすくなります。分析ワークロードのテストに対しては、AlloyDB 上のカラム型エンジンを有効化するのを忘れないようにしてください。デフォルトでは無効になっていますのでご注意ください。自動化モードまたはメモリ内のカラム型ストレージに入力するタスクを手動実行することで、テストを実施できます。


インデックス アドバイザーを使用したい場合は有効化してください。インデックス アドバイザーの説明とその使い方に関するブログが公開予定になっていますので、ぜひ Google Cloud のブログをお見逃しなくご覧ください。


まとめ

ここで、これまでお話ししたことについてまとめましょう。きっと、記事全体に目を通す時間のない方々にも役立つはずです。AlloyDB に対するベンチマーク テストを正しく実施する手順は次のとおりです。

  • テストの目標を定義する

  • ベースラインとなるシステムに関して、利用可能な最小限ではなく適切な構成を使用する

  • クライアント(ベンチマーク)マシンは、ベースラインとなるシステムと対象のシステムで似た構成とする

  • 十分に大きなデータセットまたはスケール係数を使用する

  • ベースラインとなるシステムのワークロードを最大化する

  • 信頼性の高い結果を得るために、各テストを十分な時間実行する

  • 各テストは最低でも 3 回繰り返す

  • ネットワークが重要なため、クラウドで適切なトポロジを使用する

  • 分析ワークロードまたはハイブリッド型ワークロードに対してカラム型エンジンを有効化する

  • 最適化にインデックス アドバイザーを使用して実際のワークロードをテストに使用することを計画している場合は、同アドバイザーを有効化する

これは AlloyDB のベンチマークで候補となる数あるアプローチの一つにすぎません。要件によっては、パフォーマンス評価の第 1 ステップにすぎないこともあります。このアプローチに関する詳しいガイダンスやベンチマーク テストの技術的な詳細が必要な場合、Google の AlloyDB チームが作成した下記 2 点のガイドブックが公開されていますので、これらを読むことをおすすめします。

  • AlloyDB - トランザクション(OLTP)ベンチマーク ガイド

  • AlloyDB - 分析(OLAP)ベンチマーク ガイド

前に言及したように、実際のワークロードと実際のデータを使用したテストが最適です。ベンチマークを実際のテストの代わりにすることはできませんが、特定条件下のシステムから予想されることについて、ある程度の見当をつける役に立ちます。テストがうまくいくことを願っています。ご質問がある場合は、Google のお客様担当までお気軽にお問い合わせください。


- データベース、Cloud アドボケイト Gleb Otochkin
投稿先