Cloud Bigtable

解決する課題

• 数十億行・ペタバイト級でも安定して一桁ミリ秒の読み書きを出したい
• 毎秒数十万〜数百万オペレーションの高スループットを捌きたい
• 時系列 / IoT / 監視メトリクス / ユーザー行動ログなど書き込みが膨大なワークロードを扱いたい
• 容量計画やシャーディング、パッチ適用を自分で運用したくない
• 必要なときだけノードを足してスループットを伸ばし、減らしてコストを抑えたい

主要概念と用語

• インスタンス: Bigtable の最上位コンテナ。1 つ以上のクラスタとテーブルを束ねる。DynamoDB のリージョン内テーブル群に近い管理単位
• クラスタ: 実際にリクエストを処理するノード群。特定のゾーンに属し、ノード数でスループットが線形にスケールする
• ノード: クラスタ内の処理ユニット。CPU と接続を提供し、ストレージとは分離されている
• テーブル / 行 / 列 / セル: テーブルは行の集合。各行は行キーで一意。列は列ファミリーでグループ化され、セルにはタイムスタンプ付きの複数バージョンを保持できる
• 行キー（Row Key）: 各行を一意に識別するキーで、辞書順にソートして格納される。設計が性能を左右する最重要要素。DynamoDB のパーティションキーに相当する役割
• 列ファミリー（Column Family）: 関連する列をまとめる単位。アクセスパターンやガベージコレクション設定の単位になる
• ガベージコレクションポリシー: セルのバージョン数や保持期間で古い値を自動削除するルール
• タブレット（Tablet）: 行キー範囲ごとに分割されたデータの塊。負荷に応じて自動分割・再配置される
• アプリプロファイル: ルーティング方法（単一クラスタ / マルチクラスタ）や優先度を定義する接続設定
• レプリケーション: 複数クラスタ間でデータを非同期コピーし、可用性や地理的近接、ワークロード分離を実現する

仕様・制限・クォータ

• インターフェースは HBase 互換 API と独自のクライアントライブラリ。HBase からの移行がしやすい
• クエリは行キー中心。行キーの完全一致または範囲スキャンが基本で、任意フィールドの二次インデックスや SQL の複雑な結合は持たない（用途が異なる）
• 整合性は単一クラスタへの読み書きで強整合。マルチクラスタにルーティングすると結果整合になりうる
• ストレージは SSD と HDD から選択でき、インスタンス作成時に決める（あとから変更不可）
• 1 行のサイズには上限があり、極端に大きな行（数百 MB 級）は推奨されない。値そのものにもセルサイズの上限がある
• 最小ノード数やノードあたりの処理上限といった目安があり、必要スループットに応じてノード数を見積もる
• 上記のような具体的な数値・上限は変動しうるため、設計時は公式ドキュメントの最新値を確認すること

内部の仕組み

Bigtable はストレージとコンピュート（ノード）を分離したアーキテクチャです。実データは Google の分散ファイルシステム上に行キーで辞書順ソートして保持され、ノードはそのデータへのポインタとリクエスト処理だけを担います。データはタブレットと呼ばれる行キー範囲の塊に分割され、各タブレットがノードに割り当てられます。負荷やデータ量が偏ると、Bigtable は**タブレットを自動で分割・再配置（リバランス）**してノード間の負荷を均します。

この仕組みのため、ノードを追加するとスループットがほぼ線形に増加します。一方で、行キーが**単調増加（タイムスタンプ昇順や連番）**だと書き込みが常に末尾のタブレット＝特定ノードに集中し、ホットスポットが発生してスケールしません。

設計パターン / ベストプラクティス

• アクセスパターン（読みたい範囲・絞り込みキー）を列挙し、それに合わせて行キーを設計する
• 行キーには頻繁に絞り込む属性を前方に置き、範囲スキャンが効くよう連結する（例: ユーザー ID + 逆順タイムスタンプ）
• 単調増加キーを避け、必要ならハッシュ前置やフィールドの並べ替えで分散させる
• 関連して読む列を同じ列ファミリーにまとめ、アクセスしない列を無駄に読まない
• 古いデータはガベージコレクションポリシーでバージョン数・保持期間を絞り、ストレージとスキャン量を抑える
• 本番投入前にKey Visualizerでホットスポットの兆候（特定キー範囲への偏り）を確認する
• 高可用やワークロード分離が要る場合はレプリケーション＋アプリプロファイルでルーティングを設計する
• 複雑な集計・分析が必要なら、Bigtable をストレージ層に据えて BigQuery など分析サービスと組み合わせる

