こんにちは！
BFT名古屋支店の佐野です。
今回は佐野が勝手に進めるブログプロジェクト「GCPクイックスタートガイド」の第８回です。
前回はGCPで基本的な仮想マシンを作成するGCEについて解説しました。
今回はGCP上においてデータベースの役割を担うGCPサービスについて解説します。
GCPにおけるデータベースサービス
GCPでデータベースを扱うサービスは、大きく分けてBigQueryとCloud SQLがあります。
そのふたつは以下の通りそれぞれ異なる性質を持っているので、比べることはあれど、単純比較でどちらが優れているかではなく、ケースに応じて合う方を選択するようにします。
フルマネージドなリレーショナルデータベースサービス、Cloud SQL
GCPによるフルマネージドなリレーショナルデータベースを作成できるサービスがCloud SQLです。
フルマネージドなので、リレーショナルデータベースとして必要なソフトウェアはすべて用意された状態のデータベースを作成でき、またセキュリティパッチ適用を始めとしたソフトウェアアップデートやレプリケーション構成設定、バックアップ設定といった運用要素はGCPによって管理され、自動で行われます。
2024/2/26現在ではMySQL、PostgreSQL、SQL Serverの３つのデータベースエンジンのいずれかを載せて作成でき、接続可能なネットワークを敷いていれば作成直後からすぐに利用できます。
またGCPサービスのひとつなので、GCPの他のサービスとはシームレスに統合が行えるため、クラウドネイティブなシステムのひとつとして違和感なく組み入れられますし、例によって従量課金制であるため、コストの最適化を行ないやすいGCPサービス共通の長所も持っています。
なお他のクラウドサービスにおける類似のサービスとして、AWSのRDSがあります。
データウェアハウス型のサーバーレスデータベース、BigQuery
BigQueryはGCP上で利用できるデータウェアハウス型のサーバーレスデータベースです。
Cloud SQLとは根本的に違い、Cloud SQLはリレーショナルデータベースの仮想マシン（インスタンス）を作成しますが、BigQueryは既にGoogleが用意したデータベース（の一部）を借りてデータの処理を行なってもらうような形を取ります。
というのもBigQuery自体は元々Google社内で用いられていたDremelというビッグデータ解析システムを一般向けに公開したもので、利用者がBigQueryに格納したデータに対してSQLクエリを実行し、データを分析するというサービスを提供します。
そのためBigQueryはデータベースインスタンスを作成するサービスではなく、ビッグデータの分析やクエリ処理を支援するためのプラットフォームとして機能するサーバーレスサービスなのです。
BigQueryが何より優れている要素はそのパフォーマンスです。
BigQueryの元となったDremelはGoogle検索や膨大な数のユーザーが存在するGmailのデータ解析に用いられていると言われており、数テラバイト、数ペタバイト規模のデータに対するクエリも数秒もしくは数分で完了できると説明されています。
その上でコストも安価であると評されることが多く、メリットであるとされます。
BigQueryも例によって従量課金となっていますが、課金の対象となる要素は利用ストレージ量、クエリの処理量が主で、リアルタイムのデータ収集を行なう場合には収集したデータをテーブルにインサートした量に対して課金されるものの、逆を言えばその３つのみとなっています。
またBigQueryは毎月1TB分のクエリ処理が無料であるため、ストリーミングインサートを積極的に利用しないなら費用は低く抑えられるのです。
そのように優れた処理能力を低コストで発揮できるBigQueryですが、分析に特化しているため、例えば大量のトランザクション処理やリアルタイムのデータ更新など、データの記録や登録、更新を目的としたデータベース活用をしたい場合には向いていません。
また圧倒的な処理速度を有するためビッグデータ分析には最適ですが、小規模なデータ分析を頻繁に行なうという場合にはオーバースペックと言えます。
BigQueryは幅広い自動スケーリングが可能ですが、今挙げた用途でデータベースを利用したい場合はCloud SQLでリレーショナルデータベースを作成した方がよいかもしれません。
結局どっちをどのケースで使うのか
まずもってデータを保存したい、という要件があるならCloud SQLを選択します。
加えて小規模なトランザクション処理やリアルタイムなデータ更新が見込まれる場合もCloud SQLがよいでしょう。
さらに単純なSQLクエリや小規模なデータの分析でも、Cloud SQLを使った方がよいとされます。
BigQueryを用いるのは大規模なデータセットやビッグデータの分析のみと覚えておけばおおよそは問題ないはずです。
BigQueryのさらなる解説は長くなるため、以降はCloud SQLでのデータベースインスタンス作成のみに絞って解説します。
（BigQueryの利用方法や利用例は別記事にて解説します）
Cloud SQLでリレーショナルデータベースインスタンスを作成する
では実際にCloud SQLコンソールからリレーショナルデータベースインスタンスを作成する手順を作成画面を踏まえて解説します。
また今回も筆者主観で特に作成画面において抜けやすい点をしっかり見ていきます。
リレーショナルデータベースインスタンスの作成はナビゲーションメニューから「SQL」を選択し、コンソール上の「インスタンスを作成」から行えます。
まず最初に作成するデータベースのエンジンを選びます。
先に述べた通り2024/2/26現在は、MySQL、PostgreSQL、SQL Serverの中からデータベースエンジンを選ぶことになります。
使用したいデータベースエンジンの「（データベースエンジン名）を選択」を押下しましょう。
本記事では、ここでPostgreSQLを選択しています。
データベースエンジンを決めると、GCEインスタンスを作成した時のような画面になります。
その最初の項目として、インスタンスを識別するためのインスタンスIDと、データベースエンジン毎に設定された管理ユーザーのパスワードを設定します。
エンジンがPostgreSQLの場合、管理ユーザーは「postgres」です。
またその他、データベース上で作成されるユーザーのパスワードの設定ポリシーをここで決めることもできます。
「パスワードポリシー」を展開し、「パスワードポリシーを有効にする」にチェックを入れるとパスワードポリシーに関する項目が表示されます。
加えて各項目にチェックを入れると、具体的なポリシーや数値を入れることが可能です。
インスタンスIDと管理ユーザのパスワード設定の後は、データベースエンジンのバージョンとデータベースインスタンスに適用するCloud SQL エディションを選択します。
Cloud SQL エディションはデータベースインスタンスに提供される機能とサービス、およびそれらの範囲を定めた料金プランです。
エディション毎の主な差異は、SLAとして保証する稼働率や利用可能なマシン、データキャッシュ機能の有無が挙げられます。
例えばEnterpriseエディションにおけるSLAは99.95%ですが、Enterprise PlusエディションであればSLAが99.99%になります。
本番システムで実用する場合は機能と保証が充実しているEnterprise Plusエディションの方が良いですが、Enterpriseエディションと比べ料金が増えるため、稼働や性能を担保する必要のない、検証用のような重要度の低いデータベースはEnterpriseエディションでの利用を検討しましょう。
またデータベースインスタンスの性能がある程度決められたプリセットをここで選ぶことができます。
あくまでプリセットであるため、この後に出てくる項目でデータベースインスタンスの性能は調整することができます。
その次にある設定項目はデータベースインスタンスを配置するリージョンおよびゾーンについてです。
リージョンについてはシンプルに何処のリージョンを利用するか選択するのみですが、ゾーンの設定では「シングルゾーン」と「複数のゾーン（高可用性）」の選択肢があります。
シングルゾーンはひとつのゾーンのみにデータベースを置く形となり、障害などによって停止した際にもフェイルオーバーが行われないため、低コストではありますが本番用として耐えうる可用性は持たなくなります。
複数のゾーン、つまりマルチゾーンの構成はふたつのゾーンにデータベースを配置するためコストは多くなりますが、もし片方のゾーンにあるデータベースが障害などで停止した場合には、もう片方のゾーンにあるデータベースにフェイルオーバーが行われ、システムの稼働を継続できます。
このため本番環境に利用するなら複数のゾーン、検証用であるならシングルゾーンとしておくのがコストと可用性の面で効率的です。
また複数のゾーンを選択した場合、データベースを置くゾーンを細かく指定することができます。
本番用のシステム構築では「特定のゾーンのみを利用したい」要件が出ることもありますが、そういった場合にはここで利用したいゾーンを指定することで対応できます。
ここからは「インスタンスのカスタマイズ」に内包されている項目となり、「インスタンスのカスタマイズ」を展開すると表示されます。
「インスタンスのカスタマイズ」内の項目として最初にあるのが「マシンの構成」で、そこでデータベースインスタンスのマシンシェイプを選択できます。
ここでいうマシンシェイプとは、簡単に言えばデータベースインスタンスの構成であり、同時に性能を表すものです。
表示されているvCPUとメモリの組み合わせ（マシンシェイプ）からひとつを選びましょう。
ここで選択できるマシンシェイプはCloud SQL エディションで選択したエディションによって異なります。
また「マシンの構成」ではデータキャッシュの有効／無効を設定できます。
次に「ストレージ」を展開し、データベースインスタンスに利用するストレージの種類と容量、そしてデータベースインスタンスの暗号化方式を設定します。
ストレージの種類はSSDかHDDのどちらかを、ストレージ容量はプリセットされたうちのどれかか、カスタム値を設定できます。
容量がひっ迫した場合に自動的容量拡張を行なうかの設定もここで行なえます。
暗号化の設定ですが、暗号化自体はデフォルトでGoogle管理の暗号鍵によって行われる設定になっています。
もし独自の暗号鍵を使ってデータベースインスタンスの暗号化を管理したい場合は、ここで設定を行ないます。
次に「接続」を展開し、データベースインスタンス自体に割り当てるIPの設定と、データベースインスタンスに接続可能なネットワークの指定を行ないます。
データベースインスタンスにはプライベートIPとパブリックIPのふたつのIPを割り当てられます。
デフォルトはパブリックIPのみ有効で、プライベートIPを有効化する場合はデータベースインスタンスを含めるVPCを指定します。
またVPC指定後、データベースインスタンスに割り当てるIPを設定できます。
プライベートIPを有効化すれば、VPC内のインスタンスなどからデータベースインスタンスへの接続が可能になります。
パブリックIPのみの場合、データベースインスタンスへの接続を認めるネットワークを指定する必要があります。
承認済みネットワークの「ネットワークの追加」を選択することで、新たにデータベースインスタンスへの接続を承認するネットワークを追加できます。
次にある「データ保護」では自動バックアップの実行設定とその実行タイミングの調整が行えます。
またバックアップの保存数、そしてバックアップの保存先リージョンの設定もできます。
特に保存先リージョンについてはデフォルトだとマルチリージョンとなっており、その状態だとどのリージョンにバックアップが保存されるか分かりません。
データの保存先は必ず国内に限る、のような要件がある場合に引っ掛かりポイントになるため、そういった要件がある際はチェックしておきましょう。
またデータベースインスタンスの削除保護設定もここで有効／無効を選択できます。
次の「メンテナンス」ではデータベースインスタンスへの自動メンテナンスが行われる時間を調整できます。
ピークタイムを避けた時間帯を設定しておくことで、本番稼働時の不意なダウンを避けられます。
また期間を指定してメンテナンス自体を拒否する設定も可能です。
ここまでくると、残りの項目が「フラグ」「Query Insights」「ラベル」の３つになっているはずです。
このうち重要なのは「フラグ」であり、データベースエンジン内の設定を操作できます。
なお具体的なフラグの内容についてはデータベースエンジン毎によって異なるため割愛します。
また「ラベル」にて「ラベルを追加」を選択すると、データベースインスタンスに与えるラベルを作成・追加できます。
このラベルは主にデータベースインスタンスの管理や識別を容易にするために用いられるもので、特に複数のデータベースインスタンスを区別し、管理する際に使われます。
ラベルの付与は必須ではありませんが、必要に応じてつけておくようにしましょう。
以上をすべて設定し終えたら、最下部にある「インスタンスを作成」を選択するとデータベースインスタンスの作成が始まります。
作成には5分程度かかりますが、作成完了するとSQLコンソール上のインスタンス一覧に表示されます。
区切り
これでデータベースインスタンスを作成し、GCPで構築するシステムに組み入れることができると思います。
もし既に踏み台となるインスタンスがあったり、承認済のネットワークからアクセス可能な場合は一度接続確認をしてみるとよいでしょう。
実際にデータベースインスタンス作成後の接続確認の実施やシステムとの組み合わせ等々は今後の記事で扱っていきます。
次回は本記事の続き、BigQueryの使用方法と使用例について解説していきます。
【次回】
Coming Soon...
【前回】
