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

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

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

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

インスタンス

通常、Cloud Bigtable インスタンスはクラスタノードのコンテナにすぎません。実際の作業はすべてクラスタとノードが行います。

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

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

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

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

インスタンス タイプ

インスタンスの作成時に、作成するインスタンスのタイプを選択する必要があります。

  • 本番環境: 標準的なインスタンス。1 つまたは 2 つのクラスタがあり、各クラスタには 3 つ以上のノードがあります。本番環境インスタンスを開発環境インスタンスにダウングレードすることはできません。
  • 開発環境: 低コストのインスタンス。1 ノードクラスタと同等のパフォーマンスに制限されています。モニタリングやスループットの保証はありません。レプリケーションは使用できません。また、SLA は適用されません。開発環境インスタンスはいつでも本番環境インスタンスにアップグレードできます。

ストレージ タイプ

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

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

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

本番環境インスタンスを作成した後、Cloud Bigtable はそのインスタンスを使用してアプリケーション プロファイル(アプリ プロファイル)を保存します。レプリケーションを使用するインスタンスの場合、アプリ プロファイルはアプリケーションがインスタンスのクラスタにどのように接続するかを制御します。インスタンスがレプリケーションを使用しない場合でも、アプリ プロファイルを使用して、アプリケーションごと、またはアプリケーション内のファンクションごとに個別の識別子を指定できます。その後、GCP 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 がトラフィックをクラスタ間で分散するよう設定することもできます。あるクラスタを利用できなくなった場合、別のクラスタにフェイルオーバーできます。レプリケーションの仕組みについては、レプリケーションの概要をご覧ください。

ノード

本番環境インスタンスの各クラスタには 3 つ以上のノードがあります。ノードは Cloud Bigtable がデータを管理するために使用するコンピューティング リソースです。

Cloud Bigtable はバックグラウンドで、テーブルから取得したすべてのデータを小さなタブレットに分解します。タブレットは、ノードと同じゾーンにあるディスクに、ノードとは別に格納されます。各ノードはディスク上の特定のタブレットをトラッキングし、タブレットが受信する読み取りと書き込みを処理し、定期的なコンパクションなどのメンテナンス タスクをタブレット上で実行します。各タブレットはそれぞれ 1 つのノードに関連付けられます。Cloud Bigtable によるデータの保存と管理方法の詳細については、Cloud Bigtable アーキテクチャをご覧ください。

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

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

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

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...

Cloud Bigtable ドキュメント