Cloud Bigtable のパフォーマンスについて

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

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

Cloud Bigtable では、パフォーマンスを高い精度で予測し、線形的にスケーリングできます。次に説明するパフォーマンス低下の原因を回避した場合、各 Cloud Bigtable ノードで実現されるおおよそのスループットは、クラスタで使用されているストレージの種類に応じて次のようになります。

ストレージの種類 読み取り   書き込み   スキャン
SSD 1 秒あたり最大 10,000 行 または 1 秒あたり最大 10,000 行 または 最大 220 MB/秒
HDD 1 秒あたり最大 500 行 または 1 秒あたり最大 10,000 行 または 最大 180 MB/秒

この推定値は、各行に 1 KB のデータが格納されていることを前提としています。

一般に、クラスタにノードを追加すると、クラスタのパフォーマンスは線形的にスケーリングします。たとえば、ノードが 10 個の SSD クラスタを作成すると、通常の読み取り専用または書き込み専用のワークロードの場合、このクラスタでは 1 秒あたり最大 100,000 行をサポートできます。

Cloud Bigtable の容量の計画

高スループットと低レイテンシのトレードオフ

Cloud Bigtable クラスタを計画する際は、スループットとレイテンシのトレードオフを考慮することが重要です。Cloud Bigtable は幅広いアプリケーションで使用されており、ユースケースが異なれば最適化目標も異なります。たとえば、バッチデータ処理ジョブでは、スループットは重視しても、レイテンシはそれほど重視しないことがあります。一方、ユーザー リクエストを処理するオンライン サービスでは、スループットよりもレイテンシの方が優先されることがあります。そのため、目的に応じて容量を計画することが重要です。

一般的なワークロードでのパフォーマンス セクションの数値はスループットを優先する場合は達成できますが、このような負荷での Cloud Bigtable のテール レイテンシは、レイテンシの影響を受けやすいアプリケーションには高すぎる可能性があります。Cloud Bigtable では一般に、クラスタの CPU 負荷が 70% 未満のとき、最適なレイテンシとなります。レイテンシの影響を受けやすいアプリケーションの場合、アプリケーションの最大 Cloud Bigtable QPS に対し 2 倍以上の容量を計画することをおすすめします。容量をこのようにすると、Cloud Bigtable クラスタは CPU 負荷 50% 未満で動作するため、フロントエンド サービスに対するレイテンシが低くなります。また、クラスタ内のノード間でトラフィックの不均衡が生じる可能性がある、トラフィックの急増やキーアクセス ホットスポットのためのバッファも提供されます。

Cloud Bigtable に対して独自の一般的なワークロードを実行する

容量の計画を行う際は、Cloud Bigtable クラスタに対し、必ず独自の一般的なワークロードを実行してください。これにより、アプリケーションに最適なリソース割り当てを把握できます。

Google の PerfKit Benchmarker は、YCSB を使用してクラウド サービスのベンチマークを行います。Cloud Bigtable 用の PerfKitBenchmarker チュートリアルに従って、独自のワークロード用のテストを作成できます。その際は、生成されるベンチマークが本番環境で次の特性を反映するように、ベンチマーク構成 yaml ファイルのパラメータを調整する必要があります。

  • テーブルの合計サイズ。比例させることもできますが、少なくとも 100 GB を使用してください。
  • 行データの形状(行キーのサイズ、列の数、行のデータサイズなど)
  • データアクセス パターン(行キーの分布)
  • 読み取りと書き込みの混在

ベスト プラクティスについては、Cloud Bigtable を使ったパフォーマンス テストをご覧ください。

パフォーマンス低下の原因

