Deep Dive: Storage & Database

📚 参照する公式ドキュメント

本資料は以下の Google Cloud 公式ドキュメント（2026 年時点）から技術詳細・制限・SLA・ベストプラクティスを抽出しています。各章で都度引用と URL を併記します。

1ストレージ全体像 — 7 つの分類

Google Cloud のデータストアは、形（オブジェクト・ファイル・ブロック）とクエリ特性（KV・リレーショナル・ドキュメント・分析）と速度（永続・キャッシュ）の組合せで 7 カテゴリに分類できます。試験では「データ構造」と「整合性要件」と「スケール特性」の 3 つで一意に絞り込めるよう、各カテゴリの代表サービスを最初に頭に入れます。

1.1 7 カテゴリと代表サービス（SVG 図解）

1.2 データ構造で即決する判定表

2ストレージ選定 完全決定フロー

試験シナリオでは「グローバル展開」「ACID 必須」「秒間 100 万 QPS」「<10 ms レイテンシ」など複数条件が同時に提示されます。以下のメイン決定ツリーを暗記し、矛盾する条件があった時の判断軸まで身につけます。

2.1 メイン決定ツリー（SVG 図解）

2.2 整合性・スケールの 4 象限マップ

2.3 規模・コスト感の早見表

2.4 試験での出題パターン（章2）

3Cloud Storage 完全解剖

Cloud Storage (GCS) は GCP の最も基盤的なサービスで、Organization → Project → Bucket → Object という階層を持ちます。試験では「ストレージクラス選定」「Lifecycle 設計」「Bucket Lock の不可逆性」「IAM vs ACL」「署名付き URL」「VPC Service Controls との連携」が頻出です。

「Buckets are containers to store your objects ... Objects are immutable piece[s] of data consisting of a file of any format.」 — Cloud Storage overview

3.1 ストレージクラス完全比較

3.2 ロケーション 3 種（Region / Dual-region / Multi-region）

3.3 Object Lifecycle Management（OLM）

Lifecycle Policy は「条件（Age / NewerVersions / IsLive 等）が一致したらアクション（Delete / SetStorageClass / AbortIncompleteMultipartUpload）を実行する」というルール集です。サポートされるアクションと条件を正確に覚えると、試験で出る Lifecycle ベース問題は全問正解できます。

「Lifecycle rules apply Delete, SetStorageClass, or AbortIncompleteMultipartUpload actions when conditions like age, createdBefore, numNewerVersions, isLive, or matchesStorageClass match.」 — Object Lifecycle Management

3.3.1 サポートされる 3 つのアクション

3.3.2 サポートされる 10 個の条件

{
  "lifecycle": {
    "rule": [
      {
        "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
        "condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
      },
      {
        "action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
        "condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]}
      },
      {
        "action": {"type": "SetStorageClass", "storageClass": "ARCHIVE"},
        "condition": {"age": 365, "matchesStorageClass": ["COLDLINE"]}
      },
      {
        "action": {"type": "Delete"},
        "condition": {"age": 2555}
      },
      {
        "action": {"type": "AbortIncompleteMultipartUpload"},
        "condition": {"age": 7}
      }
    ]
  }
}

3.4 Autoclass — 自動クラス遷移

Autoclass は「アクセスパターンが予測不能なバケット」向けに、オブジェクト単位でアクセス頻度を監視し、自動的にクラスを上下させる機能です。Lifecycle と違って「アクセスされたら Standard に戻す」逆方向の動きもします。

3.4.1 Autoclass の動作（公式仕様）

3.4.2 Autoclass vs Lifecycle どちらを選ぶか

3.5 Bucket Lock — 規制対応の不可逆ロック

Bucket Lock は、バケットの Retention Policy（保持期間）を「永久に減らせない」状態にする機能です。SEC 17a-4、FINRA、CFTC、HIPAA、医療業界の長期保管規制への対応に使われます。

「You can lock the bucket's retention policy, permanently preventing the policy from being reduced or removed.」 — Bucket Lock

3.5.1 Retention Policy の挙動

