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