試験で使える!!Cloud SQLの基礎知識（Google Cloud）

初めに

Cloud SQLとはGoogle Cloud（旧GCP）内でMySQL、PostgreSQL、SQL Serverを運用できるマネージドサービスになります。
オンプレミスからの移行の選択肢としても多く採用され、機能も豊富なためRDBMS（リレーショナルデータベース管理システム）としては、まず最初に考える第一選択肢となります。

今回はその基本的な仕組みと機能について、解説していきます。

まず初めにRDBMSの簡単な解説をするので、Cloud SQLの構造から知りたい方は、左にある目次メニューからバックアップ機能を選択して、RDBMSとはを飛ばしてください。

RDBMSとは

まず初学者の方からすると、RDBMS（リレーショナルデータベース管理システム）自体、フワッとした理解だと今後の説明で分かりにくい箇所が出てきてしまう可能性があるので、おさらいをしておきましょう。

簡単に言うと、下記画像のような構造化された表形式のデータになります。（テーブルともいう）
表形式のExcelを例に出すと分かり易いかもしれません。

このような表形式のデータは構造化データとも表現され、基本的にSQL文を使用してクエリを投げることが可能です。（投げる＝検索,消す,更新する..etc）
SQL文を知らない方からすると、意味不明かもしれませんが、このようなテーブル形式のデータは1つだけではない事が多いです。
色々な表形式のデータが連なって、大きなデータベースとして存在しています。

そうなった場合に、何十何百ある表データを目視で見ていて目が10個あっても足りません。
そこでSELECT * FROM usersのようなSQLを表データがまとまったデータベースなどに、クエリとして検索を投げると、その検索結果に沿った形で新しいテーブルが作成され、見たかったデータを作ることができるのです。（SELECT以外にも、テーブルを消したり、アップデートしたりするコマンドが存在します）

RDBMSとSQL文の解説はこの辺にして、次からCloud SQLの機能について触れていきたいと思います。
まだピンときていない方はいくつかのサイトの情報をかけ合わせて理解すると、より深く知ることができるのではないかなと思います。
（RDBMSとは、SQL文とは、でググれば参考になるサイトが山ほどあるので色々と見てみてください）

まとめ

バックアップ機能

まずはデータを守るために不可欠なバックアップ方法について解説していきます。

2種類のバックアップ

バックアップとは何らかの障害などによりデータが紛失した時などに有用に使え、簡単に言うとある時点のデータの状態を保存しておくことになります。

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

オンデマンドは次に紹介する自動バックアップとは逆に手動でバックアップを作成する方式です。
シチュエーションとして、データベース上でリスクの高いオペレーション（操作）を実行しようとしている場合や、自動バックアップで設定した時間枠に関係なくバックアップを作成したい場合などになります。
また、先にお伝えした通り、自動バックアップを有効にして、随時オンデマンドでバックアップするといった併用が可能です。

また、自動的に削除などはされないため、手動で削除するか、インスタンスが削除された時に一緒に削除されます。

自動バックアップ

指定した〜4時間の枠の中で毎日バックアップが行われます。指定したバックアップ時間枠内（〜4時間以内）に開始されます。こちらは、インスタンスの使用率が最も少ない時間帯にバックアップを実行することが推奨されています。

また、インスタンスが停止した場合にも追加の自動バックアップが作成され、停止する前のすべての変更が保存されます。
デフォルトでは、最新の7件のバックアップが保持されます。インスタンスが36時間以上停止されている場合、自動バックアップは停止されます。
デフォルトからのバックアップ数の変更は、1～365の範囲指定することが出来ます。

バックアップの保存場所

バックアップの場所を指定しない（デフォルト）場合にはデフォルトの保存場所として、Cloud SQLインスタンより最も近いマルチリージョンのロケーションで保存されます。

【参考】

たとえば、Cloud SQL インスタンスが us-central1 にある場合、デフォルトでは us マルチリージョンにバックアップが保存されます。ただし、australia-southeast1 のようなデフォルトのロケーションはマルチリージョンのいずれにも該当しません。最も近いマルチリージョンは asia です。