• Retention 期間中はオブジェクトを 削除も上書きもできない（IAM 権限があっても）
• 各オブジェクトに retentionExpirationTime メタデータが付与される
• 最大保持期間は 100 年（3,155,760,000 秒）
• 未ロック時は Retention 期間を「減らす・削除する」が可能
• ロック後は増やすことのみ可能、減らす・解除は永久不可
• バケット削除は、全オブジェクトの retention 満了後にしかできない

3.5.2 関連機能との違い

3.6 セキュリティ機能まとめ

3.7 試験での出題パターン（章3）

4GCS パフォーマンス設計

GCS は内部で「オブジェクト名でハッシュ → 自動シャーディング」していますが、連番・タイムスタンプ先頭のファイル名は同一シャードに集中させてしまい、1 秒あたりの書き込み QPS が頭打ちになります。試験では「アップロード QPS が伸びない」「ホットスポット」というキーワードで頻出。

4.1 ホットスポット回避（命名規則）

logs/2026-05-28-001.json
logs/2026-05-28-002.json
logs/2026-05-28-003.json
...（同じ prefix なので 1 つのシャードに集中）

3a/logs/2026-05-28-001.json
7f/logs/2026-05-28-002.json
b2/logs/2026-05-28-003.json
...（プレフィックス分散 → 並列シャード）

公式ガイドより：「Use a hash prefix at the start of object names to evenly distribute high request rates across multiple servers.」 — Request rate and access distribution

4.2 アップロード方式の使い分け

4.3 Parallel Composite Upload の仕組みと注意点

gsutil -o GSUtil:parallel_composite_upload_threshold=150M cp big.tar gs://... のようなコマンドで、ローカルファイルを N 分割して並列アップロードし、サーバ側で compose API により 1 つのオブジェクトに結合する仕組みです。

4.4 Premium Network Tier と Cloud CDN 連携

GCS の URL（例: storage.googleapis.com/bucket/object）は Premium Tier の Anycast 経由でグローバル配信されます。さらに静的サイト/Web アセット配信なら、Global External Application Load Balancer + Cloud CDN でエッジキャッシュを効かせるのが定石です。

4.5 試験での出題パターン（章4）

4.X GCS 事故ケース集

本番運用で頻出する GCS の事故シナリオです。一般化したパターンとして、設計レビューのチェックリストに使えます。

4.Y GCS 運用・保守ベストプラクティス

# Soft Delete 設定（保持 30 日）
gcloud storage buckets update gs://my-bucket --soft-delete-duration=30d

# Versioning 有効化
gcloud storage buckets update gs://my-bucket --versioning

# Retention Policy + Bucket Lock（変更不可）
gcloud storage buckets update gs://logs-bucket --retention-period=7y
gcloud storage buckets update gs://logs-bucket --lock-retention-period

# Public Access Prevention 強制
gcloud storage buckets update gs://my-bucket --public-access-prevention

# 削除済みオブジェクト復元（Soft Delete）
gcloud storage objects restore gs://my-bucket/path/file.txt --generation=1234567890

# Lifecycle dry-run（ローカル JSON で検証）
gcloud storage buckets update gs://my-bucket --lifecycle-file=lifecycle.json

5Cloud SQL 詳細 — マネージド RDB

Cloud SQL は MySQL / PostgreSQL / SQL Server を Google が運用するマネージドサービスです。試験では「HA（High Availability）構成」「Read Replica」「PITR（Point-in-Time Recovery）」「Cloud SQL Auth Proxy」「IAM 認証」「自動メンテナンス」が頻出です。Spanner を選ぶ前の標準的な選択肢として位置付けられます。

5.1 主要スペック早見表

5.2 Edition の差分（Enterprise / Enterprise Plus）

5.3 High Availability（HA）構成 — 内部動作

「The configuration provides data redundancy through synchronous replication to each zone's persistent disk. ... You can expect the instance to be unavailable for about sixty seconds」 — Cloud SQL HA

5.3.1 HA フェイルオーバーの仕組み（SVG）

5.3.2 HA の重要メトリクス

5.4 Read Replica（読込スケール）

「Limit the number of direct read replicas of your primary instance to 10 or fewer.」 — Cloud SQL Replication

• 同一リージョン Read Replica：読込負荷分散、低レイテンシ
• クロスリージョン Read Replica：地理的近接読込、DR 用途
• Cascading Replicas：プライマリ + 4 レベルまでのチェーンで、プライマリへの replication 負荷を軽減
• External Read Replica：Google Cloud 外の MySQL に複製可能（外向き転送料金あり）

