📚 GCP PCA 学習: 2026-05-01

セクション: 2.2 個別ストレージシステムの設定 前回からの繋がり: 前回のネットワークトポロジーの設定で「通信路」を整えたので、今回はその通信路を流れるデータを保存する「ストレージ」を実装していく。データの形態・スケール・アクセスパターンによって、最適なストレージサービスが異なる。

① 一言サマリー

「ストレージシステムの設定とは、データの『形態』『スケール』『アクセスパターン』の 3 軸に従い、Cloud Storage / Cloud SQL / Cloud Spanner / Firestore / Bigtable の中から最適なサービスを選び、ライフサイクル・バージョニング・レプリケーション・ストレージクラスで構成する実装である」

② たとえ話

大型図書館の整備になぞらえる： - 📚 本（データ）をどこに保管するか？ - 「本棚」（Cloud Storage）：形・サイズ不問、大量の本を安く保管。利用頻度が落ちたら別館に移す（ライフサイクル） - 「検索システム付き棚」（Cloud SQL）：決まった分類法で、高速に目的の本を引き出す。複数版の保管も対応（バージョニング） - 「全文検索機能付き白書室」（Firestore）：カテゴリ分けしない、フレキシブルなレイアウト。スマホ相談窓口も同期対応 - 「超高速メモリ特化室」（Bigtable）：数百年分の新聞記事を秒単位で検索・集計 - 冗長化：「本館が火災になった時のため、別館に同じ本を保管」（レプリケーション）

③ 図解

