リレーショナルデータベース — Cloud SQL・AlloyDB・Spanner

RDB 3 兄弟の全体像 — どれを選ぶか

前章のオブジェクトストレージが「ファイルの置き場」だったのに対し、本章はトランザクションを伴う構造化データ、つまりリレーショナルデータベースを扱います。Google Cloud のマネージド RDB は 3 つあります。Cloud SQL は MySQL・PostgreSQL・SQL Server をそのまま動かす定番のマネージド RDB、AlloyDB for PostgreSQL は PostgreSQL 互換のまま性能を引き上げた Google 独自エンジンの上位版、Spanner は書き込みまで水平スケールするグローバル分散 RDB です。まず選択の順序を頭に入れましょう。

Cloud SQL — 定番のマネージド RDB

Cloud SQL は MySQL・PostgreSQL・SQL Server の 3 エンジンに対応するフルマネージドのリレーショナルデータベースです。実体としては、各インスタンスが Google 管理の VM + 永続ディスク + 静的 IP アドレスで構成され（第 4 章の部品と同じ土台です）、バックアップ・HA とフェイルオーバー・メンテナンスとパッチ適用・モニタリングを Google 側が引き受けます。利用者は SQL とスキーマ設計に集中できる、というのがマネージド DB の価値です。オンプレからの移行では Database Migration Service が使えます（第 17 章）。

2 つのエディション

Cloud SQL には Enterprise と Enterprise Plus の 2 エディションがあり、SLA・メンテナンスの影響・性能機能が異なります（2026-08 時点）。

学習用途やスモールスタートは Enterprise の共有コアマシン（db-f1-micro など）で十分です。試験では「メンテナンスの停止も許されない」「読み取り性能を強化したい」という文言が Enterprise Plus を指すシグナルになります。

高可用性（HA）構成 — リージョナルインスタンス

Cloud SQL の HA 構成はリージョナルインスタンスとも呼ばれ、同一リージョン内の異なるゾーンにプライマリとスタンバイの 2 台を配置します。書き込みは、トランザクションのコミットが応答される前に両ゾーンの永続ディスクへ同期複製されるため、フェイルオーバーでコミット済みデータは失われません。プライマリの死活は毎秒のハートビートで監視され、応答が複数回途絶えるとスタンバイへの自動フェイルオーバーが始まります。切り替え中は 60 秒程度利用できなくなります（2026-08 時点のドキュメント記載値。環境により変動）。

設計上の注意は 2 つです。第一に、スタンバイは読み取りクエリを処理しません。純粋な待機系です。第二に、HA 構成の料金は CPU・RAM・ストレージが 2 台分になるため単体構成の 2 倍です。「可用性のための HA」と「読み取りスケールのためのリードレプリカ」は目的が別物です。

リードレプリカ — 読み取りスケールとクロスリージョン DR

リードレプリカはプライマリのデータを非同期で複製する読み取り専用のコピーです。レポート集計や参照系トラフィックをオフロードしてプライマリの負荷を下げるのが本来の用途で、別リージョンに置くクロスリージョンレプリカにすればリージョン障害への備え（DR）や低レイテンシの読み取り拠点にもなります。レプリカの下にさらにレプリカをぶら下げるカスケードレプリカはプライマリを含めて最大 4 階層まで構成でき、プライマリ直下のレプリカ数は 10 以下が推奨です（2026-08 時点）。

重要な違いとして、リードレプリカにはフェイルオーバー機能がありません。プライマリが失われたときは、レプリカを独立したインスタンスへ手動で昇格（プロモート）します。昇格したレプリカは書き込み可能な単体インスタンスになり、配下のカスケードレプリカは階層ごと引き継がれます。

バックアップとポイントインタイムリカバリ

Cloud SQL のバックアップは初回を除いて増分バックアップで、自動バックアップ（スケジュール実行）とオンデマンドバックアップ（任意のタイミングで作成、明示的に削除するまで保持）の 2 種類があります。さらにポイントインタイムリカバリ（PITR）を有効にすると、バックアップ時点だけでなく「昨日 14:32 の状態」のような任意の時点へ復元できます。仕組みは、自動バックアップを土台に、そこからのトランザクションログ（MySQL ではバイナリログ）を連続適用するものです。したがって PITR には自動バックアップとバイナリログの両方が有効であることが前提で、復元は常に新しいインスタンスとして行われます。既存インスタンスをその場で巻き戻すことはできません。