5.5 PITR・バックアップ

5.6 Cloud SQL Auth Proxy と IAM 認証

本番では Public IP は使わず、必ず Private IP + Cloud SQL Auth Proxy を使うのが推奨です。Auth Proxy は IAM 認証情報を使って認可された IAM プリンシパルのみ DB 接続を確立できる仕組みで、パスワードレス DB 接続を実現します。

# インスタンス接続名を確認
gcloud sql instances describe my-instance --format="value(connectionName)"
# 出力例: my-project:asia-northeast1:my-instance

# Auth Proxy をローカル起動
./cloud-sql-proxy my-project:asia-northeast1:my-instance \
  --port=5432 \
  --auto-iam-authn

# アプリは localhost:5432 に接続するだけ
psql "host=127.0.0.1 port=5432 sslmode=disable dbname=mydb user=my-sa@my-project.iam"

5.7 Maintenance Window と Maintenance Reschedule

• 毎週 1 回の自動メンテナンス（ストレージ拡張・パッチ適用等）
• 曜日と時間を --maintenance-window-day / --maintenance-window-hour で指定
• メンテナンス通知を 1 週間前に受信可能
• Enterprise Plus は Near-Zero Downtime メンテナンス（<10 秒）を提供
• Maintenance Reschedule で「来週・後で・今すぐ」を選択可能

5.8 試験での出題パターン（章5）

5.9 Cloud SQL 事故ケース集

5.10 Cloud SQL 運用・保守ベストプラクティス

# HA 有効化（regional）
gcloud sql instances patch my-db --availability-type=REGIONAL

# 自動バックアップ + PITR
gcloud sql instances patch my-db \
  --backup-start-time=03:00 \
  --enable-bin-log \
  --retained-backups-count=30 \
  --retained-transaction-log-days=7

# Maintenance Window 設定
gcloud sql instances patch my-db \
  --maintenance-window-day=SUN \
  --maintenance-window-hour=3

# Deny Maintenance Period
gcloud sql instances patch my-db \
  --deny-maintenance-period-start-date=2026-11-23 \
  --deny-maintenance-period-end-date=2026-12-31 \
  --deny-maintenance-period-time=03:00:00

# PITR で 1 時間前に復元
gcloud sql instances clone my-db my-db-restored \
  --point-in-time='2026-05-28T05:00:00.000Z'

# Cross-region Read Replica 作成
gcloud sql instances create my-db-replica \
  --master-instance-name=my-db \
  --region=us-east1

6AlloyDB for PostgreSQL

AlloyDB は PostgreSQL 完全互換でハイパフォーマンス版の位置付けです。Cloud SQL PostgreSQL は「コンピュート + ストレージが密結合」ですが、AlloyDB は 分散ストレージ層 + コンピュート層を完全に分離し、Reader Pool で読込を最大 20 ノードに水平スケール、Columnar Engine で HTAP（OLTP + OLAP）を高速化します。

「AlloyDB uses disaggregated architecture separating compute and storage layers ... Primary instance contains either two nodes (HA) or one node (basic). Read pool instances can contain up to 20 nodes total.」 — AlloyDB overview

6.1 アーキテクチャ（SVG 図解）

6.2 Cloud SQL PG との決定的な違い

6.3 Columnar Engine — HTAP の鍵

Columnar Engine は、Primary や Reader のメモリ内に列指向フォーマットの「シャドウデータ」を保持し、同じテーブルに対して行指向 OLTP と列指向 OLAP を同時にサポートします。設定は対象テーブル/列を指定するだけで、リアルタイムに同期されます。

6.4 Cross-Region 災害復旧

Primary Cluster とは別リージョンに Secondary Cluster を作成し、非同期で継続的に複製します。災害時は Secondary を Promotion して新 Primary に切替。Cloud SQL の Cross-Region Read Replica と機能的には似ていますが、AlloyDB は「クラスタ全体」の単位で複製するため、複数 Read Pool も同時に DR されます。

6.5 試験での出題パターン（章6）

6.6 AlloyDB 事故ケース集

6.7 AlloyDB 運用・保守ベストプラクティス

