Firestore / Bigtable

解決する課題

アクセスが急増しても落ちない/遅くならないDBが欲しい
DBの容量計画・シャーディング・パッチ適用を自分でやりたくない
モバイル/Web にリアルタイムで変更を同期したい（オフライン対応も）
ミリ秒〜数十ミリ秒の応答を安定して出したい

主要概念と用語

ドキュメント / コレクション: 1 件のデータ（JSON 風の構造）と、その入れ物。DynamoDB の項目（Item）/ テーブルに相当
サブコレクション: ドキュメント配下にネストできるコレクション。階層パスで一意に表現される
ドキュメント ID: コレクション内でドキュメントを一意に指す。DynamoDB のパーティションキーに近い役割
複合インデックス / 単一フィールドインデックス: クエリ高速化のためのインデックス。Firestore は全フィールドを自動でインデックス化し、複合条件は明示的に複合インデックスを定義する
モード: Native モード（リアルタイム同期・オフライン・強整合）と Datastore モード（旧 Cloud Datastore 互換、サーバーサイド向け）の 2 種類。データベース単位で選ぶ
トランザクション / バッチ書き込み: 複数ドキュメントをまとめて整合的に更新
リアルタイムリスナー: ドキュメント/クエリの変更を購読し、差分を即時受信
Firestore triggers（Cloud Functions）: 書き込みをイベント化して関数を起動（DynamoDB Streams + Lambda 相当）
TTL ポリシー: フィールド値の時刻でドキュメントを自動削除（DynamoDB の TTL 相当）
Cloud Bigtable: 別サービス。ワイドカラム型でペタバイト級・高スループットの分析/時系列向け

仕様・制限・クォータ

1 ドキュメント最大 1 MiB（DynamoDB の項目 400KB より大きい）
1 ドキュメントあたりの書き込みは持続 1 回/秒が目安（同一ドキュメントの高頻度更新は分散シャーディングで回避）
クエリはインデックスに基づき結果セットに比例して課金・スケールする（テーブル全件スキャンの概念がない）
整合性は Native モードで強整合（単一ドキュメント read と多くのクエリ）。リスナーは変更を順序保証して配信
マルチリージョン / リージョナルのロケーションを選択でき、データは複数ゾーン（マルチリージョンなら複数リージョン）に自動複製
1 プロジェクトに複数の Firestore データベースを作成可能（既定 DB の名前は (default)）

内部の仕組み

Firestore はドキュメントをキー範囲でソートして分散ストレージに保持し、負荷に応じて内部的にキー範囲を自動分割（スプリット）してスケールします。クエリは必ずインデックスを引くため、スキャン量はヒット件数に比例し、コレクションが巨大でも速度は劣化しにくいのが特徴です。一方で、連番 ID やタイムスタンプ昇順など単調増加するキーに書き込みを集中させると、特定のキー範囲（=特定の内部サーバー）に負荷が偏るホットスポットが発生します。

設計の鉄則

RDB の正規化ではなくアクセスパターン駆動設計。「どう問い合わせるか」を先に決めてコレクション構造とインデックスを設計します。書き込みキー（ドキュメント ID やインデックス対象フィールド）は単調増加を避けて分散させ、ホットスポットを防ぎます。

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

アクセスパターンを列挙 → コレクション/サブコレクション構造と複合インデックスを設計
ドキュメント ID は自動生成 ID（ランダム） を基本にし、連番・タイムスタンプ前置を避けてホットスポット回避
高頻度カウンタは分散カウンタ（複数シャードに分割して集計） で 1 ドキュメント 1 回/秒の制限を超える
変更駆動の処理は Firestore trigger → Cloud Functions（集計・通知・他システム連携）
リアルタイム性が要るクライアントはリスナーで購読し、ポーリングを避ける
超高スループット・大容量の時系列/分析は Firestore ではなく Cloud Bigtable を選ぶ

運用・監視・トラブルシュート

Cloud Monitoring でメトリクス（document_reads/writes/deletes、API レイテンシ、アクティブな接続数など）を監視
クエリが遅い/エラーになる場合は必要な複合インデックスの不足を疑う（コンソールやエラーメッセージに作成リンクが出る）
書き込みエラーや遅延はホットスポット（単調増加キー / 同一ドキュメント高頻度更新）を疑い、キー分散や分散カウンタで解消
マネージドエクスポート/インポートでバックアップを取得（gcloud firestore export/import）、加えて PITR（ポイントインタイムリカバリ） で過去の状態に復元可能

コスト

Firestore はドキュメントの読み取り/書き込み/削除の回数、ストレージ量、ネットワーク下り（外向き）で課金されます。DynamoDB の「キャパシティユニット」ではなくオペレーション回数が基本単位である点が大きな違いです。

コスト要素	課金の単位	節約のコツ
ドキュメント読み取り	read 1 件ごと（クエリは返却件数ぶん）	クエリで件数を絞る / 必要な分だけ取得
ドキュメント書き込み・削除	write・delete 1 件ごと	バッチ書き込みでまとめる / 不要な更新を避ける
インデックス書き込み	インデックスエントリの更新ぶん	不要な単一フィールドインデックスを除外
ストレージ	保存バイト数（ドキュメント＋インデックス）	TTL で古いデータを自動削除

セキュリティ

保存時暗号化はデフォルトで有効（Google 管理鍵、または CMEK で顧客管理鍵を利用可能）
サーバーサイドのアクセスは Cloud IAM のロール（例 roles/datastore.user）で制御し、サービスアカウントに最小権限を付与
モバイル/Web から直接アクセスする場合は Firestore セキュリティルールで、ユーザー（Firebase Authentication）やドキュメントの内容に応じたドキュメント/フィールド単位の許可を記述
VPC 内からの到達制御や持ち出し防止には VPC Service Controls を組み合わせる

アンチパターン

クライアント直結なのにセキュリティルールを allow read, write: if true;（全開放）のまま公開するのは NG。誰でも全データを読み書きできてしまいます。認証状態と所有者チェックを必ずルールに書きましょう（サーバー経由のアクセスでも IAM サービスアカウントは最小権限に）。

観点	Firestore（GCP）	Amazon DynamoDB（AWS）
位置づけ	サーバーレスドキュメント NoSQL	サーバーレスキーバリュー/ドキュメント NoSQL
データ単位	ドキュメント / コレクション	項目（Item）/ テーブル
1 件の最大サイズ	1 MiB	400 KB
インデックス	全フィールド自動 + 複合インデックス	GSI / LSI を明示作成
変更イベント	Firestore triggers → Cloud Functions	DynamoDB Streams → Lambda
課金単位	読み書き削除の回数 + ストレージ	読み書きキャパシティ + ストレージ
クライアント直結	セキュリティルールで制御	Cognito + IAM で制御
超高スループット代替	Cloud Bigtable	DynamoDB（+ DAX）

ハンズオン / CLI例

# Firestore API を有効化し、Native モードのデータベースをマルチリージョンに作成
gcloud services enable firestore.googleapis.com

gcloud firestore databases create \
  --location=nam5 \
  --type=firestore-native

# 複合インデックスを定義（例: status で絞り、createdAt 降順で並べる）
gcloud firestore indexes composite create \
  --collection-group=orders \
  --field-config=field-path=status,order=ascending \
  --field-config=field-path=createdAt,order=descending

# TTL ポリシーを作成（expireAt フィールドの時刻でドキュメントを自動削除）
gcloud firestore fields ttls update expireAt \
  --collection-group=sessions \
  --enable-ttl

# データを Cloud Storage にエクスポート（バックアップ）
gcloud firestore export gs://my-bucket/firestore-backup