接続方法 — Auth Proxy とプライベート IP

データベースは作って終わりではなく、「どこから・どう安全につなぐか」が設計問題です。Cloud SQL の接続は次の 3 パターンを押さえます。

公式ドキュメントの推奨は、セキュリティ観点でプライベート IP、認証観点でIAM データベース認証です。パブリック IP を使うなら Auth Proxy などのコネクタを挟み、承認済みネットワークを広く開けることは避けます。

AlloyDB for PostgreSQL — PostgreSQL 互換の高性能版

AlloyDB for PostgreSQL は、PostgreSQL 完全互換のインターフェースに Google 製データベースエンジンとクラウドネイティブな分散アーキテクチャを組み合わせたフルマネージド DB です。Cloud SQL for PostgreSQL と同じアプリケーションコード・ドライバがそのまま動きつつ、より高い性能と可用性を狙うワークロードの受け皿になります。

• コンピュートとストレージの分離: 計算層とストレージ層が独立してスケールする分散構成（disaggregated architecture）です。リソースは「クラスタ」を頂点に、読み書きを担うプライマリインスタンス（クラスタに 1 つ、HA 構成可）と、読み取り専用のリードプールインスタンス（複数追加可）で構成されます
• 性能（Google 公表値、2026-08 時点）: トランザクション処理で標準 PostgreSQL の 4 倍超、内蔵のカラム型エンジンにより分析クエリで標準 PostgreSQL の最大 100 倍。OLTP と分析を 1 つの DB でこなす HTAP（Hybrid Transactional and Analytical Processing）が設計思想です
• 可用性: 99.99% の稼働率 SLA をメンテナンス込みで提供します（2026-08 時点）
• AlloyDB Omni: ダウンロード版の AlloyDB で、オンプレミスや他クラウドなど自前の Linux 環境でも同じエンジンを動かせます

位置づけとしては「Cloud SQL for PostgreSQL では性能が足りない、しかし Spanner ほどの水平スケールとグローバル分散は要らない」という中間帯を埋めるプロダクトです。MySQL や SQL Server の互換性が要る場合は選択肢に入りません。

Spanner — 水平スケールとグローバル整合

外部整合性と自動シャーディング

Spanner は、リレーショナルの整合性と NoSQL 級の水平スケールを両立させた Google 独自の分散データベースです。リレーショナルに加えてグラフ・キー値・検索のモデルを 1 つのサービスに統合しており、SQL インターフェースは GoogleSQL と PostgreSQL 互換の 2 方言から選べます。

最大の特徴が外部整合性（external consistency）です。これは「分散トランザクションであっても、全世界のどこから見てもコミットの順序が実際の時刻順と一致する」という、単一マシンの直列化可能性をグローバル規模に広げた最強クラスの整合性保証です。全 Google サーバーに提供される高可用の分散クロック TrueTime がこれを支えています。またデータはスプリットという単位に自動分割（自動シャーディング）され、スプリットはサーバー間を独立に移動して負荷を分散します。コンピュート容量は稼働中のインスタンスに対して後から増減できます。

インスタンス構成と SLA

Spanner のインスタンスは、レプリカをどこへ配置するかを決めるインスタンス構成を選んで作成します（2026-08 時点。エディションは Standard / Enterprise / Enterprise Plus の 3 つで、デュアルリージョン以上は Enterprise Plus が必要です）。

• リージョナル構成（例: regional-asia-northeast1）: 1 リージョン内の 3 ゾーンに read-write レプリカを 1 つずつ配置。SLA 99.99%
• デュアルリージョン構成: 同一国内の 2 リージョン間でレプリケーション（日本を含む一部の国で提供）。SLA 99.999%
• マルチリージョン構成（例: 東京を read-write リージョンに含む asia1）: 2 つの read-write リージョン（各 2 レプリカ）+ witness リージョンで構成。SLA 99.999%。読み取り専用レプリカを追加してさらに読み取り拠点を広げられる

コンピュート容量（processing units）と無料トライアル