7Spanner 完全解剖

Spanner は Google が F1（広告）の運用基盤として開発し、「グローバル分散・外部強整合性・水平スケール・ACID トランザクション」を全て満たす唯一の DB です。試験では「グローバル」「99.999%」「TrueTime」「分散トランザクション」「Sharding」がキーワード。

「Spanner offers transactional consistency at global scale ... uses TrueTime for external consistency ... Multi-region 99.999% availability.」 — Spanner concepts

7.1 内部アーキテクチャの本質

7.2 Instance Configuration（リージョナル vs マルチリージョン）

7.3 マルチリージョンの代表構成

7.4 ホットスポット回避（主キー設計）

Spanner で最も犯しやすく、最も致命的なミスが 「単調増加プライマリキー」です。タイムスタンプや auto_increment 風の整数を先頭に置くと、すべての書込が 同一 Split（最も末尾のシャード）に集中し、水平スケールできません。

CREATE TABLE events (
  created_at TIMESTAMP NOT NULL,
  event_id STRING(36) NOT NULL,
  ...
) PRIMARY KEY (created_at, event_id);
-- 最新行が全部同じ Split に集中

CREATE TABLE events (
  shard_id INT64 NOT NULL,  -- FARM_FINGERPRINT(user_id) % 100
  user_id STRING(36) NOT NULL,
  created_at TIMESTAMP NOT NULL,
  ...
) PRIMARY KEY (shard_id, user_id, created_at);

7.5 Interleaved Tables（親子テーブル局所性）

Spanner の特徴的な機能。「親テーブルの行と一緒に同じ Split に物理配置する子テーブル」を作れます。1:N 関係のクエリ（例: user とその orders）を 同一サーバの 1 リードで完結させ、JOIN 性能を最大化します。

CREATE TABLE users (
  user_id STRING(36) NOT NULL,
  name STRING(MAX),
  ...
) PRIMARY KEY (user_id);

-- users の子テーブルとして配置
CREATE TABLE orders (
  user_id STRING(36) NOT NULL,
  order_id STRING(36) NOT NULL,
  amount NUMERIC,
  ...
) PRIMARY KEY (user_id, order_id),
  INTERLEAVE IN PARENT users ON DELETE CASCADE;

7.6 PostgreSQL 互換ダイアレクト

Spanner は GoogleSQL（ANSI 2011 + 拡張）と PostgreSQL 互換ダイアレクトの 2 つを提供。既存 PG アプリの移行を容易化します。ただし PG ダイアレクトも完全互換ではなく、一部の PG 固有機能（pg_advisory_lock、CTAS など）は未サポート。

7.7 Spanner Editions（コンピュート割り当て）

7.8 試験での出題パターン（章7）

7.9 Spanner 事故ケース集

7.10 Spanner 運用・保守ベストプラクティス

8BigQuery 完全解剖

BigQuery は 「Storage と Compute が完全に分離されたサーバーレス DWH」です。内部では Capacitor（列指向ストレージ）、Dremel（分散クエリエンジン）、Colossus（Google ファイルシステム）、Jupiter（Petabit ネットワーク）が連動します。試験では「On-demand vs Editions」「Partitioning + Clustering」「フェデレーテッドクエリ」「BigQuery ML」「Omni」が頻出。

「BigQuery separates compute and storage layers connected via Google's petabit-scale network ... storage layer uses columnar format optimized for analytics.」 — BigQuery overview

8.1 BigQuery アーキテクチャ（SVG 図解）

8.2 ストレージの 3 階層

8.3 課金モデル — On-demand vs Editions

「BigQuery offers dual pricing: on-demand per-query charges or capacity-based reservations.」 — BigQuery Reservations

8.3.1 Editions の機能差分

8.3.2 Reservation の構造

• Capacity Commitment：1 年 / 3 年 コミットで割引購入（Flex Slots は廃止）
• Reservation：プロジェクトに割り当てるスロットの「箱」
• Baseline Slots：常時確保される最小スロット数
• Max Slots（Autoscaler）：需要に応じて自動拡張する上限
• Assignment：プロジェクト/フォルダ/組織を Reservation に紐付け

8.4 Partitioning + Clustering（コスト削減の双璧）

8.4.1 Partitioning の 3 方式

