Google Cloud(GCP)のリレーショナル データベースサービス「Cloud SQL」について紹介

はじめに

データベースはシステム上のデータの保存場所としてはもちろん、必要な時にすぐに参照や追加、削除、更新ができる仕組みとして欠かせません。近年はWebサイトやショッピングサイト、アプリ、ゲーム、業務システムといった様々なシステムで利用されています。またビッグデータ分析のために必要となる大量なデータもデータベース内に保存されます。

これら多くのシステムで利用されるデータベースですが、クラウドサービスの登場によって格段に利用しやすくなったと言えます。データベースを利用するとなると当然ながらデータベースサーバーの構築が必要となりますが、その際は設計(概念設計・論理設計・物理設計)から始まってサーバー構築を行い、データベースを実際に作成・設定したらテストデータを流し込み正常に動作するかチェックし、本番稼働に適用するという工程が発生します。

これらの工程にはSEやデータベースエンジニア(インフラエンジニア)が携わり、数時間〜数日かけて対応することになりますが、クラウドサービスでデータベースを利用する場合は各サービスで用意された管理コンソール上で希望の項目を選択し、後はたったの数分待てばデータベースの利用が可能な環境が整う仕組みとなっています。

さらにデータベースは正規化やエンティティ、属性、リレーション等の概念を理解するために学習コストを多く費やすこととなり、比較的敷居の高い分野とされた時代もありましたが、現在はそこまで深い知識を持ち合わせていなくてもクラウド上で簡単に運用できるようになりました。

GoogleのクラウドサービスGoogle Cloud(旧・GCP)においても簡単にデータベース環境を構築し、様々なシステムと連携して利用できるサービスが提供されています。今回はそんなGoogle Cloudのデータベースサービス「Cloud SQL」について紹介していきます。クラウドサービスの選定に迷っているという方、Cloud SQLがどのような仕組みであるか、どんなメリットがあるか知りたいという方、クラウドのデータベースサービスについて知りたいという方はぜひご覧ください。

Google Cloud(旧・GCP)について

Googleのクラウドコンピューティンサービスはかつて「GCP(Google Cloud Platform)」という名称で提供されていましたが、2016年にGoogle Apps for Work(以前のG Suite)、Google Cloud Platfor、Google Maps、Androidといった様々な形態のサービスと統合し「Google Cloud」に名称変更されました。GCP自体は2008年にGoogle App Engine(GAE)と共にサービスが開始され、その後数年の間にGoogle Cloud StorageやGoogle Compute Engine(GCE)もリリースされていますが、Google Cloudとなった後もこれらのサービスは引き続き提供されています。

GAEはPaaSの形態を採ったサービスであるので、GCPではIaaSよりも先にPaaSサービスが開始されたということになります。その後にデータ保存に特化したストレージサービスのGoogle Cloud Storage、IaaSの仮想マシンサービスであるGCEが続いた状況です。その間にGoogleの社内ツール「Dremel」を基とした高速なデータ解析サービス「BigQuery」も提供が開始されています。

ここまでだけでもGoogle Cloudでは幅広い分野に対応可能なサービスが提供されていることがわかると思いますが、他にも機械学習モデルを構築できる「Cloud Machine Learning Engine」、ビッグデータ等の大容量データの取得・分析が可能な「Cloud Dataflow」、コンテナ化したアプリケーションのデプロイが可能な「Google Kubernetes Engine(GKE)」等、2023年時点で160以上のサービスがあります。

今回はデータベースサービスとして「Cloud SQL」を取りあげますが、同じデータベースサービスとしてはデータ圧縮機能が備えられた大量データの管理サービス「Cloud Big table」や、高いスケーラビリティが特徴的なNoSQLサービス「Cloud Datastore」もあります。基本的にデータウェアハウスとして「BigQuery」、インメモリとして「Cloud Memorystore」、非リレーショナルとして「Cloud Firestore」「Cloud Big table」、リレーショナルとして「Cloud SQL」「Cloud Spanner」を利用するといった使い分けができること、複数のサービスを合わせて利用することも可能ということを頭に入れておくと、今後Google Cloudでデータベース運用をする際は便利です。

Google Cloudのサービスは全てGoogleの運用するデータセンターで運用されており、日本を含むアジアやヨーロッパ、北米、南米等の各リージョンに配置されています。これらのリージョンを適切に選択することで物理的に近いネットワークの利用による高速化、障害発生時のリージョンを隔てた冗長構成等が可能となります。