Cloud Bigtable のパフォーマンスが上記の推定値よりも低くなることがあります。その原因として次のことが考えらます。

  • テーブルのスキーマが正しく設計されていません。Cloud Bigtable で良好なパフォーマンスを得るには、テーブル間に読み取りおよび書き込みを均等に分散できるスキーマを設計することが不可欠です。詳細については、スキーマの設計をご覧ください。
  • Cloud Bigtable テーブルの行に大量のデータが含まれています。前述のパフォーマンス推定値は、各行に 1 KB のデータが含まれていることを前提としています。1 行あたり大量のデータを読み書きできますが、1 行あたりのデータ量を増やすと、1 秒あたりの行数も減少します。
  • Cloud Bigtable テーブルの行に大量のセルが含まれています。Cloud Bigtable が行内の各セルを処理するため時間がかかります。セルが多くなると、テーブルにデータを格納する際やネットワーク経由でのデータを送信する際のオーバーヘッドも増加します。たとえば、1 KB(1,024 バイト)のデータを格納する場合、1 バイトずつ 1,024 個のセルに分散させるのではなく、データを 1 つのセルに格納したほうがスペース効率が良くなります。必要以上に多くのセルにデータを分割すると、最高のパフォーマンスが得られない可能性があります。タイムスタンプ付きバージョンのデータが列に複数含まれることで行に多数のセルが含まれている場合は、最新の値のみを保持することを検討してください。既存のテーブルに対する別の方法としては、以前のバージョンすべての削除を書き換えごとに送信することが挙げられます。
  • Cloud Bigtable クラスタを構成するノード数が不足しています。Cloud Bigtable クラスタが過負荷状態になった場合は、ノードを追加するとパフォーマンスが向上します。モニタリング ツールを使用して、クラスタが過負荷状態になっているかどうかチェックしてください。
  • 最近 Cloud Bigtable クラスタがスケールアップまたはスケールダウンされています。クラスタ内のノード数を増やしてからスケールアップすると、負荷がかかった状態ではクラスタのパフォーマンスに大幅な改善が見られるまでに最大 20 分を要する場合があります。クラスタ内のノード数を減らしてスケールダウンする場合は、レイテンシの急増を最小限に抑えるため、10 分間は 10% を超えるクラスタサイズの縮小は行わないようにしてください。
  • Cloud Bigtable クラスタが HDD ディスクを使用しています。ほとんどの場合、クラスタには SSD ディスクを使用すべきです。SSD ディスクを使用すると、HDD ディスクに比べてパフォーマンスが大幅に向上します。詳しくは、SSD ストレージか HDD ストレージの選択をご覧ください。
  • ネットワーク接続で問題が発生しています。ネットワークの問題が発生するとスループットが低下し、読み取りと書き込みに要する時間が通常より長くなります。特に、クライアントが Cloud Bigtable クラスタと同じゾーンで実行されていない場合や、クライアントが Google Cloud の外部で実行されている場合には、問題が発生することがあります。

ワークロードが異なるとパフォーマンスも変化するため、最も正確なベンチマークが得られるよう、テストは自分のワークロードを使って実行してください。

レプリケーションとパフォーマンス

レプリケーションを有効にすると、Cloud Bigtable インスタンスのパフォーマンスに影響します。その影響は、一部の指標ではプラスですが、その他の指標ではマイナスになります。レプリケーションの有効化を決定する前に、パフォーマンスに与える可能性のある影響を理解する必要があります。

読み取りスループット

特に複数クラスタ ルーティングを使用する場合は、レプリケーションによって読み取りスループットが向上します。さらに、レプリケーションで、Cloud Bigtable データをアプリケーションのユーザーの地理的位置の近くに配置することで、読み取りのレイテンシを短縮できます。

書き込みスループット

レプリケーションによって可用性と読み取りパフォーマンスが向上する可能性はありますが、書き込みスループットは向上しません。1 つのクラスタへの書き込みは、インスタンス内の他のすべてのクラスタに複製される必要があります。したがって、各クラスタは、他のクラスタから変更を pull する目的で CPU リソースを消費します。レプリケーションでは各クラスタが追加の処理を行う必要があるので、実際には書き込みスループットが低下する可能性もあります。

たとえば、単一クラスタ インスタンスがあり、そのクラスタに 3 つのノードがあるとします。

3 つのノードがある単一クラスタ インスタンス

クラスタにノードを追加した場合に書き込みスループットに及ぶ影響は、インスタンスに 3 ノードクラスタをもう 1 つ追加してレプリケーションを有効にする場合とは異なります。

元のクラスタにノードを追加する場合: 3 つのノードをクラスタに追加して、合計 6 つのノードにできます。インスタンスの書き込みスループットは 2 倍になりますが、インスタンスのデータは 1 つのゾーンでのみ利用可能です。

6 つのノードがある単一クラスタ インスタンス

レプリケーションがある場合、あるいは、3 つのノードを持つ 2 番目のクラスタを追加できます(合計 6 つのノード)。インスタンスは、各データを 2 回書き込むようになります。書き込みが最初に受信されたときと、それがもう一方のクラスタに複製されるときです。書き込みスループットは向上せず、低下する可能性もありますが、2 つの異なるゾーンでデータを利用できるというメリットがあります。

6 つのノードがある 2 クラスタ インスタンス

こうした例における単一クラスタ インスタンスでは、複製インスタンスが処理できる 2 倍の書き込みスループットを処理できます(各インスタンスのクラスタに合計 6 つのノードがある場合でも)。

