割り当てと上限
このドキュメントでは、Bigtable の割り当てと上限について説明します。
- 割り当ては、使用できるカウント可能な共有リソースの量を指定します。割り当ては、Bigtable などの Google Cloud サービスによって定義されます。
- システムの上限は固定値で、変更できません。
Google Cloud では、割り当てを使用して公平性を確保し、リソースの使用量と可用性の急増を抑えます。割り当ては、Google Cloud プロジェクトで使用できる Google Cloud リソースの量を制限します。割り当ては、ハードウェア、ソフトウェア、ネットワーク コンポーネントなど、さまざまなリソースタイプに適用されます。たとえば、割り当てによって、サービスへの API 呼び出しの数、プロジェクトで同時に使用されるロードバランサの数、作成可能なプロジェクトの数を制限できます。割り当てを適用することで、サービスの過負荷を防ぎ、Google Cloud ユーザーのコミュニティを保護します。割り当ては、自組織で使用している Google Cloud リソースの管理にも役立ちます。
Cloud Quotas システムは次のことを行います。
- Google Cloud のプロダクトとサービスの消費量をモニタリングする
- これらのリソースの消費量を制限する
- 割り当て値の変更をリクエストする方法を提供する
ほとんどの場合、割り当ての許容量を超えるリソースを消費しようとすると、システムによってリソースへのアクセスがブロックされ、実行しようとしているタスクは失敗します。
割り当ては通常、Google Cloud プロジェクト レベルで適用されます。あるプロジェクトでリソースを使用しても、別のプロジェクトで使用可能な割り当てに影響することはありません。Google Cloud プロジェクト内では、すべてのアプリケーションと IP アドレスで割り当てが共有されます。
通常、割り当てを調整するには、Google Cloud コンソールを使用します。 詳細については、割り当ての調整をリクエストするをご覧ください。
Bigtable リソースにはシステムの上限もあります。システムの上限は変更できません。
割り当て
このセクションでは、Bigtable のすべての使用状況に適用されるデフォルトの割り当てについて説明します。
管理オペレーションの割り当て
次の割り当ては、一定時間に実行できる Bigtable 管理オペレーション（管理 API の呼び出し）の数に影響します。
一般に、指定されている場合を除き、管理オペレーションの割り当ての増加をリクエストすることはできません。やむを得ない理由がある場合、例外が認められることがあります。ただし、使用量が増えても、アプリケーションが管理 API に対して行う呼び出し数は増加しません。増加している場合は、通常、アプリケーション コードが管理 API を不必要に呼び出している兆候であるため、管理オペレーションの割り当ての増加をリクエストするのではなく、アプリケーションを変更する必要があります。
毎日の割り当ては、午前 0 時（太平洋時間）にリセットされます。
| 名前 | 説明 | デフォルトの割り当て量 |
|---|---|---|
| インスタンスとクラスタ | ||
| インスタンスとクラスタの読み取りリクエスト | インスタンスまたはクラスタの構成（インスタンス名やクラスタ内のノード数など）の読み取り、またはインスタンスのリストの読み取り |
1 プロジェクト、1 日あたり: 864,000 オペレーション（平均 10 オペレーション/秒） 1 ユーザー、1 分あたり: 1,000 オペレーション |
| インスタンスとクラスタの書き込みリクエスト | インスタンスまたはクラスタの構成（インスタンス名やクラスタ内のノード数など）の変更、新しいインスタンスの作成 |
1 プロジェクト、1 日あたり: 500 オペレーション 1 ユーザー、1 分あたり: 100 オペレーション |
| アプリケーション プロファイル | ||
| アプリ プロファイルの読み取りリクエスト | アプリ プロファイルの構成の読み取り |
1 プロジェクト、1 日あたり: 5,000 オペレーション 1 ユーザー、1 分あたり: 1,000 オペレーション |
| アプリ プロファイルの書き込みリクエスト | アプリ プロファイルの構成の変更 |
1 プロジェクト、1 分あたり: 500 オペレーション 1 ユーザー、1 分あたり: 100 オペレーション |
| テーブル | ||
| テーブル管理読み取りリクエスト | テーブルの構成（列ファミリーの詳細など）の読み取り、またはテーブルのリストの読み取り |
1 プロジェクト、1 日あたり: 864,000 オペレーション（平均 10 オペレーション/秒） 1 ユーザー、1 分あたり: 1,000 オペレーション |
| テーブル管理の書き込みリクエスト | テーブルの構成（列ファミリーのガベージ コレクションの設定など）の変更 |
1 プロジェクト、1 日あたり: 5,000 オペレーション 1 ユーザー、1 分あたり: 100 オペレーション |
DropRowRange メソッド |
1 回のオペレーションでテーブルから行の範囲を削除 |
1 プロジェクト、1 日あたり: 5,000 オペレーション 1 ユーザー、1 分あたり: 100 オペレーション |
| バックアップ | ||
| バックアップ オペレーション | バックアップの作成、更新、削除 |
1 プロジェクト、1 日あたり: 1,000 オペレーション 1 ユーザー、1 分あたり: 10 オペレーション1 |
| バックアップ取得リクエスト | バックアップの取得とリスト表示 |
1 プロジェクト、1 日あたり: 864,000 オペレーション |
RestoreTable メソッド |
新しいテーブルにバックアップを復元 |
1 プロジェクト、1 日あたり: 5,000 オペレーション 1 ユーザー、1 分あたり: 100 オペレーション |
| Identity and Access Management | ||
| きめ細かい ACL の取得リクエスト | Bigtable インスタンスの IAM ポリシーに関する情報の読み取り、インスタンスの IAM 権限のテスト。 |
1 プロジェクト、1 日あたり: 864,000 オペレーション（平均 10 オペレーション/秒） 1 ユーザー、1 分あたり: 1,000 オペレーション |
| きめ細かい ACL の設定リクエスト | Bigtable インスタンス向けの IAM ポリシーの変更 |
1 プロジェクト、1 日あたり: 864,000 オペレーション（平均 10 オペレーション/秒） 1 ユーザー、1 分あたり: 1,000 オペレーション |
|
||
ノードの割り当て
Google Cloud プロジェクトには、クラスタのコンテナである Bigtable インスタンスが含まれています。クラスタは、単一のゾーンで実行されている実際の Bigtable サービスを表します。クラスタにはノードが含まれています。ノードは Bigtable がデータを管理できるようにするコンピューティング リソースです。
各プロジェクトで 1 つのゾーンにプロビジョニングできるデフォルトのノード数は、リージョンに応じて異なります。1 つのプロジェクト内で 1 つのゾーンにプロビジョニング可能な最大ノード数として、HDD ノードのデフォルトのノード数と SSD ノードのデフォルトのノード数が定められています。
デフォルトのノード割り当ては次のとおりです。
| リージョン | SSD | HDD |
|---|---|---|
| asia-east1 | 100 | 100 |
| europe-west1 | 200 | 200 |
| us-central1 | 200 | 200 |
| us-east1 | 50 | 50 |
| us-east4 | 50 | 50 |
| us-west1 | 100 | 100 |
| 他のすべての Bigtable のロケーション | 30 | 30 |
クラスタの自動スケーリングを有効にすると、クラスタがそのノード数にスケーリングされていない場合でも、構成される最大ノード数でこの上限が考慮されます。デフォルトの上限よりも多くのノードをプロビジョニングする必要がある場合は、引き上げをリクエストできます。
割り当てとノードの可用性
ノード割り当てとは、各プロジェクトで 1 つのゾーンにプロビジョニングできるノードの最大数です。この割り当て数にまだ達していなくても、クラスタにノードを追加できるとは限りません。ゾーンでこれ以上ノードを利用できない場合、プロジェクトで割り当てが残っていても、そのゾーンのクラスタにノードを追加できないことがあります。
たとえば、すでに 20 個のノードがあるクラスタに 10 個の SSD ノードを追加しようとしたが、ゾーンでこれ以上ノードが利用できない場合は、そのリージョンの SSD ノードのノード割り当てが 30 であっても、10 個のノードを追加することはできません。
このような場合、Google はゾーンのノードリソースを増やし、それらのリソースが利用可能になった後でリクエストを実現しようとしますが、タイミングと達成の保証はありません。
すでにプロビジョニングされているノードは常に可用性が保証されます。
Data Boost の割り当て
次のサーバー処理ユニット（SPU）の割り当ては、プロジェクトごとにリージョンごとに適用されます。
| リージョン | SPU |
|---|---|
| asia-east1 | 100,000 |
| europe-west1 | 200,000 |
| us-central1 | 200,000 |
| us-east1 | 100,000 |
| us-east4 | 100,000 |
| us-west1 | 100,000 |
| 他のすべての Bigtable のロケーション | 30,000 |
Data Boost の詳細については、Data Boost の概要をご覧ください。
割り当て情報を表示する
Google Cloud コンソール を使用すると、Google Cloud プロジェクトの各ゾーンに SSD ノードと HDD ノードが何個あるかを確認できます。左側のナビゲーション パネルの [IAM と管理] で [割り当て] をクリックし、[サービス] プルダウン リストで Bigtable Admin API サービスを選択します。
このページには、サービス、ノードタイプ、ロケーションの各組み合わせでの割り当てを示す行が表示されます。[SSD nodes/ゾーン] または [HDD nodes/ゾーン] という小見出しの行を確認してください。[上限] 列は指定したノードタイプとロケーションで許可されているノードの最大数、[現在の使用量] 列は現在存在するノード数を示しています。これら 2 つの数値の差が、割り当ての増大をリクエストすることなく追加できるノードの数になります。
ノード割り当ての増加をリクエストする
リクエストを処理する時間を十分に確保するため、常に前もって計画を立て、追加のリソースが必要になる数日前にリクエストするようにしてください。ノード割り当て増加のリクエストは、実現が保証されているわけではありません。詳細については、割り当ての操作をご覧ください。
ノード割り当て増加をリクエストするインスタンスを含むプロジェクトに対して、少なくとも編集者レベルの権限が必要です。
ノード割り当ての増加リクエストを行っても課金されません。料金が発生するのは、リソースの使用量が増えたときのみです。
- [割り当て] ページに移動します。
- [割り当て] ページで、変更する割り当てを選択します。
- ページ上部にある [割り当てを編集] ボタンをクリックします。
- 右側のパネルに、名前、メールアドレス、電話番号を入力して [次へ] をクリックします。
- 希望する新しい割り当て上限を入力し、[次へ] をクリックします。
- リクエストを送信します。
上限
このセクションでは、Bigtable の使用に適用される上限について説明します。上限はサービスに組み込まれており、変更できません。
インスタンスあたりのアプリ プロファイル数
1 つのインスタンスに使用できるアプリケーション プロファイルは最大 2,000 です。
承認済みビュー
- Bigtable インスタンスあたりの承認済みビュー: 最大 10,000
- 承認済みビューあたりの列修飾子接頭辞: 10
バックアップ
- 作成可能な標準バックアップの最大数: クラスタあたり、テーブルあたり 150 件
- 作成可能なホットバックアップの最大数: クラスタあたり、テーブルあたり 10 件
- バックアップの最小保持期間: 初回作成時から 6 時間
- バックアップの最大保持期間: 初回作成日から 90 日
Data Boost
Data Boost アプリ プロファイルでは、1 秒あたり 1,000 件を超える読み取りリクエストを送信できません。
テーブル内のデータサイズ
上限の推奨値
スキーマの設計時には、データのサイズが以下の推奨上限値を超えないようにすることをおすすめします。
- テーブルあたりの列ファミリーの数: 100
- 単一の列修飾子: 16 KB
- テーブルセル内の単一の値: 10 MB
- 1 行内のすべての値: 100 MB
ハード制限
さらに、データが以下のハードリミット内に収まるようにする必要があります。
- 単一の行キー: 4 KB
- テーブルセル内の単一の値: 100 MB
- 1 行内のすべての値: 256 MB
サイズの上限は、バイナリ キロバイト（KB）単位とバイナリ メガバイト（MB）単位で測定されます。1 KB は 210 バイト、1 MB は 220 バイトです。これらの測定単位は、キビバイト（KiB）、メビバイト（MiB）とも呼ばれます。
オペレーションの上限
Bigtable に複数のミューテーションを 1 つのバッチとして送信する場合、次の上限が適用されます。
CheckAndMutateを呼び出す条件付きミューテーションのバッチには、最大 100,000 個の true ミューテーションと最大 100,000 個の false ミューテーションを含めることができます。他のすべてのタイプのミューテーションのバッチの場合、バッチに 100,000 個までミューテーションを含めることができます。
インスタンスあたりのリージョン数
Bigtable インスタンスでは、Bigtable で使用可能なリージョンを 8 つまで使用できます。1 つのリージョン内の各ゾーンに 1 つのクラスタを作成できます。使用可能なゾーンの一覧については、Bigtable のロケーションをご覧ください。
行フィルタ
行フィルタは 20 KB 以下にしてください。エラー メッセージが表示された場合は、フィルタを再設計するか短縮する必要があります。
ノードあたりのストレージ
現在のワークロードと保存されているデータの量に基づく十分なノードがクラスタに確保されていない場合、Bigtable は、クラスタに関連付けられているすべてのタブレットを管理するのに十分な CPU リソースを得ることができません。また、Bigtable はバックグラウンドで必要なメンテナンス作業を実行することもできません。その結果、クラスタは受信したリクエストを処理できなくなり、レイテンシが増加します。詳細については、ストレージ使用量とパフォーマンスのトレードオフをご覧ください。
このような問題を回避するには、クラスタのストレージ使用量をモニタリングして、次の上限に基づいて、クラスタ内のデータ量をサポートするのに十分なノードを確保します。
- SSD クラスタ: 1 ノードあたり 5 TB
- HDD クラスタ: 1 ノードあたり 16 TB
この値はバイナリ テラバイト（TB）単位で測定されます。1 TB は 240 バイトです。この測定単位は、テビバイト（TiB）とも呼ばれます。
ベスト プラクティスとして、クラスタに十分なノードを追加して、使用率を上限の 70% 以内に抑えるようにすることをおすすめします。これは、ストレージ使用量の急上昇に対応するのに役立ちます。たとえば、SSD ストレージを使用するクラスタで 50 TB のデータを保存する場合、少なくとも 15 のノードをプロビジョニングするようにしてください。これにより、最大 75 TB までのデータを処理できます。クラスタに大量のデータを追加しない場合は、この推奨使用率を超えて上限の 100% までデータを保存できます。
インスタンスあたりのテーブル数
Bigtable では、インスタンスごとに最大 1,000 個のテーブルがサポートされます。
ID の長さの上限
Bigtable でサポートされている ID の最小と最大の文字数（文字数）。
- アプリ プロファイル: 1～50
- バックアップ: 1～50
- クラスタ: 6～30
- 列ファミリー: 1～64
- インスタンス: 6～33
- テーブル: 1～50
- 承認済みビュー: 1～50
利用ポリシー
本サービスを利用するにあたっては、Google の利用規約とプライバシー ポリシーを遵守する必要があります。