パフォーマンスのベンチマークを行う場合は、テストを開始する前に、テストから得られる結果を定義します。次に例を示します。
- システムで達成できる最大スループット
- 特定のクエリまたはワークロードにかかる時間
- データ量の増加に伴うパフォーマンスの変化
- 2 つのシステムのパフォーマンスの比較
- カラム型エンジンによって短縮されるクエリのレスポンス時間の長さ
- データベースが処理できる負荷の量（より高スペックなマシンへのアップグレード前の検討材料）
パフォーマンス調査の目標を理解することにより、実行するベンチマーク、必要な環境、収集する指標を把握できます。
反復性
パフォーマンス テストから結論を得るには、テストの結果が再現可能である必要があります。テスト結果に大きなばらつきがある場合、アプリケーションやシステム構成に加えた変更の影響を評価するのは困難です。テストを複数回または長時間実行してより多くのデータを収集すると、ばらつきを減らすことができます。
パフォーマンス テストは他のシステムから分離されたシステムで実行するのが理想的です。外部システムがアプリケーションのパフォーマンスに影響する可能性がある環境で実行すると、誤った結論が導き出される可能性があります。マルチテナント クラウド環境で実行する場合、完全な分離が不可能なことが多いため、結果のばらつきが大きくなることを想定してください。
反復性の一環として、テスト ワークロードが実行間で同じ状態になるようにします。テストへの入力がランダムな場合でも、それがアプリケーションの動作に大きな違いをもたらすものでない限り許容されます。ランダムに生成されたクライアント入力によって、実行ごとに読み取りと書き込みの割合が変化すると、パフォーマンスが大幅に異なることになります。
データベースのサイズ、キャッシュ、I/O パターン
テストに使用するデータの量がアプリケーションのデータ量と同量であることを確認します。数百 GB または数 TB のデータがある場合に少量のデータでテストを実行すると、アプリケーションのパフォーマンスを正確に評価することができません。データセットのサイズも、クエリ オプティマイザーによる選択に影響します。テスト用の小さなテーブルに対するクエリでは、大規模なスケールではパフォーマンスが低下するテーブル スキャンが使用されることがあります。この構成では、不足しているインデックスを特定できません。
アプリケーションの I/O パターンを再現するようにしてください。読み取りと書き込みの比率は、アプリケーションのパフォーマンス プロファイルにとって重要です。
ベンチマークの時間
複雑なシステムでは、システムの実行時に多くの状態情報が存在します。データベース接続の確立、キャッシュへのデータの入力、プロセスとスレッドの生成などです。ワークロードの実行時間が短すぎると、これらのコンポーネントの初期化のためパフォーマンス テストの開始時にシステム リソースが消費され、測定されたパフォーマンスに悪影響をおよぼす可能性があります。
システムのウォームアップの影響を最小限に抑えるため、パフォーマンス テストは 20 分以上実行することをおすすめします。起動後に安定した状態のパフォーマンスを測定し、データベースのオペレーションのすべての状況が含まれるよう十分な時間を確保します。たとえば、データベースのチェックポイントはデータベース システムの重要な機能であり、パフォーマンスに大きな影響を与える可能性があります。チェックポイント間隔の前に完了する短いベンチマークを実行すると、アプリケーションの動作においてこの重要な状況が把握できません。
計画的なテスト
パフォーマンスをチューニングする際は、変数の変更は 1 回につき 1 つだけにしてください。実行間で複数の変数を変更すると、パフォーマンスの向上につながった変数を特定できなくなります。実際には、複数の変更同士で相殺が発生するため、変更の効果が適切に得られない場合があります。データベース サーバーが過負荷になっている場合は、負荷を一定に保ちながら、vCPU の数が多いマシンに切り替えてみます。データベース サーバーの使用率が低い場合は、CPU 構成を変更せずに負荷を増やしてみてください。
ネットワーク トポロジとレイテンシ
システムのネットワーク トポロジが、パフォーマンス テストの結果に影響する可能性があります。レイテンシはゾーン間で異なります。パフォーマンス テストを行う場合は、クライアントとデータベース クラスタが同じゾーンにあることを確認すると、ネットワーク レイテンシが最小限に抑えられ、最適なパフォーマンスが得られます。特に、スループットが高く、トランザクションが短いアプリケーションでは、ネットワーク レイテンシがトランザクションの全体的な応答時間の大きな要素になる可能性があるため、この確認が重要です。
2 つの異なるシステムのパフォーマンスを比較する場合は、両方のシステムのネットワーク トポロジが同じであることを確認してください。ネットワーク レイテンシの変動を完全になくすことはできません。同じゾーン内でも、基盤となるネットワーク トポロジが原因でレイテンシに差異が生じる可能性があります。
アプリケーションをデプロイする際は、一般的な大規模ウェブ アプリケーションを検討して、クロスゾーン レイテンシの影響をより深く理解することをおすすめします。このアプリケーションでは、高可用性を確保するために複数のゾーンにデプロイされた複数のウェブサーバーにリクエストを送信するロードバランサが使用されています。ゾーン間のレイテンシは異なるため、リクエストを処理するウェブサーバーによってレイテンシが異なる場合があります。
次の図に示すのは、AlloyDB Omni を使用するウェブ アプリケーションの一般的なアーキテクチャです。クライアントのリクエストはロードバランサによって処理され、各リクエストはロードバランサにより複数のウェブサーバーのいずれかに転送されます。すべてのウェブサーバーは AlloyDB Omni に接続されています。一部のサーバーは AlloyDB Omni が実行されているゾーンとは異なるゾーンにあり、データベース リクエストを行うとレイテンシが増加します。
リソースのモニタリング
データベース システムのパフォーマンスを最適化するには、データベース システムと、データベース システムを使用するクライアント システムの両方のリソース使用状況をモニタリングする必要があります。両方のシステムをモニタリングすることで、クライアント システムがデータベース システムで有意な測定値を得られるよう十分なワークロードを提供していることを確認できます。テスト対象のシステムのリソース使用率をモニタリングすることが重要です。同様に、ワークロードの実行に使用しているクライアント システムのリソース使用状況をモニタリングすることも重要です。たとえば、CPU リソースを使い果たす前のデータベース システムがサポートできるクライアントの最大数を特定する場合は、データベース システム内のすべての CPU リソースを使い果たすために必要なワークロードを生成できる十分なクライアント システムが必要です。負荷を生成するクライアント マシンに十分な CPU がない場合、データベース システムはその性能を十分に発揮できません。
スケーラビリティ テスト
スケーラビリティ テストは、パフォーマンス テストの別の一面です。ワークロードのある特性が変化するにつれてパフォーマンス指標がどのように変化するかを、スケーラビリティと言います。スケーラビリティ テストの例として、次のものがあります。
- 同時リクエスト数が増加するとスループットと応答時間にどのように影響するか
- データベースのサイズが大きくなるとスループットと応答時間にどのように影響するか
スケーラビリティ テストは、ワークロードを複数実行することで行われます。実行ごとに分割項目が 1 つ変化し、1 つ以上の指標が収集されてプロットされます。このタイプのテストでは、システムのボトルネック、特定の構成でシステムが処理できる負荷量、システムがサポートできる最大負荷、負荷がそれらのレベルを超えた場合のシステムの動作に関する決定を行うことができます。
マシンサイズに関する考慮事項
AlloyDB Omni では、データベースの信頼性と可用性を向上させる多くの新機能が Postgres に導入されています。これを行うために必要なモニタリングでは、AlloyDB Omni を実行しているマシンのリソースが使用されます。マシンサイズが非常に小さい場合はメモリと CPU リソースが最初から制限されるため、ベンチマークでは、少なくとも 4 つの vCPU を持つマシンサイズを使用することをおすすめします。