自動スケーリング

このページでは、自動スケーリングの仕組みについて説明します。このページを読む前に、Bigtable の概要とインスタンス、クラスタ、ノードについて理解しておく必要があります。

Bigtable では、インスタンスはクラスタ用のコンテナで、リクエストを処理するロケーション固有のリソースです。各クラスタには 1 つ以上のノードがあります。ノードは、データの管理に使用されるコンピューティングリソースです。インスタンスにクラスタを作成するときに、手動でのノードの割り当てか自動スケーリングを選択します。

手動でのノード割り当ての場合、ユーザーが変更するまで、クラスタ内のノードの数は変わりません。自動スケーリングを有効にすると、Bigtable がクラスタを継続的にモニタリングし、必要に応じてクラスタ内のノードの数を自動的に調整します。自動スケーリングは、すべての Bigtable リージョンの HDD クラスタと SSD クラスタの両方で機能します。

自動スケーリングの構成は、Google Cloud Console、gcloud、または Java 用 Cloud Bigtable クライアントライブラリを使用して行います。

自動スケーリングを使用する場合

ほとんどの場合は、自動スケーリングを有効にすることをおすすめします。自動スケーリングには次の利点があります。

コスト - 自動スケーリングの場合、Bigtable が状況に応じてクラスタ内のノード数を減らすため、最適なコストを維持できます。これは、オーバープロビジョニングの回避にも役立ちます。
パフォーマンス - 自動スケーリングの場合、ワークロードが変更されたり、データストレージの要件が増加すると、自動的に Bigtable がクラスタにノードを追加します。これにより、クラスタで目標の CPU 使用率とストレージ要件を満たすために十分なノード数が確保されるため、ワークロードのパフォーマンス目標を維持できます。
自動化 - 自動スケーリングにより複雑な管理作業が軽減されます。クラスタサイズは Bigtable サービスによって自動的に処理されます。クラスタサイズを手動でモニタリングしてスケーリングする必要も、このような処理を行うアプリケーションを作成する必要もありません。

次のワークロードタイプでは、自動スケーリングのみでは適切に機能しない可能性があります。トラフィックの増加時に、Bigtable はすぐにノードを追加しますが、追加したノードの調整に時間がかかるためです。

トラフィックが急増する
バッチワークロードが突然発生する

使用量の急増が予測可能である場合、または定期的にスケジュールされている場合は、自動スケーリングを使用して、計画されたバースト前に設定を調整できます。詳しくは、ノードの再調整中に発生する遅延をご覧ください。

自動スケーリングの仕組み

自動スケーリングは、ノードの追加や削除によってクラスタを自動的にスケーリング（またはサイズ変更）するプロセスです。自動スケーリングを有効にすると、Bigtable がクラスタのサイズを自動的に調整します。クラスタでワークロードまたはストレージの変動が必要になると、Bigtable がスケールアップ（クラスタへのノードの追加）またはスケールダウン（クラスタからのノードの削除）を行います。

Bigtable の自動スケーリングでは、次の項目に基づいて必要なノードの数が決まります。

CPU 使用率の目標値
ストレージ使用率の目標値
ノードの最小数
ノードの最大数

スケーリング項目ごとに推奨ノード数が生成され、Bigtable は自動的に最も高いノード数を使用します。たとえば、クラスタがストレージ使用率の目標を達成するためには 10 ノードが必要だが、CPU 使用率の目標を達成するためには 12 ノードを必要とする場合、Bigtable はクラスタを 12 ノードにスケーリングします。

ノード数が変わるため、Bigtable は継続的にストレージの最適化を行います。ノード間でデータを調整して、トラフィックが均等に分散されて過負荷状態にならないようにします。

Bigtable は、クラスタをスケールアップした後、クラスタ内のノードを自動的に再調整し、パフォーマンスを最適化します。スケーリングや再調整の進行中であっても、すべてのリクエストがクラスタに到達します。詳細については、スケーリングの制限をご覧ください。

クラスタの最大ノード数までスケールアップされ、CPU 使用率の目標を超えると、リクエストのレイテンシが増加するか、失敗する可能性があります。クラスタが最大ノード数までスケールアップされ、ストレージ使用率の上限を超えると、書き込みリクエストが失敗します。ストレージの上限については、ノードあたりのストレージをご覧ください。

1 ノードクラスタなどの小規模なクラスタにノードが追加されると、クラスタのリバランスによって一時的にレイテンシが増加することがあります。これは、追加のノードが比例してクラスタのサイズを 2 倍にするためです。同様に、クラスタのサイズが 2 ノードから 1 ノードに減少すると、レイテンシが発生する可能性があります。

クラスタがスケールダウンされると、レイテンシへの影響を防ぐため、スケールアップ時よりも遅いペースでノードが削除されます。詳細については、スケーリングの制限をご覧ください。

自動スケーリングのパラメータ

クラスタを作成または編集して自動スケーリングを選択する場合、CPU 使用率の目標値、最小ノード数、最大ノード数の値を定義します。ストレージ使用率の目標値を構成するか、デフォルト値の 50%（SSD の場合は 2.5 TB、HDD の場合は 8 TB）のままにします。