レプリケーション レイテンシ

複数クラスタ ルーティングを使用する場合、Cloud Bigtable のレプリケーションは結果整合性があります。一般に、遠距離間でデータを複製するには時間がかかります。異なるリージョンの複製クラスタは、通常、同じリージョンの複製クラスタよりもレプリケーション レイテンシが高くなります。

アプリ プロファイルとトラフィック ルーティング

使用例によっては、Cloud Bigtable トラフィックをルーティングするために 1 つ以上のアプリ プロファイルを使用します。各アプリ プロファイルは、複数のクラスタ ルーティングまたは単一クラスタ ルーティングを使用します。ルーティングの選択はパフォーマンスに影響を与える可能性があります。

複数クラスタ ルーティングは、レイテンシを最小限に抑えることができます。複数クラスタ ルーティングを使用するアプリ プロファイルは、アプリケーションの観点から、インスタンス内の最も近いクラスタに自動的にリクエストをルーティングします。その後、書き込みはインスタンス内の他のクラスタに複製されます。このように最短距離が自動的に選択されるため、レイテンシが可能な限り最小限に抑えられます。

単一クラスタ ルーティングを使用するアプリ プロファイルは、ワークロードの分離や単一クラスタでの read-after-write セマンティクスを使用するなど、特定の使用例には最適ですが、複数クラスタ ルーティングのようにレイテンシを低減することはできません。

こうした使用例に合わせてアプリ プロファイルを構成する方法については、レプリケーション設定の例をご覧ください。

Cloud Bigtable が時間の経過とともにデータを最適化する方法

各テーブルの基盤となるデータを格納するために、Cloud Bigtable はデータを複数のタブレットに分割します。タブレットは、Cloud Bigtable クラスタ内のノード間を移動できます。このストレージ方式により、Cloud Bigtable は、2 つの異なる戦略を用いて、時間の経過に伴うデータの最適化を実行できます。

  1. Cloud Bigtable は、各 Cloud Bigtable ノード上にほぼ同じ量のデータを格納しようと試みます。
  2. Cloud Bigtable はすべての Cloud Bigtable ノード上に、読み取りオペレーションと書き込みオペレーションを均等に分散しようと試みます。

この 2 つの戦略は互いに矛盾することがあります。たとえば、あるタブレットの行に対する読み取り頻度が極めて高い場合、Cloud Bigtable は、そのタブレットをそれ専用のノードに格納することがあります。その結果、一部のノードに格納されるデータが他のノードより多くなるとしてもです。

このプロセスで、Cloud Bigtable は、1 つのタブレットを 2 つ以上の小さなタブレットに分割して、タブレット サイズを減らしたり、既存のタブレット内のアクセスが集中している行を分離したりすることもあります。

以下の各セクションで、これらの戦略について詳しく説明します。

各ノードにデータ量を分散配置する

Cloud Bigtable テーブルにデータを書き込む際に、Cloud Bigtable は、テーブルのデータを複数のタブレットに分割します。各タブレットにはテーブル内の連続する範囲の行が格納されます。

ごく少量のデータをテーブルに書き込んだ場合、Cloud Bigtable は、クラスタ内の単一のノード上にすべてのタブレットを格納します。

1 つのノードに 4 つのタブレットが存在するクラスタ。

タブレットがたまってくると、Cloud Bigtable は、一部をクラスタ内の別のノードに移して、クラスタ全体でデータ量が均等に分散されるようにします。

以降追加されたタブレットは複数のノードに分配される。

各ノードに読み取りオペレーションと書き込みオペレーションを分散させる

スキーマの設計が正しければ、読み取りオペレーションと書き込みオペレーションがテーブル全体にほぼ均等に分散されるはずです。ただし、特定の行に対するアクセス頻度が他の行より高くなるのを避けられないケースもあります。Cloud Bigtable は、各ノードにタブレットを分散配置する際に読み取りオペレーションと書き込みオペレーションを考慮することで、このようなケースに対応できるようにします。

たとえば、読み取りオペレーションの 25% がクラスタ内の少数のタブレットに集中しており、それ以外のすべてのタブレットには読み取りオペレーションが均等に分散しているとします。

48 タブレットのうち、25% の読み取りオペレーションが 3 つのタブレットに集中している。

Cloud Bigtable は既存のタブレットを再配置して、読み取りオペレーションがクラスタ全体でできる限り均等に分散するようにします。

アクセスが集中している 3 つのタブレットを専用のノードに分離する。

Cloud Bigtable を使ったパフォーマンス テスト

