インスタンス、クラスタ、ノード

Cloud Bigtable を使用するには、インスタンスを作成します。インスタンスには、アプリケーションが接続できるクラスタが 4 つあります。各クラスタにはノードがあります。これはデータの管理とメンテナンス タスクの実行のためのコンピューティング単位です。

このページでは、Cloud Bigtable のインスタンス、クラスタ、ノードについて詳しく説明します。

このページを読む前に、Cloud Bigtable の概要を理解する必要があります。

インスタンス

Cloud Bigtable インスタンスはデータのコンテナです。インスタンスには 1 つ以上のクラスタがあり、別のゾーンに配置されています。各クラスタには 1 以上のノードがあります。

テーブルはクラスタやノードではなく、インスタンスに属します。インスタンスに複数のクラスタがある場合は、レプリケーションを使用します。個々のクラスタにテーブルを割り当てることはできません。また、インスタンス内のクラスタごとに一意のガベージ コレクション ポリシーを作成することもできません。また、各クラスタで同じテーブルに異なるデータセットを格納することもできません。

インスタンスにはいくつかの重要なプロパティがあります。

  • ストレージ タイプ(SSD または HDD)
  • アプリケーション プロファイル(主にレプリケーションを使用するインスタンスの場合)

以下のセクションでは、これらのプロパティについて説明します。

ストレージ タイプ

インスタンスを作成するときに、インスタンスのクラスタがデータを SSD(ソリッド ステート ドライブ)に保存するのか、ハードディスク(HDD)に保存するのかを選択する必要があります。常に当てはまるとは限りませんが、SSD は多くの場合、最も効率的でコスト効果の高い選択肢です。

SSD か HDD かの選択は永続的なもので、インスタンス内のすべてのクラスタが同じストレージ タイプを使用しなければなりません。そのため、ユースケースに最適なストレージ タイプを選択する必要があります。詳しくは SSD ストレージか HDD ストレージかの選択をご覧ください。

アプリケーション プロファイル

インスタンスを作成すると、Cloud Bigtable はそのインスタンスを使用してアプリケーション プロファイル(またはアプリ プロファイル)を保存します。レプリケーションを使用するインスタンスの場合、アプリ プロファイルはアプリケーションがインスタンスのクラスタにどのように接続するかを制御します。

インスタンスがレプリケーションを使用しない場合でも、アプリ プロファイルを使用して、アプリケーション単位か 1 つのアプリケーション内の関数単位で、個別の識別子を指定できます。そうすると、アプリ プロファイルごとに個別のグラフを Cloud Console に表示できます。

アプリ プロファイルの詳細については、アプリケーション プロファイルをご覧ください。インスタンスのアプリ プロファイルを構成する方法については、アプリ プロファイルの構成をご覧ください。

クラスタ

クラスタは、特定のロケーションにある Cloud Bigtable サービスを表します。各クラスタは 1 つの Cloud Bigtable インスタンスに属し、1 つのインスタンスには最大で 4 つのクラスタがあります。アプリケーションが Cloud Bigtable にリクエストを送信すると、そのリクエストはインスタンスのクラスタのいずれかによって処理されます。

各クラスタは 1 つのゾーンに配置されています。インスタンスの各クラスタは、それぞれ異なるゾーン内に存在する必要があります。Cloud Bigtable が利用可能なゾーンであれば、どのゾーンにでも追加のクラスタを作成できます。たとえば、最初のクラスタが us-east1-b にある場合、同じリージョン内の別のゾーン(us-east1-c など)を選択することも、別のリージョン内のゾーン(europe-west2-a など)を選択することもできます。Cloud Bigtable を利用できるゾーンとリージョンのリストについては、Cloud Bigtable のロケーションをご覧ください。

クラスタが 1 つしかない Cloud Bigtable インスタンスでは、レプリケーションを使用しません。インスタンスに 2 つ目のクラスタを追加すると、Cloud Bigtable はデータのレプリケーションを自動的に開始します(クラスタの各ゾーンにデータのコピーを保持し、コピー間で更新を同期します)。アプリケーションが接続するクラスタを選択できます。これにより、トラフィックをタイプ別に分離できます。また、Cloud Bigtable がクラスタ間でトラフィックを分散するように設定することもできます。あるクラスタを利用できなくなった場合、別のクラスタにフェイルオーバーできます。レプリケーションの仕組みについては、レプリケーションの概要をご覧ください。

ノード

インスタンス内の各クラスタには、Cloud Bigtable がデータの管理に使用するコンピューティング リソースが 1 つ以上あります。

Cloud Bigtable は、バックグラウンドでテーブル内のすべてのデータを別々のタブレットに分割します。タブレットは、ノードと同じゾーンにあるディスクに、ノードとは別に格納されます。タブレットは 1 つのノードに関連付けられます。

各ノードの役割は次のとおりです。

  • ディスク上の特定のタブレットをトラッキングする。
  • 受信するタブレットの読み取りと書き込みを処理する。
  • 定期的なコンパクションなどのメンテナンス タスクをタブレットで実行する。

