2026.07.23 インフラ

Cloud SQLとは？GCPのマネージドRDBの仕組み・エディションと採用判断を実装者目線で解説

Cloud SQLは、Google Cloud（GCP）が提供するMySQL・PostgreSQL・SQL Server向けのフルマネージド リレーショナルデータベースです。インスタンスの構築、パッチ適用、バックアップ、レプリケーション、フェイルオーバーといったデータベース運用の定型作業をGoogle側が肩代わりし、開発者はスキーマ設計とクエリに集中できます。この記事で扱うのは、内部構成と高可用性の仕組み、EnterpriseとEnterprise Plusの違い、Cloud RunやVPCからの接続方法、料金の考え方、そしてSpannerやBigtableとの選び分けまで。実装者が設計判断にそのまま使える粒度で整理します。

目次

まとめ:Cloud SQLの要点と採用判断の結論

Cloud SQLは「既存のMySQL/PostgreSQL/SQL Serverアプリを、SQL方言を変えずにマネージド環境へ載せ替えたい」場面に向くサービスです。単一リージョン内で動く垂直スケール型のRDBであり、1インスタンスがスケールアップできるCPU・メモリの上限が、実質的な処理能力の天井になります。読み取りはリードレプリカで分散できますが、書き込みは基本的に1つのプライマリへ集約する構成です。

採用の目安はシンプルです。トランザクション整合性を持つ関係データベースが必要で、単一リージョンのプライマリで書き込みを捌ける規模なら、Cloud SQLが第一候補になります。複数リージョンにまたがる強整合の書き込みや、垂直スケールの上限を超える書き込みスループットが要件ならCloud Spannerの分散リレーショナルDBの仕組みを、行あたり数千列に及ぶ大規模な時系列・センサーデータならCloud BigtableのワイドカラムNoSQLが候補です。可用性を最優先する本番系はEnterprise Plusエディション、開発・検証環境はEnterpriseで費用を抑える。これが実務の初期設計になります。

Cloud SQLの定義とフルマネージドが肩代わりする運用範囲

Cloud SQLの本質は「データベースエンジンそのものは標準のOSS/商用RDBのまま、その周辺運用をGoogleが引き受ける」点にあります。エンジンの互換性を保つ設計のため、アプリケーション側のSQLやドライバをほぼ変えずに移行できます。

対応する3つのデータベースエンジンとバージョン互換性の考え方

Cloud SQLが対応するのはMySQL・PostgreSQL・SQL Serverの3エンジンです。いずれも各エンジンの主要メジャーバージョン系列（MySQL 8系、PostgreSQL 16系前後、SQL Server 2022系など、2026年7月時点で提供される版）をマネージドで動かせます。ここで効くのがエンジン互換の維持。提供バージョンは順次更新されるため、採用時はGoogle Cloud公式ドキュメントの対応バージョン一覧を実測で確認します。互換性が保たれる利点は、ローカルのMySQLで動くアプリケーションを接続先だけCloud SQLへ差し替えて移せる点にあります。

エンジンによって使える機能に差があります。たとえばリードレプリカの上限数、拡張機能（PostgreSQLのpg_stat_statements等）、SQL Serverのライセンス込み課金など、エンジン固有の制約は設計前に洗い出します。

フルマネージドが肩代わりする作業とユーザー側に残る責任の範囲

Cloud SQLが肩代わりするのは、インフラのプロビジョニング、OS・データベースエンジンのパッチ適用、自動バックアップ、レプリケーション設定、障害時のフェイルオーバーといった運用作業です。一方でユーザー側に残る責任は、スキーマ設計、インデックス設計、クエリのチューニング、接続元のアクセス制御、そしてインスタンスサイズの見積もりです。

この境界を理解すると、Cloud SQLで避けられない設計課題が見えます。マネージドでも遅いクエリは遅く、インデックスの張り忘れやN+1クエリはそのまま性能問題になります。運用は任せられるが、設計は自分でやる。この前提で使うサービスです。