「Maximum 4,000 partitions per table. Limited to 10,000 partition modifications daily.」 — Partitioned tables

8.4.2 Clustering との組合せ

Partitioning が「パーティション単位の物理分割」を提供するのに対し、Clustering は「列の並べ替えによるブロック内ソート」を提供します。両者を組み合わせると以下の効果：

CREATE TABLE logs
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS SELECT * FROM source;

8.5 Materialized View と BI Engine

8.6 BigQuery Omni（マルチクラウドクエリ）

BigQuery Omni は、Amazon S3 / Azure Blob 上のデータを「データを GCP に動かさずに」BigQuery 構文でクエリできる機能です。AWS リージョン内に Anthos クラスタを Google が管理して BigQuery エンジンを動かす方式。

• S3 / Blob のデータをそのまま SQL でクエリ
• クロスクラウド転送：EXPORT DATA で結果を S3/Blob/GCS に出力可能
• マルチクラウド戦略・規制でデータ移動できないケースに有効

8.7 BigQuery ML（SQL で機械学習）

BigQuery ML は SQL だけで ML モデルを学習・推論できる機能。データを動かさずモデル化、Vertex AI との連携、生成 AI（Gemini）の呼出までサポート。

8.8 フェデレーテッドクエリ（外部 OLTP の直接 SQL）

BigQuery から Cloud SQL / Spanner / AlloyDB に直接クエリを発行できる機能。データを BigQuery にロードせず、リアルタイムの OLTP 値を分析に組み込めます。

-- Cloud SQL を BigQuery から直接クエリ
SELECT * FROM EXTERNAL_QUERY(
  "my-project.us.my-cloudsql-connection",
  "SELECT customer_id, total_amount FROM orders WHERE status = 'pending'"
);

8.9 試験での出題パターン（章8）

9BigQuery コスト最適化

BigQuery は安く使えば極めて安い一方、「SELECT * の事故」「予期しない再計算」「On-demand での暴走」で月数千ドル〜数万ドルの請求事故を生みます。本章ではコスト削減のテクニックを体系化します。

9.1 4 大ルール（暗記必須）

1. SELECT * は絶対禁止：必要な列だけを明示。BigQuery は列指向なので、列を絞れば線形にコスト削減。
2. 必ず Partition を切り、クエリで WHERE 句にパーティション列を含める：パーティションプルーニングで読込量を 1/100〜1/1000 に削減。
3. Cluster で高カーディナリティ列（user_id 等）を並べ替え：パーティション内ブロックも skip 可能に。
4. Dry Run で予測 → 月予算アラート設定：--dry_run で「このクエリは何 TB スキャンするか」を実行前に確認。

9.2 コストガード設定

# Dry Run でスキャン量を予測
bq query --use_legacy_sql=false --dry_run \
  'SELECT user_id, event_type FROM `myproject.logs.events`
   WHERE DATE(event_timestamp) = "2026-05-28"'

# 出力: This query will process 12.4 GB when run.

# 1 クエリの最大課金バイト数を制限
bq query --use_legacy_sql=false --maximum_bytes_billed=10000000000 \
  'SELECT ...'  # 10 GB を超えるクエリは実行前にエラー

9.3 Storage コスト削減

• 古いパーティションの自動削除：partition_expiration_days で N 日経過後に自動削除
• Long-term Storage の自動適用：90 日変更なしで自動 50% OFF
• Physical Storage Billing：圧縮率が良いテーブルは切替で 50-80% 削減
• External Tables の活用：頻度の低いデータは GCS にコールド保管し、必要時のみ External Table でクエリ

9.4 試験での出題パターン（章9）

9.X BigQuery 事故ケース集

9.Y BigQuery 運用・保守ベストプラクティス

# Maximum bytes billed をクエリ設定で強制
bq query --maximum_bytes_billed=1000000000 'SELECT ...'

# Custom Quota 例（コンソール/API）: QueryUsagePerDay = 10 TB

# Time Travel で 1 時間前の状態を参照
SELECT * FROM `project.dataset.table`
  FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR);

# Table Snapshot 作成
CREATE SNAPSHOT TABLE `project.dataset.events_snap_20260528`
  CLONE `project.dataset.events`
  OPTIONS(expiration_timestamp = TIMESTAMP '2026-12-31 00:00:00');

