スケーリング
クラスタのスケーリングとは、クラスタのワークロードまたはデータ ストレージのニーズの変化に応じて、クラスタにノードの追加または削除を行うプロセスです。
Bigtable クラスタは次の方法でスケーリングできます。
- 自動スケーリング
- 手動ノード割り当て
ほとんどの場合、自動スケーリングを選択します。クラスタの自動スケーリングを有効にすると、Bigtable はクラスタを継続的にモニタリングし、設定に基づいてノード数を自動的に調整します。
Bigtable クラスタは、クラスタの CPU 使用率などの指標に基づいてスケーリングできます。たとえば、クラスタの負荷が大きく、CPU 使用率が極めて高い場合は、CPU 使用率が下がるまでクラスタにノードを追加できます。また、クラスタの使用率が高くないときにノードを削除すれば、コストを節約できます。
ノードのスケーリング ファクタ
Bigtable クラスタを作成するときに、2 倍のノード スケーリング係数でクラスタを構成できます。この構成を選択すると、Bigtable は 2 つの標準ノードを大きな単一のコンピューティング ノードとして扱い、クラスタは常に 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 コンソールでインスタンスをモニタリングする方法を確認する。