【補足】
・usマルチリージョンに該当する場合のみ
画像では世界中のリージョンに保存されているように見えますが、実際のバックアップ先はusマルチリージョンに該当するリージョンのみになります。

・カスタムロケーションで任意の場所を選択可能
このシュチュエーションとしては、リージョンの選択は国単位となるので会社ごとに決められたデータを扱うポリシーの遵守が必要な場合に、任意の場所を指定する事があります。
このような場合、その会社の組織に組織ポリシーとしてあらかじめ制限することで予期せぬポリシー違反を防ぐ事が可能です。
詳しくは、リソース ロケーションの制限をご覧ください。

まとめ

HA構成（高可用性/フェイルオーバー）

Cloud SQLはリージョンリソースと呼ばれ、各ゾーンごとに分散が可能です。
対照的に、グローバルリソースというのはリージョンを跨いだ分散配置が可能となる使用です。（Cloud Spannerなど）
資格試験などではこの辺の理解も必須になってくるので、ある程度は覚えておいた方が解きやすくなると思います。

高可用性

Cloud SQLにはHA構成という仕組みがあり、リージョン内のゾーン単位でデータを保持しておくことで冗長性の確保が可能となります。
作成したインスタンスが稼働するゾーンをプライマリゾーン、そのインスタンスはプライマリインスタンスと呼びます。
さらに、HA構成で追加されている方のゾーンをセカンダリゾーン、そのインスタンスはスタンバイインスタンスと呼びます。

つまり、高可用性 ＝ 災害時の復旧のための構成、と言い換えることも出来ます。

フェイルオーバー

インスタンスやゾーンに障害が発生した場合、スタンバイインスタンス → プライマリインスタンスに昇格させます。ユーザーは新しいプライマリインスタンスに再転送され、引き続きサービスを使うことが可能です。これを総じてフェイルオーバーと呼びます。

仕組みとしては、HA構成された各ゾーンの永続ディスクへの同期レプリケーションにより、プライマリインスタンスへの書き込みのすべてが両方のゾーンのディスクに複製されることにより、障害時のフェイルオーバーが可能となります。
このディスク自体はリージョン永続ディスクと呼ばれたりします。

また、フェイルオーバー後の動きとしては、プライマリに昇格したインスタンスはそのまま使用され、障害が起きたインスタンスは再作成されます。
フェイルオーバーが発生した時のダウンタイムはおよそ3分ほどのようです。

HA構成とフェールオーバーをまとめた図を載せます。

【補足】
・障害が発生した元のプライマリを使用したい場合にはフェイルバックが可能です。
手順については左記をご覧ください → フェイルオーバーを開始する
・トラフィックはセカンダリインスタンスのとなっても同一のIPでアクセスを振り分けることが可能です。

リードレプリカ

Cloud SQLにはリードレプリカという読み取り専用のインスタンスを作成することが可能となります。
いくつか使い方がありますが、基本的には名前の通りプライマリDBの負荷を軽減する役割を持ちます。
もちろん、プライマリDBには書き込みが発生するので、障害が発生した場合にはサービスに影響があります。
リードレプリカは単にプライマリのデータを複製したものになりますので、ユーザー側のDB読み取りを複数または単一のリードレプリカに分散させることで、プライマリ負荷の軽減の他に、高可用性も確保することが可能となります。

HA構成の料金に注意

スタンドアロン型（1つのインスタンスのみ）の場合と比べて、2倍の費用が掛かってしまいます。料金が発生するリソースとしてはCPU、RAM、およびストレージの料金が含まれます。
（参考：料金のページ）。

まとめ

Cloud SQLへの接続

ネットワーク周りの仕組みを頭に入れておくことは試験には必須の知識であり、Cloud SQL自体を理解する上ではとても重要なものです。
教科書で最初に学んだ時につまずく点としては、自分のVPCの中に作成して運用するのか？という点だと思います。
結論から言うと、Google管理のVPC内に外部IPを利用してアクセスすることになります。

私の覚え方としては、そもそもPaaSというマネージドサービスの位置付けのためGoogle管理のVPCで作成されるんだな~　←このように理解し暗記しました（あくまで覚え方）
次から具体的な接続方法について解説していきます。

