Cloud SQL

解決する課題

物理サーバーや自前のDBチューニング・運用を抱えずに、定番のリレーショナルDBをすぐ使い始められます。

• DBサーバーのOSパッチ・バックアップ・監視が重い → 自動化したい
• 障害でDBが止まると困る → 高可用性(HA)構成の自動フェイルオーバーで可用性を上げたい
• 読み取りが増えてきた → リードレプリカで読み取りをスケールしたい
• 急成長で書き込みも水平分割したい → MySQL/PostgreSQL 互換のまま Cloud SQL から AlloyDB / Spanner への移行も検討できる

主要概念と用語

• インスタンス: 稼働しているDB本体。エディションは Enterprise と Enterprise Plus（高性能・キャッシュ・短いフェイルオーバー時間）の2つ
• 高可用性(HA)構成: 別ゾーンに同期スタンバイを持ち、リージョナル永続ディスクで複製。プライマリ障害時に同一リージョン内で自動フェイルオーバー（可用性）
• リードレプリカ: 非同期の読み取り専用コピー。読み取りスケール用。クロスリージョン・カスケードも可能
• 自動バックアップ / オンデマンドバックアップ: バックアップ＋バイナリログ/WAL による ポイントインタイムリカバリ(PITR)
• 接続方式: Cloud SQL Auth Proxy / Cloud SQL Language Connector（IAM 認証・TLS を自動処理）、プライベートIP（VPC ピアリング）、パブリックIP（承認済みネットワーク）
• メンテナンスウィンドウ: パッチ適用の時間帯を指定

仕様・制限・クォータ

• 提供エンジンは MySQL / PostgreSQL / SQL Server の3種類（Aurora のような独自エンジンや MariaDB/Oracle は対象外）
• 自動バックアップの保持は既定で複数世代、PITR はトランザクションログ保持期間内に任意時点へ復元
• ストレージは 自動拡張（一度拡張すると縮小はできない点に注意）
• インスタンスはリージョン内のゾーンに配置。HA はゾーン障害に耐えるがリージョン障害には別途クロスリージョンレプリカが必要
• 1プライマリあたり作成できるリードレプリカ数や接続数の上限あり。CPU/メモリはマシンタイプで決まり、引き上げはマシンタイプ変更で対応
• シャーディングは非対応（単一の縦スケール＋レプリカが基本。水平分割が必要なら AlloyDB / Spanner を検討）

内部の仕組み

• HA構成: プライマリの書き込みを別ゾーンのスタンバイへ同期複製（リージョナル永続ディスクで両ゾーンに同時書き込み）。プライマリやゾーン障害時はスタンバイへ自動フェイルオーバーし、接続先IP/名前は変わらないため接続文字列の変更は不要。Enterprise Plus は近接キャッシュ等によりフェイルオーバーが高速
• リードレプリカ: 非同期複製のためレプリケーション遅延がある。書き込みは伝播せず、読み取りクエリの分散に使う
• PITR: フルバックアップ＋継続的なバイナリログ(MySQL)/WAL(PostgreSQL)/トランザクションログ(SQL Server) を保持し、指定時刻の状態を新インスタンスとして復元

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

• 本番は HA構成（リージョナル） を有効化し、ゾーン障害に備える
• 読み取り負荷は リードレプリカ で分散。アプリ側で書き込み(プライマリ)と読み取り(レプリカ)のエンドポイントを分ける
• DBは プライベートIP（VPC内） で構成し、インターネットへ公開しない
• アプリからの接続は Cloud SQL Auth Proxy / Language Connector を使い、IAM 認証と TLS を委譲する（証明書やIP許可の手運用を減らす）
• リージョン障害対策が要件なら クロスリージョンのリードレプリカ を用意し、DR時に昇格(promote)する

運用・監視

• Cloud Monitoring / Cloud Logging でCPU・メモリ・ディスク・接続数・レプリケーション遅延を可視化
• Query Insights でスロークエリや高負荷クエリを特定し、インデックス・クエリを見直す
• 接続不可時は VPC / ファイアウォール / 承認済みネットワーク / Auth Proxy のIAM権限（Cloud SQL Client ロール） を確認
• メンテナンスはメンテナンスウィンドウとメンテナンス拒否期間でタイミングを制御

コスト

課金は vCPU・メモリ（マシンタイプ）＋ストレージ＋ネットワーク＋バックアップ の積み上げです。割引オプションの使い分けがコスト最適化の肝になります。

停止してもストレージとIPの料金は発生し続ける点、HAやリードレプリカは台数ぶんコンピューティング課金が増える点に注意します。

セキュリティ

• 保存時暗号化はデフォルトで有効。要件に応じて CMEK（Cloud KMS の顧客管理鍵） を指定できる
• 転送時は TLS/SSL を強制可能。接続は プライベートIP＋Cloud SQL Auth Proxy が安全
• 認証は IAM データベース認証 を使い、DBユーザー/パスワードのハードコードや手配布を避ける
• ネットワークは プライベートIP配置 を基本にし、パブリックIPを使う場合も承認済みネットワークを最小化

関連サービス・比較（AWS との対応）

ハンズオン / CLI例

# HA構成（リージョナル）の PostgreSQL インスタンスを作成
gcloud sql instances create app-db \
  --database-version=POSTGRES_16 \
  --edition=enterprise \
  --tier=db-custom-2-7680 \
  --region=asia-northeast1 \
  --availability-type=REGIONAL \
  --storage-auto-increase \
  --backup-start-time=18:00 \
  --enable-point-in-time-recovery

# アプリ用ユーザーを作成
gcloud sql users create appuser \
  --instance=app-db \
  --password='CHANGE_ME_USE_SECRET_MANAGER'

# リードレプリカを追加して読み取りを分散
gcloud sql instances create app-db-replica \
  --master-instance-name=app-db \
  --region=asia-northeast1

# Cloud SQL Auth Proxy 経由でローカルから安全に接続（IAM/TLS は Proxy が処理）
cloud-sql-proxy --port 5432 PROJECT_ID:asia-northeast1:app-db