G-gen の杉村です。 Google Cloud (旧称 GCP) のマネージドの RDBMS サービスである Cloud SQL について徹底的に解説します。
- Cloud SQL とは
- 料金
- インスタンス
- vCPU とメモリ
- ストレージ (ディスク)
- 高可用性 (HA 構成)
- リードレプリカ
- バックアップとリストア
- ネットワークと接続方法
- Cloud SQL Auth Proxy
- 認証・認可
- メンテナンス
- モニタリング・ロギング
- 監査
- 暗号化
- Cloud SQL editions
- その他留意事項
Cloud SQL とは
Cloud SQL とは Google Cloud (旧称 GCP) のマネージドの RDBMS サービスです。
MySQL 、 PostgreSQL 、 Microsoft SQL Server をホストすることができ、利用者は OS レイヤ以下を意識することなく、データベースを利用することができます。いわゆる DBaaS とも呼ばれる分類のサービスであり、他社サービスでは Amazon Web Services (AWS) の Amazon RDS がこれにあたります。
簡単に利用開始できるほか、データベースエンジンのインストールやアップデート、バックアップやモニタリング、 CPU/メモリやストレージの拡張などの工数を大幅に削減することができます。
また複数のゾーンにまたがる冗長化設定やリードレプリカの作成も容易です。
BigQuery など他の Google Cloud サービスとの連携もシームレスに行うことができます。
Google Cloud にホストするアプリケーションでリレーショナルデータベースを利用する際は、使わない手はないサービスです。
料金
Cloud SQL の料金
Cloud SQL は 従量課金 です。割り当てた vCPU コア数、メモリ、ストレージ量に対して課金されます。
SQL Server の場合はこれに加え、ライセンス料金も起動時間に応じて 1 時間単位で発生します。
また Cloud SQL for MySQL と for PostgreSQL にはエディションの概念があります (後述)。Enterprise と Enterprise Plus の 2 エディションが存在し、後者のほうが vCPU/メモリあたりの単価が高い代わりに、より高い可用性 SLA・短いダウンタイム・キャッシュ用ストレージなどが利用可能です。
月額費用の例として Enterprise エディションの Cloud SQL for PostgreSQL を「vCPUs: 2 / RAM: 8 GB」で 1 ヶ月間フル稼働すると、約 21,864 円 / 月です (2023年7月時点、東京リージョン、140円/ドル、ストレージは 100GB SSD) 。
最新の利用料金は以下の公式ページでご確認ください。また、公式の見積もりツールで料金が試算できます。
- 参考 : Cloud SQL pricing
- 参考 : Introduction to Cloud SQL editions
- ツール : Google Cloud Pricing Calculator
確約利用割引
Cloud SQL には 確約利用割引 の仕組みがあります (英名: Committed use discount / CUD) 。
1年間または3年間の利用を確約 (コミット) することで最大 52% の割引を受けることができます。確約利用割引は、 Google Cloud のコンソール画面から購入します。
確約利用割引は vCPU とメモリの料金に対して利用することができますが、ストレージ / バックアップ / ライセンス / ネットワーク料金には適用することができません。
詳細は以下の公式ドキュメントをご確認ください。
インスタンス
インスタンス とは
Cloud SQL は インスタンス という単位で管理します。インスタンスは 1 台の仮想サーバーであるとイメージすればよいでしょう。
DB エンジン (MySQL / PostgreSQL / SQL Server) 、 vCPU コア数、メモリ数、ストレージサイズなどを指定してインスタンスを作成すると、データベースがインストール済みの仮想サーバーが自動的に構築されます。
起動と停止
インスタンスは、利用しない間は 停止 することができます。
停止されたインスタンスには vCPU とメモリの料金が発生しません。ただし確保されたストレージに対しては料金が発生し続けるほか、確保された IP アドレスの利用料金もわずかに発生します。
なおインスタンスのストレージ容量が上限に近づくと、データロスを防ぐためインスタンスが自動的に停止されることがあります。オンプレミスや仮想サーバーで動作するデータベースと同様に、ストレージ使用率の適切なモニタリングが必要です。必要に応じて、後述のストレージ自動拡張機能を有効化することも検討します。
なお後述のリードレプリカインスタンスは停止することができません。
データベースフラグ
データベースフラグ とは DB エンジン (MySQL / PostgreSQL / SQL Server) が持つパラメータを設定するための Cloud SQL インスタンスの設定値です。
Cloud SQL では OS レイヤやミドルウェアレイヤを Google Cloud が管理しているため、例えば PostgreSQL でいう postgresql.conf ファイルなどの設定ファイルを直接編集できません。
そのため Cloud SQL ではデータベースパラメーターは、データベースフラグという Cloud SQL インスタンスの設定値として管理されます。
DB エンジンが用意している全てのパラメータが Cloud SQL でも利用可能というわけではなく、パラメータによっては変更不可なものがあります。対応状況は以下のドキュメントをご参照ください。
※ 上記は PostgreSQL 版ドキュメントへのリンクとなっていますが、タイトルの見出し横のリンクから別の DB エンジンのドキュメントへ移動することができます。以下、全てのドキュメントで同じです。
vCPU とメモリ
マシン構成
Cloud SQL では、vCPU 数とメモリ量をカスタムして適切なサイズのインスタンスを作成できます。
なお検証目的等のため、弱いスペックの「共有コア CPU」を使用するインスタンスを構築することもできます。共有コアを使う場合は、通常とは別単価が設定されているほか、Cloud SQL SLA には含まれません。
運用中の変更
vCPU とメモリ量は前述の通り、インスタンスの初期作成時にマシンタイプを指定することで決定しますが、インスタンスを編集することで後から変更できます。
ただし vCPU / メモリーの変更にはインスタンスの再起動が必要です。再起動を行うと、データベースにダウンタイムが発生します。
ストレージ (ディスク)
種類
Cloud SQL を作成時、使用するストレージ (ディスク) を HDD (ハードディスク) か SSD の中から選ぶことができます。どちらの場合でも複数の物理ドライブにデータが複製されているので、高い堅牢性が確保されます。
一般的な用途では SSD が 推奨されています 。 HDD は SSD よりもパフォーマンスに劣りますが、料金単価が安い点が特徴です。
通常のユースケースでは SSD を選択し、データ容量が大きくレイテンシが問題にならない (特にランダムリードアクセスの頻度が低く、シーケンシャルライトが中心のワークロード) の場合のみ HDD を選択すると良いでしょう。
容量
ストレージの容量はインスタンス作成時に指定できます。またインスタンス作成後にも拡張が可能です。ただし 縮小はできません 。
ストレージの拡張はオンラインのまま行うことができ、ダウンタイムは発生しません。
ストレージの自動増量
オプションで ストレージの自動増量 を有効化することができます。ストレージの自動増量を有効化すると、ストレージの残容量が 30 秒ごとにチェックされ、残容量が一定回数以上、閾値を下回るとストレージが追加されます。
またストレージの自動増量には上限値を設定することもできます。
ストレージ自動拡張のトリガとなる閾値の計算方法などの詳細は、以下のドキュメントを参照してください。
パフォーマンス
Cloud SQL のストレージのパフォーマンスは IOPS とスループットで表されます。
Cloud SQL ではバックエンドに Compute Engine (Google Cloud の仮想サーバーサービス) を使っており、 IOPS とスループットが決まる仕組みは Compute Engine の永続ディスクと同じです。
原則的に、ストレージのサイズを大きくすればするほど IOPS とスループットが大きくなっていきます。詳細は、以下の記事の「永続ディスクのパフォーマンス」の項を参考にしてください。
また MySQL/PostgreSQL で利用可能な Cloud SQL Enterprise Plus エディションでは、書き込みレイテンシが最適化されているためより高い性能が発揮できるほか、データキャッシュにより読み取りレイテンシの最小化を図ることもできます。
高可用性 (HA 構成)
概要
Cloud SQL インスタンスでは、簡単に 高可用性構成 にすることができます。インスタンス作成時に、高可用性のオプションのチェックマークを入れるだけです。
高可用性構成は HA (High Availability) 構成とも呼ばれ、プライマリインスタンス (主系) とは別のゾーンにスタンバイインスタンス (従系) を配置し、プライマリインスタンスに障害が発生した際に自動的にスタンバイインスタンスに フェイルオーバー させることができる仕組みです。
プライマリインスタンスからスタンバイインスタンスへは、永続ディスクにデータが 同期レプリケーション されます。つまり HA 構成の DB のトランザクションは、両方のゾーンのディスクに書き込まれて初めてコミット完了となります。
そのため、書き込みパフォーマンスは HA 構成でない場合と比べて劣る可能性があります。どのくらいの影響が出るかは、ディスク容量に応じた IOPS やデータ量などによるため、一概には言えず、検証する必要があります。
また HA 構成を有効化するとインスタンスが 2 台稼働するため、インスタンスの CPU ・メモリ・ストレージ料金が 2 倍かかります。
フェイルオーバー
Cloud SQL は毎秒、データベースに対してハートビートを送ります。プライマリインスタンスが約 60 秒間応答しない、またはプライマリインスタンスのゾーンで Cloud SQL としてのサービス停止が発生した場合にフェイルオーバーが発動します。
セカンダリインスタンスがプライマリに昇格し IP アドレスも引き継がれる ため、アプリから見ると若干のダウンタイムの後に透過的に新プライマリインスタンスに接続できるようになります。
なおフェイルオーバー後に旧プライマリインスタンスが正常に戻っても、自動的にフェイルバックはしません。プライマリを元のゾーンに戻したい場合は明示的に再度 フェイルオーバーを実行 してフェイルバックする必要があります。
フェイルオーバーの発生履歴は オペレーションログ から確認できます。
可用性 SLA
Cloud SQL SLA では HA 構成となっていること」「共有コアインスタンスではないこと」など一定の条件のもとに、 Cloud SQL サービスのダウンタイムが一定期間を超えるとクレジットの払い戻しが受けられることが定義されています。
Enterprise edition (MySQL/PostgreSQL) および SQL Server インスタンスでは条件を満たしていれば月間 99.95% 以上の可用性が、Enterprise Plus edition (MySQL/PostgreSQL) では月間 99.99% 以上の可用性が定義されています。
詳細な定義は、以下の公式ドキュメントをご参照ください。
- 参考 : Cloud SQL SLA
リードレプリカ
リードレプリカとは
リードレプリカ は Cloud SQL インスタンスのコピーであり、読み取りリクエストを負荷分散する目的で利用します。
プライマリインスタンスのデータが更新されると、ニアリアルタイムで非同期レプリケーションされます。レプリケーションの遅延は Cloud Monitoring のメトリクスで 確認する ことができます。
リードレプリカは読み取りリクエストを受け取れますが、書き込みリクエストを受け取ることはできません。
これを聞くとリードレプリカは高可用性 (HA) 構成と似ているように思えるかもしれませんが、 HA 構成は高可用性が目的であり、リードレプリカは 読み取りワークロードの負荷分散が目的 であるという点で似て非なるものです。
リードレプリカは高可用性が目的ではないものの、リードレプリカをプライマリインスタンスに 手動で昇格 させることは可能です。これにより後述のクロスリージョンリードレプリカを用いてリージョン間の DR を実現することも可能です。
クロスリージョンリードレプリカ
リードレプリカには通常のリードレプリカの他に クロスリージョンリードレプリカ が存在します。
クロスリージョンリードレプリカはリージョン間でデータを同期します。以下のような目的で利用されます。
- 他リージョンのアプリケーションからの DB 読み取りのレイテンシを抑える
- リージョン間のデータ移行
- リージョン間 DR
レプリカと HA のアーキテクチャ
高可用性構成 (HA 構成) は「可用性目的」、リードレプリカは「読み取りワークロードの分散目的」という目的の違いがあります。
HA とリードレプリカは併用でき、以下のような構成が可能です。
外部レプリカ
Cloud SQL では 外部レプリカ (External replica) も構成可能です。
オンプレミスや他のパブリッククラウドの MySQL / PostgreSQL / SQL Server から Cloud SQL に対してデータを同期できます。 MySQL では逆に Cloud SQL のデータベースを外部にレプリケーションできるなど、 DB エンジンによって可能なことが異なります。
外部レプリカは高可用性目的や DR 目的の他、データベースの移行の目的で利用されることもあります。
バックアップとリストア
バックアップ
仕組み
Cloud SQL にはインスタンス稼働中にデータを バックアップ する機能があります。
バックアップには オンデマンドバックアップ (手動) と 自動バックアップ があります。どちらもベースは同じ仕組みで、バックアップのトリガが手動か、自動のスケジューリングかの違いです。
Cloud SQL インスタンスのバックアップを取得すると、その瞬間のインスタンスの状態が保存されます。同じインスタンスで複数回バックアップを取得すると、2回目以降は 増分バックアップ になります。つまり、前回のバックアップ時点から変更されたデータのみがバックアップされます。最も古いバックアップが削除されたとしても、その次に古いバックアップにフルバックアップが引き継がれるため「どれがフルバックアップでどれが増分バックアップか」を気にする必要はありません。
リストアの項で後述しますが、バックアップからのリストアは 既存 Cloud SQL インスタンスを上書きする あるいは 新しい Cloud SQL インスタンスを生成する ことができます。
料金
ストレージ容量に応じて、バックアップを保存している期間だけ料金が発生します。料金は 2022 年 8 月時点、東京リージョンで $0.104/GB/月 です。
例として 100 GB ストレージの Cloud SQL インスタンスのバックアップを 7 世代保存するとします。1 世代目のバックアップの容量は 100 GB であり、その後の世代は 10 % ずつ変更があるとすると、料金は以下のようになります。
100 GB + (10 GB × 6) = 160 GB
→ 160 GB × $0.104 = $16.64 / 月
自動バックアップ
Cloud SQL では、自動バックアップの取得はデフォルトで日次 7 世代の自動バックアップが取られることになっています。世代数は 0 (無効化) 〜 365 世代の間で設定できます。
自動バックアップの取得は日次で行われ、取得時刻は 4 時間の バックアップウインドウ を指定し、その中で行われます。バックアップ取得によりダウンタイムが発生することはありませんが、多少のパフォーマンス影響はありえるため、可能な限り利用者が少ない時間帯に設定することが望ましいです。
保存先ロケーション
バックアップの保存先のロケーション (リージョン) を指定することができます。
何も指定しない場合はインスタンスに最も近い「マルチリージョン」のロケーションに保存されます。インスタンスが東京リージョンにあれば asia というマルチリージョンに保存されます。データが複数リージョンに冗長化されるため、リージョン単位の大規模障害でもデータの堅牢性が保持されます。
トランザクションログ
リストアの項でも記載しますが Cloud SQL では ポイントインタイムリカバリ (PITR) が可能です。ポイントインタイムリカバリは Cloud SQL 用語というわけではなく、データをある日時・時刻の状態に巻き戻すというリカバリ方法を指す一般的な用語です。
ポイントインタイムリカバリにはデータベースのトランザクションログを用います。 MySQL で言う バイナリログ (binlog) 、 PostgreSQL で言う WAL です。
トランザクションログの保持期間は1～7日の範囲で設定できます (Enterprise Plus エディションの場合は最大35日まで)。デフォルト値は7日です。トランザクションログの保持期間は PITR の必要性に応じて期間を設定します。ただし、自動バックアップの保持期間より長く設定することはできません。
なおトランザクションログはかつては通常のデータ領域と同じディスクに保存されていましたが、PostgreSQL は2023年1月から、MySQL は2023年8月から、Cloud Storage に保存されるようになりました。それ以前からポイントインタイムリカバリを有効にしている場合はトランザクションログがディスク領域を圧迫していますが、一度無効化してから再度有効化することでログが Cloud Storage に保管されるようになります。ただしこれを行った場合は直近のログは消えてしまいますので注意が必要です。
リストア
前述のバックアップ機能で取られた Cloud SQL インスタンスからの リストア は、以下のいずれかの方法で実現できます。
| 名称 | 説明 | 条件・制約等 |
|---|---|---|
| 同じインスタンスへの復元 | 元のインスタンスの中身をバックアップ時の状態に復元 | - |
| 別のインスタンスへの復元 | バックアップから別のインスタンスを生成 | 別プロジェクトにも復元可。データベースフラグは復元されない |
| ポイントインタイムリカバリ | 特定時点の状態に復元。ただし別インスタンス生成となり元のインスタンスは巻き戻せない | 対象時点のバックアップとトランザクションログが必要 |
注意点として ポイントインタイムリカバリ (PITR) は「元のインスタンスをある時点に巻き戻す」のではなく「 ある時点の状態のインスタンスを別インスタンスとして作成する 」という挙動になります。
そのため PITR 実施後にはアプリケーションの向き先を変更したり、あるいは復元した新インスタンスから必要なデータだけを抜き取るなどが必要です。
インポート・エクスポート
Cloud SQL の標準機能のバックアップを Google Cloud の外にエクスポートすることは できません 。
ただし各 DB エンジンの機能によるダンプファイルのエクスポートや csv ファイルによるエクスポート、およびインポートは可能です。
DB エンジンによりますが Google Cloud コンソールや gcloud コマンドによる操作で Cloud Storage (GCS) へ直接エクスポートさせることも可能です。
また Cloud SQL for MySQL / PostgreSQL では サーバーレスエクスポート 機能があります。エクスポートジョブを実行するための一時的なインスタンスが作成され、そこからダンプファイルが Cloud Storage バケットへエクスポートされるため、本番インスタンスへのパフォーマンス影響を回避できます。
詳細は以下のドキュメントやその周辺リンクからご確認ください。
ネットワークと接続方法
Cloud SQL とネットワーク
Cloud SQL インスタンスは Google Cloud が持つ VPC (Virtual Private Cloud : 仮想ネットワーク) に作成されます。ユーザーの VPC ではなく、 Google の VPC だという点がポイントです。
AWS の Amazon RDS を例に取ると Amazon RDS インスタンスはユーザーが所有する VPC に作成できますが、 Cloud SQL インスタンスはそうではなく、 Google の持つマネージドな VPC 内にインスタンスが作成されるのが特徴です。これは プライベートサービスアクセス という仕組みであり、インスタンスが配置される Google の VPC を サービスプロデューサーのネットワーク と呼びます。
ユーザーのアプリケーションから Cloud SQL に接続するには、以下の二通りの選択肢があります。
- Public IP で接続
- Private IP で接続
前者は Cloud SQL インスタンスにパブリック IP (グローバル IP) を割り振り、インターネット経由でアクセスする方法です。
後者は Cloud SQL インスタンスにプライベート IP だけを割り振ります。そのうえで、ユーザーの VPC と Cloud SQL が存在するサービスプロデューサーのネットワークを VPC ピアリング で接続して利用することになります。
Public IP で接続
仕組み
Cloud SQL にはパブリック IPv4 アドレスを持たせ、インターネット経由でアクセスすることができます (IPv6 には未対応) 。もちろん Public IP は無効にすることができ、その場合は後述の Private IP での接続を利用します。
インターネット経由でのアクセスとなりますので、アプリケーションと Cloud SQL インスタンス間の通信は SSL/TLS で暗号化 するべきです (後述) 。
また後述の Cloud SQL Auth Proxy 等を使えば通信は自動的に暗号化されます。
アクセス制御
インターネットからの無制限のアクセスを許可することはセキュリティ上のリスクであるため、明示的に許可する接続元 IP をホワイトリスト形式で指定する仕様となっています。
この許可対象の接続元 IP リストは 承認済みネットワーク と呼ばれます。逆に、承認済みネットワークを一つも設定しない場合、インスタンスへの接続はできません。
承認済みネットワークは CIDR 形式 で登録するため、IP アドレスを範囲で指定可能です (例: xx.yy.zz.0/24) 。
Private IP で接続
仕組み
セキュリティ上の理由から Cloud SQL にはパブリック IP アドレスを持たせたくないケースがほとんどと考えられます。その場合は Private IP を用いた接続を行います。
前述した通り Cloud SQL インスタンスは Google の VPC に作成されます。そのためユーザーの VPC と Google の VPC を VPC ピアリング で接続する必要があります。
なおこのようにインスタンスが Google の VPC (サービスプロデューサーのネットワーク) に作成され、ユーザーの VPC と接続して利用することを プライベートサービスアクセス と言います。 Cloud SQL 以外にも Memorystore 、 Cloud Build 、 Vertex AI などで利用されるネットワーク形態です。
プライベートサービスアクセス用のサブネット作成
Cloud SQL インスタンスを設置するサービスプロデューサーのネットワークは、始めて利用するときに IP レンジを指定して作成する必要があります。
最小は /24 ですが推奨は /16 となっています。このとき、 Cloud SQL を利用する予定の接続元ノード (Compute Engine の VM やオンプレミスのサーバー) があるネットワークと 重複しない IP レンジ を割り当てる必要があります。重複すると、当然ながら適切なルーティングができなくなるおそれがあります。
一度プライベートサービスアクセス用のサブネットを作成すれば、次回以降に Cloud SQL や Memorystore のインスタンスを構築する際は、そのネットワークを流用することができます。
設定方法
コンソール画面では、指示に沿って設定を進めることで Cloud SQL に Private IP を割り振り、プライベートサービスアクセス用のサブネットを作成し、ユーザーの VPC との接続を有効化することで、 Compute Engine VM 等から Cloud SQL インスタンスへ到達することができるようになります。
初期構築時のほか、既存の Public IP を利用しているインスタンスを Private IP での利用に変更することも可能です。
詳細な手順は以下を参考にしてください。
アクセス制御
Cloud SQL インスタンスが存在するサービスプロデューサーのネットワークにはファイアウォールを任意に設定できません。
また Public IP でアクセス制御に用いた「承認済みネットワーク」の仕組みは Private IP では原則的に使えません。RFC 1918 アドレス範囲 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) は 自動的に許可される仕様 です (ただしクライアントが RFC 1918 以外のアドレス範囲であれば、明示的に承認済みネットワークに追加する必要があります)。
そのため Private IP を用いる際はアクセス元 VPC のファイアウォールでのアウトバウンド制御などを用います。
またアクセス元を厳しく制限したい場合、 Private IP 接続でなくあえて Public IP 接続を用い、承認済みネットワークに一つも CIDR を登録せず、Cloud SQL Auth Proxy (後述) での IAM 接続元承認を用いることで、特定のサービスアカウントだけからの接続に制限するという方法も考えられます。
Cloud SQL Auth Proxy
Cloud SQL Auth Proxy とは
Cloud SQL に接続するには、Public IP/Private IP アドレス宛に直接接続する以外にも、Cloud SQL Auth Proxy というプロキシソフトウェアを使う方法があります。
Cloud SQL Auth Proxy はアプリケーションと同じサーバーで動作して Cloud SQL への接続をプロキシするソフトウェアです。
アプリケーション (DB クライアント) から Cloud SQL Auth Proxy へはローカル通信 (127.0.0.1 or localhost) で接続し、その後は Cloud SQL Auth Proxy から Cloud SQL へ通信が確立されます。
Cloud SQL Auth Proxy から Cloud SQL インスタンスへの通信は TLS 1.3 で暗号化されます。
Cloud SQL Auth Proxy では Linux, macOS, Windows に対してバイナリが用意されています。 Go のソースコードが公開されているため、他の OS 用にコンパイルして利用することも可能です。
メリット
Cloud SQL Auth Proxy を使う利点は、以下のようなものがあります。
- 自動的に通信が SSL/TLS 暗号化される。データベース側の設定や SSL/TLS 証明書の管理は不要
- Public IP を利用する場合でも「承認済みネットワーク」の追加が不要 (IAM で接続元を承認する)
- IAM データベース認証 (IAM 権限で DB にログインする。ユーザー・パスワード不要 ※ただし PostgreSQL のみ)
3 つ目の IAM データベース認証については後述します。
接続の流れ
アプリケーションが Cloud SQL Auth Proxy を通じて Cloud SQL へ通信するフローは以下のとおりです。
- アプリケーションからローカル上の Cloud SQL Auth Proxy へ接続 (通常のデータベースのプロトコル)
- Cloud SQL Auth Proxy は Cloud SQLインスタンスへの既存コネクションがあるかチェックし、存在すればそれを使う
- 存在しない場合、 Cloud SQL Admin API へアクセスし一時的な SSL/TLS 証明書を取得
- Cloud SQL Auth Proxy から Cloud SQL インスタンスへコネクション確立
上記の 3. では Cloud SQL Auth Proxy から sqladmin.googleapis.com へ 443/TCP で通信が発生します。このドメインの IP アドレスは固定ではないので、 VPC Firewall 等でアプリケーションサーバーから 0.0.0.0/0 へのアウトバウンド通信を許可する必要があります。
また 4. では Cloud SQL Auth Proxy から Cloud SQL インスタンスへ 3307/TCP でアウトバウンド通信が発生します。やはり VPC Firewall 等で、 Cloud SQL インスタンスの IP アドレスに対してアウトバウンド通信の許可が必要です。
接続コマンド例
psql "host=127.0.0.1 sslmode=disable dbname=DB_NAME user=USERNAME"
他の Cloud SQL コネクタ
Cloud SQL Auth Proxy の他にも、Cloud SQL への接続をプロキシする仕組みがあります。プログラムのランタイムに組み込むことのできる Cloud SQL コネクタ です。
現在では Java、Python、Go、Node.js 用のコネクタが存在しており、これらの言語環境であれば、 Cloud SQL Auth Proxy のように外部プロセスを稼働させることなく暗号化や IAM データベース認証のメリットを受けることが出来ます。
ライブラリとしてインポートして利用できるため、Cloud SQL Auth Proxy とは異なり実行環境に配置してプロセス起動する必要がありません。言語が対応していれば、第1選択肢として有用です。
設定と接続の方法
Cloud SQL Auth Proxy を利用するには DB クライアントと同じローカルに Cloud SQL Auth Proxy をインストールします。
また Cloud SQL インスタンスへの接続元として承認されるために IAM 権限が必要です。なおこの「接続元の承認」はデータベース (MySQL / PostgreSQL / SQL Server) による ユーザー認証とは別物 である点に注意しましょう。日本語ドキュメントではどちらも「認証」とされているため紛らわしいのですが、当記事では「接続元の承認」という言葉と「 (データベースの) (ユーザー) 認証」という言葉で区別しています。前者の「承認」という言葉は Public IP を利用して接続する際に登録する「承認済みのネットワーク」と同じ意味合いです。
接続元の承認のための IAM 権限は、 Google ユーザーアカウントやサービスアカウント等にひも付きます。
もし Cloud SQL Auth Proxy の実行環境が Compute Engine 等の Google Cloud リソースであれば、 VM インスタンス等にサービスアカウントをアタッチして、その IAM 権限で承認することが推奨です。そうでない場合はサービスアカウントの認証情報 JSON をダウンロードして利用することになります。
詳細は以下のドキュメントを参照してください。
認証・認可
データベースログインのための認証
Cloud SQL のデータベースにログインするための認証方法は、二通りあります。
- ユーザー・パスワードによる認証
- IAM による認証
前者は、通常の MySQL / PostgreSQL / SQL Server の組み込みのユーザー・パスワードを使ってログインする方法です。通常のデータベースと変わりありません。
後者は、 Google Cloud の IAM の認証情報を使ってログインする方法です。 MySQL と PostgreSQL でのみ利用可能で、 SQL Server では使えません。 IAM による認証にも「手動」と「自動」の二種類があります。
DB エンジンにより、利用可能な認証方法が異なっています。以下の表は 2023 年 2 月現在の対応状況です。
| DB エンジン | ユーザー・パスワード認証 | IAM 認証 (手動) | IAM 認証 (自動) |
|---|---|---|---|
| MySQL | ◯ | ◯ | ◯ |
| PostgreSQL | ◯ | ◯ | ◯ |
| SQL Server | ◯ | ✕ | ✕ |
続けて、それぞれどのような認証方法なのかを解説します。
ユーザー・パスワードによる認証
通常の MySQL / PostgreSQL / SQL Server と同じ用にユーザー名とパスワードを使って認証します。
mysql コマンドや psql クライアントなどを用いて、通常通りアクセスすることが可能です。
ユーザーの作成・管理は、原則的に通常の DB と同じ用に作成できます。また Google Cloud コンソール画面や gcloud コマンド等からもユーザー作成・削除やパスワードリセットが可能です。
インスタンス作成直後には デフォルトユーザーアカウント が作成されており、初期パスワードの設定は Google Cloud コンソールから実施する必要があります。
Cloud SQL のデフォルトユーザーアカウント名は MySQL では root 、 PostgreSQL では postgres 、 SQL Server では sqlserver です。
IAM による認証 (自動・手動共通)
Google Cloud の IAM の仕組みで認証できます。
Cloud SQL の該当インスタンスに対して、ユーザーアカウントまたはサービスアカウントを cloudsql.instances.login 権限を含むロールで紐づけることで認証できます。注意点として Google グループや Google Workspace / Cloud Identity ドメイン全体を紐づけることは できません 。
同権限を含むロールは Cloud SQL 管理者 (roles/cloudsql.admin) 、 Cloud SQL インスタンス ユーザー (roles/cloudsql.instanceUser) 等です。
「自動認証」では Cloud SQL Auth Proxy や各種コネクタが IAM 権限を使って認証情報の取得を認証を自動的に行ってくれます。「手動認証」ではアプリケーションのコードで明示的にアクセストークンを取得して、これを使って認証する方法です。
IAM による認証 (自動)
IAM 自動認証を使うためには、データベースへの接続に通常の DB クライアントではなく前述の Cloud SQL Auth Proxy もしくは Cloud SQL コネクタ (Java / Python) を利用します。
IAM による認証 (手動)
手動認証は、自動認証とは異なり、プログラム内で明示的にアクセストークン (DB ログインのための一時的なパスワード。 OAuth 2.0 トークン) を Google API 経由で取得する必要があります。
- ユーザーアカウント / サービスアカウントで gcloud コマンドを実行し Google Cloud へ認証
- ユーザーアカウントの場合 :
gcloud auth login - サービスアカウントの場合 :
gcloud auth activate-service-account
- ユーザーアカウントの場合 :
- コマンド
gcloud sql generate-login-tokenでアクセストークンを取得 - DB クライアントで DB へ接続
- ユーザー名 : ユーザーアカウント / サービスアカウントのメールアドレス
- パスワード : 取得したアクセストークン
コマンド例
gcloud auth login
PGPASSWORD=$(gcloud sql generate-login-token) psql --host=localhost
--username=hoge@example.com
--dbname=mydatabase
メンテナンス
概要
Cloud SQL はマネージドサービスです。 物理マシン、 OS 、 DB エンジンは Google Cloud によって管理されます。
これらに対して、数か月に一度程度の頻度で、ダウンタイムを伴う メンテナンス が必要となります。例として Cloud SQL 自体の機能アップデート、 DB エンジンのマイナーバージョンアップデート、 OS に対するパッチ適用などです。
メンテナンスによる平均的なダウンタイムは 30秒未満とされて います (Enterprise エディションの PostgreSQL の場合)。MySQL と PostgreSQL で利用可能な Enterprise Plus エディションの場合は10秒未満とされています。
設定値
メンテナンスを実施する時間を指定するため Cloud SQL インスタンスには メンテナンスウインドウ (メンテナンスの時間枠) を設定します。
メンテナンスウインドウは 曜日 + 1時間枠 で設定します。例えば「日曜日 01:00〜02:00」のように設定すると、メンテナンスが必要な際にこの時間枠の中でアップデートが実施されます。最もシステムの利用率が低い時間帯に設定するのが望ましいでしょう。
また複数のインスタンスがある場合の更新順序も設定できます。 Any (任意)、 Earlier (早め)、 Later (遅め) から選択でき、 Later は Earlier から1週間遅れて適用されます。
システムの繁忙期等の理由で安定稼働が求められる場合は メンテナンス拒否期間 を最長 90 日間設定できます。これが設定されている期間はアップデートがかかりません。
事前通知
メンテナンスの発生は遅くとも1週間前までに予告されます。 Google Cloud コンソールのインスタンス詳細ページ等から確認可能です。
メンテナンス通知をメールで受け取れるように 設定可能 です。
メンテナンスの延期・即時適用
元々のメンテナンス予定日時から 28 日以内の範囲で、メンテナンスのスケジュールを変更することができます。スケジュールは「次回 (1週間後) のメンテナンスウインドウ」あるいは「任意の日時」に変更可能です。
反対に、予告されているメンテナンスに対して即時実行を指示することもできます。
メンテナンスの仕組み
最初に記載したように、平均的なダウンタイムは 30 秒未満とされています。これはアップデートを短期間で終わらせる仕組みを Cloud SQL がバックエンドで実現しているからです。
特に意識する必要はありませんが、以下のようなプロセスが動いています。
- 裏でアップデート済みデータベースの新規インスタンスが構築される
- 既存インスタンスを停止する
- 新規インスタンスが起動する
ディスクと IP アドレスを新規インスタンスに引き継ぐ
参考 : メンテナンスの仕組み
インプレースアップグレード
メンテナンスではデータベースのマイナーバージョン等に対するパッチ適用がされますが、一方で メジャーバージョンのアップグレード も可能です。
既存 Cloud SQL インスタンスのデータベースのメジャーバージョンをアップグレードすることを インプレースアップグレード (In-place Upgrade) と言います。
インプレースアップグレードでは既存インスタンスが直接アップグレードされるので、インスタンス名、 IP アドレス、データベースフラグ、データなどは引き継がれます。アップグレードにはダウンタイムが伴いますが、通常は 10 分以内に収まります。ただし所要時間はインスタンスの vCPU やメモリ量、データサイズに応じて変化します。またアップグレードの前後にバックアップが自動的に取得されます。
なおインプレースアップグレード以外には、新しいメジャーバージョンの新規インスタンスを構築して、データを移行するという方法があります。
実施の手順や対応しているバージョン等は DB エンジンによって異なります。詳細は以下のドキュメントをご参照ください。
モニタリング・ロギング
Cloud Monitoring によるメトリクス収集
Cloud SQL の主要な指標 (メトリクス) は Cloud Monitoring の機能により自動的に収集されています。収集される指標は多岐にわたりますが、以下は代表的なものです。
- CPU 使用率
- メモリ使用量
- ストレージ使用量
- ディスクI/O
- ネットワークI/O
- アクティブコネクション数
- 秒間トランザクション数
取得可能なメトリクスは DB エンジン (MySQL / PostgreSQL / SQL Server) によって異なります。正確な一覧は以下のドキュメントをご参照ください。
Query Insights
Query Insights 機能で、データベースに対するクエリのパフォーマンスを精査できます (ドキュメントにより Cloud SQL Insights と表記される場合もあります) 。 2022 年 8 月現在は PostgreSQL でのみ利用できます。
利用するには Query Insights を有効化する必要がありますが、特に料金等は発生しません。有効化すると 7 日分の情報が保存されます。
Query Insights では以下のような事項が確認できます。
- データベースの負荷状況
- クエリごとの負荷状況
- 特に負荷が高いクエリの特定、実行計画・所要時間等の表示
またアプリで OR マッパー (ORM) を使っている場合、直接 SQL を記述しないため不可の大きいクエリを特定しづらいときがあります。そのような場合に sqlcommenter というオープンソースライブラリを使うことでクエリにタグ付けをし Query Insights で クエリを特定しやすく することができます。
ロギング
Cloud SQL の各種ログは Cloud Logging に出力されます。 Cloud Logging は Google Cloud のフルマネージドなログ管理サービスです。これにより Google Cloud コンソール画面から直接ログを参照することができます。
例として PostgreSQL であれば postgres.log ファイルの内容等が Cloud Logging に自動的に出力されます。
ログは Cloud Logging の _Default ログバケットに入るため、ログは30日間保存され、料金も発生しません。これ以上の期間のログ保存が必要な場合、新しいシンクを Cloud Logging で作成してより長期間のログバケットへログを格納する必要があります。
Cloud Logging の機能の詳細は以下の記事をご参照ください。
監査
Cloud SQL の 監査ログ は Cloud Audit Logs の機能を通じて Cloud Logging に出力されます。
Cloud SQL に対する「インスタンスの作成、削除、設定変更、起動、停止」のような変更オペレーションは、デフォルトで自動的に記録されます (管理アクティビティ監査ログ) 。
一方で「インスタンス一覧の表示、設定情報の取得」のような閲覧系オペレーションや「 Google Cloud コンソールや gcloud コマンドからの DB ユーザーの作成」のようなオペレーションは明示的に有効化する必要があります (データアクセス監査ログ) 。
Cloud Audit Logs の詳細は以下の記事をご参照ください。
なお、上記は Cloud SQL としての監査ログを指しています。一方でデータベース内部でのデータへのアクセスや変更の履歴等は、 DB エンジンごとの監査ログの仕組み を有効化する必要があります。
例として PostgreSQL では pgAudit エクステンションを 有効化 してログを出力するよう明示的に設定する必要があります。
暗号化
デフォルトの暗号化
Google Cloud ではすべてのデータが ストレージ保存時に暗号化 されています (参考: Google Cloud での保存時の暗号化) 。 これはストレージでの透過的な暗号化であるため、対抗できる脅威は「物理的な持ち去り」などです。
また同様に VPC ネットワーク内を転送中のデータも、自動的に暗号化されます (参考: Google Cloud での転送データの暗号化) 。対抗できる脅威は 「Google Cloud のデータセンター内での盗聴」等です。
追加の選択肢
前述のように Cloud SQL では何もしなくても、データが保存時や転送時に暗号化されています。
「各種セキュリティ監査の対応」「パブリックインターネットでのデータ転送」「 Google Cloud 内部犯行への対策を含むより強固なセキュリティが求められる」などの理由がある場合、以下のような追加の選択肢もあります。
Cloud KMS に暗号鍵を登録することで、 Google が管理する鍵ではなくユーザーが管理する鍵でストレージを暗号化するよう指定できます。通常は Google 管理の鍵で十分ですが、監査上の目的や前述のような理由で自前での鍵管理が求められており、かつ自前での鍵管理が 運用上可能 であるときに Cloud KMS を使った CMEK (顧客管理の鍵) での暗号化を利用します。
詳細は上記の1個目のドキュメントをご参照ください。
また透過的な暗号化では Web アプリやミドルウェアの脆弱性を突く攻撃手法の多くに対抗できません。以下のドキュメントでは Google Cloud サービスの一つである Cloud KMS によって管理された鍵を使いデータをエンベロープ暗号化手法で暗号化したうえでデータベースに格納する手法が紹介されています。
Cloud SQL editions
Cloud SQL editions とは
Cloud SQL for MySQL と for PostgreSQL にはエディションの概念があります。Enterprise と Enterprise Plus エディションが存在し、前者は一般的なユースケースに、後者はより高い可用性とパフォーマンスが求められる場合に利用します。
Enterprise Plus エディションでは読み取り・書き込みの両パフォーマンスが Enterprise と比較して高くなります。公称では Cloud SQL Enterprise Plus for MySQL で「読み取りスループットが最大 3 倍、書き込みレイテンシが最大 2 倍向上」とされます。また可用性 SLA の向上、メンテナンス時のダウンタイムの短縮、トランザクションログの保持期間の長期化など、よりエンタープライズ・レディな仕様です。
エディションはインスタンスごとに選択することが可能で、1つのプロジェクトの中で複数のエディションを併用することは問題ありません。
- 参考 : Introduction to Cloud SQL editions
- 参考 : Cloud SQL Enterprise Plus エディションを発表：新エディションでは MySQL のパフォーマンスが最大 3 倍に向上
Enterprise と Enterprise Plus の違い
それぞれのエディションには以下のような違いがあります。
| 比較観点 | Enterprise | Enterprise Plus |
|---|---|---|
| 料金 | - | vCPU/Memory の時間単価が Enterprise の約1.3倍 |
| DB バージョン | MySQL 5.6, 5.7, 8.0 PostgreSQL 9.6, 10, 11, 12, 13, 14, 15 |
MySQL 8.0 PostgreSQL 14, 15 |
| マシンタイプ | General purpose machine family | Performance optimized N family |
| マシンスペック最大値 | 最大 96 vCPU 最大 624 GB RAM コア:メモリ比 = 1:6.5 |
最大 128 vCPU 最大 864 GB RAM コア:メモリ比 = 1:8 |
| 可用性 SLA | 99.95% | 99.99% |
| メンテナンス時ダウンタイム | 60 秒未満 | 10 秒未満 |
| データキャッシュ | 利用不可 | オプションで利用可 |
| ポイントインタイムログ保持期間 | 最大7日間 | 最大35日間 |
| 書込レイテンシ | - | Enterprise と比較して最大2倍向上 |
| 自動チューニング | - | 基盤に応じて自動チューニング |
| 対応リージョン | - | Enterprise と比較して限定的 (Tokyo は対応) |
データキャッシュ
Enterprise Plus エディションではデータキャッシュが利用可能です。高速なローカル SSD をバッファ領域とすることで、読み取りパフォーマンスが向上します。
データベースはメインメモリ＞ローカル SSD (データキャッシュ)＞ストレージの順にデータを探します。書き込み時には、ストレージへの書き込みとローカル SSD (データキャッシュ) への書き込みを同時に行います。
当機能の利用はオプションであり、インスタンス作成時の設定または作成後の変更が可能です。割り当てた SSD の GB 数に応じて料金が発生します。
以下のような場合に当機能の利用が推奨されています。
- ワークロードがメインメモリに収まらない場合
- 書き込みよりも読み取りが多いワークロードの場合
また MySQL インスタンスでは、インスタンスに 16 コア以上の vCPU を割り当てられている場合にデータキャッシュの恩恵がより受けられるとされています。
料金
Enterprise Plus エディションでは、vCPU とメモリの時間単価が Enterprise と比較して約1.3倍となります。
またオプションで割り当てたデータキャッシュ用ストレージにも、GB あたりの料金が発生します。HA 構成にする場合、スタンバイインスタンスにもデータキャッシュ用ストレージを割り当てるため、倍の料金が発生します。
- 参考 : Cloud SQL pricing
Enterprise Plus への移行
Enterprise エディションのインスタンスを Enterprise Plus エディションに移行するには、gcloud コマンドラインを使います。
gcloud sql instances patch コマンドで --edition=ENTERPRISE_PLUS オプションを指定します。変更には60秒未満のダウンタイムを伴います。Enterprise Plus エディションから Enterprise エディションへのダウングレードも可能です。
- 参考 : Upgrade an instance by using in-place upgrade
- 参考 : Introducing Cloud SQL in-place upgrade: move from Enterprise to Enterprise Plus with ease
その他留意事項
DB エンジンごとの機能差
Cloud SQL では MySQL 、 PostgreSQL 、 SQL Server の3種類のデータベースエンジンをサポートしていますが、エンジンごとに利用可能な Cloud SQL 機能に差があります。
以下のドキュメントでは機能差を一覧表で確認できます。
標準的なデータベースとの違い
Cloud SQL で動作する DB エンジンには、 Cloud SQL ではない通常の MySQL / PostgreSQL / SQL Server との違いが存在します。
いくつかの機能や特殊なコマンドが使えない場合があります。
詳細は以下のドキュメントでご確認ください。
杉村 勇馬 (記事一覧)
執行役員 CTO / クラウドソリューション部 部長
元警察官という経歴を持つ現 IT エンジニア。クラウド管理・運用やネットワークに知見。AWS 12資格、Google Cloud認定資格11資格。X (旧 Twitter) では Google Cloud や AWS のアップデート情報をつぶやいています。
Follow @y_sugi_it