また、その他クラウドサービス同様に、Google Cloudも機器の調達や場所の確保をなくすこと、人件費・工数を減らすことによるコスト削減、柔軟なスケーラビリティの実現、クラウドサービス提供元の高度な技術や強力なネットワークバックボーンを利用できるといったメリットを持ち合わせています。一方でクラウドサービスは全てとは言わないまでもそのほとんどが従量課金制となっているため、導入するとこれまでと同じ方法では予算が立てづらくなることでしょう。しかしGoogleでは利用料金のシミュレーションができる「Google Cloud Pricing Calculator」やコストの最適化をサポートしてくれる「Cloud Billing」といったサービスも用意されているので必要に応じて利用してみてください。

Cloud SQLでは何ができる？

Cloud SQLは一言で表すとフルマネージドのRDBMSサービスです。ある程度クラウドサービスを利用している方であればこの一言だけでも多少のイメージが浮かぶかも知れませんが、今回初めてクラウドサービスに触れる方、エンジニアとしての実務が限定的であったり浅かったりという場合はさっぱりということもあるでしょう。まずRDBMSですが、これはオンプレミスでも共通ですが「リレーショナルデータベース管理システム」のことを表しています。

データベースの種類は大きく階層型、ネットワーク型、リレーショナル型、NoSQL型の4つに分けられますが、そのうちのリレーショナルに分類されるデータベースを管理できるソフトウェアのことをRDBMSと呼びます。2023年時点ではNoSQLが次第に普及しているものの、いまだシステムで利用されているデータベースのほとんどがリレーショナルであるため、RDBMSを利用する機会は多いと言えます。代表的なものとしてはオープンソース系でMySQL、Postgre SQL、商用系でOracle Database、Microsoft SQL Server等が挙げられます。

もう一つの「フルマネージド」ですが、この言葉はこれからクラウドサービスを運用するのであれば抑えておいた方が便利な概念です。「フル(全て)」を「マネージド(管理)」してくれるのはサービス側となります。システムを稼働し続けるためには基本的に運用・保守といったSE(システムエンジニア)やインフラエンジニアの業務が発生し、障害が発生した際の復旧対応や、定期・不定期なメンテナンス、日々の監視対応等に時間・人件費がかかります。しかしそれらの全て、あるいはほとんどがサービス側で行われるため、その分開発やその他の作業に専念できるようになります。またサーバー、ネットワークといったインフラに関して熟知したエンジニアがいなくてもシステム運用が可能となります。

今回紹介するCloud SQLにおいても、冒頭で紹介したように運用・保守や環境構築にかかる時間やコストを削減できるという点が大きなメリットとなります。具体的にはインストール作業、バックアップ、アップデート、スケールアップ、モニタリング・ログイング、フェールオーバー、エクスポート・インポート等の作業をCloud SQL側が受け持ってくれます。

Cloud SQLはAWSで言う「Amazon RDS」、Microsoft Azureで言う「Azure SQL Database」が近いサービスとなります。「Amazon Aurora」と同じという説明も見受けられますが、Auroraは正確に言うとRDBMSと共に利用する「データベースエンジン」の一つに分類されるので、この記事では別物として扱います。なお、Cloud SQLではMySQL、PostgreSQL、Microsoft SQL Serverといったデータベースエンジンから選択してデータベースの運用ができます。

またデータベースシステムは単独で利用することがほぼないですが、Cloud SQLもCompute EngineやApp Engine、BigQueryをはじめとした様々なGoogle Cloudと連携してシステムの構築・運用をすることが可能なので、データベースサーバーとして利用することをイメージしてもらえれば問題ありません。

料金体系について

Cloud SQLも料金は従量課金制ですが、確約利用割引という仕組みも適用できます。この割引は1年あるいは3年間の利用をあらかじめ確約しておくことで安く利用できるもので、1年間の場合は25%、3年間の場合は52%までコスト削減が可能(リージョンにかかわらず)となっています。なお、確約利用割引が適用できるのはvCPUとメモリに対してのみということに注意が必要です。また必要リソースの見当が付かない場合は割引とは言え割高になる可能性もあるので、ある程度予測可能な場合に利用するのがおすすめです。

