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

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

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

• インスタンスを作成する方法については、インスタンスの作成をご覧ください。
• クラスタを追加または削除する方法については、インスタンスの変更をご覧ください。
• インスタンスとクラスタをモニタリングする方法については、インスタンスのモニタリングをご覧ください。
• クラスタのノード数を更新する方法については、ノードを追加または削除するをご覧ください。

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

インスタンス

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

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

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

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

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

ストレージ タイプ

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

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

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

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

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

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

クラスタ

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

各クラスタは 1 つのゾーンに配置されています。 インスタンスでは、Bigtable が使用可能なリージョンを 8 個まで使用できます。各リージョン内のそれぞれのゾーンに配置できるクラスタは 1 つのみです。 たとえば、インスタンスのクラスタが us-east1-b にある場合は、同じリージョン内の別のゾーン（例 us-east1-c）、または別のリージョンのゾーン（例: europe-west2-a）にクラスタを追加できます。

インスタンスで作成できるクラスタの数は、選択したリージョンの利用可能なゾーンの数によって異なります。たとえば、8 つのリージョンにそれぞれ 3 つのゾーンを持つクラスタを作成する場合、インスタンスで作成できるクラスタの最大数は 24 です。Bigtable を利用できるゾーンとリージョンのリストについては、Bigtable のロケーションをご覧ください。

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

ほとんどの場合、クラスタの自動スケーリングを有効にする必要があります。これにより、Bigtable はクラスタのワークロードの処理の必要に応じてノードを追加または削除できます。

ノード

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

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

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

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

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

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

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

自動スケーリング用にノードの最大数を構成する場合や、ノードを手動で割り当てる場合、インスタンスに複数のクラスタがある状況ではフェイルオーバーを考慮する必要があります。

• アプリ プロファイルのいずれかで複数クラスタ ルーティングを使用している場合、1 つ以上のクラスタが使用不能になると自動フェイルオーバーが発生する可能性があります。

• クラスタ間で手動でフェイルオーバーするときや、自動フェイルオーバーが発生するときを考慮して、受信側のクラスタは負荷をサポートするのに十分な容量を持つことが理想的です。フェイルオーバーをサポートするのに十分なノードを常に割り当てることも、トラフィックのフェイルオーバー時に自動スケーリングを使用してノードを追加することもできますが、この方法にはクラスタがスケールアップする一方で、パフォーマンスに一時的な影響が発生する可能性がある点に注意してください。

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

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

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

次のステップ

• Bigtable イン��タンスを作成します。
• Bigtable インスタンスをモニタリングする。
• レプリケーションの仕組みを確認する。