Spanner の性能はコンピュート容量で決まり、単位は processing units（PU）またはノードです。1,000 PU = 1 ノードで、100 PU 単位で指定できるため、1 ノード未満の小さなインスタンスから始められます。ストレージは 100 PU あたり 1,024 GiB、1 ノードあたり 10 TiB まで使えます（2026-08 時点）。課金は「使ったクエリ数」ではなくプロビジョニングした容量 × 時間で、レプリカ数分のノード時間に対して発生し、最低 1 時間分から按分されます。CPU 使用率などに応じて容量を自動調整するマネージドオートスケーラーも利用できます。

学習用には無料トライアルインスタンスが用意されています。90 日間・データ 10 GB・最大 5 データベースまで使えますが、SLA の適用外で、バックアップや CMEK は使えません。有効な請求先アカウントが必要で、作成できるのはプロジェクトのライフサイクルにつき 1 つ、請求先アカウントにつき最大 5 つです。期限が来る前に、ダウンタイムなしで有料インスタンスへアップグレードできます（2026-08 時点）。

gcloud services enable sqladmin.googleapis.com

gcloud sql instances create handson-mysql \
  --database-version=MYSQL_8_0 \
  --tier=db-f1-micro \
  --region=asia-northeast1 \
  --root-password=ROOT_PASSWORD

gcloud sql instances list

NAME           DATABASE_VERSION  LOCATION           TIER         STATUS
handson-mysql  MYSQL_8_0         asia-northeast1-b  db-f1-micro  RUNNABLE

gcloud sql connect handson-mysql --user=root

CREATE DATABASE handson;
USE handson;
CREATE TABLE books (id INT PRIMARY KEY, title VARCHAR(100));
INSERT INTO books VALUES (1, 'Cloud SQL 入門'), (2, 'PCA 合格ガイド');
SELECT * FROM books;
EXIT;

gcloud sql instances delete handson-mysql --quiet
gcloud sql instances list

gcloud services enable spanner.googleapis.com
gcloud spanner instances create handson-spanner \
  --config=regional-asia-northeast1 \
  --description="PCA handson" \
  --processing-units=100 \
  --edition=STANDARD

gcloud spanner databases create handson-db \
  --instance=handson-spanner

gcloud spanner databases ddl update handson-db \
  --instance=handson-spanner \
  --ddl='CREATE TABLE Players (PlayerId INT64 NOT NULL, Name STRING(100)) PRIMARY KEY (PlayerId)'

gcloud spanner databases execute-sql handson-db \
  --instance=handson-spanner \
  --sql="INSERT INTO Players (PlayerId, Name) VALUES (1, 'Sato'), (2, 'Suzuki')"
gcloud spanner databases execute-sql handson-db \
  --instance=handson-spanner \
  --sql='SELECT PlayerId, Name FROM Players ORDER BY PlayerId'

PlayerId  Name
1         Sato
2         Suzuki

gcloud spanner instances delete handson-spanner --quiet
gcloud spanner instances list

つまずきポイント

理解度チェック

まとめと次章へ

• 選択の軸は「互換性・スケール・可用性」。既存 RDB の移行は Cloud SQL、PostgreSQL のまま高性能 / HTAP なら AlloyDB、水平スケールと 99.999% なら Spanner
• Cloud SQL の HA 構成はゾーンをまたぐ同期複製 + 自動フェイルオーバー（スタンバイは読めない・料金 2 倍）。読み取りスケールと DR は非同期のリードレプリカで担う
• PITR は自動バックアップ + バイナリログが前提で、復元先は常に新インスタンス
• 接続はプライベート IP と IAM 認証が推奨。パブリック IP なら Auth Proxy / コネクタを挟む
• Spanner は TrueTime による外部整合性と自動シャーディングが核。リージョナル 99.99% / マルチリージョン 99.999%、容量は 100 PU 単位のプロビジョニング課金（最低 1 時間）

リレーショナルで持つ必然性がないデータ — 柔軟なスキーマのドキュメント、超大量の時系列、キャッシュ — には、それぞれ専用のデータベースがあります。次の第 10 章では Firestore・Bigtable・Memorystore を取り上げ、ストレージプロダクト全体の選択マップを完成させます。

• Cloud SQL overview（公式ドキュメント）
• Cloud SQL: About high availability（公式ドキュメント）
• Cloud SQL: About replication（公式ドキュメント）
• AlloyDB for PostgreSQL overview（公式ドキュメント）
• Spanner documentation（公式ドキュメント）
• Spanner: Instance configurations（公式ドキュメント）