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

新しいデータベース プラットフォームやテクノロジーにデータベースを移行することは、さまざまな理由で困難な場合があります。一般的な懸念事項としては、データベースのパフォーマンスが挙げられます。実際のデータの移行やアプリケーションの変更を行うことなく、評価サイクルの早い段階でデータベースのパフォーマンスを評価することは容易ではありません。データベース層とアプリケーション層の両方でモダナイゼーションが必要な Cloud Spanner の場合、データベースのパフォーマンスはさらに重要性が増します。

データベースのパフォーマンスを評価するための従来のアプローチは、アプリケーションとデータベースを一緒にデプロイし、過去のデータを新しいデータベースに移行した後に、新しいデータベースでアプリケーションを実行して負荷テストをシミュレートすることです。Cloud Spanner の早期パフォーマンス評価のためにこうした作業をすべて行うのは、大変な労力のように感じるかもしれません。

この投稿では、JMeter を使用したパフォーマンス テストの折衷案を公開します。カスタム ワークロードで Cloud Spanner のパフォーマンス テストを行ってから、アプリケーション コードを変更してデータ移行を実施します。より詳細な手順ガイドは、こちらで公開されています。

目標

• 必要な Cloud Spanner ノードの数を見積もる（加えてコスト見積もりを取得する）。

• 最も頻繁に使用される一連のクエリとトランザクションのパフォーマンス テストを実施する。

• 水平スケーリングの能力を示す。

• スキーマや SQL クエリに必要な最適化について理解を深める。

• DML オペレーションのレイテンシを判断する。

制限事項

• Java 以外のクライアント ライブラリではテストできません。

•  ミューテーションや同時読み取りなど、JDBC に準拠していない機能をテストする場合はさらに複雑になります。

パフォーマンス テストの準備

1. よく使う SQL のクエリやレイテンシ、頻度 / 時間に加え、クエリごとに返される行や更新される行の平均数を特定します。この情報は現在のシステムのベースラインとしても機能します。

2. Cloud Spanner のリージョン / マルチリージョンのデプロイを決定します。レイテンシを最小限に抑え、パフォーマンスを最大限に引き出すには、Cloud Spanner インスタンスのリーダー リージョンから負荷を生成するのが理想的です。Cloud Spanner のさまざまな構成について詳しくは、Cloud Spanner のマルチリージョン構成について理解するをご参照ください。

3. （ステップ 1）に基づいて、特定のワークロードに必要な Cloud Spanner ノードの数を見積もります。線形スケーリングには、最低でも 2 つのノードを使用することをおすすめします。
   注: リージョン構成のパフォーマンスとマルチリージョン構成のパフォーマンスのピーク時のパフォーマンス値が公開されています。これは、セカンダリ インデックスのない 1 KB の単一行トランザクションに基づいています。

4. 特定のリージョン / マルチリージョンの Cloud Spanner ノードに対する割り当てのリクエストを行います。最長で 1 営業日ほどかかる場合があります。

Cloud Spanner の設定

Cloud Spanner のスキーマを作成する

以下のソース データベースから移行する場合は、各ツールを使用して Cloud Spanner のスキーマを生成できます。または、スキーマを手動でモデル化することも可能です。スキーマの設計はパフォーマンスへの影響が大きいため、スキーマの確認は慎重に行うことをおすすめします。

注: 潜在的なホットスポットの最適化や軽減を行うには、スキーマの手動レビューと調整が必要になります。スキーマをモデル化するときは、スキーマ設計のベスト プラクティスに留意する必要があります。

シードデータを Cloud Spanner に入力する

データベースのパフォーマンスは、存在するデータの量によって異なります。既存のデータ（およびインデックス）によって、SELECT クエリでスキャンされるデータの量、ひいてはパフォーマンスが決まります。したがって、パフォーマンス テストの前に Cloud Spanner にシードデータを入力することが重要です。

最も現実的な結果を得るためには、本番環境の既存ソースからデータを移行する必要がありますが、スキーマの変更により、それをできない場合があります。一つは、カスタム ETL ジョブを利用することで、データをエクスポートして変換してから、Cloud Spanner にインポートする方法があります。もう一つの方法は、JMeter を使用してシードデータをモックすることです（詳細は後のセクションでご説明します）。

JMeter のパフォーマンス テスト

テストを作成する

JMeter は、アプリケーションと同じように Cloud Spanner と対話します。また、アプリケーションと同じ方法で DML オペレーションを実行します。そのため、テストではトランザクションをはじめとする本番環境をシミュレートする必要があります。たとえば、トランザクション境界内に複数のテーブルの挿入ステートメントや更新ステートメントから構成されるトランザクションがある場合、JMeter はそのトランザクションを模倣する必要があります。

JMeter には次の階層があります。

テスト計画 > スレッド グループ > サンプラー（テスト）

テスト計画は最上位のコンポーネントです。グローバル プロパティとライブラリ（JDBC ドライバなど）を含めることができます。

スレッド グループはデータベースのトランザクションを表し、1 つ以上のサンプラーが含まれます。スレッド グループ内のすべてのサンプラーは 1 つずつ順番に実行されます。

サンプラーは 1 つの DML 呼び出しにする必要があります。トランザクションで複数の DML 呼び出しを行う必要がある場合は、複数のサンプラーを作成してください。通常、データベース呼び出しには JDBC サンプラーを使用します。また、こちらで説明されているように JSR 223 サンプラーを使用することもできます（ミューテーションや同時読み取りなどを使用する必要がある場合）。実際のアプリケーションのように、あるサンプラーからの結果を次のサンプラーに渡すことが可能です。

テストを実行し、結果を収集する

JMeter テストは、できるだけ Cloud Spanner インスタンスに物理的に近い場所で実行して、ネットワーク レイテンシを最小限に抑える必要があります。したがって、Cloud Spanner インスタンスと同じリージョンの Compute Engine から（Private Service Connect を通じて）実行するのが最適です。マルチリージョンの Cloud Spanner の場合は、GCE インスタンスを Cloud Spanner インスタンスのリーダー リージョンに作成して、ネットワーク レイテンシを最小限に抑える必要があります。

JMeter はコマンドラインから実行する必要があります。このアプリケーションは多くの CPU リソースを必要とするため、VM に十分なリソースが割り振られていることをご確認ください。

また、Cloud Spanner モニタリング ダッシュボードを参照して、Cloud Spanner インスタンスの CPU 使用率が推奨値以下であることをご確認ください。さらに、イントロスペクション ツールを使用して、データベースのパフォーマンスの問題を調査します。

必要に応じて、クエリを最適化（インデックスを追加）し、複数のウェーブでテストを再実行してパフォーマンスを調整すべき場合があります。

実際に試す

Measure Cloud Spanner performance using JMeter（JMeter を使用した Cloud Spanner のパフォーマン測定）の詳細なチュートリアルに沿って、Cloud Spanner のパフォーマンスをご自身でテストしてみてください。