パラメータ	説明
CPU 使用率の目標値	クラスタの CPU 容量の割合。10～80% の範囲で指定できます。クラスタの CPU 使用率が設定した目標値を超えると、Bigtable は直ちにノードをクラスタに追加します。CPU 使用率がターゲットより大幅に低い場合、Bigtable はノードを削除します。詳しくは、CPU 使用率の目標を決めるをご覧ください。
ノードの最小数	Bigtable がクラスタをスケールダウンする最小のノード数。この値は 0 より大きい数にする必要があり、またノードの最大数に設定した値の 10% 未満にすることはできません。たとえば、ノードの最大数が 40 の場合、ノードの最小数は 4 以上にする必要があります。この 10% の要件はハードリミットです。詳しくは、ノードの最小数を決めるをご覧ください。
ノードの最大数	クラスタをスケールアップするノードの最大数。この値は 0 より大きく、ノードの最小数以上である必要があります。この値は、最小ノード数に選択した数の 10 倍を超えることはできません。この 10 倍の要件はハードリミットです。詳しくは、ノードの最大数を決めるをご覧ください。
ストレージ使用率の目標値	Bigtable がスケールアップするまで保存できるノードあたりの最大テラバイト数。この目標値により、保存するデータ量の変動に対処するために十分なノードが常に確保されます。詳しくは、ストレージ使用率の目標値を決めるをご覧ください。

自動スケーリングを構成する

このセクションでは、自動スケーリングパラメータの選択方法について説明します。初期値を設定したら、クラスタをモニタリングし、必要に応じて数を調整します。

CPU 使用率の目標値を決める

固有のワークロードに基づいて CPU 使用率の目標値を設定します。クラスタに最適な目標値は、ワークロードのレイテンシとスループットの要件によって異なります。詳細については、Bigtable の容量を計画するをご覧ください。

一般に、許容できない長さのレイテンシが発生した場合は、CPU 使用率の目標値を小さくする必要があります。

ストレージ使用率の目標値を決定する

レイテンシの影響を受けやすいアプリケーションの場合、ストレージ使用率を 60% 以下に抑えてください。レイテンシの影響を受けにくいアプリケーションの場合、ストレージ使用率の目標を 70% 以上で選択できます。詳細については、Bigtable の容量を計画するをご覧ください。

自動スケーリングでは、ストレージ使用率は割合ではなく、ノードあたりのストレージのバイト数で表されます。ストレージ使用率の目標値はノード単位で指定しますが、クラスタ全体に適用されます。ノードの容量の上限は、SSD ストレージの場合はノードあたり 5 TB、HDD ストレージの場合はノードあたり 16 TB です。

次の表に、一般的なストレージ使用率の目標値の割合を示します。Google Cloud コンソールでは 1 ノードあたりの値は TB 単位で受け入れられます。gcloud CLI、API、Cloud Bigtable クライアントライブラリでは 1 ノードあたりの整数値が GiB 単位で受け入れられます。

割合	SSD	HDD
80%	4 TB または 4,096 GiB	12.8 TB または 13,107 GiB
70%	3.5 TB または 3,584 GiB	11.2 TB または 11,468 GiB
60%	3 TB または 3,072 GiB	9.6 TB または 9,830 GiB
50%	2.5 TB または 2,560 GiB	8 TB または 8,192 GiB

ノードの最大数を決める

最大ノード数として選択する値は、その量に達することがほとんどない場合でも、クラスタで最も多いトラフィックの処理に必要なノード数を選択する必要があります。Bigtable は、必要以上にノードをスケールアップすることはありません。この数は、支払い可能なノードの最大数と考えることもできます。指定できる値の詳細については、自動スケーリングパラメータをご覧ください。

最大数を設定する場合は、ユーザーが設定した CPU 使用率の目標値と Bigtable が設定したストレージ使用率の目標の両方を考慮する必要があります。

クラスタを手動割り当てから自動スケーリングに変更する場合は、過去 1 か月の間にクラスタで最も多かったノード数を探します。自動スケーリングの最大値は、この値以上に設定する必要があります。

既存のインスタンスの新しいクラスタで自動スケーリングを有効にする場合は、インスタンスの他のクラスタの指標を指針として使用します。

新しいワークロードで、それがどのように成長するのかわからない場合は、組み込みのストレージ使用率の目標を達成するために必要なノード数を推定し、その数をあとで調整します。

この値を得るには、クラスタに保存する予定のデータ量を計算し、使用するストレージタイプのストレージ使用率の目標値で割ります。

たとえば、SSD クラスタに 10 TB を保存する場合、10 TB を自動スケーリングの SSD クラスタにデフォルトで設定されたストレージ使用率の目標値（2.5 TB）で割ります。結果は 4 です。これが、そのデータ量を処理できるノード数になります。最大値は、これよりも大きい値でなければなりません。

次の例では、同じ式を使用してサンプルのストレージ量に必要なノード数を示しています。

