パフォーマンスの概要

このページでは、最適な条件下にある Spanner で実現可能なおおよそのパフォーマンス、パフォーマンスに影響を与える可能性がある要因、Spanner のパフォーマンスをテストして問題があった場合のトラブルシューティングのヒントを示します。

このページの情報は、GoogleSQL データベースと PostgreSQL データベースの両方に適用されます。

パフォーマンスとストレージの改善

パフォーマンスとストレージの改善は、すべての Spanner リージョンおよびマルチリージョン インスタンス構成に展開されています。改善されたこれらのパフォーマンスを利用する場合、追加料金はなく、アプリケーションに変更を加えることや、Spanner インスタンスで手動で構成する必要もありません。これらのパフォーマンスの改善により、リージョンとマルチリージョンの両方のインスタンス構成で、Spanner ノードのスループットが向上し、レイテンシが改善します。すべてのインスタンス構成でスループットが向上し、一部のインスタンス構成ではストレージが向上しています。

パフォーマンス スループットの向上

すべての Spanner インスタンス構成でパフォーマンスが向上し、スループットが向上しています。次の表に、Spanner インスタンス構成のおおよそのスループット(1 秒あたりのクエリ数)を示します。

インスタンス構成タイプ ピーク時の読み取り(リージョンあたりの QPS)   ピーク時の書き込み(QPS の合計)   スループット最適化書き込みを使用したピーク時の書き込み(QPS の合計)
リージョン 22,500 または 3,500 22,500
デュアルリージョンとマルチリージョン 15,000 または 2,700 15,000

これらのインスタンス構成のパフォーマンス スループットの詳細については、通常のワークロードでのパフォーマンスをご覧ください。

書き込みガイダンスは構成全体に適用されますが、読み取りガイダンスはリージョンごとに異なります(読み取り / 書き込みリージョンまたは読み取り専用リージョンから読み取りを処理できるため)。読み取りガイダンスでは、1 KB の単一行を読み取ることを前提としています。書き込みガイダンスでは、1KB / 行で 1 行ずつ書き込むことを前提としています。

スループットが最適化された書き込みを使用したピーク書き込みパフォーマンスは、100 ミリ秒のバッチ遅延で実現されます。

一般に、インスタンスにコンピューティング容量(ノードまたは処理ユニット)を追加すると、Spanner インスタンスの読み取りスループットと書き込みスループットの両方が比例的にスケーリングされます。たとえば、ノードが 2 つある単一リージョンの Spanner インスタンスで 1 秒あたり最大 45,000 の読み取りを提供できる場合、4 つのノードを持つ単一リージョンの Spanner インスタンスは 1 秒あたり最大 90,000 の読み取りを提供できます。

Spanner のワークロードで期待されるパフォーマンスが得られない場合は、パフォーマンス低下のトラブルシューティングで一般的な原因を確認してください。

保存容量を増量

一部の Spanner リージョンおよびマルチリージョン インスタンス構成では、インスタンス内のコンピューティング容量の各ノード(1,000 処理ユニット)はストレージ容量が 10 TB 高くなります。ストレージの増加は、以下を除くすべての Spanner インスタンス構成で利用できます。

リージョン インスタンス構成

us-west4us-west8

マルチリージョン インスタンス構成

nam10nam-eur-asia1

通常のワークロードでのパフォーマンス

すべての Spanner インスタンス構成でパフォーマンスが向上し、スループットが向上しています。

リージョン構成でのパフォーマンス

リージョン インスタンス構成では、1,000 処理単位(1 ノード)ごとのコンピューティング容量は、次のピーク パフォーマンス(100% の CPU で)を実現できます。

ピーク時の読み取り(リージョンあたりの QPS)   ピーク時の書き込み(QPS の合計)   スループット最適化書き込みを使用したピーク時の書き込み(QPS の合計)
22,500 または 3,500 22,500

オプションの読み取り専用レプリカを許可するリージョン インスタンス構成の場合、オプションの読み取り専用レプリカは毎秒 5,000 回の追加読み取りをサポートできます。

デュアルリージョン構成のパフォーマンス

