Harmonic Society
オンライン予約 お問い合わせ
プログラミング

Google Cloud SQLの導入ガイド｜マネージドDBの構築・運用・バックアップ実践

kento_morota 15分で読めます

「自社サーバーで運用しているデータベースの管理コストが高い」「バックアップやアップデートの手間を削減したい」「障害時の対応が心配で夜も眠れない」――データベース運用の負担を感じているIT担当者やエンジニアは多いのではないでしょうか。

Google Cloud SQLは、MySQL、PostgreSQL、SQL Serverに対応したフルマネージドのリレーショナルデータベースサービスです。パッチ適用、バックアップ、レプリケーション、フェイルオーバーといった運用タスクをGoogleに任せられるため、アプリケーション開発に集中できます。

この記事では、Cloud SQLのインスタンス構築から日常的な運用、バックアップ戦略、パフォーマンスチューニングまで、現場で即実践できる知識を解説します。

Cloud SQLの基本概念と対応データベースエンジン

Cloud SQLは、GCPが提供するマネージドRDBサービスで、以下の3つのデータベースエンジンに対応しています。

対応データベースエンジン

MySQL
世界で最も広く使われているオープンソースRDB。WordPress、Laravel、Ruby on Railsなど多くのWebフレームワークで標準的に使用されます。Cloud SQLではMySQL 8.0/8.4をサポートしています。

PostgreSQL
高度な機能と標準SQL準拠で知られるオープンソースRDB。地理空間データ（PostGIS）やJSON型のネイティブサポートが強力です。Cloud SQLではPostgreSQL 14〜16をサポートしています。

SQL Server
Microsoft製のRDB。.NETアプリケーションとの親和性が高く、エンタープライズ環境で広く使われています。Cloud SQLではSQL Server 2019/2022をサポートしています。

Cloud SQLとセルフマネージドDBの比較

Cloud SQLを使うメリットを、自前でサーバーにデータベースをインストールする場合と比較します。

  • 自動バックアップ：毎日の自動バックアップとポイントインタイムリカバリが標準装備
  • 自動パッチ適用：セキュリティパッチが自動的に適用されます
  • 高可用性：リージョン内フェイルオーバーが設定可能（ダウンタイム数十秒）
  • スケーリング：CPUやメモリ、ストレージの拡張がコンソールからワンクリック
  • 暗号化：保存データとネットワーク通信が自動的に暗号化されます

大規模なデータ分析が必要な場合は、Cloud SQLとは異なるアプローチとしてBigQueryも検討してください。

Cloud SQLインスタンスの構築手順

実際にCloud SQLインスタンスを構築する手順を、gcloudコマンドとコンソールの両方で解説します。

gcloudコマンドによるインスタンス作成

# PostgreSQLインスタンスの作成
gcloud sql instances create my-db \
  --database-version POSTGRES_16 \
  --tier db-custom-2-8192 \
  --region asia-northeast1 \
  --availability-type regional \
  --storage-type SSD \
  --storage-size 50GB \
  --storage-auto-increase \
  --backup-start-time 02:00 \
  --enable-point-in-time-recovery \
  --maintenance-window-day SUN \
  --maintenance-window-hour 3

# データベースの作成
gcloud sql databases create myapp_production --instance=my-db

# ユーザーの作成
gcloud sql users create app_user \
  --instance=my-db \
  --password="secure-password-here"

各パラメータの解説

--tier（マシンタイプ）
インスタンスのCPUとメモリを指定します。db-custom-[CPU]-[メモリMB]の形式です。開発環境ではdb-f1-micro（共有vCPU・614MB）から始めて、本番環境に合わせてスケールアップしましょう。

--availability-type
zonalは単一ゾーン配置（低コスト）、regionalはゾーン間フェイルオーバー対応（高可用性）です。本番環境ではregionalを推奨します。

--storage-auto-increase
ストレージ使用量がしきい値に達したとき、自動的に容量を増やします。予期しないディスクフル障害を防げます。

--maintenance-window
メンテナンス（パッチ適用など）が実行される時間帯を指定します。業務に影響の少ない深夜帯を設定しましょう。

本番環境向けの推奨構成

本番環境で使用する場合の推奨構成例です。

データベースエンジン: PostgreSQL 16
マシンタイプ: db-custom-4-16384（4vCPU / 16GB RAM）
ストレージ: SSD 100GB（自動増加あり）
可用性: リージョナル（高可用性）
バックアップ: 自動バックアップ + PITR
リージョン: asia-northeast1（東京）

接続方法の設計と実装

Cloud SQLへの安全な接続方法を用途別に解説します。

Cloud SQL Auth Proxy（推奨）

