このページでは、Spanner で概念実証（POC）を計画して実行するための戦略について説明します。インスタンス構成、スキーマ設計、データ読み込み、パフォーマンス評価など、POC の重要な側面に関する詳細なリファレンスと分析情報を提供します。ここでは、Spanner の機能を評価するための重要な手順が示します。これにより、Spanner の導入に関連する潜在的なリスクとメリットを特定できます。
POC は、Spanner の技術的な機能を検証するだけでなく、次の 2 つの目的も果たします。
- ユースケースで Spanner が提供するメリットを理解できるようにする
- Spanner の導入に関連するリスクを特定できるようにする
Spanner POC には、次の図に示すように、特定のビジネス目標と技術目標に対応するようにカスタマイズされたさまざまな評価要素が含まれています。
このドキュメントのガイドラインは、これらの各領域を評価するうえで役立ちます。
パフォーマンスとスケーラビリティでは、Spanner が特定のワークロードを処理する方法、レイテンシ要件、さまざまなインスタンス構成の影響を理解できます。これらのテストでは、Spanner がシームレスにスケーリングできることを確認できます。
モニタリング機能を使用すると、Spanner が効果的なデータベース運用に必要な分析情報を提供しているかどうかを評価できます。この評価には、次の項目が含まれます。
- クエリ実行プランを分析するオプション
- システム リソースの使用率
- アラートの構成オプション
POC では、運用効率を最大限に高めるために対処する必要があるギャップを確認できます。
組織に Spanner が適しているかどうかを判断するうえで、セキュリティとコンプライアンスは重要な要素です。これには、次のような堅牢なコンプライアンス上のメリットを実現しながら、Spanner がセキュリティ リスクを軽減できることを確認するための評価が含まれます。
- 転送中と保存中のデータの暗号化オプション（CMEK または EKM など）
- 最小権限のアクセス制御ポスチャー
- 監査ロギング
- 規制要件への準拠
運用とデータの復元力を確保するには、バックアップと障害復旧（DR）機能が不可欠です。POC では、ポイントインタイム リカバリや可用性など、Spanner の DR 機能を検証できます。
移行の実現可能性では、現在のデータベース ソリューションから Spanner への移行の複雑さを理解する必要があります。スキーマの互換性、移行ツール、アプリケーションの変更を評価すると、必要な投資を定量化し、Spanner の導入のリスクとメリットを判断できます。
評価中に、Spanner の機能セットを調べて、アプリケーションの機能要件を満たしていることを確認できます。これには、グローバルな整合性、SQL クエリ機能、他の Google Cloud サービスとの統合のテストが含まれます。
評価では、リージョン間の一貫性など、Spanner の独自の強みを確認できますが、既存のアプリケーション アーキテクチャとの統合作業など、潜在的なリスクも明らかになります。
POC アクティビティのライフサイクル
この POC では、次の手順について説明します。このドキュメントの推奨事項に沿って、特定のユースケースに合わせて Spanner を設定して評価します。
POC を計画する
成功する POC の基盤は、技術とビジネスの両方の優先事項に沿った明確で測定可能な目標を定義することです。「Spanner の可能性を探る」というような、あいまいな目標は設定しないでください。このような目標では、焦点の定まらない取り組みや、あいまいな結果につながることがよくあります。代わりに、具体的な項目（99.999% の可用性の達成、ダウンタイムの短縮、トランザクション レイテンシは 20 ミリ秒未満に維持しながらスループットの 200% 増加に対応するスケーリングなど）を POC の目標に設定してください。
Spanner の独自のアーキテクチャは、大規模なスケーラビリティを必要とするワークロードに最適です。そのため、ユースケースのスケーラビリティを評価することをおすすめします。テストシナリオには、以下を含める必要があります。
- 一般的な運用負荷の処理
- トラフィックの急増の管理
- 効率的なスケールダウン
これらのテストは、さまざまな条件下での Spanner のパフォーマンスと、スケーラビリティに関する技術要件を満たしているかどうかを把握するうえで役立ちます。具体的で実行可能な目標を設定すると、POC の構成に役立つだけでなく、成功を評価するための確固たる基盤を構築できます。
定量化された評価基準を定義する
POC が目標を達成したかどうかを判断するには、明確で測定可能な指標と個別の成功基準からなる評価基準が必要です。たとえば、パフォーマンスのみをテストするのではなく、次のような目標も指定する必要があります。
- 特定の本番環境レベルの QPS（秒間クエリ数）を処理する
- 事前に定義されたピーク負荷で 20 ミリ秒未満のレイテンシを維持する
- 明確に定義されたトラフィックの急増をパフォーマンスの低下なしで処理する
明確に定義された基準は、ワークロードに対して Spanner を客観的に評価し、次のステップに役立つ分析情報を提供することができます。読み取り / 書き込みオペレーションのレイテンシのパーセンタイル目標を明確に定義します（p50 や p95 など）。許容できるレイテンシしきい値を明確に定義することで、ビジネスニーズに合わせて Spanner パフォーマンスのテスト設計を行うことができます。
評価用評価基準の例を次に示します。
| 評価ファセット | 成功基準 |
| 可用性 | 99.999% |
| セキュリティ | CMEK と EKM が必要 |
| リージョン停止の場合の目標復旧時点（RPO）の保証 | 0 |
| 最も重要なトランザクションのレイテンシの上限 | p50 が 20 ミリ秒未満 |
| ユーザー向けの最も重要なクエリのレイテンシ | p50 が 100 ミリ秒未満 |
| スケーラビリティ | 1 時間以内に 1 秒あたり 10,000 件のトランザクションから 1 秒あたり 100,000 件のトランザクションにスケールアップし、p50 レイテンシが 20 ミリ秒未満であることを示します。 |
評価ケースのスコープを設定する
POC では、大規模な移行は必要ありません。代わりに、システムの代表的なワークロードや重要なコンポーネントのテストに重点を置きます。たとえば、オペレーションの中心となる主要なクエリ、重要なトランザクション シェイプ、特定のデータドリブン ワークフローに焦点を当てます。結果の関連性と有意性を維持しながら、複雑さを軽減するためにスコープを絞り込みます。このアプローチでは、システム全体の移行の複雑さに圧倒されることなく、Spanner の機能を管理可能な方法で評価できます。
Spanner インスタンス構成を選択する
評価目的で Spanner インスタンスを作成する場合は、地理的位置とサービスの可用性 SLA に関するビジネス要件を満たすインスタンス構成を選択します。 Spanner には、シングルリージョン、マルチリージョン、デュアルリージョンなど、さまざまな構成があります。各構成は、レイテンシ、可用性、冗長性のさまざまな要件を満たすように設計されています。
- シングルリージョン構成では、1 つの Google Cloud リージョンにデータを保存し、そのリージョン内の低レイテンシと費用対効果を実現します。このトポロジは、99.99% の可用性を提供するリージョン内ゾーン冗長性を必要とするワークロードに最適です。
- デュアルリージョン構成では、1 つの国の 2 つのリージョンにまたがってデータを複製し、各リージョンにフェイルオーバー用のウィットネス レプリカを配置します。この構成では、シングルリージョンの設定よりも高い可用性（99.999%）とフォールト トレランスが提供されます。このトポロジは、厳格なコンプライアンス（データ所在地など）または地理的な近接性要件があるワークロードに適しています。
- マルチリージョン構成では、複数のリージョンにデータを複製し、リージョンの停止に対する非常に高い可用性と復元力を実現します。このトポロジは、最大 99.999% の可用性で地理的冗長性が必要なアプリケーションに最適です。
クロスリージョン インスタンスでのレイテンシに関する考慮事項
デュアルリージョン構成とマルチリージョン構成では、Spanner レプリカの地理的な分散がレイテンシに影響する可能性があります。書き込みレイテンシは、読み取り / 書き込みトランザクションを調整するリーダー リージョンと、各書き込みオペレーションを確認する他のリージョンの近さによって異なります。アプリケーションのコンピューティング リソースをリーダー リージョンの近くに配置すると、ラウンドトリップの遅延が短縮され、レイテンシが最小限に抑えられます。
アプリケーションのニーズに合わせて、データベースのリーダー リージョンを変更できます。読み取り専用オペレーションの場合、Spanner は最も近いレプリカからステイル読み取りを提供できるため、レイテンシを短縮できます。一方、強力な読み取りではリーダー リージョンが使用されるため、オペレーション レイテンシが増加する可能性があります。マルチリージョン設定でレイテンシを最適化するには、リーダー リージョンを戦略的に選択して、サービスのコンピューティング リソースをリーダー リージョンに配置し、読み取り負荷の高いワークロードでステイル読み取りを利用します。
アプリケーションの要件を満たす構成
アプリケーションのインスタンス構成を選択する場合は、可用性、レイテンシ、データ所在地に関する要件などの要素を考慮してください。たとえば、アプリケーションで特定の地理的エリアのユーザーに対して低レイテンシのレスポンスを必要とする場合は、リージョン インスタンスで十分な場合があります。ただし、高可用性が求められるアプリケーションや、グローバルに分散されたユーザーにサービスを提供するアプリケーションの場合は、マルチリージョン構成が適しています。
パフォーマンスを評価するには、アプリケーションの本番環境要件に近い構成から始めます。レイテンシと費用は構成によって異なるため、ユースケースのニーズに合わせて POC 環境を調整してください。マルチリージョン デプロイの場合は、地理的なサービス分散をシミュレートし、レイテンシをテストして、構成が本番環境の要件に準拠していることを確認します。詳細については、Spanner マルチリージョン リーダーの配置に関するガイダンスをご覧ください。
Spanner のサイジング
POC 中に評価ワークロードを効果的に処理できるように、Spanner インスタンスの初期コンピューティング容量をプロビジョニングします。最初のインスタンスのサイズは、読み取り書き込みの秒間クエリ数（QPS）、クエリの複雑さ、同時実行レベルを考慮して、想定されるワークロードに合わせて調整する必要があります。
妥当な前提条件から始めることで、ベースラインを確立し、測定されたパフォーマンスに基づいて段階的にスケーリングできます。Spanner のリファレンス ベンチマークのサイジング ガイダンスを使用して、ベースライン インスタンス構成を確立できます。
POC 中のサイジングは反復的である必要があります。最初に設定を行い、レイテンシや CPU 使用率などの主要な指標をモニタリングし、必要に応じて割り当てられたコンピューティング容量を調整します。これにより、本番環境に似た条件を再現しながら、Spanner のスケーラビリティとパフォーマンス機能を検証できます。
ワークロードの一般的なパターン（トラフィックの継続性と需要の変動など）は、サイジング方法に影響を与えます。自動スケーリングを有効にすると、Spanner はワークロードの負荷に合わせてコンピューティング リソース容量を動的にプロビジョニングします。
スキーマの設計
データの編成方法はパフォーマンスとスケーラビリティに直接影響するため、スキーマ設計は Spanner POC の重要な要素です。
適切に設計されたスキーマは、POC で Spanner の機能を実証するための基礎となります。負荷テストでは、潜在的なボトルネックや非効率性が明らかになり、最適なスキーマを作成するための継続的な改善に役立ちます。
スケーラビリティを考慮した設計
Spanner のデータベース スキーマを作成する場合は、分散アーキテクチャを考慮することが重要です。主な考慮事項と最適化には、次のようなものがあります。
- 主キー: キースペースにデータを均等に分散する主キーを選択します。タイムスタンプなど、スプリットでホットスポットが発生する可能性のある単調に増加するキーは避けてください。
- インデックス: 書き込みパフォーマンスとストレージ費用への影響を考慮しながら、クエリのパフォーマンスを最適化するようにインデックスを設計します。インデックスが多すぎるか、計画が不十分な場合、不要なオーバーヘッドが発生する可能性があります。
- テーブル インターリーブ: テーブル インターリーブを使用して、関連データのアクセス パターンを最適化します。これにより、プロセス間の通信が減り、クエリの効率が向上する可能性があります。
Spanner スキーマ設計のベスト プラクティスで、一般的な落とし穴を回避し、高パフォーマンスとスケーラビリティをサポートするスキーマを設計します。
次の図に示すように、 Google Cloud コンソールでドラフト スキーマを作成できます。
Spanner 移行ツールを使用したスキーマの移行
Spanner 移行ツール（SMT）を使用すると、MySQL や PostgreSQL などのリレーショナル データベースから移行する際のスキーマ作成を簡素化できます。SMT はスキーマの生成を自動化し、インデックスの候補の提案やスキーマの調整などの基本的な最適化を行います。SMT は優れた開始点を提供しますが、スキーマを特定のユースケースやワークロード パターンに合わせるには、手動で調整することがよくあります。
反復的なスキーマ設計プロセスを使用する
最初のスキーマは出発点として使用できますが、完璧なものではありません。POC のスキーマ作成は 1 回限りのタスクではなく、テストから分析情報を得るにつれて進化する反復プロセスです。堅牢なスキーマはアプリケーションのパフォーマンスに不可欠です。これを実現するには、慎重な初期設計、SMT などのツールの活用、負荷テストの結果に基づく反復的な改善が必要です。このプロセスに沿ってスキーマを作成すると、スキーマがアプリケーションの要件を効果的に満たすことができます。また、Spanner の機能を最大限に活用する方法についても理解できます。
データ読み込み
Spanner POC を成功させるには、代表的なデータをデータベースに読み込んで、スキーマ設計を検証し、アプリケーション ワークフローをシミュレートする必要があります。このプロセスを効率化できるおすすめのツールがいくつかあります。独自のデータを読み込むため、Spanner には次のオプションが用意されています。
- Spanner への BigQuery のリバース ETL（抽出、変換、読み込み）は、SQL ベースの変換を使用してデータを Spanner に読み込むことができる、使いやすい統合データ読み込みメカニズムです。この方法は、JSON などの半構造化データを含む、さまざまなデータ形式に適しています。
- MySQL や PostgreSQL などのリレーショナル データベースの場合、Spanner 移行ツール（SMT）は、スキーマの作成、データ型のマッピング、一括データの読み込みを自動化します。
- フラット ファイル形式の場合、CSV から Spanner と Avro から Spanner への Dataflow テンプレートが用意されており、一括データ読み込み用の手動スキーマ定義を作成できます。JDBC 互換データベースに対しては、JDBC to Spanner Dataflow テンプレートが用意されています。
これらのオプションの詳細については、独自のデータを使用するをご覧ください。
サンプルデータがない場合は、Machmeter の JMeter や QuickPerf などの合成データ生成ツールを使用して、スキーマとユースケースに合わせてデータセットを作成できます。詳細については、サンプルデータを生成するをご覧ください。
自社データを活用する
POC に使用するサンプルデータがある場合は、そのデータを Spanner に読み込む方法がいくつかあります。
| ソース | ツール | スキーマ作成 | 変換 | データサイズ |
| MySQL | SMT | 自動 | データ型の変換のみ | 小 |
| PostgreSQL | SMT | 自動 | データ型の変換のみ | 小 |
| 任意の JDBC | JDBC to Spanner | 手動 | データ型の変換のみ | 大 |
| CSV | CSV to Spanner | 手動 | データ型の変換のみ | 大 |
| BigQuery リバース ETL | 手動 | サポートされている複雑な変換 | 大 | |
| Avro | Avro to Spanner | 手動 | データ型の変換のみ | 大 |
| BigQuery リバース ETL | 手動 | サポートされている複雑な変換 | 大 | |
| JSON | BigQuery リバース ETL | 手動 | サポートされている複雑な変換 | 大 |
BigQuery から Spanner へのリバース ETL
BigQuery から Spanner へのリバース ETL を使用すると、幅広いデータソースを迅速に取り込み、SQL を使用して BigQuery テーブルに変換できます。その後、BigQuery テーブルから Spanner テーブルにデータをエクスポートできます。これは、JSON などの半構造化データに対して特に役立ちます。JSON は、多くの場合、NoSQL データソースからのエクスポートとして取得されます。BigQuery にはスキーマの自動検出機能がありますが、Spanner のスキーマの作成は手動で行うため、データの読み込み前にスキーマを定義する必要があります。
Spanner 移行ツール
POC をすぐに開始するには、Spanner 移行ツール（SMT）を使用して、MySQL ソースと PostgreSQL ソースから Spanner にデータを移行します。SMT は、スキーマ作成プロセスを自動化し、ソース データベースのデータ型を Spanner の同等の型にマッピングします。また、Spanner 固有のスキーマ最適化の推奨事項も生成します。そのため、自動スキーマ変換で十分な簡単な移行に特に便利です。
SMT には、移行プロセスをガイドするユーザー インターフェースが用意されています。このプロセスでは、移行元データベースを選択し、スキーマ設計に関する推奨事項とオプションを確認します。
Dataflow テンプレート
Dataflow は、スケーラブルなデータ処理用に設計されたフルマネージド サービスであるため、大量のデータを読み込む場合に適しています。
Google は、一般的な読み込みパターン用に次のオープンソース テンプレートを提供しています。
- CSV to Spanner は、Cloud Storage に保存されている CSV ファイルから Spanner にデータを読み込みます。
- Avro to Spanner は、Cloud Storage から既存の Avro データファイルを読み込みます。
- JDBC to Spanner は、JDBC をサポートするデータベースからデータを読み込みます。
これらのテンプレートでは、データの読み込みを開始する前に Spanner スキーマを手動で作成する必要があります。
Dataflow は、任意のサイズのデータセットに対応するように自動的にスケールアウトします。これにより、テラバイト規模のデータセットでも、Spanner への高パフォーマンスのデータ取り込みが保証されます。このスケーラビリティは、いくつかのトレードオフを犠牲にして提供されます。
- Dataflow パイプラインでは、最適な実行のためにスキーマ、データ マッピング、実行パラメータを定義するために手動で構成する必要があります。
- Dataflow は、大規模なデータ移行に必要な柔軟性と能力を提供しますが、他のツールよりも設定と管理に多くの労力が必要になる場合があります。
サンプルデータを生成する
サンプルデータがないが、特定のユースケースを想定している場合は、要件に基づいてスキーマをモデル化し、ツールを使用して代表的なデータセットを生成できます。これらのツールを使用すると、Spanner に意味のあるデータを入力して、スキーマ設計とアプリケーション ワークフローを検証できます。
Machmeter の JMeter
Machmeter の JMeter には、JMeter を使用して Spanner のサンプルデータを生成する例が用意されています。Machmeter はユースケース ドリブンの例に重点を置いているため、想定される本番環境スキーマに構造的に類似したデータパターンを生成するための出発点として最適です。提供されている例には、一括挿入などのオペレーションのスクリプトが含まれています。スクリプトを調整して、合成データセットを大規模に生成できます。詳細については、Machmeter のリポジトリまたはドキュメントをご覧ください。
QuickPerf
QuickPerf は、Spanner JDBC ドライバとともに配布されます。QuickPerf には、スキーマの完全性とデータベースの動作をテストするための代表的なデータセットをすばやく作成する SQL ベースのスクリプトが用意されています。これにより、複雑度の低い小規模から中規模のデータセットをすばやく、簡単に生成できます。
負荷テスト
負荷テストでは、ワークロードを処理する際の Spanner のパフォーマンスをモニタリングして、データベースが本番環境の需要に最適な構成になっていることを確認できます。前述の 2 つのツール（Machmeter の JMeter と QuickPerf）は、ワークロードをシミュレートし、スループット、レイテンシ、リソース使用率などのパフォーマンス指標を測定する場合に特に効果的です。
Machmeter プロジェクトで強化された Apache JMeter は、Spanner を使用した分散負荷テスト用の強力なフレームワークを提供します。Machmeter には、Spanner ワークロードをシミュレートするために特別に設計され、事前構築された JMeter 構成が含まれています。これらの構成は、代表的なクエリ、トランザクション、バッチ オペレーションを実行するように調整できるため、さまざまなシナリオで Spanner のパフォーマンスを測定できます。
JMeter は、同時実行ユーザーとトランザクションをシミュレートできるため、Spanner インスタンスのスケーラビリティと復元力をテストする場合に適しています。Kubernetes またはマネージド サービス GKE を使用して JMeter を分散モードでデプロイし、テスト環境をスケーリングできます。結果から、Spanner が特定のワークロードをどのように管理し、需要の増加に応じてスケーリングして、ピーク負荷時にどのように動作するかについて分析情報を得ることができます。
詳細と構成例については、Machmeter リポジトリをご覧ください。
QuickPerf は、Spanner でのパフォーマンス テスト用に設計された軽量のベンチマーク ツールです。最小限のセットアップでパフォーマンス指標を生成し、最適化をすばやく繰り返すことに重点を置いています。QuickPerf は簡単に構成でき、特定のスキーマやクエリの最適化によるパフォーマンスへの影響をすばやく測定したい小規模なテストやシナリオに特に適しています。
負荷テストのベスト プラクティス
負荷テストを実施する際は、Spanner のベスト プラクティスに従って、正確で実用的な結果が得られるようにすることが重要です。
- ウォームアップ期間: ノードのスケーリング後や新しいワークロードの導入後に Spanner が安定状態に達するように、ウォームアップ期間（通常 30 分以上）を設定します。
- 関連する指標を測定する: スループット（1 秒あたりのオペレーション数）、レイテンシのパーセンタイル（p50、p95 など）、CPU 使用率などの指標に焦点を当て、Spanner がワークロードを処理する方法を確認します。
- 長いベンチマークを実行する: より代表的な結果を得るには、負荷テストを長時間（1 時間以上など）実行し、再バランシングやバックグラウンド メンテナンス タスクなどのシステム動作を確認します。
- スケーリング テスト: スケールアップとスケールダウンの両方のシナリオをテストして、さまざまなノード構成とピーク負荷での Spanner の動作を確認します。
JMeter Machmeter や QuickPerf などのツールと、負荷テストのベスト プラクティスを使用することで、Spanner のパフォーマンスを効果的に評価できます。これにより、ボトルネックを特定し、ワークロードの需要を満たすようにデータベースを最適化できます。
モニタリング
POC で Spanner のパフォーマンスとスケーラビリティを効果的に実証するには、特に負荷がかかっているときの運用特性をよく理解している必要があります。Spanner には、データベースのパフォーマンスのあらゆる側面に関する詳細な分析情報を提供するように設計された、包括的なモニタリング ツールと診断ツールが用意されています。このツールセットには、指標ダッシュボードから詳細なシステム テーブルまで、ボトルネックの特定、設計選択の検証、パフォーマンスの最適化に役立つさまざまなリソースが用意されています。
システム分析情報は、Spanner インスタンスのパフォーマンスと運用の健全性に関する詳細なオブザーバビリティを提供します。CPU 使用率、レイテンシ、スループットなど、さまざまな領域の指標と分析情報を、調整可能な粒度で提供します。POC では、テスト中の Spanner の動作を観察する出発点となります。システム分析情報を使用すると、CPU 使用率が高い、読み取りまたは書き込みのレイテンシが増加しているなど、パフォーマンスのボトルネックをすばやく特定できます。この情報は、その後の調査の基盤となります。
クエリの分析情報では、CPU 時間、実行回数、平均レイテンシなどの指標に基づいて、最も頻繁に実行され、コストのかかるクエリを特定し、クエリ実行のトップダウン ビューを確認できます。クエリ分析情報では、クエリの各ステップの統計情報など、詳細な実行プランを調べて、速度低下を引き起こしている特定のオペレーションを特定できます。また、過去のパフォーマンスの傾向を調査したり、さまざまな期間のクエリのパフォーマンスを比較する機能も用意されています。これにより、リグレッションやスキーマとコードの変更の影響を特定できます。インデックス アドバイザーなどの追加ツールは、クエリを分析して、クエリのパフォーマンスを改善できる新しいインデックスの作成やインデックスの変更を推奨します。
トランザクション分析情報では、トランザクションのレイテンシ、commit 待ち時間、読み取りと書き込みの行数とバイト数、分散トランザクションの参加者に関する詳細な指標を使用して、トランザクションのパフォーマンスを把握できます。これらの指標は、レイテンシが高いトランザクションや中断されたトランザクションを明らかにし、その特性に関する詳細情報を提供します。POC の負荷テストでは、ストレス状態のシステムのトランザクション効率を評価するために、トランザクション分析情報が不可欠です。これにより、負荷が増加するにつれてパフォーマンスが低下しているかどうかをモニタリングして特定できます。個々のトランザクションを分析すると、長時間実行中のトランザクションが他のトランザクションをブロックしている場合や、単一のトランザクションが過大なデータ量の読み取りまたは書き込みを行っている場合など、速度低下の原因を特定できます。トランザクション分析情報の情報に基づいて、トランザクション境界の最適化、トランザクション内のクエリの調整、スキーマの調整など、ターゲットを絞った調整を行うことができます。これにより、一般的なトランザクションに関連するデータの量を削減できます。また、POC では、想定される負荷レベルでトランザクションの整合性とパフォーマンスを維持する Spanner の能力を実証できます。
ロックの分析情報は、トランザクションのロック動作を可視化することで、ロック競合問題の特定と解決に役立ちます。問題の原因となっている特定の行キー範囲など、ロックの待機に関する情報が表示されます。POC の負荷テストでは、トランザクション ロックの競合がスケーラビリティの制限を引き起こしているかどうかを特定するために、ロックに関する分析情報が重要となります。同時実行の負荷が増加すると、トランザクションが同じデータの更新を競合し始め、待ち時間が長くなり、スループットが低下する可能性があります。この情報は、スキーマの最適化、トランザクション境界の変更、アプリケーション ロジックの調整に役立ちます。これらのアクションにより競合が軽減され、予測されるワークロードで Spanner データベースのパフォーマンスが維持されるため、ロック メカニズムによるパフォーマンスの低下を防ぐことができます。
ホットスポットの分析情報は、ホットスポットの条件に起因するパフォーマンスのボトルネック（特にレイテンシの増加）を特定します。ホットスポットは通常、負荷が高く不均一な場合に発生します。多くの場合、ホットスポットの原因は次のとおりです。
- 最適でないスキーマ設計
- 主キーの選択
- オペレーションをノード間で均等に分散するのではなく、オペレーションをデータの小さなサブセットに集中させるアクセス パターン
POC の負荷テストでは、ホットスポットの分析情報を使用して、スキーマを最適化する場所を決定できます。たとえば、ホットスポットを防ぐために、主キーを調整したり、セカンダリ インデックスを変更することが必要になることがあります。
Key Visualizer は、テーブルとインデックスの両方のキースペース全体にわたるデータベースの使用パターンを経時的で視覚的に表現します。読み取り / 書き込みアクティビティを示すヒートマップを生成し、強度が高く、問題のあるパターンの可能性がある領域をハイライト表示します。POC では、このツールを使用してスキーマ設計を検証し、潜在的なスケーラビリティの制限を特定できます。負荷が増加すると、ワークロードがキースペースとそれぞれのテーブルとインデックスにどのように分散されているかを確認できます。
イントロスペクション テーブル（主に Spanner_SYS テーブルのシステム）は、データベースの内部状態とパフォーマンスに関する豊富な情報を提供します。これらのテーブルには、クエリの実行、トランザクションの動作、ロック競合、スキーマの詳細に関する詳細な統計情報が表示されます。POC の負荷テストでは、これらのイントロスペクション テーブルにより、前述の分析ツールを超えるデータドリブンのパフォーマンス診断を行うことができます。たとえば、データベース内のロック競合の根本原因をトラブルシューティングし、最適化のための実用的な分析情報を導き出すことができます。
最適化
負荷テストは、Spanner 実装のパフォーマンスの問題と潜在的なボトルネックを特定するうえで重要なステップです。これらのテストから得られた分析情報に基づいて、スキーマ設計、トランザクション動作、クエリ パフォーマンス全体の最適化作業を進め、Spanner がワークロードの要件を満たすようにする必要があります。
スキーマ設計を最適化する
初期のスキーマ設計はスケーラビリティとパフォーマンスのベスト プラクティスに基づいていますが、実際の条件でワークロードを実行すると、調整が必要な領域が明らかになることがよくあります。負荷テストは、特定の条件下でのスキーマのパフォーマンスに関する貴重な分析情報を提供します。ホットスポット、データ分散の不均一性、クエリ パフォーマンスの非効率性などの問題をハイライトします。
最適化では、アプリケーションのワークロードの特性に合わせて次の領域を微調整します。
- 主キーの調整: 負荷テストでホットスポットやデータ分散の不均衡が検出された場合は、主キーの設計を確認します。たとえば、キー接頭辞にランダム性を追加して、クエリの効率を維持しながらノードの間でデータをより均等に分散することを検討します。
- インデックスの調整: 負荷テストでは、冗長なインデックスや過剰なインデックスが書き込みスループットに悪影響を及ぼしているかどうかを特定できます。不要なインデックスを削除するか、既存のインデックスを再構築して、クエリのパフォーマンスを改善します。インデックスの選択性を評価し、一般的なクエリパターンと一致していることを確認します。
- インターリーブされたテーブルと階層: 関連するテーブルでテーブルのインターリーブを活用してクエリ レイテンシを短縮できるかどうかを分析します。テスト中に観測されたアクセス パターンに基づいて、インターリーブに関する決定を調整します。逆に、階層構造が予期しないオーバーヘッドを引き起こす場合は、これらのテーブルを個別にモデリングすることを検討します。
スケーラブルなスキーマの構築については、Spanner スキーマ設計のベスト プラクティスをご覧ください。
トランザクションのセマンティクスとクエリを最適化する
負荷テストでは、競合の増加やロックの問題など、トランザクションとクエリの実行の非効率性が明らかになることがよくあります。トランザクション セマンティクスとクエリ構造を最適化して、スループットを最大化し、レイテンシを最小限に抑えます。
- トランザクション モード: ワークロード オペレーションごとに適切なトランザクション モードを使用します。たとえば、データを変更しないクエリには読み取り専用トランザクションを使用し、一括更新と削除にはパーティション化 DML を使用します。
- バッチ処理: 可能であれば、バッチ書き込みオペレーションを使用して、複数のラウンドトリップによって発生するオーバーヘッドを削減します。
- クエリの最適化: クエリをリファクタリングして必要な列と行のみを含め、インデックスを活用し、アプリケーションでクエリ パラメータを使用してオーバーヘッドを削減します。
最適化戦略については、トランザクションの概要と SQL のベスト プラクティスをご覧ください。
反復的な負荷テスト
最適化は反復的なプロセスです。スキーマやクエリの重要な変更のたびに負荷テストを実施して、改善点を検証し、新しいボトルネックが発生していないことを確認します。
さまざまなレベルの同時実行、トランザクション タイプ、データ量で現実的なアプリケーション シナリオをシミュレートし、ピーク時と定常時の条件で Spanner が期待どおりに動作することを確認します。
モニタリングすべき主要な指標
最適化中に、レイテンシ（p50、p99）、スループット、CPU 使用率などの主要な指標を追跡します。
次のステップ
- Spanner POC の計画と実行方法で、Spanner の機能を効果的に評価するために必要な重要な手順、ベスト プラクティス、ツールを確認する。