課金の対象はvCPU コア数、メモリ、ストレージ量、ネットワークトラフィック量、割り当てられたIPアドレス数ですが、Microsoft SQL Serverを利用する場合はさらに起動時間に応じたライセンス料が必要となります。Microsoft SQL Serverは他にもMySQL、PostgreSQLのいずれかを利用する場合と1時間当たりの料金が異なるということも覚えておきましょう。ただし最大CPU数が96、最大メモリ容量が624GBという点はどれも共通です。リージョンによっても1時間当たりの料金は異なり、日本のリージョンとしては東京(asia-northeast1)と大阪(asia-northeast2)が利用できる状態です。具体的な料金については変動する可能性もあるため今回は記載しません。詳しく知りたい場合はGoogle Cloud の公式サイト内にある「Cloud SQL の料金」のページをご参照ください。

またvCPUやメモリ量はインスタンス作成時に設定されますが、運用中にインスタンス編集を行うことで変更が可能となります。しかしスムーズな拡張が可能なクラウドサービスではあるものの、これらを変更する際はインスタンスの再起動が必要となるため、計画的に実施する必要があります。

ディスクに関してはHDDとSDDから選択が可能です。一般的に速度やコストを優先させたい場合はSDDを利用し、扱うデータ量が多くスピードよりパフォーマンス性を重視したい場合はHDDが選ばれる傾向にあります。ストレージ容量についてはシステムを停止せずに拡張可能であるものの、一度拡張すると縮小ができないという仕様であるため、十分に今後の状況を考慮したうえで行う必要があります。

Cloud SQLにおける高可用性と負荷分散の仕組み

Cloud SQLには高可用性を実現するオプションが用意されており、インスタンス作成時に選択できるようになっています。これは高可用性構成(HA構成)と呼ばれるもので、プライマリインスタンスの他に別のゾーンへスタンバイインスタンスを準備し、障害等が発生してプライマリインスタンスが正常動作できなくなった際にスタンバイインスタンスへフェイルオーバーさせられるようになります。

プライマリとスタンバイは永続ディスクにおいて常に同じデータが保持できるよう同期レプリケーションが行われているため、ユーザー側からすると普段と何ら変わらずシステムを利用できる状態となります。ただし常に両ゾーンにデータが書き込まれることとなるため、それだけパフォーマンスは落ちるということは頭に入れておきましょう。

Cloud SQLでフェールオーバーが行われるのはプライマリが60秒程度応答がない場合や、Cloud SQLのサービスが停止したことを検知した際となります。ユーザー側が普段と変わらずシステムを利用できると述べましたが、フェールオーバーが行われるまでの短時間においてはサービスが利用できないタイミングが発生します。プライマリで利用していたIPアドレスはそのままフェールオーバー先に引き継がれます。場合によってCloud SQLはフェールオーバーではなく再起動を実施することがあり、この場合は対象インスタンスの「オペレーションとログ」から状況を確認すると再起動のログが残ります。

またプライマリインスタンスが復旧したとしても自動でフェールバックされることはないので、稼働させるインスタンスを元に戻したい場合はフェールオーバー時と同様の操作でトラフィックをプライマリに再転送し、フェールバックを行います。

Cloud SQLも他のGoogle Cloudのサービス同様にSLA(Service Level Agreement:サービス水準合意)が適用されますが、公式サイトには「Googleの合理的な制御が及ばない要因によって発生する停止は除外」となることが明記されています。この制御が及ぶ状態とするために必要な条件の一つにHA構成が含まれ、他にも共有コアインスタンス（db-f1-micro、db-g1-small)、シングルゾーンインスタンスではないこと、ストレージが逼迫している状態を回避することといった条件も定められています。条件を満たしたうえで、あらかじめ定められたダウンタイムを超過するとクレジットの払い戻しが行われることとなります。

リードレプリカについて

Cloud SQLの負荷分散の仕組みで覚えておくと便利なのがリードレプリカです。リードレプリカは通常のものとクロスリージョンリードレプリカの2種類があります。通常のリードレプリカは読み取りのリクエストを負荷分散する目的でCloud SQLインスタンスのコピーを生成します。ただし書き込みのリクエストは受け取れない仕様となっています。元のインスタンスでデータの更新があった場合は非同期で直後にレプリケーションが行われます。

通常のリードレプリカがインスタンス間であるのに対し、クロスリージョンリードレプリカはリージョン間でのコピーが行われる仕組みとなっています。別リージョンにあるシステムからの読み取りリクエストの遅延を防いだり、リージョン間でのデータ移行をしたり、DR(ディザスタリカバリ)の構成にしたりといったことが可能となります。なおDRの際はリードレプリカをプライマリに昇格して運用することとなります。