クラスタには、クラスタの現在のワークロードと、クラスタに保存されているデータの量をサポートできるだけのノードが必要です。十分なノードがない場合、受信されたリクエストを処理できず、レイテンシが増加することがあります。クラスタの CPU とディスクの使用状況をモニタリングします。指標が以下の推奨値と上限を超えた場合は、インスタンスにノードを追加します。

Cloud Bigtable によるデータの保存と管理方法の詳細については、Cloud Bigtable アーキテクチャをご覧ください。

CPU 使用率

Cloud Bigtable は、CPU 使用率について以下の指標をレポートします。

指標 説明
平均 CPU 使用率

クラスタ内にあるすべてのノードの平均 CPU 使用率。

推奨最大値により、使用率が急増した場合のヘッドルームを確保できます。

クラスタが構成の推奨最大値を超過する時間が数分間にわたる場合は、クラスタにノードを追加します。

最もホットなノードの CPU 使用率

クラスタで最もビジーなノードの CPU 使用率。

最もホットなノードが頻繁に推奨値を超える場合、平均 CPU 使用率が適切な範囲にあっても、ごく一部のデータに他のデータよりも頻繁にアクセスしている可能性があります。

  • Key Visualizer ツールを使用して、CPU 使用率の急上昇を引き起こしている可能性があるホットスポットをテーブル内で特定します。
  • スキーマ設計を確認し、読み取りと書き込みが各テーブル間で均等に分散されるようにします。

こうした指標の値は、以下を超えてはいけません。

構成 推奨最大値
単一クラスタ

平均 CPU 使用率 70%
最もホットなノードの CPU 使用率 90%

単一クラスタ ルーティングを使用する任意のクラスタ数

平均 CPU 使用率 70%
最もホットなノードの CPU 使用率 90%

複数クラスタ ルーティングの 2 つのクラスタ

平均 CPU 使用率 35%
最もホットなノードの CPU 使用率 45%

複数クラスタ ルーティングを使用する 3 つ以上のクラスタ

構成によります。一般的な使用例については、レプリケーション設定の例をご覧ください。

ディスク使用量

Cloud Bigtable は、ディスク使用量について以下の指標をレポートします。

指標 説明
ストレージの利用率(バイト)

クラスタに格納されているデータの量。

この値は費用に影響します。また、後述のように、データ量の増加に伴い各クラスタにノードを追加することが必要になる場合があります。

ストレージの利用率(最大に対するパーセント)

クラスタのストレージ容量のうち、使用されている容量の割合。この容量はクラスタ内のノード数に基づいています。

一般的に、データを追加する場合は、ストレージ合計でハードリミットの 70% を超過しないでください。大量のデータをインスタンスに追加する予定がない場合は、ハードリミットの 100% まで使用できます。

ストレージ上限の推奨パーセンテージを超えて使用している場合は、クラスタにノードを追加してください。既存のデータを削除することもできますが、コンパクションが発生するまでは、削除されたデータの占有容量が少なくなるどころかむしろ多くなります

この値の計算方法については、ノードあたりのストレージ使用率をご覧ください。

ディスク負荷

HDD の読み取りと書き込みに使用できる最大帯域幅のうち、クラスタが使用している容量の割合。HDD クラスタの場合のみ使用可能です。

この値が頻繁に 100% に達する場合、レイテンシが増加することがあります。クラスタにノードを追加して、ディスク負荷の割合を下げます。

複製されたクラスタのノード

レプリケーションを使用するインスタンスの場合、ユースケースをサポートできるだけのノードが各クラスタにあることを確認します。

  • レプリケーションによって高可用性を実現する場合やアプリ プロファイルのいずれかで複数クラスタのルーティングを使用している場合、各クラスタのノード数は同じでなければなりません。また、上記の CPU 使用率の項で説明しているとおり、推奨される CPU 使用率は半分に減ります。

    この構成により、自動フェイルオーバーが必要な場合、正常なほうのクラスタにすべてのトラフィックを処理できるだけの容量が確保されます。

  • すべてのアプリ プロファイルが単一クラスタのルーティングを使用している場合、ノード数はクラスタごとに異なっていてもかまいません。クラスタのワークロードに基づき、必要に応じて各クラスタのサイズを変更します。

    Cloud Bigtable ではクラスタごとにデータのコピーが個別に保存されるため、各クラスタにはディスク使用量をサポートし、クラスタ間の書き込みを複製できるだけのノードが常に必要です。

    必要があればクラスタ間で手動フェイルオーバーを行うことができます。ただし、あるクラスタで他のクラスタよりはるかに多くのノードが必要な場合に、ノードが少ないほうのクラスタにフェイルオーバーするには、まずノードを追加する必要があります。フェイルオーバーが必要な場合に追加のノードを利用できる保証はありません。ノードを事前に予約するには、ノードをクラスタに追加するしかありません。

次のステップ