# 月別クエリコスト集計
SELECT user_email, SUM(total_bytes_billed)/POW(1024,4) AS tb_billed
FROM `region-asia-northeast1`.INFORMATION_SCHEMA.JOBS
WHERE creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY user_email ORDER BY tb_billed DESC;

10Bigtable 詳細 — 大規模ワイドカラム KV

Bigtable は Google の Search、Gmail、Maps、AdSense を支えてきた 「ペタバイトクラスの低レイテンシ KV ストア」です。HBase API 互換、行キー設計が性能の 9 割を決めます。試験では「行キー設計」「時系列の hot tablet」「Multi-cluster Routing」「SSD vs HDD」が頻出。

「Bigtable tables are sharded into blocks of contiguous rows, called tablets ... data is never stored in Bigtable nodes themselves; each node has pointers to a set of tablets.」 — Bigtable overview

10.1 アーキテクチャ（SVG 図解）

10.2 Row Key 設計 — 性能を 100 倍変える

「Design your row key based on the queries you will use ... Place high-cardinality values at the beginning to distribute data evenly.」 — Bigtable schema design

10.2.1 致命的なアンチパターン

2026-05-28-12-34-56-event001
2026-05-28-12-34-57-event002
2026-05-28-12-34-58-event003

3f2a#device-001#9999999999-event001
7b1c#device-002#9999999999-event002
a4d8#device-001#9999999998-event003

10.2.2 設計原則のまとめ

• Row Key は 4 KB 以下（推奨はもっと短く）
• delimiter（#）で複数フィールドを連結
• 先頭は 高カーディナリティ列（device_id, user_id 等）
• 順序スキャン（時系列）が必要なら Reverse Timestamp（Long.MAX_VALUE - ts）
• 頻繁に更新する単一行を避ける（同じ行への上書きは tablet 圧縮負荷）。代わりに新規行を時刻付きで作成
• Column Family は最大 100 個推奨、名前は短く

10.3 Multi-cluster Routing と Replication

Bigtable のインスタンスは 1 つのインスタンスに最大 8 個のクラスタ（リージョン横断含む）を持てます。「Multi-cluster Routing」を有効にすると、クライアントは最も近い健全なクラスタに自動接続し、フェイルオーバーが透過的に行われます。

10.4 SSD vs HDD ノード

10.5 Autoscaling

Bigtable は CPU 使用率と Storage 使用率を監視し、ノード数を自動 +/- する Autoscaling をサポート。最小・最大ノード数と「CPU 目標 %」を指定するだけ。

10.6 試験での出題パターン（章10）

10.7 Bigtable 事故ケース集

10.8 Bigtable 運用・保守ベストプラクティス

11Firestore — モバイル/Web リアルタイム DB

Firestore は 「ドキュメント指向 NoSQL ＋ モバイル SDK によるリアルタイム同期」を一体で提供する DB です。試験では「Native vs Datastore mode」「Composite Index」「整合性モデル」「Security Rules」「Multi-Database」が頻出。

11.1 Native mode vs Datastore mode

11.2 データモデル — Collection / Document / Subcollection

• Collection：ドキュメントのコンテナ。スキーマレス
• Document：JSON ライクなフィールドの集まり、最大 1 MB
• Subcollection：ドキュメントの下にネストする Collection、最大 100 階層
• Document ID：自動生成 or 指定。連番は hot spot の原因

11.3 Index — Single Field と Composite

Firestore はデフォルトで全フィールドに Single Field Indexを自動生成します。複数フィールドの組合せ（例: WHERE city = 'Tokyo' AND age >= 20 ORDER BY name）は Composite Index を明示的に作成する必要があります。Composite Index がない場合、Firestore コンソールにエラー + 作成リンクが表示されます。

11.4 制限（重要）

11.5 Multi-Database

2023 以降、同一プロジェクトに複数の Firestore Databaseを作成可能（最大 100）。本番 / ステージング / リージョン別を 1 プロジェクトに同居でき、IAM で個別制御可能。

11.6 Security Rules