Cloud Bigtable に依存するアプリケーションのパフォーマンス テストを実行する場合は、テストを計画し実行する際、次のガイドラインに従ってください。

  • 十分なデータでテストする。
    • 本番環境インスタンスのテーブルに含まれるデータがノードあたり合計 100 GB 以下の場合は、同じ量のデータのテーブルでテストします。
    • テーブルに含まれるデータがノードあたり 100 GB を超える場合は、ノードあたり 100 GB 以上のデータを含むテーブルでテストします。たとえば、本番環境のインスタンスに 1 つの 4 ノードクラスタがあり、インスタンスのテーブルに合計 1 TB のデータが含まれている場合は、400 GB 以上のテーブルを使用してテストを実行します。
  • 単一のテーブルでテストする
  • ノードあたりの推奨ストレージ使用率を超えないようにします。詳細については、ノードあたりのストレージ使用率をご覧ください。
  • テスト前に、負荷の大きな事前テストを数分間実行します。この手順により、Cloud Bigtable に、観察したアクセス パターンに基づいて、各ノード間にデータを分散させる機会が与えられます。
  • 最低 10 分間テストを実行します。この手順により、Cloud Bigtable はデータをさらに最適化するので、ディスクからの読み取りだけでなく、メモリからのキャッシュ経由の読み取りも確実にテストできます。

パフォーマンスの問題のトラブルシューティング

Cloud Bigtable が原因でアプリケーションでパフォーマンスのボトルネックが発生していると思われる場合は、以下のすべての項目をチェックしてください。

  • Key Visualizer でテーブルのスキャン結果を確認します。Cloud Bigtable 用 Key Visualizer ツールは、クラスタ内の各テーブルを毎日スキャンし、その使用パターンを表示します。Key Visualizer を使用すると、使用パターンが問題の原因かどうかを確認できます。たとえば、ホットスポットになっている行や CPU の過剰使用を確認できます。こちらで Key Visualizer の使い方をご覧ください。
  • Cloud Bigtable の読み取りと書き込みを実行するコードをコメントアウトしてみます。その結果、パフォーマンスの問題が発生しなくなったら、おそらく、次善のパフォーマンスしか得られないような方法で Cloud Bigtable を使用しています。パフォーマンスの問題が解決しない場合は、おそらく Cloud Bigtable とは無関係の問題が発生しています。
  • 作成するクライアント数をできるだけ少なくします。Cloud Bigtable でクライアントを作成する処理は比較的負荷の大きいオペレーションです。このため、作成するクライアント数はできるだけ少なくする必要があります。

    • レプリケーションを使用する場合や、アプリ プロファイルを使用してインスタンスへのトラフィックの種類を識別する場合は、アプリ プロファイルごとに 1 つのクライアントを作成し、アプリ全体でそのクライアントを共有します。
    • レプリケーションやアプリ プロファイルを使用しない場合は、クライアントを 1 つだけ作成し、アプリケーション全体で共有します。

    Java 用 HBase クライアントを使用している場合は、クライアントではなく Connection オブジェクトを作成するため、確立する接続の数をできる限り少なくする必要があります。

  • テーブル内で多数の異なる行の読み取りと書き込みが行われていることを確認します。Cloud Bigtable では、読み取りオペレーションと書き込みオペレーションがテーブル全体に均等に分散されており、結果として、ワークロードがクラスタ内のすべてのノードに分散されているときに、最高のパフォーマンスが得られます。読み取りオペレーションと書き込みオペレーションをすべての Cloud Bigtable ノードに分散させることができない場合は、パフォーマンスが低下します。

    読み取りおよび書き込みオペレーションが少数の行に限られていることが判明したら、スキーマの設計を見直して読み取りおよび書き込みオペレーションがより均等に分散されるようにする必要があります。

  • 読み取りオペレーションと書き込みオペレーションで、ほぼ同じパフォーマンスが得られていることを確認します。読み取りオペレーションが書き込みオペレーションに比べてかなり速いことが判明したら、存在しない行キー、またはごく少数の行しか含まれていない広範囲の行キーを読み取ろうとしている可能性があります。

    読み取りオペレーションと書き込みオペレーションの間で正当な比較を行うには、読み取りオペレーションの 90% 以上が有効な結果を返すという状態を目指す必要があります。また、広範な行キーを読み取る場合は、存在する可能性のある最大行数ではなく、その範囲内の実際の行数に基づくパフォーマンスを計測するようにします。

  • データに適したタイプの書き込みリクエストを使用します。データの書き込みに最適な方法を選択すると、高いパフォーマンスを維持できます。

次のステップ