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

友人の家を訪ねたいとします。飛行機を使うべきでしょうか?それは、行き先によります。友人が近くに住んでいるなら、飛行機など使わなくてももっと良い手段があるでしょう。しかし、友人がかなり遠方に住んでいるなら、飛行機を利用するのが一番早いでしょう。

Cloud Bigtable を使用するのは、移動に飛行機を利用するのとよく似ています。Cloud Bigtable は、超大容量のデータ(数テラバイトまたは数ペタバイト)を比較的長期間にわたって処理する場合に卓越した性能を発揮します。少量のデータをほんの短い時間処理するのに適した設計にはなっていません。Cloud Bigtable を数 GB のデータを使って 30 秒ほどテストしたとしても、その本来のパフォーマンスを把握することは難しいでしょう。

ここでは、Cloud Bigtable によって得られるパフォーマンスについて詳しく説明します。

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

通常のワークロードを与えた場合、Cloud Bigtable は、極めて予測可能性の高いパフォーマンスを実現します。すべてが問題なく動作している場合、Cloud Bigtable クラスタの各ノードは、クラスタで使用するストレージの種類に応じて、以下のパフォーマンスを実現することが予想されます。

ストレージの種類 読み取り   書き込み スキャン
SSD 6 ms で 10,000 行/秒 または 6 ms で 10,000 行/秒 220 MB/秒
HDD 200 ms で 500 行/秒 または 50 ms で 10,000 行/秒 180 MB/秒

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

一般に、クラスタのパフォーマンスは、クラスタにノードを追加すると、直線的に向上します。たとえば、10 ノードの SSD クラスタは、通常の読み取り専用または書き込み専用ワークロードのもとで、100,000 QPS(読み取りまたは書き込みオペレーション 1 回あたりのレイテンシは 6 ミリ秒)まで実現可能です。

これらのパフォーマンス推定値はガイドライン的な数値であって、厳格なルールというわけではありません。ノードあたりのパフォーマンスは、負荷やテーブルの各行の通常サイズに応じて変わります。

また、これらの推定値は、読み取り専用または書き込み専用のワークロードのパフォーマンスの推定値です。読み取りと書き込みの両方を行うワークロードの場合、パフォーマンスが異なります。ワークロードによっては、全体のスループットが読み取り専用または書き込み専用ワークロードの標準的な 1 秒あたりの行数よりも低くなる場合があります。

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

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

  • テーブルのスキーマが正しく設計されていません。 Cloud Bigtable で良好なパフォーマンスを得るには、テーブル間に読み取りおよび書き込みを均等に分散できるスキーマを設計することが不可欠です。詳細については、スキーマの設計をご覧ください。
  • ワークロードが Cloud Bigtable で処理するのに適していません。 テストデータが少量(300 GB 未満)の場合、またはテスト期間が短い場合(数分とか数時間ではなく、数秒)、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 分ほど負荷が多くなります。
  • Cloud Bigtable クラスタが HDD ディスクを使用しています。 ほとんどの場合、クラスタには SSD ディスクを使用すべきです。SSD ディスクを使用すると、HDD ディスクに比べてパフォーマンスが大幅に向上します。詳しくは、SSD ストレージか HDD ストレージの選択をご覧ください。
  • Cloud Bigtable インスタンスは開発インスタンスです。 開発インスタンスのパフォーマンスは 1 つの単一ノードクラスタがあるインスタンスと同等で、本番環境インスタンスと同様には動作しません。特にインスタンスの負荷が大きい場合、大量のエラーが発生する可能性があります。
  • ネットワーク接続で問題が発生しています。 ネットワークの問題が発生するとスループットが低下し、読み取りと書き込みに要する時間が通常より長くなります。たとえば、クライアントが Cloud Bigtable クラスタと同じゾーンで実行されていない場合や、クライアントが Google Cloud Platform 以外で実行されている場合に問題が発生する可能性があります。

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

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

レプリケーションを有効にすると、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 に依存するパフォーマンス テストを実行する場合は、テストを計画および実行する際に、必ず以下の手順に従ってください。

  1. 本番環境インスタンスを使用します。 開発インスタンスでは、負荷状態での本番環境インスタンスの動作を正確に把握することはできません。
  2. 少なくとも 300 GB のデータを使用します。 Cloud Bigtable のパフォーマンスは、1 TB 以上のデータを処理するときに最も高くなります。ただし、3 ノードクラスタ上でのパフォーマンス テストであれば、300 GB のデータであっても相応の結果が得られます。それより大きな規模のクラスタでは、ノードあたり 100 GB 以上のデータを使用します。単純さを保つために、単一のテーブルでテストしてください。
  3. ノードあたりの推奨ストレージ利用率を超えないようにします。 詳細については、ノードあたりのストレージ使用率をご覧ください。
  4. テスト前に、負荷の大きな事前テストを数分間実行します。 この手順により、Cloud Bigtable に、観察したアクセス パターンに基づいて、各ノード間にデータを分散させる機会が与えられます。
  5. 最低 10 分間テストを実行します。 この手順により、Cloud Bigtable はデータをさらに最適化するので、ディスクからの読み取りだけでなく、メモリからのキャッシュ経由の読み取りも確実にテストできます。

独自のパフォーマンス テストを開発する土台として、Cloud Bigtable loadtest ツールを使用できます。Go で作成されたこの loadtest ツールは、読み取り 50%、書き込み 50% の単純なワークロードを実行します。

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

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% 以上が有効な結果を返すという状態を目指す必要があります。また、広範な行キーを読み取る場合は、存在する可能性のある最大行数ではなく、その範囲内の実際の行数に基づくパフォーマンスを計測するようにします。

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Bigtable ドキュメント