Firestore はクライアント SDK から直接アクセスされるため、Security Rules でアクセス制御が必須。デフォルトでは allow read, write: if false;（全拒否）。本番に向けて Auth UID ベースのルールを徹底します。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    // ユーザー自身のドキュメントのみ書込可
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth.uid == userId;
    }
    // 公開投稿は誰でも読める
    match /posts/{postId} {
      allow read: if true;
      allow create: if request.auth != null
        && request.resource.data.authorId == request.auth.uid;
      allow update, delete: if request.auth.uid == resource.data.authorId;
    }
  }
}

11.7 Firestore 事故ケース集

11.8 Firestore 運用・保守ベストプラクティス

11.9 試験での出題パターン（章11）

12Memorystore — Redis / Valkey / Memcached

Memorystore は 「Google マネージドのインメモリ KV」です。3 つのエンジン（Redis、Valkey（Redis OSS のフォーク）、Memcached）から選び、Standard / Cluster / Cluster Enterprise の 3 ティアでスケール特性が変わります。試験では「Standard vs Cluster」「Persistence (AOF/RDB)」「Failover」が頻出。

12.1 エンジン選定

12.2 Tier 比較 — Standard vs Cluster

12.3 Persistence — AOF vs RDB

• AOF（Append-Only File）：全書込操作をログ化、再起動時にリプレイ。RPO ≈ 1 秒（fsync everysec の場合）。AOF rewrite 中にメモリ使用量が一時的に増える点に注意
• RDB（Snapshot）：定期的に完全スナップショット。RPO は数十分〜数時間。CPU/Disk 負荷が一時的にかかる
• Persistence 無効：純粋キャッシュ用途。再起動で全消滅

12.4 Memorystore 事故ケース集

12.5 Memorystore 運用・保守ベストプラクティス

12.6 試験での出題パターン（章12）

13Persistent Disk vs Hyperdisk

VM にアタッチするブロックストレージは、従来の Persistent Disk（PD） と新世代 Hyperdisk の 2 系統があります。Hyperdisk は「容量と IOPS と Throughput を独立してプロビジョン」できる点が革新的で、新規構築では Hyperdisk が第一候補です。試験では「タイプ選定」「Snapshot vs Image」「Regional PD」「Local SSD の揮発性」が頻出。

13.1 タイプ全体マップ

13.2 Hyperdisk のキー特徴

• 容量 / IOPS / Throughput を独立にプロビジョン（PD は容量に IOPS が連動）
• 動的に IOPS / Throughput を変更可能（停止不要、ライブ調整）
• 第 3 世代以降のマシン（C3, N4, X4, M3, Z3 等）でのみ利用可
• 同じスペックなら PD より高性能 + 低コスト になることが多い

13.3 Regional PD と Async Replication

Regional PD は 2 ゾーン間で同期レプリケーションされる PD。ゾーン障害時のフェイルオーバーが容易ですが、レイテンシ・コスト面で Zonal PD の約 2 倍。Hyperdisk はAsync Replication（非同期、別リージョンへ）を別途サポートします（DR 用）。

13.4 Snapshot のベストプラクティス

• Snapshot Schedule で日次/週次/月次の自動化
• 初回はフル、以降は差分のみ課金
• 別リージョン保管が可能（DR 用）
• Application-consistent Snapshot は OS との連携（pre/post script）が必要
• VM 削除前に Snapshot を必ず取得（PD は VM と独立だが、削除フラグで道連れになる設定がある）

13.5 PD/Hyperdisk 事故ケース集

13.6 PD/Hyperdisk 運用・保守ベストプラクティス

13.7 試験での出題パターン（章13）

14Filestore — マネージド NFS

Filestore は 「マネージド NFS」で、Compute Engine / GKE / Dataproc / VMware Engine から POSIX 互換でマウントできます。試験では「Tier 選定」「Backup」「NFS v3 vs v4.1」が中心。

14.1 Tier 比較

14.2 NFS バージョン

全 Tier で NFS v3 サポート。Enterprise tier のみ NFS v4.1 もサポート（ファイルロックなど一部用途で必要）。

14.3 Filestore 事故ケース集

14.4 Filestore 運用・保守

• Backup Schedule：日次自動バックアップ、別リージョン保管可
• Snapshot：Enterprise / Regional / Zonal tier で利用可、PITR 用（同一インスタンス内）
• モニタリング：filestore.googleapis.com/nfs/server/used_bytes_percent で容量、operations_count でスループット