Cloud SQLのインスタンス構成と高可用性フェイルオーバーの仕組み

Cloud SQLの構成単位はインスタンスです。インスタンスはリージョン内の特定ゾーンに配置され、割り当てたvCPU数・メモリ量・ストレージ容量で処理能力が決まります。

インスタンスのゾーン配置と高可用性フェイルオーバーの動作原理

標準構成ではプライマリインスタンスが単一ゾーンに置かれます。高可用性（HA）を有効にした場合の挙動が要点です。同一リージョン内の別ゾーンにスタンバイインスタンスが作られ、同期レプリケーションでデータが複製されます。プライマリのゾーン障害を検知すると、スタンバイへ自動でフェイルオーバーし、同じ接続名でアクセスを継続できます。フェイルオーバーが守るのはゾーン障害まで。リージョン全体の障害には、別途クロスリージョンのリードレプリカで備えます。

HA構成はスタンバイ分のリソースが常時課金されるため、費用はおおむね倍増します。本番系はHA有効、開発系はHA無効。この切り分けが、費用と可用性の現実的なバランスになります。

リードレプリカによる読み取りスケールとストレージ自動増加の設定

書き込みはプライマリ1台に集約されますが、読み取りはリードレプリカを追加して分散できます。レプリカは非同期レプリケーション。そのため、プライマリへの書き込みがレプリカに届くまでにレプリケーション遅延（レプリカラグ）が生じます。読み取り整合性が厳密に求められる処理はプライマリへ、集計・レポートなど多少の遅延を許容できる読み取りはレプリカへ振り分けます。

ストレージは自動増加を有効にでき、使用量が上限へ近づくと容量を自動で拡張します。ただし一度拡張したストレージは縮小できません。過大なストレージ増加は費用へ直結するため、増加上限の設定と定期的な使用量の確認をセットにします。

Cloud SQLのエディション:EnterpriseとPlusの違い

Cloud SQLにはEnterpriseとEnterprise Plusの2エディションがあります。両者は可用性SLA、性能、メンテナンス時のダウンタイム、費用で差があり、ワークロードの重要度で選び分けます。

EnterpriseとEnterprise Plusの比較と選定基準

Enterprise Plusはデータキャッシュによる読み取り・書き込み性能の向上、より高い可用性SLA（99.99%）、計画メンテナンス時のダウンタイムを1秒未満に抑える構成などを備えます。Enterpriseは標準的な可用性SLAで、費用を抑えられます。

観点 Enterprise Enterprise Plus
可用性SLA（HA構成時） 標準水準 99.99%
データキャッシュ なし あり（読み書き性能を向上）
計画メンテナンス時のダウンタイム 数十秒規模が生じうる 1秒未満に短縮可能
費用 低め 高め
向く用途 開発・検証、中程度の本番 ミッションクリティカルな本番系

選定の言い切りはこうです。SLAの数字を契約や社内基準で約束する本番データベースなら、Enterprise Plusを選びます。数値のSLAを求められない内部ツールや開発環境でEnterprise Plusを選ぶのは、費用の無駄です。エディションはインスタンス作成後にも変更できますが、変更にダウンタイムを伴う場合があるため、本番系は初期設計で決め切ります。

Cloud SQLへの接続方法とアプリケーションからの接続実装

Cloud SQLへの接続経路は、パブリックIP・プライベートIP（VPC経由）・Cloud SQL Auth Proxyの3系統に整理できます。本番ではプライベートIPかAuth Proxyを使い、パブリックIPの直接公開は避けます。

Cloud SQL Auth ProxyとプライベートIPの使い分け

