スケーリング
クラスタのスケーリングとは、クラスタのワークロードまたはデータ ストレージのニーズの変化に応じて、クラスタにノードの追加または削除を行うプロセスです。クラスタを作成するときに、クラスタのノード スケーリング ファクタを構成することもできます。スケーリングを構成する前に、制限事項を確認してください。
Bigtable クラスタは次の方法でスケーリングできます。
- 自動スケーリング
- 手動ノード割り当て
ほとんどの場合、自動スケーリングを選択します。クラスタの自動スケーリングを有効にすると、Bigtable はクラスタを継続的にモニタリングし、設定に基づいてノード数を自動的に調整します。
クラスタの CPU 使用率などの指標に基づいて Bigtable クラスタをスケーリングできます。たとえば、クラスタの負荷が大きく、CPU 使用率が極めて高い場合は、CPU 使用率が下がるまでクラスタにノードを追加できます。また、クラスタの使用率が高くないときにノードを削除すれば、コストを節約できます。
ノードのスケーリング ファクタ
Bigtable クラスタを作成するときに、2 倍のノード スケーリング係数でクラスタを構成できます。この構成を選択すると、Bigtable は 2 つの標準ノードを 1 つの大きなコンピューティング ノードとして扱い、クラスタは常に 2 ノード単位でスケールされます。その結果、クラスタ内のノード間のコンピューティング境界が少なくなります。ワークロードによっては、ノード スケーリングを 2 倍にすると、次のようなメリットがあります。
- スループットとテールレイテンシの安定性の向上
- ホットスポットを吸収する能力の向上
Google Cloud コンソールまたは gcloud CLI を使用すると、ノード スケーリング係数 2 倍でクラスタを作成できます。
自動スケーリングまたは手動ノード割り当てを使用して、2 倍のノード スケーリングを構成できます。
制限については、ノード スケーリング係数の制限をご覧ください。
小規模なクラスタ
2 倍のノード スケーリングは、大規模なワークロードに最適です。標準ノード スケーリング(係数 1)から 2 倍のノード スケーリングへの変更を検討している場合は、費用の影響を考慮してください。1 つのノードで実行されるクラスタなど、小規模なワークロードの場合、2 倍のノード スケーリングを使用すると、コストが 2 倍になります。同様に、以前に 3 つのノードを持つクラスタで実行されていたワークロードに 2 倍のノード スケーリングを使用すると、費用が 33% 増加します。
一方、以前に大規模なクラスタ(50 個のノードを含むクラスタなど)で実行されていたワークロードの場合、ノード数の 2 倍のスケーリング ファクタの効果は、ノード数に比べて小さくなります。
サポートされていないゾーンで 2 倍のノード スケーリング係数を使用してクラスタを作成しようとすると、Bigtable はエラーを返します。
制限事項
クラスタのスケーリングはノードの可用性の影響を受け、完了までに時間がかかります。また、不適切なスキーマ設計を補うことはできず、段階的に行う必要があります。以降のセクションでは、これらの制限事項と、2 倍のノード スケーリングに適用される制限事項について説明します。
ノードの可用性
クラスタで手動ノード割り当てが有効か、自動スケーリングが有効かにかかわらず、ノードの割り当てが適用されます。詳細については、割り当てとノードの可用性をご覧ください。
ノードの再調整中に発生する遅延
クラスタにノードを追加した後、クラスタのパフォーマンスが大幅に向上するまでに、負荷のかかった状態が最大 20 分間続く可能性があります。そのため、短期的にアクティビティが増大するワークロードでは、CPU 負荷が上昇した後でクラスタにノードを追加しても、Cloud Bigtable がデータをリバランスし終わるまでにアクティビティの急増が終了してしまうので、パフォーマンスは向上しません。
この遅延に対応するには、クラスタの負荷が増加する前に、プログラムまたは Google Cloud コンソールを使用してクラスタにノードを追加します。これにより、ワークロードが増加する前に、Bigtable が追加ノード間でデータの再調整を完了できるようになります。ノードの手動割り当てを使用しているクラスタでは、ノード数を変更します。自動スケーリングを使用しているクラスタでは、ノードの最小数を変更します。トラフィックが正常な状態に戻ったら、ノードの設定を元に戻します。
スケールダウンが速すぎることによるレイテンシの増加
クラスタ内のノード数を減らしてスケールダウンする場合、10 分間に 10% を超えるクラスタサイズの縮小は行わないようにしてください。スケールダウンが速すぎると、クラスタ内の残りのノードが一時的に過負荷になる場合にレイテンシが増加するなど、パフォーマンス上の問題が発生する可能性があります。
スキーマ設計に関する問題
テーブルのスキーマ設計に問題がある場合は、Bigtable クラスタにノードを追加してもパフォーマンスが向上しないことがあります。たとえば、テーブル内の 1 つの行に対して多数の読み取りまたは書き込みを行うと、すべての読み取りまたは書き込みがクラスタの同じノードで行われるため、ノードを追加してもパフォーマンスは向上しません。一方、読み取りや書き込みがテーブル内の複数の行に均等に分散している場合は、ノードの追加によって一般にパフォーマンスが向上します。
Bigtable を効果的にスケーリングできるスキーマを設計する方法について詳しくは、スキーマの設計をご覧ください。
ノードのスケーリング ファクタの制限事項
標準ノード スケーリングを使用するクラスタを 2 倍のノード スケーリングを使用するように変換することはできません。新しいクラスタを作成し、作成時に 2 倍のノード スケーリングを有効にする必要があります。インスタンスにクラスタを追加する方法については、インスタンスを変更するをご覧ください。
HDD クラスタで 2 倍のノード スケーリングを構成することはできません。
2 倍のノード スケーリングで構成されたクラスタは、すべての Bigtable リージョンに作成できますが、すべてのゾーンに作成できるわけではありません。次のゾーンには、ノード スケーリングが 2 倍のクラスタを含めることはできません。
- asia-south1-c
- europe-central2-c
- me-central2-b
- me-central2-c
- northamerica-northeast1-a
- northamerica-northeast1-b
- southamerica-east1-c
- us-south1-b
- us-south1-c
次のステップ
- Bigtable の自動スケーリングについて学習する。
- プログラムまたは Google Cloud コンソールでインスタンスをモニタリングする方法を確認する。