最も安全で推奨される接続方法です。IAM認証によるアクセス制御が可能で、SSL証明書の手動管理が不要です。

# Cloud SQL Auth Proxyのダウンロードと起動
curl -o cloud-sql-proxy https://storage.googleapis.com/cloud-sql-connectors/cloud-sql-proxy/v2.8.0/cloud-sql-proxy.linux.amd64
chmod +x cloud-sql-proxy

# プロキシの起動
./cloud-sql-proxy PROJECT_ID:asia-northeast1:my-db \
  --port 5432

アプリケーションからはlocalhost:5432に接続するだけでCloud SQLにアクセスできます。

Cloud Runからの接続

Cloud RunからCloud SQLに接続する場合、組み込みのCloud SQL接続機能を使います。

# Cloud RunのデプロイでCloud SQL接続を設定
gcloud run deploy my-app \
  --add-cloudsql-instances PROJECT_ID:asia-northeast1:my-db \
  --set-env-vars "DB_USER=app_user,DB_NAME=myapp_production" \
  --set-secrets "DB_PASSWORD=db-password:latest" \
  --region asia-northeast1

# Pythonでの接続例（Unix domain socket経由）
import sqlalchemy

def connect():
    db_user = os.environ["DB_USER"]
    db_pass = os.environ["DB_PASSWORD"]
    db_name = os.environ["DB_NAME"]
    instance_connection = "PROJECT_ID:asia-northeast1:my-db"

    pool = sqlalchemy.create_engine(
        sqlalchemy.engine.url.URL.create(
            drivername="postgresql+pg8000",
            username=db_user,
            password=db_pass,
            database=db_name,
            query={"unix_sock": f"/cloudsql/{instance_connection}/.s.PGSQL.5432"}
        ),
        pool_size=5,
        max_overflow=2,
        pool_timeout=30,
        pool_recycle=1800,
    )
    return pool

プライベートIP接続

VPC内のリソースからCloud SQLに接続する場合は、プライベートIPを使います。インターネットを経由しないため、セキュリティとパフォーマンスの両面で有利です。

# プライベートIPを有効化
gcloud sql instances patch my-db \
  --network projects/PROJECT_ID/global/networks/my-vpc \
  --no-assign-ip

バックアップ戦略とディザスタリカバリ

データベースのバックアップは、事業継続の生命線です。Cloud SQLでは複数のバックアップ手段が用意されています。

自動バックアップの設定

Cloud SQLの自動バックアップは、毎日指定した時間帯に自動実行されます。

# 自動バックアップの有効化（UTC 02:00に実行）
gcloud sql instances patch my-db \
  --backup-start-time 02:00 \
  --retained-backups-count 30 \
  --enable-point-in-time-recovery

ポイントインタイムリカバリ（PITR）は、トランザクションログを使って任意の時点にデータベースを復元する機能です。「今朝10時の状態に戻したい」といった柔軟なリストアが可能になります。

オンデマンドバックアップ

重要な変更作業の前後には、オンデマンドでバックアップを取得しましょう。

# オンデマンドバックアップの作成
gcloud sql backups create --instance=my-db \
  --description="Before schema migration 2026-03-22"

# バックアップ一覧の確認
gcloud sql backups list --instance=my-db

# バックアップからの復元（新しいインスタンスに復元）
gcloud sql instances restore-backup my-db-restored \
  --backup-instance=my-db \
  --backup-id=BACKUP_ID

クロスリージョンバックアップ

災害対策として、バックアップを別リージョンに保存する設定が可能です。

# クロスリージョンバックアップの有効化
gcloud sql instances patch my-db \
  --backup-location asia-northeast2

これにより、東京リージョン全体の障害が発生しても、大阪リージョンのバックアップから復旧できます。

パフォーマンスチューニングの実践

Cloud SQLのパフォーマンスを最大限引き出すための設定とモニタリングについて解説します。

データベースフラグの最適化

Cloud SQLでは、データベースエンジン固有の設定パラメータ（フラグ）をカスタマイズできます。

# PostgreSQLのパフォーマンス関連フラグを設定
gcloud sql instances patch my-db \
  --database-flags \
    max_connections=200,\
    shared_buffers=4096MB,\
    effective_cache_size=12288MB,\
    work_mem=64MB,\
    maintenance_work_mem=512MB,\
    random_page_cost=1.1

主要なパラメータの目安は以下の通りです。

  • shared_buffers：メモリの25%程度を割り当て
  • effective_cache_size：メモリの75%程度を設定
  • work_mem：ソートや結合操作で使用するメモリ。大きすぎると接続数 x work_memの消費になるので注意
  • max_connections：アプリケーションの同時接続数に余裕を持たせて設定