Cloud SQL Auth Proxyは、IAM認証と暗号化を担うローカルプロキシです。アプリケーションはローカルのソケット経由でプロキシに接続し、プロキシがCloud SQLへ暗号化トンネルを張ります。狙いは認証情報の分離。データベースのパスワードをアプリに埋め込まず、IAMの権限でアクセスを制御できます。一方、同一VPC内のGCEやGKEからは、プライベートIPで直接つなぐ構成が低レイテンシで扱いやすくなります。

接続文字列はPROJECT:REGION:INSTANCE形式のインスタンス接続名で指定します。オンプレミスや別クラウドからの接続はAuth Proxyに加えVPNやInterconnect経由に限定し、パブリックIPを開放しない設計を原則とします。

Cloud RunなどサーバーレスからCloud SQLへ接続する構成

サーバーレス環境からの接続には固有の注意点があります。Cloud RunのサーバーレスコンテナからCloud SQLへつなぐ場合、Cloud RunのCloud SQL接続機能を有効にするとAuth Proxyが組み込まれ、インスタンス接続名を指定するだけで接続できます。問題はコネクション数です。サーバーレスはリクエストごとにコンテナが増減するため、プールの上限がインスタンスの最大接続数を超えないよう、1コンテナあたりのプールサイズを絞る設計が要点になります。接続が集中してCloud SQL側のmax_connectionsに達すると、新規接続は拒否。上限は負荷試験で確認します。

Cloud SQLの料金の考え方とバックアップ・災害復旧の設計

Cloud SQLの費用は、使った量に応じた従量課金です。何にいくら掛かるかを分解しておくと、見積もりと適正化の勘所がつかめます。

Cloud SQLの料金を構成する課金要素とコストを抑える設計

課金要素は主に、割り当てたvCPU数・メモリ量、プロビジョニングしたストレージ容量（GiB/月）、バックアップ保管量、ネットワーク下り通信量、割り当てた外部IPアドレス数で構成されます。HA構成やリードレプリカは、その分のコンピュート・ストレージが加算されます。

費用を抑える現実的な手は3つに絞れます。第一に、開発環境は夜間・休日にインスタンスを停止する（停止中もストレージ課金は残る点に注意）。第二に、リードレプリカは読み取り負荷が実測で偏っている場合のみ追加し、予防的に増やさない。第三に、Enterprise PlusのデータキャッシュはSLAを要求される本番に限定する。過剰なvCPU割り当ては最も見落とされがちな無駄で、CPU使用率のメトリクスを見て、見合ったサイズへ下げます。

自動バックアップとポイントインタイムリカバリ(PITR)の設定

Cloud SQLは日次の自動バックアップと、トランザクションログを使ったポイントインタイムリカバリ（PITR）に対応します。PITRを有効にすると、任意の時点の状態へ復元でき、誤ったUPDATEやDELETEからの巻き戻しに使えます。ここで効くのが保持期間の設計です。保持期間とPITRのログ保持ウィンドウは設定値であり、延ばすほど保管費用が増える点に注意。災害復旧では、クロスリージョンのリードレプリカを1本用意し、リージョン障害時にそのレプリカを昇格させる手順を平時に検証しておきます。

Cloud SQLと他のGCPデータベースの選び分け:採用すべきでない場面

Cloud SQLは万能ではありません。RDBの形をしていても、Cloud SQLが不向きなワークロードは明確に存在します。ここでは判断を言い切ります。

Cloud SQLを第一候補から外したほうがよい3つの判断条件

次の3条件のいずれかに当てはまる場合、Cloud SQLは第一候補から外します。

  • 複数リージョンで強整合の書き込みが必要：グローバルに分散したユーザーへ、どのリージョンからでも整合した書き込みを提供する要件では、垂直スケール・単一プライマリのCloud SQLでは無理があります。水平スケールと強整合を両立するCloud Spannerの分散アーキテクチャが適します。
  • 書き込みスループットが単一インスタンスの上限を超える：秒間数万件超の書き込みや、ペタバイト級の時系列・IoTデータでは、リレーショナルモデルよりCloud BigtableのワイドカラムNoSQLが適します。
  • 大規模な分析クエリを日常的に流す：数億行を横断する集計・BIはOLTP向けのCloud SQLでは重く、BigQueryのような分析特化のデータウェアハウスへ分離します。