運用・監視

• Cloud Monitoring で CPU 使用率、ディスク使用率、レイテンシ、リクエスト数などのメトリクスを監視する
• CPU 使用率が高止まりしたらノードを増やす。逆に余裕があれば減らしてコストを下げる。オートスケーリングでノード数を負荷に追従させることもできる
• Key Visualizer で行キーへのアクセス分布をヒートマップとして可視化し、ホットスポットを早期発見する
• レプリケーションを使う場合はレプリケーション遅延を監視し、整合性要件と照らす
• バックアップ機能でテーブルのスナップショットを取得し、誤操作や障害から復元できるようにする
• ストレージタイプ（SSD / HDD）はインスタンス作成後に変更できないため、用途を見極めて初期選択する

コスト

Bigtable のコストは主にノード数（プロビジョニングしたコンピュート）、ストレージ量（SSD / HDD で単価が異なる）、そしてネットワーク下り（外向き）転送量で構成されます。DynamoDB のオンデマンド課金とは異なり、ノード単位で時間課金される点が大きな違いで、アイドル時もノードを保持していれば費用が発生します。

セキュリティ

• 保存時暗号化はデフォルトで有効（Google 管理鍵、または CMEK で顧客管理鍵を利用可能）
• アクセス制御は Cloud IAM のロール（例として閲覧者・ユーザー・管理者に相当するロール）で付与し、サービスアカウントには最小権限を割り当てる
• アクセス権限はインスタンス単位やテーブル単位で絞り込め、用途に応じた分離ができる
• ネットワーク到達制御やデータ持ち出し防止には VPC Service Controls を組み合わせ、境界の外からのアクセスを遮断する
• 監査は Cloud Audit Logs で管理操作やデータアクセスを記録する

Well-Architected の観点

• パフォーマンス効率: ノード追加でスループットがほぼ線形にスケールし、ストレージとコンピュートが分離されているため大規模でも一桁ミリ秒を維持しやすい。行キー設計とホットスポット回避が前提条件
• コスト最適化: ノードの時間課金が中心。オートスケーリングでアイドルコストを抑え、低頻度アクセスのデータには HDD ストレージを選んでストレージ単価を下げる
• 信頼性: タブレットの自動分割・再配置でノード障害や負荷偏りを吸収。レプリケーションで複数ゾーン / リージョンに分散すると可用性とワークロード分離が向上する
• 運用上の優秀性: フルマネージドでパッチやシャーディングの手運用が不要。Key Visualizer と Cloud Monitoring で性能を継続的に観測できる

試験で問われるポイント

関連サービス・比較

関連する Google Cloud サービスとしては、ドキュメント型でモバイル同期に強い Firestore、リレーショナルでグローバル整合の Cloud Spanner、分析用データウェアハウスの BigQuery があり、アクセスパターンと整合性要件で使い分けます。

ハンズオン / CLI例

# Bigtable API を有効化
gcloud services enable bigtable.googleapis.com bigtableadmin.googleapis.com

# SSD ストレージのインスタンスとクラスタを作成（ノード数を指定）
gcloud bigtable instances create my-instance \
  --display-name="My Bigtable" \
  --cluster-config=id=my-cluster,zone=us-central1-b,nodes=3 \
  --cluster-storage-type=SSD

# クラスタのオートスケーリングを有効化（ノード数を負荷に追従させる）
gcloud bigtable clusters update my-cluster \
  --instance=my-instance \
  --autoscaling-min-nodes=2 \
  --autoscaling-max-nodes=10 \
  --autoscaling-cpu-target=60

# cbt CLI でテーブルと列ファミリーを作成し、1 行書き込んで読む
cbt -instance=my-instance createtable user-events
cbt -instance=my-instance createfamily user-events activity
cbt -instance=my-instance set user-events "user123#20260614" activity:type=click
cbt -instance=my-instance read user-events