14.5 試験での出題パターン（章14）

15データ移行ツール

移行ツールの選定は試験でも頻出です。「何を、どこから、どこへ、どれくらいの規模で」の 4 軸で決まります。

15.1 主要ツール対応表

15.2 オブジェクト移行の決定ロジック

15.3 DB 移行の決定ロジック

• MySQL → Cloud SQL：DMS（同種、ダウンタイム最小）
• Oracle → PostgreSQL/AlloyDB：DMS（異種、スキーマ変換あり）
• Oracle/PG → BigQuery（分析）：Datastream（CDC、サーバーレス）
• Teradata/Redshift/Snowflake → BigQuery：BigQuery Migration Service
• カスタム変換が必要：Dataflow（streaming or batch）

16運用・保守 全体ベストプラクティス

本章はストレージ＆DB 全サービス横断の運用視点をまとめた章です。本番設計レビューのチェックリストとして使えます。

16.1 バックアップ戦略マトリクス（全サービス横断）

16.2 災害復旧（DR）シナリオ別 RTO/RPO

16.3 モニタリング指標まとめ

16.4 キャパシティ計画の原則

• Cloud SQL / AlloyDB：Disk Auto-resize で容量、CPU は事前にスケールアップ計画。Replication Lag のトレンドで Read Replica 追加判断
• Spanner：CPU 65% を維持するように Autoscaling、ノード当り 4 TB Storage 上限
• BigQuery：Reservation の Baseline + Max を月次見直し、Slot 不足はオンデマンドにフォールバック設定
• Bigtable：CPU 目標 70%、Storage は SSD 2.5 TB / HDD 8 TB per node
• Memorystore：メモリ 80% で警告、AOF rewrite buffer のため 50% 空けるのが理想
• PD/Hyperdisk：Hyperdisk は IOPS/Throughput をライブで動的変更可能（Hyperdisk なら計画ミスもリカバリ容易）

16.5 パッチ管理

• Cloud SQL：Maintenance Window（曜日 + 時間）を業務時間外に設定。Deny Maintenance Period で最大 90 日延期可（セール期間など保護）。メジャー版アップグレードは事前テスト必須
• AlloyDB：Maintenance Window 設定、Primary とは別タイミングで Secondary をアップグレード
• Spanner / BigQuery / Bigtable / Firestore：完全マネージド、パッチは透過的（影響を意識する必要なし）
• GCE（PD アタッチ VM）：OS Config Patch Management で自動パッチ。Maintenance Policy で live migration / restart 制御
• Memorystore：Maintenance Window 設定、Persistence 有効化で再起動耐性確保

16.6 コスト監視

• Budget Alert：Project / Folder / Label 単位、閾値超過で Pub/Sub → Slack 通知
• Quotas：Project の API Quota（特に BigQuery）を絞る
• BigQuery Custom Quotas：ユーザー / プロジェクトの QueryUsagePerDay を制限
• Recommender：Idle PD、未使用 IP、過剰 Cloud SQL を自動検出
• Pricing Calculator：設計時に必ず月額試算

17試験頻出パターン — ケーススタディ別の推奨構成

PCA 試験では「ケース」が与えられ、最適なストレージ構成を 1 つ選ぶ問題が頻出です。以下にパターン別の正解構成を整理します。

17.1 ケーススタディ別 推奨構成

17.2 試験のキーワード反射表

18アンチパターン総集編

サービス横断で「やってはいけない設計」を一覧化します。本番リリース前のレビューチェックリストとして使えます。

18.1 GCS アンチパターン

18.2 Cloud SQL アンチパターン

18.3 Spanner アンチパターン

18.4 BigQuery アンチパターン

18.5 Bigtable アンチパターン

18.6 Firestore アンチパターン

18.7 Memorystore アンチパターン

18.8 PD/Hyperdisk アンチパターン

19クォータと制限の一覧（早見表）

19.1 GCS

19.2 Cloud SQL

19.3 AlloyDB

19.4 Spanner

19.5 BigQuery

19.6 Bigtable

19.7 Firestore

19.8 Memorystore

19.9 PD / Hyperdisk

19.10 Filestore

次のステップ