逆に言えば、単一リージョンのトランザクション処理で、既存のSQL資産をそのまま使いたいなら、Cloud SQLは過不足のない選択です。将来のグローバル展開を漠然と理由にSpannerを最初から選ぶと、運用の複雑さと費用を過剰に抱え込みます。要件が単一リージョンで足りるうちはCloud SQLで始め、上限が見えた時点で移行を検討する順序が現実的です。

マネージドRDBの設計・移行を外部の開発会社と進めるときの勘所

Cloud SQLの設計は、エディション選定・HA構成・接続方式・バックアップ方針・監視の5点を押さえれば骨格が固まります。ただし難所は別にあります。既存システムからの移行や、可用性・災害復旧まで含めたクラウドインフラの設計は、DB単体でなくシステム全体の要件から逆算する作業です。GCPを含むクラウド基盤の構築・移行を外部と進める場合は、AWS・Google Cloud・Azureのインフラ構築の実績を持つ体制へ、要件定義の段階から相談すると設計の手戻りを減らせます。

Cloud SQLの導入検討でよくある質問と実装上の判断基準

Cloud SQLの導入検討で技術選定者から挙がる質問を、実装判断に必要な粒度で答えます。

Cloud SQLとAmazon RDSの違いは何ですか？

どちらもマネージドリレーショナルデータベースで、位置づけは同等です。Cloud SQLはGCP、Amazon RDSはAWSのサービスであり、対応エンジンや周辺サービスとの結び付きが異なります。判断材料は周辺環境。すでにGCPで他サービス（Cloud Run、BigQuery、GKEなど）を運用しているなら、同一VPC・同一IAMで完結するCloud SQLが接続と権限管理の面で扱いやすくなります。選定はDB単体の優劣より、周辺のクラウド基盤をどちらへ寄せるかで決まります。

Cloud SQLは自動でスケールしますか？

ストレージ容量は自動増加できますが、vCPUやメモリ（コンピュート）は自動では水平スケールしません。書き込み能力を上げるにはインスタンスサイズを手動でスケールアップし、読み取りはリードレプリカを追加して分散します。負荷に応じてノードが自動で増減する水平スケールが要件なら、Cloud SQLではなくSpannerが該当します。

Cloud SQLのダウンタイムはどのくらいですか？

計画メンテナンスと障害時フェイルオーバーの2種類があります。HA構成では別ゾーンのスタンバイへ自動フェイルオーバーします。Enterprise Plusエディションは計画メンテナンス時のダウンタイムを1秒未満に抑える構成を選べ、HA構成時の可用性SLAは99.99%です。SLAの数値を契約で約束する本番系では、Enterprise Plus＋HAを前提にします。

既存のMySQLデータベースをCloud SQLへ移行できますか？

移行できます。Cloud SQLはエンジン互換のため、Database Migration Service（DMS）でダンプ・リストアや継続的レプリケーションに対応します。注意は制限機能の洗い出しです。SQL方言やドライバはそのまま使えるのが基本ですが、拡張機能や特定のストレージエンジン、SUPER権限が必要な操作など、マネージド環境で制限される機能は事前に確認します。

Cloud SQLの接続数の上限に達したらどうなりますか？

インスタンスのmax_connectionsに達すると、新規接続が拒否されエラーになります。対策は接続数の管理です。サーバーレスや多数のコンテナから接続する構成では、各アプリのコネクションプールサイズの合計が上限を超えないよう設計します。接続の急増が避けられない場合は、PgBouncerなどの外部コネクションプーラーを挟むか、インスタンスサイズを上げて上限を引き上げます。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る