パフォーマンスについて
このページでは、最適な条件下にある Bigtable で実現可能なおおよそのパフォーマンス、パフォーマンスに影響を与える可能性がある要因、Bigtable のパフォーマンスをテストして問題があった場合のトラブルシューティングのヒントを示します。
通常のワークロードでのパフォーマンス
Bigtable では、パフォーマンスを高い精度で予測し、線形的にスケーリングできます。このページで説明するパフォーマンス低下の原因を回避した場合、各 Bigtable ノードで実現されるおおよそのスループットは、クラスタで使用されているストレージの種類に応じて次のようになります。
| ストレージ ティア | 読み取り | 書き込み | スキャン | ||
|---|---|---|---|---|---|
| インメモリ階層（プレビュー） | 1 秒あたり最大 120,000 行1 | または | 1 秒あたり最大 10,000 行2 | なし | |
| SSD | 1 秒あたり最大 17,000 行 | または | 1 秒あたり最大 14,000 行 | または | 最大 220 MBps |
| HDD | 1 秒あたり最大 500 行 | または | 1 秒あたり最大 10,000 行 | または | 最大 180 MBps |
| アクセス頻度の低いストレージ | 1 秒あたり最大 100 行 | または | 1 秒あたり最大 10,000 行 | または | 最大 36 MBps |
この推定値は、各行に 1 KB のデータが格納されていることを前提としています。
1 Enterprise Plus ノードには 1 秒あたり 40,000 行が含まれており、40,000 行単位でノードあたり 1 秒あたり 120,000 行まで垂直方向にスケーリングできます。詳細については、インメモリ ティアをご覧ください。
2 インメモリ階層のデータに対する 1 秒あたりの行の書き込み数が多いと、書き込みスループットに影響する可能性があります。
一般に、クラスタにノードを追加すると、クラスタのパフォーマンスは線形的にスケーリングします。たとえば、ノードが 10 個の SSD クラスタを作成すると、インメモリ ティアが有効になっていない場合、通常の読み取り専用または書き込み専用のワークロードの場合、このクラスタでは 1 秒あたり最大 140,000 行をサポートできます。インメモリ階層を有効にすると、クラスタは 1 秒あたり最大 120 万行の読み取りスループットをサポートできます。
Bigtable の容量を計画する
Bigtable クラスタを計画する際は、レイテンシとスループットのどちらを最適化するかを決定します。たとえば、バッチデータ処理ジョブでは、スループットは重視しても、レイテンシはそれほど重視しないことがあります。一方、ユーザー リクエストを処理するオンライン サービスの場合は、スループットよりもレイテンシの方を優先する場合があります。スループットを最適化するときに、一般的なワークロードでのパフォーマンス セクションの数値を達成できます。
インメモリ階層
インメモリ階層が有効になっている場合、各ノードには 1 秒あたり 40,000 行が含まれます。ノードを水平方向に追加すると、クラスタの総容量が増加します。また、各ノードは、インメモリ読み取りスループットをサポートするために、ノードあたり最大 1 秒あたり 120,000 行まで垂直方向にスケーリングできます。垂直スケーリングの上限に達すると、Bigtable 自動スケーリングは追加のノードを追加して水平方向にスケーリングします。手動スケーリングを使用するクラスタは、スループット容量に達するまでインメモリの垂直スケーリングをサポートします。1 秒あたり 40,000 行を超える垂直スケーリングは、ノードの時間単位の費用に乗数を適用して課金されます。詳細は、料金をご覧ください。
各インメモリ ノードには 8 GB のストレージ容量が含まれています。スループットは垂直方向にスケーリングできますが、ストレージ容量はノードごとに固定されます。ただし、水平スケーリングでは、新しいノードごとに 8 GB のメモリが追加されます。垂直スケーリング中にストレージが増加しないため、ノードがインメモリ スループットを垂直方向にスケーリングすると、ワークロードのミス率が上昇する可能性があります。
CPU 使用率
ほとんどの場合、自動スケーリングを使用することをおすすめします。これにより、Bigtable は使用状況に基づいてノードを追加または削除できます。詳細については、自動スケーリングをご覧ください。
自動スケーリング ターゲットを構成する場合、または手動ノード割り当てを選択する場合は、次のガイドラインを使用します。これらのガイドラインは、インスタンスに存在するクラスタの数に関係なく適用されます。ノードの手動割り当てを使用するクラスタでは、最適なパフォーマンスを実現するために、CPU 使用率をこれらの値未満に保つことを目標に、クラスタの CPU 使用率をモニタリングする必要があります。
| 最適化の目標 | 最大 CPU 使用率 |
|---|---|
| スループット | 90% |
| レイテンシ | 60% |
モニタリングの詳細については、モニタリングをご覧ください。
ストレージの利用率
容量計画のもう一つの考慮事項はストレージです。クラスタのストレージ容量は、ストレージ タイプとクラスタ内のノード数によって決まります。クラスタに保存されるデータ量が増加すると、Bigtable はクラスタ内のすべてのノードにデータを分散してストレージを最適化します。
ノードのストレージ使用量は、クラスタのストレージ使用率（バイト数）をクラスタ内のノード数で割ることで計算できます。たとえば、3 つの HDD ノードと 9 TB のデータのあるクラスタについて考えてみましょう。各ノードに格納される容量は約 3 TB です。これは、ノード上限（16 TB）あたりの HDD ストレージの 18.75% に相当します。
ストレージの使用率を高めると、クラスタ全体で CPU のニーズを満たすのに十分なノード数がある場合でも、ワークロードでのクエリ処理のレイテンシが増加する可能性があります。これは、ノードあたりのストレージが大きいほど、インデックス作成などのバックグラウンド処理が必要になるためです。より多くのストレージを処理するためにバックグラウンドの作業が増加すると、レイテンシが増加し、スループットが低下する可能性があります。
自動スケーリングの設定を構成する際は、まず次の設定を行います。手動ノード割り当てを選択した場合は、クラスタのストレージ使用率をモニタリングし、以下を維持するためにノードを追加または削除します。
| 最適化の目標 | 最大ストレージ使用率 |
|---|---|
| スループット | 70% |
| レイテンシ | 60% |
詳細については、ノードあたりのストレージをご覧ください。
Bigtable に対してワークロードを実行する
容量の計画を行う際は、Bigtable クラスタに対して必ずワークロードを実行して、アプリケーションに最適なリソース割り当てを決定してください。
Google の PerfKit Benchmarker は、YCSB を使用してクラウド サービスのベンチマークを行います。Bigtable 用の PerfKitBenchmarker チュートリアルに沿って、ワークロード用のテストを作成できます。その際は、生成されるベンチマークが次の本番環境の特性を反映するように、ベンチマーク構成 YAML ファイルのパラメータを調整します。
- テーブルの合計サイズ（比例しますが、少なくとも 100 GB）。
- 行データの形状（行キーのサイズ、列の数、行のデータサイズなど）
- データアクセス パターン（行キーの分布）
- 読み取りと書き込みの混在
ベスト プラクティスについては、Bigtable を使ったパフォーマンス テストをご覧ください。
パフォーマンス低下の原因
Bigtable のパフォーマンスが推定値よりも低くなることがあります。その原因として次のことが考えらます。
- 1 つの読み取りリクエストで連続していない行キーまたは行範囲を大量に読み取る。Bigtable はテーブルをスキャンし、リクエストされた行を順次読み取ります。この並列性の欠如が全体的なレイテンシに影響を与え、ホットノードが読み取られると、テール レイテンシの増加につながる場合があります。詳細については、読み取りとパフォーマンスをご覧ください。
- テーブルのスキーマが正しく設計されていません。Bigtable で良好なパフォーマンスを得るには、各テーブルに読み取りおよび書き込みを均等に分散できるスキーマを設計することが不可欠です。また、あるテーブルのホットスポットが、同じインスタンスの他のテーブルのパフォーマンスに影響する可能性もあります。詳しくは、スキーマ設計のベスト プラクティスをご覧ください。
- Bigtable テーブルの行に大量のデータが含まれています。パフォーマンスの推定値は、各行に 1 KB のデータが含まれていることを前提としています。1 行あたり大量のデータを読み書きできますが、1 行あたりのデータ量を増やすと、1 秒あたりの行数も減少します。
- Bigtable テーブルの行に大量のセルが含まれています。 Bigtable が行内の各セルを処理するため時間がかかります。セルが多くなると、テーブルにデータを格納する際やネットワーク経由でのデータを送信する際のオーバーヘッドも増加します。たとえば、1 KB（1,024 バイト）のデータを格納する場合、1 バイトずつ 1,024 個のセルに分散させるのではなく、データを 1 つのセルに格納したほうがスペース効率が良くなります。必要以上に多くのセルにデータを分割すると、最高のパフォーマンスが得られない可能性があります。タイムスタンプ付きバージョンのデータが列に複数含まれることで行に多数のセルが含まれている場合は、最新の値のみを保持することを検討してください。既存のテーブルに対する別の方法としては、以前のバージョンすべての削除を書き換えごとに送信することが挙げられます。
Bigtable クラスタに十分なノードが存在しません。クラスタのノードは、クラスタの読み取りと書き込み、ストレージの追跡、圧縮などのメンテナンス タスクを行うクラスタを提供します。コンピューティングとストレージの両方の推奨制限を満たすのに十分なノードをクラスタで確保する必要があります。モニタリング ツールを使用して、クラスタが過負荷状態になっているかどうかチェックしてください。
- コンピューティング - Bigtable クラスタの CPU が過負荷状態のときにノードを追加すると、より多くのノードにワークロードを分散してパフォーマンスを改善できます。
- ストレージ - ノードあたりのストレージ使用量が推奨値を上回る場合は、クラスタがリクエストを処理するのに十分な CPU を備えていても、最適なレイテンシとスループットを維持するためにノードを追加します。これは、ノードあたりのストレージを増やすと、ノードあたりのバックグラウンド メンテナンス作業が増えるためです。詳細については、ストレージ使用量とパフォーマンスのトレードオフをご覧ください。
最近 Bigtable クラスタがスケールアップまたはスケールダウンされています。自動スケーリングによってクラスタ内のノード数が増加した後、パフォーマンスが大幅に向上するまでに、負荷のかかった状態が最大 20 分間続く可能性があります。Bigtable は、負荷に基づいてクラスタノードをスケーリングします。
クラスタ内のノード数を減らしてスケールダウンする場合は、レイテンシの急増を最小限に抑えるため、10 分間は 10% を超えるクラスタサイズの縮小は行わないようにしてください。
Bigtable クラスタが HDD ディスクを使用しています。ほとんどの場合、クラスタには SSD ディスクを使用すべきです。SSD ディスクを使用すると、HDD ディスクに比べてパフォーマンスが大幅に向上します。詳しくは、SSD ストレージか HDD ストレージの選択をご覧ください。
ネットワーク接続で問題が発生しています。ネットワークの問題が発生するとスループットが低下し、読み取りと書き込みに要する時間が通常より長くなります。特に、クライアントが Bigtable クラスタと同じゾーンで実行されていない場合や、クライアントが Google Cloudの外部で実行されている場合は、問題が発生することがあります。
レプリケーションを有効にしていますが、アプリケーションが古いクライアント ライブラリを使用しています。レプリケーションを有効にした後にレイテンシが増加した場合は、アプリケーションで使用している Cloud Bigtable クライアント ライブラリが最新かどうか確認してください。以前のバージョンのクライアント ライブラリは、レプリケーションをサポートするように最適化されていない場合があります。Cloud Bigtable クライアント ライブラリで、使用しているクライアント ライブラリの GitHub リポジトリを探してください。ライブラリのバージョンを確認して、必要に応じてアップグレードしてください。