クエリパフォーマンスの分析

Cloud SQLのQuery Insightsを有効にすると、遅いクエリの特定と分析ができます。

# Query Insightsの有効化
gcloud sql instances patch my-db \
  --insights-config-query-insights-enabled \
  --insights-config-query-string-length=4096 \
  --insights-config-record-application-tags \
  --insights-config-record-client-address

Query Insightsが有効になると、GCPコンソールのCloud SQLページから以下の情報を確認できます。

  • 実行時間の長いクエリのランキング
  • クエリの実行計画（EXPLAIN ANALYZE相当）
  • CPU使用率とクエリの相関
  • 待機イベントの分析

読み取りレプリカの活用

読み取りが多いワークロードでは、リードレプリカを使って負荷を分散できます。

# リードレプリカの作成
gcloud sql instances create my-db-replica \
  --master-instance-name=my-db \
  --tier=db-custom-2-8192 \
  --region=asia-northeast1

アプリケーション側で書き込みはプライマリに、読み取りはレプリカに振り分けるように実装します。

セキュリティ設定とアクセス制御

データベースのセキュリティは、情報漏洩防止の最重要項目です。GCP IAMとセキュリティ設計の原則に基づいて、Cloud SQL固有のセキュリティを設定します。

ネットワークアクセスの制限

# 特定のIPアドレスからの接続のみ許可
gcloud sql instances patch my-db \
  --authorized-networks="203.0.113.10/32,203.0.113.20/32"

# パブリックIPを無効化（プライベートIPのみ）
gcloud sql instances patch my-db \
  --no-assign-ip

本番環境では、パブリックIPを無効化してプライベートIP接続のみに限定することを強く推奨します。

IAMデータベース認証

PostgreSQLインスタンスでは、IAMを使ったデータベース認証が可能です。パスワード管理が不要になり、セキュリティが向上します。

# IAMデータベース認証を有効化
gcloud sql instances patch my-db \
  --database-flags cloudsql.iam_authentication=on

# IAMユーザーの追加
gcloud sql users create user@example.com \
  --instance=my-db \
  --type=CLOUD_IAM_USER

データの暗号化

Cloud SQLのデータは、保存時（at rest）と転送中（in transit）の両方で自動的に暗号化されます。顧客管理の暗号化キー（CMEK）を使うことで、より厳格なセキュリティ要件にも対応可能です。

まとめ：Cloud SQLで実現する安心のデータベース運用

Cloud SQLは、データベースの運用負担を大幅に軽減する強力なマネージドサービスです。本記事で解説したポイントを振り返ります。

  • 構築：用途に応じたエンジン（MySQL/PostgreSQL/SQL Server）の選択と適切なインスタンスサイズ
  • 接続：Cloud SQL Auth Proxyを使った安全な接続と、Cloud Runとの統合
  • バックアップ：自動バックアップ、ポイントインタイムリカバリ、クロスリージョンバックアップの3層構成
  • パフォーマンス：データベースフラグの最適化、Query Insights、リードレプリカの活用
  • セキュリティ：プライベートIP接続、IAM認証、暗号化の徹底

まずは開発環境用の小さなインスタンスで試用を始め、アプリケーションの要件に合わせて段階的にスケールアップしていくのがおすすめです。インフラ管理をコードで自動化したい場合は、TerraformによるIaC入門もあわせて参考にしてください。

#GCP#Cloud SQL#データベース
共有:
無料メルマガ

週1回、最新の技術記事をお届け

AI・クラウド・開発の最新記事を毎週月曜にメールでお届けします。登録は無料、いつでも解除できます。

※ プライバシーポリシーに基づき管理します

関連記事

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説

AWS CloudFrontでサイト高速化｜CDN設定からキャッシュ戦略まで実践解説
AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド

AWS CloudWatchで監視・アラート設定｜運用担当者のための実践ガイド
AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化

AWS CodePipelineでCI/CD構築｜コード変更から本番デプロイまでの自動化
AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術

AWS Cost Explorerでコスト可視化｜ムダを見つけて月額費用を削減する実践術
AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド

AWS ECS/Fargateでコンテナ運用｜Docker→本番デプロイの実践ガイド
AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法

AWS IAMのベストプラクティス｜最小権限の原則を実務で実装する方法
AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング

AWS RDSの実務ガイド｜データベース構築・バックアップ・パフォーマンスチューニング
AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践

AWS S3の実務活用ガイド｜バケット設計・アクセス制御・コスト最適化の実践
AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AWS VPCのネットワーク設計入門｜サブネット・セキュリティグループの実践構成

AI活用のヒントをお探しですか？お気軽にご相談ください。

まずは話だけ聞いてもらう