クラスタあたりの SSD ストレージ	最小のノードの最大数
25 TB	10
35 TB	14
50 TB	20

クラスタが稼働し、自動スケーリングが有効になったら、クラスタをモニタリングして、ノードの最大数に選択した値が、recommended number of nodes for CPU target および recommended number of nodes for storage target の値以上になっていることを確認します。

ノードの最小数を決める

最小値を 1 に設定すると、Bigtable は可能であれば、最も小さくコスト効率の高いサイズにスケールダウンします。クラスタのサイズが小さくなりすぎることはありません。Bigtable は、CPU とストレージの使用率の目標値を維持するために必要な最小ノード数を下回らないように自動的に調整します。指定できる値の詳細については、自動スケーリングパラメータをご覧ください。

ほとんどの場合、1 より大きい値を設定します。次の状況が発生した場合は、値を大きくするか、ノードの最小数を増やしてください。

サイバーマンデーのように、トラフィックが一時的に増加することが予想されるイベントが近く、十分な容量を確保したい。
アプリケーションが送信するトラフィックが急増している。新しいノードが追加されると、Bigtable は新しいノードで自動的に再調整を行います。このプロセスには数分かかることもあります。このような急増にクラスタがシームレスに対応できるように、慎重な方法を取り、最小値により大きな値を選択したほうが良いことが少なくありません。
ノードの最大数が増えている。最小値は常にノードの最大数の 10% 以上でなければなりません。たとえば、最大値を 30 に設定した場合は、最小値を 3 以上に設定する必要があります。

クラスタの最小ノード数を増やすと、Bigtable は直ちにクラスタを新しい最小ノードにスケーリングします。ただし、標準の制約が適用されるため、ゾーンでノードがなくなると、構成した最小ノード数を満たすように追加ノードがプロビジョニングされません。Bigtable は、クラスタが新しい最小ノード数まで正常にスケーリングされるまで、ノードの追加を試行し、失敗するたびに監査ログエントリを作成します。この状況では、Bigtable は構成済みの値を変更しません。その結果、スケーリングが完了するまで、クラスタのノード数が最小数を下回る場合があります。

設定を調整する

ノードの使用状況にモニタリングし、必要に応じて設定を調整してください。特に、最初に自動スケーリングを有効にした後は注意が必要です。

レプリケーションを使用する場合の注意

レプリケーションを使用するインスタンスの場合、各クラスタの自動スケーリングの設定とアクティビティは、インスタンスの他のクラスタと完全に独立しています。インスタンス内のクラスタごとにスケーリングモードを構成する必要があります。

一般に、レプリケートされたインスタンスでは、インスタンス内のすべてのクラスタに対して自動スケーリングを有効にする必要があります。通常、自動スケーリングの構成はインスタンス内のすべてのクラスタで同じになりますが、クラスタのユースケース、ワークロード、パフォーマンス要件によっては異なる場合があります。

複製されたインスタンスのクラスタでは、レプリケーションを管理するための作業が行われるため、単一クラスタインスタンスの場合よりも、ノードの最大数を大きくする必要があります。詳細については、レプリケーションとパフォーマンスをご覧ください。

アクセス制御

自動スケーリングを構成するには、構成するクラスタとインスタンスに対する create 権限と update 権限を含むロールのプリンシパルである必要があります。

モニタリング

Bigtable から提供される指標を使用すると、ワークロード要件を満たすために Bigtable の自動スケーリングでスケールアップとスケールダウンがどのように行われているのかを把握できます。また、ビジネスのワークロードとコストの要件を満たすために最適な設定かどうかも確認できます。たとえば、クラスタのノード数がノードの最大数に近い場合は、最大値を増やすことを検討します。Bigtable リソースのモニタリングの詳細については、インスタンスのモニタリングをご覧ください。

次の指標は、Google Cloud コンソールのクラスタの概要ページにグラフで表示されます。これらの指標は、Cloud Monitoring で表示することもできます。

bigtable.googleapis.com/cluster/autoscaling/min_node_count
bigtable.googleapis.com/cluster/autoscaling/max_node_count
bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_cpu
bigtable.googleapis.com/cluster/autoscaling/recommended_node_count_for_storage

ロギング

Bigtable は、クラスタをスケーリングするたびにシステムイベント監査ログを出力します。ログエントリは次のようになります。

Grew from 9 to 10 nodes to maintain CPU utilization at 60%.

自動スケーリングシステムイベントログは、Google Cloud コンソールの Bigtable クラスタの概要ページに表示されます。ログエクスプローラを使用してログを表示することもできます。

ログエクスプローラに移動します。

ログエクスプローラに移動

適切な Google Cloud プロジェクトを選択します。

[クエリ] フィールドに次のクエリを入力します。

resource.type="audited_resource" resource.labels.service="bigtableadmin.googleapis.com"
resource.labels.method="AutoscaleCluster"

[実行] をクリックします。

[クエリ結果] ペインには、過去 1 時間のログが表示されます。

ログの表示の詳細については、Cloud Logging をご覧ください。