また高可用性を目的としたHA 構成と負荷分散を目的としたリードレプリカは併用しての構成も可能です。さらに外部レプリカを取り込んだ構成も可能となっており、オンプレミス(パブリッククラウド)配下の各種データベースとのデータ同期も実現できます。MySQLに限っては、Cloud SQLのデータベースを外部レプリケーションとすることも可能です。

バックアップについて

Cloud SQLでは手動、自動(スケジューリング)両方のバックアップに対応しており、インスタンスを止めることなく実施可能です。初回のバックアップは対象インスタンスのフルバックアップとなり、2回目以降は増分のみのバックアップとなります。なお自動バックアップの初期設定状態では7世代分となっていますが、最大365世代までの設定が可能です。システムの停止は発生しないものの全く影響がないとは言い切れないため、極力深夜等の利用者の少ない時間帯に実施することをおすすめします。

リストアに関しては同じインスタンスへのリストア、別のインスタンスへのリストア、ポイントインタイムリカバリのいずれかを選択できます。ポイントインタイムリカバリとは、ある時点のインスタンスの状態を別のインスタンスにリストアすることを表しており、元のインスタンスにおいては特に何も起こらないことに注意が必要です。

Cloud SQLへの接続方法とCloud SQL Auth Proxyについて

近年、データベースには個人情報が格納されることも多いので対応できる限り最大のセキュアな接続をすることが望まれます。セキュアな接続をしたい場合にCloud SQLで利用できる方法がオプションのCloud SQL Auth Proxyです。これを使わない場合Cloud SQLへの接続は、単純にパブリックIPアドレスを公開してインターネット経由で接続するか、VPC(Virtual Private Cloud)経由でプライベートIPアドレスでアクセスするかになります。

Proxyサーバーとはインターネットへ接続できない内部ネットワークから外部へ接続する際に代理(Proxy)として中継してくれる機能を備えたサーバーを指しますが、Cloud SQL Auth Proxyも同様に各アプリケーションからCloud SQL Auth Proxyまでをローカル接続し、そのままCloud SQL Auth ProxyからCloud SQLへ接続できるようになっています。なお、2023年時点でCloud SQL Auth Proxy、Cloud SQL間の通信はTLS1.3と256ビットAES暗号で自動的に暗号化される仕様となっています。

アプリケーションからローカルにあるCloud SQL Auth Proxyへ接続し、Cloud SQL Admin API へアクセスして一時的に利用できるSSL/TLS 証明書を取得し、最終的にCloud SQLとの接続を確立させるという流れです。

Cloud SQL Auth Proxyを利用することでSSL/TLS 証明書を別途管理する必要がなくなり、パブリックIPを利用するとしても承認済みネットワークの追加をする必要がなくなります。ただし接続が承認されるためには、データベース自体のユーザー認証とは別にIAM権限を付与しておかなければなりません。そのため、例えばCompute EngineからCloud SQL Auth ProxyからCloud SQLを経由してCloud SQLへ接続したい場合は、VMにサービスアカウントを紐付け、そのアカウントをIAM権限で承認することになるでしょう。Cloud SQL側でも「cloudsql.instances.login」の権限を持ったロール(roles/cloudsql.admin、roles/cloudsql.instanceUser等)をサービスアカウントに紐付ける必要があります。

まとめ

クラウドサービスはいまや「クラウドファースト」という考えが大々的に謳われているようにシステム運用のあり方として常識的な状態となっています。その中でAmazon、Microsoft、GoogleといったITの大手企業はそれぞれにクラウドサービスを提供しており、世界のシェア率の大部分を占めています。

Cloud SQLは、そんなGoogleの提供するGoogle Cloudに含まれるフルマネージドのRDBMSサービスであり、他のGoogle Cloudサービスと連携して様々な分野のシステム開発が可能となること、コスト削減をしたい場合は深い知識がなくともデータベースサーバーを運用したいという場合にメリットがあること、Cloud SQL Auth Proxyを利用することでより安全な接続が可能となることが今回の記事でわかっていただけたことでしょう。

ぜひ今回の記事をきっかけに、オンプレミス・クラウドのどちらでもデータベースを自在に扱えるデータベースエンジニア、クラウドエンジニアを目指してみてはいかがでしょうか。