デュアルリージョン インスタンス構成では、1,000 処理単位(1 ノード)ごとのコンピューティング容量で、次のピーク パフォーマンス(100% の CPU で)を実現できます。スループット最適化書き込みを使用して、テーブル内の数値よりも書き込みスループットを向上させます。

ベース構成名 ピーク時の読み取りの概算値(リージョンあたりの QPS) ピーク時の書き込みの概算値(QPS の合計)
dual-region-australia1 15,000 2,700
dual-region-germany1 15,000 2,700
dual-region-india1 15,000 2,700
dual-region-japan1 15,000 2,700

書き込みガイダンスは構成全体に適用されますが、読み取りガイダンスはリージョンごとに異なります(読み取りはどこからでも処理できるため)。読み取りと書き込みガイダンスでは、行あたり 1 KB のデータで 1 つの行を読み取りおよび書き込みが行われていると想定しています。

マルチリージョン構成でのパフォーマンス

Spanner マルチリージョン インスタンス構成のパフォーマンス特性は、レプリケーション トポロジによって若干異なります。スループット最適化書き込みを使用して、テーブル内の数値よりも書き込みスループットを向上させます。

1,000 処理単位(1 ノード)ごとのコンピューティング容量は、次のピーク パフォーマンス(100% の CPU で)を実現できます。

ベース構成名 ピーク時の読み取りの概算値(リージョンあたりの QPS) ピーク時の書き込みの概算値(QPS の合計)
asia1 15,000 2,700
asia2 15,000 2,700
eur3 15,000 2,700
eur5 15,000 2,700
eur6 15,000
オプションの読み取り専用レプリカごとに 7,500
2,700
nam3 15,000
オプションの読み取り専用レプリカごとに 7,500
2,700
nam6 us-central1us-east1 に 15,000
us-west1us-west2 に 7,500 [1]
2,700
nam7 15,000
オプションの読み取り専用レプリカごとに 7,500
2,700
nam8 15,000 2,700
nam9 15,000 2,700
nam10 15,000 2,700
nam11 15,000
オプションの読み取り専用レプリカごとに 7,500
2,700
nam12 15,000 2,700
nam13 15,000 2,700
nam14 15,000 2,700
nam15 15,000 2,700
nam16 15,000 2,700
nam-eur-asia1 15,000 1,500
nam-eur-asia3 15,000 1,500
  • [1]: us-west1us-west2 は、リージョンごとに 2 つのレプリカではなく 1 つのレプリカが存在するため、QPS パフォーマンスの半分のみ提供します。

書き込みガイダンスは構成全体に適用されますが、読み取りガイダンスはリージョンごとに異なります(読み取りはどこからでも処理できるため)。読み取りと書き込みガイダンスでは、行あたり 1 KB のデータで 1 つの行を読み取りおよび書き込みが行われていると想定しています。

Spanner に対して通常のワークロードを実行する

容量の計画を行う際は、Spanner インスタンスに対し、必ず独自の一般的なワークロードを実行してください。これにより、アプリケーションに最適なリソース割り当てを把握できます。Google の PerfKit Benchmarker は、YCSB を使用してクラウド サービスのベンチマークを行います。Spanner 用の PerfKitBenchmarker チュートリアルに沿って、独自のワークロード用のテストを作成できます。その際は、生成されるベンチマークが本番環境で次の特性を反映するように、ベンチマーク構成 yaml ファイルのパラメータをチューニングする必要があります。

ベンチマーク番号を再現する

ベンチマーク番号を再現するには、throughput_benchmark フォルダ内の対応する yaml ファイルを使用して、PerfKit Benchmarker を使用した Spanner のベンチマーク チュートリアルに沿って操作します。

パフォーマンスの改善が行われたインスタンス構成でインスタンスのベンチマークを行う場合は、改善されたインスタンス構成のいずれかでテストが実行されていることを確認してください。

ゾーンとリージョンの障害からの保護

本番環境でワークロードを実行する場合は、ゾーン全体(リージョン インスタンスの場合)またはリージョン全体(デュアルリージョンおよびマルチリージョン インスタンスの場合)の損失があった場合に、トラフィックの処理を続けられるようコンピューティング容量を十分にプロビジョニングすることが重要です。推奨の最大 CPU 数の詳細については、CPU 使用率が高い場合のアラートをご覧ください。

次のステップ