外部IPを利用したアクセス

インスタンスのセキュリティを保つため、基本的には重要なリソースには外部IPは付与したくありません（セキュティ攻撃を受ける穴になり得るから）。
ただし用件や環境などによって、パブリックIPをSQLインスタンスに付与する場合には、Cloud SQL Auth Proxyまたは承認済みネットワークのどちらかを使用して認可する必要があります。

このシュチュエーションとして考えられるのは、VPCの要件（ピアリングなどができない）を満たしていないクライアントから接続する場合は、外部IPを使用してインスタンスを構成する場合があります。
よって、当たり前かも知れませんが、次に紹介するピアリングでの接続と外部IPでの接続の併用は可能となります。

また今回は割愛しますがMySQLクライアントを使用して接続する方法もありますので、そちらはURLをご覧ください。

Cloud SQL Auth Proxyについては後ほど詳しく解説するので、ここでは承認されたネットワークについて触れましょう。

とはいいましてもその言葉通りの意味で、インスタンスが持つ外部IPアドレスへの接続は、承認済みネットワークから送信された場合のみ許可されます。
この承認済みネットワークとは、ユーザーが事前に接続する事を許可した、単体のIPアドレスやIPアドレス範囲のことです。

Cloud SQL Auth Proxyを使用しない要件がある場合には、こちらを検討します。

Private Service Access

こちらのアクセス方法としては、プライベートIPを利用してアクセスしたい場合に便利です。
ただ先ほど言いました通り、セキュリティの観点から考えると、基本的にDBサーバーに外部IPを付与するのはあまりしたくありません（もちろん用件により異なる）。

Private Service Accessではピアリング機能を利用して、VPCとVPC間を繋ぐ役割をしてくれます。
ということは、1つの同じVPC内にいるかのようにプライベートIPを使用して他社のVPCと接続したりできるわけです（ここ意外と試験ポイントです）。

少しピアリングに話がそれてしまいましたが、セキュアに閉域な環境でCloud SQLにアクセスした場合にはPrivate Service Accessをおすすめします。

【ピアリングのイメージ図】

【補足】
・画像では他社VPCとの接続を例にしてますが、Cloud SQLの場合も同じ原理です。（Google管理のVPCとピアリングするため）

Cloud SQL Auth Proxy

IAMの認証情報を使用して接続の認証/認可を設定できます。
外部IPを利用した接続になり、最も簡単かつ便利な接続方法となります（セキュリティ的に外部IPをダメと言いましたが、なるべく基本的には、、、というスタンスです）。

ユーザー情報またはサービスアカウントの認証情報を使用して認証認可を行い、Cloud SQLインスタンスへ受信される接続をSSL/TLSラップして接続します（SSL/TLSラップはざっくり言うと通信を暗号化すること）。

よってAuth Proxyは、Cloud SQLインスタンスに通信を渡す中間サーバーとしての機能を果たします。

それぞれのリソースによっては（Cloud RunやCloud Function、AppEngineなど）、Cloud SQL Auth Proxyを使用して接続することが可能です。
詳細については、左記のURLをご確認ください → Cloud SQL Auth Proxy

まとめ

まとめ

今回は、Cloud SQLの基本機能についてまとめました。
その他にも重要な機能がいくつか存在しますので、機会があればまた第2弾としてブログに出来ればなと思っております。
（あまり長くても最後まで読むの辛いですからね、、、笑）

ただ、試験や初学者が押さえておきたいポイントは今回の内容で結構まとまっていたりするので、ドキュメントなどを読み、これは必要だな〜と思えば再度執筆します。
まとめはそれぞれの項目の下に記載しているので、随時確認ください。?‍♂️

最後に

前職が元パーソナルトレーナーであったため、ダイエット情報や筋トレ情報を積極的に配信したいと思っています！！IT＝脳＝運動＝体調管理⇒全ては繋がっています。

【家での筋トレは身/脳を鍛える宝庫】

現在は宅トレ（家筋トレ）期間中なのですが、かなりメリットが大きいのではないかと、強く思います。

その理由について、下記にまとめます。

もっとありますが、とりあえずこんな感じです。

次回はデメリットを紹介します。