graph LR
    A["📊 データ選別"]
    B["データは何か"]
    C["スケールは"]
    D["アクセス頻度は"]

    A --> B
    B -->|構造化| E["決まったスキーマ？"]
    B -->|非構造化| F["画像・動画・ログ"]

    E -->|Yes| G["トランザクション要件は？"]
    E -->|No| H["Firestore
柔軟なDoc"]
    F --> I["Cloud Storage
安く大量保管"]

    G -->|ACID・複雑結合| J["スケールは
TB 級か？"]
    G -->|シンプルKVS| K["Firestore
リアルタイム更新"]

    J -->|<10 TB| L["Cloud SQL
RDBMS・高速"]
    J -->|>10 TB| M["Cloud Spanner
分散ACID"]

    D -->|時系列・集計| N["Bigtable
超高速・列指向"]

    style I fill:#FFE4B5
    style H fill:#E6F3FF
    style L fill:#E6F3FF
    style M fill:#E6F3FF
    style N fill:#FFF0F5
    style K fill:#E6F3FF

専門用語注釈： - 「トランザクション」とは：複数の SQL 操作が「全て成功」か「全て失敗」の原子性を保証する仕組み。たとえると、銀行の振込：「Aさん口座から 1000 円を引く + Bさん口座に 1000 円足す」が絶対に両立。ACID（Atomicity / Consistency / Isolation / Durability）の頭文字で呼ぶ。 - 「ライフサイクル」とは：作成直後は高速ストレージに保存し、90日経過したら安いコールドストレージに自動移動させるルール。 - 「レプリケーション」とは：A リージョンのデータを B リージョンに自動コピーし、A がダウンしても B から読める状態を作る。同期か非同期かで復旧戦略が変わる。

④ 仕組みの深掘り

Cloud Storage：単純・安定・スケール無限

設計思想：「AWS S3 互換の、シンプルなオブジェクトストレージ」 - バケット（Bucket）= フォルダ、オブジェクト（Object）= ファイル - REST API で自由にアップロード/ダウンロード - ストレージクラスで価格 ↔ 復旧速度をトレード - Standard：ホットデータ。GB/月 $0.020 - Nearline：90 日未アクセス推奨。GB/月 $0.010（検索料金 $0.01/GB） - Coldline：1 年未アクセス推奨。GB/月 $0.004 - Archive：7 年保管推奨。GB/月 $0.0012（復旧 12h 要） - ライフサイクルルールで自動降格 - 例：作成後 90 日で Nearline、1 年で Coldline へ自動移動 - バージョニングで削除を取り消し可能（過去 N バージョン保持） - オブジェクトロックで削除禁止（法令遵守・記録管理向け）

最新 GA 機能：AI zones でのオブジェクト保存（AI/ML ワークロード向け低レイテンシ）

Cloud SQL：既存 DB との親和性が強み

RDBMS（PostgreSQL / MySQL / SQL Server） の完全マネージド版 - HA 構成：Primary + Replica（自動フェイルオーバー秒単位） - Read Replicas：読み取り分散（Cross-region 対応でグローバル低レイテンシ） - バックアップ：日次自動 + ポイントインタイムリカバリ（PITR） - 暗号化：保存時（顧客管理キー対応）・転送時（SSL） - Insights：クエリ性能分析・遅いクエリの自動検出

スケール上限： - Storage：64 GB ～ 65.536 GB - CPU：1 ～ 96 vCPU - しかし性能は「台数増」で水平スケーリング不可（Read Replicas で読み取りのみ分散）

最新 GA 機能：cloudsql_session_read_only パラメータで、誤削除防止の読み取り専用セッション

Cloud Spanner：分散 ACID の唯一の選択肢

思想：「マルチリージョン対応の ACID RDBMS」 - Cloud SQL との最大の違い = 水平スケーリングでも ACID 保証 - Cloud SQL：1 マシンへの接続が増えるとボトルネック - Spanner：ノード 3 個 → 10 個に増やすだけで処理能力も 3 倍 - TrueTime：Google のアトミッククロックで、リージョン間データ同期を低遅延化（1-5ms） - マルチリージョンレプリケーション：リード遅延 <10ms（金融・決済向け） - 高コスト：Cloud SQL の 10 倍以上（ノード月 3 万円）

選定ルール： - <10 TB・ACID 不要：Cloud SQL - <10 TB・ACID 必須：Cloud Spanner - 10 TB 以上：Cloud Spanner

Firestore：リアルタイム・フレキシブル NoSQL

設計思想：「スキーマレス・リアルタイム同期の NoSQL」 - Document / Collection 階層（JSON ネスト構造） - リアルタイム Listener：データ変更を即座に全クライアントに通知 - モバイルアプリとの同期が簡単（Firebase SDK） - オフラインモード：ネットワーク切断時もローカル保存 → 復旧時に同期

スケール上限： - 1 document：1 MB - 1 コレクション：無制限（実質） - 同時接続：数十万

課題： - トランザクション：複数 document にまたがると複雑（全ロック方式で競合率↑） - 集計クエリ：複雑な GROUP BY は向かない（BigQuery との連携推奨）

Bigtable：時系列・集計の王様

設計思想：「HBase 互換・超大規模時系列 DB」 - 行キー = タイムスタンプ（毎秒数百万行の追記対応） - 列族（Column Family）でデータを分離・独立スケーリング - GoogleSQL サポート（GA）：SQL で分析可能（BigQuery Spark 連携） - 検索レイテンシ：p99 < 10ms（大規模集計対応）

最新 GA 機能： - Editions（GA）：Enterprise / Enterprise Plus で機能分け - Data Boost（GA）：tiered storage・HDD クラスタから高速読取 - In-memory Tier（Enterprise Plus、Preview）：サブミリ秒読取 - Window functions（GA）：SQL で分析関数が利用可能

選定ルール： - 「毎秒 1000 万行以上の追記」「秒単位での集計」 → Bigtable 必須 - それ以下なら Cloud SQL・Firestore で十分（コスト 1/10）

⑤ 他サービスとの使い分け

要件	Cloud Storage	Cloud SQL	Cloud Spanner	Firestore	Bigtable
スキーマ	不要	固定	固定	可変（JSON）	可変
スケール	∞	<10TB	10TB+	<1TB	<PB
ACID	❌	✅	✅	△（限定）	❌
リアルタイム同期	❌	△（Polling）	△（Polling）	✅	❌
月額（最小構成）	$100	$300	$3,000	$150	$2,000
典型用途	ログ・バックアップ	Web App・業務 DB	金融・決済	モバイル・IoT	ビッグデータ

PCA 試験での判断基準：

「構造化か？」
非構造化（画像・ログ・動画）→ Cloud Storage
構造化データ → 次へ
「リアルタイム同期か？」
Yes → Firestore（Web・Mobile SDK との連携も含む）
No → 次へ
「スケールは？」
<10 TB・ACID 要 → Cloud SQL
10 TB または複数リージョン ACID 要 → Cloud Spanner
毎秒百万行以上の時系列 → Bigtable

⑥ 実務への応用

ユースケース 1：Web アプリケーション + モバイル

要件： - ユーザープロフィール・投稿内容を保存 - iOS/Android アプリでリアルタイム更新 - オフライン対応

選択：Firestore - Firebase SDK で iOS/Android ネイティブ開発が簡単 - リアルタイム Listener で投稿一覧の自動更新 - オフラインモード搭載 - 月額 150 ドル以下で十分

ユースケース 2：決済・金融システム

要件： - 複数通貨の口座残高（ACID 必須） - グローバル決済（<10ms 遅延） - 1 日 1000 万トランザクション

選択：Cloud Spanner - ACID で振込の原子性保証 - TrueTime でリージョン間同期を高速化 - 水平スケーリングで 1000 万 TPS 対応 - コスト覚悟が必須

ユースケース 3：アクセスログ・時系列データ

要件： - Web サーバーログ（毎秒 10 万行） - 1 年保管・月別集計 - 検索レイテンシ <100ms

選択：Bigtable + Cloud Storage - Bigtable：ホットデータ（1 ヶ月分）を高速検索 - Cloud Storage：アーカイブ（1 年分）を月別に Coldline 保管 - ライフサイクルルール：30 日経過後、Bigtable → Cloud Storage へ自動転送 - 総コスト = Bigtable 月 $2000 + Cloud Storage 月 $100

ユースケース 4：既存オンプレ DB の移行

要件： - MySQL 5.7 を GCP に移行 - 既存アプリ（Java / Python ORM）を変更最小化 - RTO = 1 時間、RPO = 1 時間

選択：Cloud SQL for MySQL - Migrate for Compute Engine で VM から Cloud SQL へ直接移行 - HA 構成：Primary + Replica（自動フェイルオーバー） - PITR で RPO 達成 - 既存アプリは接続文字列変更のみで動作

⑦ よくある誤解・落とし穴

誤解 1：「大規模データ = 必ず Bigtable」

❌ 間違い：Bigtable は「超大規模・時系列特化」で、単に「大きいデータ」には向かない - ✅ 正解： - 100 GB の静止画コレクション → Cloud Storage（コスト 1/100） - 1 GB の構造化データで日次レポート → Cloud SQL（Bigtable はオーバースペック）

誤解 2：「Cloud SQL は 1 台だから High Availability ない」

❌ 間違い：Cloud SQL HA = 別ゾーンの Replica への自動フェイルオーバー - ✅ 正解：99.95% SLA を保証（3 秒以内のフェイルオーバー）

誤解 3：「Firestore は無制限」

❌ 間違い：1 document が 1 MB 制限、複雑な JOIN クエリは失敗 - ✅ 正解：1 GB 以上の単一ドキュメントは不可（分割必須）

誤解 4：「ライフサイクルルールは削除だけ」

❌ 間違い：ストレージクラスの自動降格も含む - ✅ 正解：例：作成後 30 日で Standard → Nearline へ自動移動（検索料金発生）

誤解 5：「Cloud Spanner は常に最速」

❌ 間違い：リージョン間コミット遅延・分散ロック競合で、単一リージョン Cloud SQL より遅い場合も - ✅ 正解： - 単一リージョン・ACID 不要 → Cloud SQL が低遅延 - マルチリージョン・ACID 必須 → Cloud Spanner 選択

⑧ 理解度チェック

問 1：以下の要件で最適なストレージを選び、理由も答えてください

「IoT センサーから 1 時間ごとに 1000 行のタイムスタンプ付きデータが送られる。3 年保管し、月単位で集計レポートを生成する。検索レイテンシは 1 秒以下。」

考えるポイント： - 1 時間ごと 1000 行 = 年 880 万行（Bigtable 必須か？） - 「月単位の集計」= 複雑な GROUP BY（Firestore は向かない） - 「3 年保管」= ストレージコスト重視（アーカイブ層へ自動転送）

模範解答： - 1 年目：Bigtable（ホットデータ、検索速度優先） - 2～3 年目：Cloud Storage Coldline へ自動転送（月 $50 以下） - 集計：BigQuery で月別 JOIN クエリ（Bigtable より柔軟） - 理由：時系列データの将来検索がないなら、Bigtable は不要。Cloud Storage + BigQuery で 80% コスト削減

問 2：「ユーザープロフィール（最大 1 MB）を 100 万ユーザーで保存。Web API でプロフィール検索・更新。リアルタイム性は不要。」どのサービスを選びますか？

考えるポイント： - 100 万 × 1 MB = 1 TB（Cloud SQL 限界付近） - スキーマは固定か？（ユーザー属性が増えない？） -「リアルタイム」不要 → Firestore の強みは活かせない

模範解答： - Cloud SQL for PostgreSQL（JSONB カラムで柔軟にプロフィール拡張可） - 理由： - スキーマ固定の構造化データ → SQL が効率的 - 1 TB なら Cloud SQL で十分（Spanner 不要） - Firestore だと複雑なプロフィール検索（WHERE 条件多数）が遅い

⑨ 深掘り補足（PCA 試験範囲外・オプション）

① Cloud Storage の詳細設定

オブジェクトロック（DELETE 禁止） - 用途：医療記録（HIPAA）・財務帳簿（法令 10 年保管） - 設定：gcloud storage buckets update --lock-retention-seconds - コスト追加なし

カスタムメタデータ - オブジェクト作成時に任意の key-value を付与（例：tier=premium） - ライフサイクルルール：メタデータで条件分岐可能

転送加速（Transfer Appliance） - 100 TB 以上のデータ：VPN より高速・安定 - 物理デバイスをレンタル → Google DC に送付 → 自動インポート - コスト：$300/週

② Cloud SQL のレプリケーション戦略

Read Replicas（読み取り分散）

Primary (us-central1) [write]
    ↓
Replica-1 (us-east1) [read]
Replica-2 (asia-east1) [read]

- 低遅延読取を実現（地域別） - 但し：Replica への書き込みはできない（読み取り専用）

外部レプリケーション - Cloud SQL → Cloud SQL 別プロジェクト - Cloud SQL → Bigtable（カラム指向で分析） - Cloud SQL → Cloud Storage（JSON エクスポート）

③ Bigtable の列族設計

rowkey: user-1000-20260501-120000

ColumnFamily: profile
  - name: "Alice"
  - age: 28

ColumnFamily: metrics
  - cpu_usage: 45%
  - memory_usage: 62%

設計のコツ： - アクセスパターン同じもの → 同一列族（キャッシュ効率↑） - 異なるパターン → 分離列族（独立スケーリング）

④ Firestore の複合インデックス

複雑なクエリ（WHERE 複数条件）は自動インデックス不足

db.collection("users")
  .where("age", ">=", 20)
  .where("country", "==", "JP")
  .orderBy("created_at", "desc")
  .get()

このクエリ実行時、Firestore が「複合インデックス作成が必要」と指摘 → Cloud Console で 1 クリック作成（数分で有効化）

コスト：月 $0.25/インデックス（少量なら無視）

⑤ Cloud Spanner の地政学的構成

⚠️ 地域制限：EU データは eu-west1 に限定（GDPR）

マルチリージョン構成：
- Primary: us-central1
- Replica: us-east1
- Replica: eu-west1 （GDPR 遵守）

レイテンシ： - Primary → Replica：同期レプリケーション（1-5ms、TrueTime） - 非同期レプリケーション設定も可（RPO 数秒、遅延 <100ms）

次回: 2.3 コンピュートシステムの設定（Compute Engine / GKE / Cloud Run / MIG の構成と選定）