ホット タブレット
Bigtable には、パフォーマンスの問題をトラブルシューティングするため、クラスタ内のホット タブレットを特定してモニタリングする機能があります。このページでは、ホット タブレットの概要、ホット タブレットのリストを取得する方法、ホット タブレットの識別が有益な状況について説明します。このページを読む前に、Bigtable の概要を理解しておく必要があります。
ホット タブレットのリストを取得するメソッドの名前は、使用する言語によって異なります。わかりやすくするため、このドキュメントでは RPC Cloud Bigtable Admin API 名（ListHotTablets）を使用します。ホット タブレットのリストは、以下のものを使用して取得できます。
ホット タブレットの識別は次のタスクで役に立ちます。
ホット タブレットについて
Bigtable テーブルは、タブレットと呼ばれる連続する行をまとめたブロックにシャーディングされ、クエリのロード バランシングを実現しています。各タブレットはノードに関連付けられ、そのノードでこれらの行に対するオペレーションが実行されます。パフォーマンスを最適化するため、タブレットはアクセス パターンに応じて分割されるか、別のノードに移動されます。タブレットは、ユーザー アクセス パターン（読み取り、書き込み、スキャンのオペレーション）に基づいてノード間で再調整されます。ロード バランシングの詳細については、Bigtable が時間の経過とともにデータを最適化する方法をご覧ください。
ホット タブレットは、他のタブレットと比較して使用率が非常に多いため、ノード CPU の使用率が過剰になるタブレットです。このノード使用量の偏りによって、レイテンシやレプリケーションの遅延が発生する可能性があります。
ホット タブレットの発生原因の中で最も多いものがホットスポットです。これは、アプリがテーブル内で互いに近接している行にアクセスする頻度が高い場合に発生します。多くの場合、ホットスポットは、アプリケーションのアクセス パターンをテーブル全体に分散するように最適化されていないスキーマ設計が原因で発生します。ホットスポットが発生しないように行キーを設計する方法については、スキーマ設計のベスト プラクティスをご覧ください。
ホット タブレットのリストを取得するには、bigtable.viewer 権限を含むロールが割り当てられている必要があります。
出力
ListHotTablets メソッドは、インスタンス内のクラスタについて次のデータを返します。
- タブレット名。Bigtable がホット タブレットに割り当てる一意の ID。このフィールドは gcloud CLI では表示されません。
- テーブル。ホット タブレットに関連付けられているテーブルの ID。
- CPU 使用量。ホット タブレットに関連付けられたノードの平均 CPU 使用率（%）。1 分間の平均で表されます。この割合は、開始時刻から終了時刻までの書き込み CPU と読み取り CPU の合計の平均です。
- 開始時刻。ホット タブレット期間の開始時刻。
- 終了時刻。ホット タブレット期間の終了時刻。
- 開始キー。ホット タブレットの最初の行キー。
- 終了キー。ホット タブレットの最後の行キー。 開始キーと終了キーが同じである場合は、接尾辞
\000が追加されます。これは、タブレットが 1 行に収まっていることを示します。
キーはタブレット内で辞書順に並べられるため、開始キーと終了キーの間のキーは、すべてホット タブレットに含まれます。
ホットスポットは 1 分間の精度で計算されます。出力にタブレットが再度表示されることもあります。つまり、1 つのタブレットが数分間ホットスポットであるとみなされる場合があります。
デフォルトでの ListHotTablets は、過去 24 時間を検索します。特定の時間範囲を検索するには、開始時刻と終了時刻を指定します。
返されるホット タブレットの最大数は 50 個です。これを変更するには、ページサイズを指定します。
クラスタにホット タブレットが 1 つもない場合、このメソッドは空のリストを返します。
gcloud CLI の使用例
この例をコピーする前に、gcloud CLI をインストールします。
特定のクラスタのホット タブレットのリストを表示するには、Cloud Shell またはローカルのターミナル ウィンドウで hot-tablets list コマンドを実行します。
gcloud bigtable hot-tablets list CLUSTER_ID --instance INSTANCE_ID
次のように置き換えます。
CLUSTER_ID: クラスタの永続的な識別子INSTANCE_ID: インスタンスの永続的な識別子
クラスタ内にホット タブレットがある場合、ターミナルには次のような出力が表示されます。クラスタ内のホット タブレットは、CPU 使用率が大きい順に表示されます。
TABLE CPU_USAGE START_TIME END_TIME START_KEY END_KEY test-data 89.3 2021-12-14T01:19:57+00:00 2021-12-14T01:20:57+00:00 user29333893046… user29333893046… test-data 22.8 2021-12-14T01:04:59+00:00 2021-12-14T01:06:59+00:00 user29333893046… user29345657428… test-data 20.9 2021-12-14T01:18:56+00:00 2021-12-14T01:20:56+00:00 user54519105346… user545293 test-data 16.5 2021-12-14T01:18:56+00:00 2021-12-14T01:20:56+00:00 user49196524328… user49206
ホット タブレット データのユースケース
クラスタ内のホット タブレットを特定すると、パフォーマンス問題のトラブルシューティングに役立ちます。ListHotTablets メソッドは、他のモニタリング ツール（Bigtable 用の Key Visualizer 診断ツールなど）と組み合わせて使用できます。
問題のある行キーを特定する
ListHotTablets は、特定の行キーと行範囲を識別するために使用できます。これにより、ホットスポットの原因となるアクセス パターンをモニタリングできます。
たとえば、テーブルの行キースキーマが [user_id]#[event_timestamp]、ユーザー ID とタイムスタンプがシャープ記号で区切られているとします。ホット タブレットのリストを取得すると、ホットスポットが特定のユーザー ID やイベントのタイムスタンプで発生しているのかどうかの判断に役立ちます。アクセス パターンを特定すると、もう一歩踏み込んだアクションが可能になります（たとえば、行キーやテーブルを再設計して使用量をキースペースに均等に分散するなど）。この例では、ユーザー ID が単調に増加しているためにホットスポットが発生している場合、ユーザー ID を別の順序で割り当てるか、代わりに UUID（Universally Unique Identifier）を使用します。
開始行キーと終了行キーが同じで、終了行キーに接尾辞 \000 が追加されている場合は、1 行のタブレットが作成されます。このタブレットが大量のトラフィックを受信すると、ホットスポットが発生します。
分単位の精度でホットスポットをモニタリングする
ホット タブレットのリストは、Key Visualizer のヒートマップと組み合わせて使用できます。Key Visualizer は、キースペースのアクセス パターンの全体像の把握に適していますが、精度は ListHotTablets のほうが高くなります。
Key Visualizer でヒートマップを調べたら、特定のホットスポットをさらに調べることができます。Key Visualizer は数週間にわたって実行されているため、ホットスポットのデータは 15 分間隔で集計されます。また、同じ Key Visualizer キースペース内に複数のタブレットを組み合わせることもできます。
Key Visualizer を使用して、ホットスポットが発生した時間範囲を特定した後は、ListHotTablets を実行して、キーと時間の両方についてより詳細に分析できます。より高い精度は、定期的な使用で特に役立ちます。ListHotTablets が、KeyVisualizer では特定できない有効期間が短いホットスポットを特定できます。
クラスタ内の問題があるテーブルを特定する
複数のテーブルがあるクラスタのトラブルシューティングを行う場合、Key Visualizer は、テーブルレベルで動作するため、必ずしも最適な選択肢になるとは限りません。ListHotTablets は、クラスタレベルで動作するため、これを使用することで CPU 使用率が高いテーブルを特定し、問題を絞り込むことができます。