インスタンス、クラスタ、ノード
Bigtable を使用するには、インスタンスを作成します。インスタンスには、アプリケーションが接続できるクラスタが含まれます。各クラスタにはノードがあります。これはデータの管理とメンテナンス タスクの実行のためのコンピューティング単位です。
このページでは、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 がデータの管理に使用するコンピューティング リソースが 1 つ以上あります。
Bigtable は、バックグラウンドでテーブル内のすべてのデータを別々のタブレットに分割します。タブレットは、ノードと同じゾーンにあるディスクに、ノードとは別に格納されます。タブレットは 1 つのノードに関連付けられます。
各ノードの役割は次のとおりです。
- ディスク上の特定のタブレットをトラッキングする。
- 受信するタブレットの読み取りと書き込みを処理する。
- 定期的なコンパクションなどのメンテナンス タスクをタブレットで実行する。
クラスタには、クラスタの現在のワークロードと、クラスタに保存されているデータの量をサポートできるだけのノードが必要です。十分なノードがない場合、受信されたリクエストを処理できず、レイテンシが増加することがあります。クラスタの CPU とディスクの使用状況をモニタリングします。指標が以下の推奨値と上限を超えた場合は、インスタンスにノードを追加します。
Bigtable によるデータの保存と管理については、Bigtable アーキテクチャをご覧ください。
CPU 使用率
Bigtable は、CPU 使用率について以下の指標をレポートします。
| 指標 | 説明 |
|---|---|
| 平均 CPU 使用率 |
クラスタ内にあるすべてのノードの平均 CPU 使用率。インスタンス内のテーブルで変更ストリームが有効になっている場合、変更ストリーム アクティビティが含まれます。 アプリ プロファイル グラフで、<system> はレプリケーションやコンパクションなどのシステムのバックグラウンド アクティビティを示します。システムのバックグラウンド アクティビティは、クライアント主導ではありません。 推奨最大値により、使用率が急増した場合のヘッドルームを確保できます。 クラスタが構成の推奨最大値を超過する時間が数分間にわたる場合は、クラスタにノードを追加します。 |
| 最もホットなノードの CPU 使用率 |
クラスタで最もビジーなノードの CPU 使用率。この指標は、継続性のために引き続き提供されますが、ほとんどの場合は、より正確な指標である「最もホットなノードのきめ細かい CPU 使用率」を使用する必要があります。 |
| 最もホットなノードのきめ細かい CPU 使用率 |
クラスタで最もビジーなノードの CPU 使用率をきめ細かく測定します。「最もホットなノードの CPU 使用率」よりも正確であるため、この指標を使用することをおすすめします。 最もホットなノードは時間とともに変化する可能性があります。特に、大規模なバッチジョブやテーブル スキャン中は急激に変化する可能性があります。 最もホットなノードが頻繁に推奨値を超える場合、平均 CPU 使用率が適切な範囲にあっても、ごく一部のデータに他のデータよりも頻繁にアクセスしている可能性があります。
|
| 変更ストリームの CPU 使用率 |
クラスタ内のすべてのノードで変更ストリーム アクティビティによって生じた平均 CPU 使用率。 |
| アプリ プロファイル、メソッド、テーブルによる CPU 使用率 |
アプリ プロファイル、メソッド、テーブルによる CPU 使用率。 クラスタの CPU 使用率が予想よりも高い場合は、この指標を使用して、特定のアプリ プロファイル、API メソッド、テーブルの CPU 使用率が CPU の負荷が高くなっている原因かどうか判断します。 |
これらの指標の値は、以下の値以下にしてください。
| 構成 | 推奨の最大値1 | |
|---|---|---|
|
||
| 単一クラスタ ルーティング、任意の数のクラスタ |
平均 CPU 使用率 70% |
|
| 複数クラスタ ルーティング、自動スケーリングが有効、2 つ以上のクラスタ |
平均 CPU 使用率 70% |
|
| 複数クラスタ ルーティング、自動スケーリングが有効になっていない、2 つのクラスタ |
平均 CPU 使用率 35%2 |
|
| 複数クラスタ ルーティング、自動スケーリングが無効、3 つ以上のクラスタ |
構成によります。一般的な使用例については、レプリケーション設定の例をご覧ください。 |
|
ディスク使用量
Bigtable は、ディスク使用量について以下の指標をレポートします。
| 指標 | 説明 |
|---|---|
| ストレージの利用率（バイト） |
クラスタに格納されているデータの量。この指標には、変更ストリームの使用量は含まれません。 この値は費用に影響します。また、後述のように、データ量の増加に伴い各クラスタにノードを追加することが必要になる場合があります。 |
| ストレージの利用率（最大に対するパーセント） |
クラスタのストレージ容量のうち、使用されている容量の割合。この容量はクラスタ内のノード数に基づいています。この指標には、変更ストリームの使用量は含まれません。 一般的に、データを追加する場合は、ストレージ合計でハードリミットの 70% を超過しないでください。大量のデータをインスタンスに追加する予定がない場合は、ハードリミットの 100% まで使用できます。 ストレージ上限の推奨パーセンテージを超えて使用している場合は、クラスタにノードを追加してください。既存のデータを削除することもできますが、コンパクションが発生するまでは、削除されたデータの占有容量が少なくなるどころかむしろ多くなります。 この値の計算方法については、ノードあたりのストレージ使用率をご覧ください。 |
| 変更ストリームのストレージ使用量（バイト） |
インスタンス内のテーブルの変更ストリームの記録によって消費されるストレージの量。このストレージは合計ストレージ使用量にカウントされません。変更ストリームのストレージに対して課金されますが、ストレージ使用率（最大 %）の計算には含まれません。 |
| ディスク負荷 |
HDD の読み取りに使用できる最大帯域幅のうち、クラスタが使用している容量の割合。HDD クラスタの場合のみ使用可能です。 この値が頻繁に 100% に達する場合、レイテンシが増加することがあります。クラスタにノードを追加して、ディスク負荷の割合を下げます。 |
複製されたクラスタのノード
レプリケーションを使用するインスタンスの場合、ユースケースをサポートできるだけのノードが各クラスタにあることを確認します。
レプリケーションによって高可用性を実現する場合やアプリ プロファイルのいずれかで複数クラスタのルーティングを使用している場合、各クラスタのノード数は同じでなければなりません。また、前述の CPU 使用率の項で説明しているとおり、推奨される CPU 使用率は半分に減ります。
この構成により、自動フェイルオーバーが必要な場合、正常なほうのクラスタにすべてのトラフィックを処理できるだけの容量が確保されます。
すべてのアプリ プロファイルが単一クラスタのルーティングを使用している場合、ノード数はクラスタごとに異なっていてもかまいません。クラスタのワークロードに基づき、必要に応じて各クラスタのサイズを変更します。
Bigtable ではクラスタごとにデータのコピーが個別に保存されるため、各クラスタにはディスク使用量をサポートし、クラスタ間の書き込みを複製できるだけのノードが常に必要です。
必要があれば、クラスタ間で手動フェイルオーバーを行うことができます。ただし、あるクラスタで他のクラスタよりはるかに多くのノードが必要な場合に、ノードが少ないほうのクラスタにフェイルオーバーするには、まずノードを追加する必要があります。フェイルオーバーが必要な場合に追加のノードを利用できる保証はありません。ノードを事前に予約するには、ノードをクラスタに追加するしかありません。
次のステップ
- Bigtable インスタンスを作成する。
- 既存の Bigtable インスタンスをモニタリングする。
- Bigtable インスタンスのクラスタにノードを追加する。
- レプリケーションの仕組みを確認する。
- Bigtable インスタンスにクラスタを追加してレプリケーションを有効にする。