ホーム
お役立ち
Google Service
第2/3回「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポート

第2/3回「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポート

AlloyDB
PostgreSQL
RDB
データベース

公開年月日: 2023.02.21

更新年月日: 2024.09.26

第2/3回「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポート

本記事は、2022年11月9日に開催されたTOPGATE Broadcaster「2022年 Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説！」において、株式会社トップゲート代表取締役CTO 飛鳥真一郎と株式会社G-gen 執行役員 CTO / クラウドソリューション部部長杉村勇馬が登壇した Special Webinar のセミナーレポートの全3回シリーズの第2回目となります。

今回の記事では、 Google Cloud のデータベースでどんな観点で選べば良いのかというところと、「 AlloyDB 」と既存サービス Cloud SQL や Cloud Spanner との違いをご紹介しています。ぜひ、最後までご覧ください。

また、前回の記事は以下よりご覧ください。

第1/3回「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポート

それでは、早速内容を見ていきましょう。

データベース選定

杉村：続いてデータベースの選定という観点で Google Cloud ってたくさんデータベースありますが、どんな観点で選べば良いのかというところをトップゲートの飛鳥さんに解説していただこうと思います。

飛鳥：Google Cloud のデータベースに RDB だけでも、今回この AlloyDB の登場によって3種類の製品が登場しました。さらに昨今クラウドネイティブな開発のシーンの中では、Flutter や Firebase のような製品から入られた方は、NoSQLの製品についても利用されているというケースも珍しくなく業務システムで利用されていることもあります。

昔から BigQuery も利用が盛んだった分野ですが、この中から自分が作りたいシステムは一体どのデータベース製品を使えばいいんですかというのは、わりと選択肢が増えること自体は嬉しいですが、迷うところも出てきたということが嬉しい悲鳴も出てきました。

例えば、選択の仕方の観点の中で Cloud SQL についていうと、元々 Google Cloud で動作させる前から既にRDBベース、 PostgreSQL 、 MySQL 、SQLサーバー等でシステムがあったものをクラウドリフトアップという形で Google Cloud にのせましょうという時には、最も互換性が高い Cloud SQL が推奨されます。PostgreSQL を AlloyDB もサポートしてますよねっていうのもありますが、サポートしているバージョンの数が違います。Cloud SQL は古いバージョンも含め PostgreSQL を幅広くサポートしていますが、AlloyDB では最新の PostgreSQL のステイブルバージョンをサポートしていますので、場合によっては動かない機能等があるかもしれないところから、クラウドリフトアップといったところでは、最も Cloud SQL が対応できるシナリオが多いかなと思います。

あえて AlloyDB を利用するといったときにどういうシーンがあるかといいますと、例えば、AlloyDB は正式リリースがされた暁には SLA の9が1個増えるという風に言われていまして、よりミッションクリティカルなシーンやユーザー数が多く、ダイナミックに性能をスケールアップしたりダウンしたりみたいなことをユーザーが利用している時間帯にも行わなければならないようなスケーラビリティ Auto ML 。システムの中でもダウンタイムも短く適用ができるのも特徴の一つにしておりまして、あえてゲームの分野などであれば Cloud Spanner まで置き換えるかというとなかなか Cloud Spanner の上で開発することができる頼り切る開発者というのが現状多くない状態から鑑みても AlloyDB は良い選択肢になり得るのではないかとなとこのように考えることができると思います。

BigTable や Firestore のような NoSQL をあえて採用しようというシーンにおいては、利用する方も情報をたくさんお持ちだと思いますから、特に NoSQL 使うか RDBベースを使うかといったところで大きく迷うことはあまりないかなと思います。あえて違いがあるという風に言いますと、Firestore でも確かに RDBベースで実装するようなシステムをトランザクション機能等を実装しているので作ることはできますが、ここはテーブルの設計であったり、性能設計、実現するためのアプリケーションレイヤーからデータベースレイヤーまで広く、NoSQL での開発の知見を求められているというところでなかなかこうチームの組成といったところや教育のコストといったところから、そこが障壁になるというところもあり、その点で AlloDB と、NoSQL のどちらでといったところについては差別化があるかなとといったところがございます。

もう一つアナリティクスの BigQuery をこの中にあえて掲載しています。その理由として、 AlloyDB は分析の機能が普通の PostgreSQL を GCE（ Google Compute Engine ）環境で動かす場合に比べて、100倍早いと言われているためです。これまで BigQuery にデータを流してから大規模分析しましょうというようなシステムについて、今後は AlloyDB 単体で分析できるということが考えられます。 AlloyDB から BigQuery のデータ清掃のバッチ処理だったり、リアルタイム処理だったり、分析のための BigQuery の集計プログラム等を作ったり、集計先の中間テーブルだったり、集計結果のレポートの帳票の設計をやってたところが AlloyDB のリードレプリカに関して、直接集計クエリを投げればダッシュボードのようなものを実装できるとなれば、これは開発コストの観点からすごくリーズナブルになることが見込めます。そういった意味で対抗できる BigQuery を載せさせて頂きました。

AlloyDB を使ってないケース、かつメインのストレージとして別の何か使っている状況で、そのデータ分析が BigQuery か AlloyDB かといった選択する場合においては、専用で分析チームを組む場合に新しく DB を使う場合は、BigQuery が多いと思いますが、メインの元々 AlloyDB に持っているような設計のアプリケーションであれば、分析機能のためだけに BigQuery を併用しなくてもいいところがある。十分ケースによってはあり得るといったところが言えると思います。

■関連記事

AlloyDB vs Cloud SQL

杉村：今のご説明でインターフェイスが PostgreSQL で Cloud SQL と同じですが、よりミッションクリティカルなサービスがなんかにも良いんじゃないかというところがありましたが、そういった意味で AlloyDB と Cloud SQL ってインターフェースの面でみると、似ていると、どっちを選べばいいんじゃという人もいるかと思いますので、表にしてまとめてみました。

ここは私と飛鳥さんで説明していきたいと思います。

これを上から見ていきますと、一番左に観点というのがあって性能、運用、料金それぞれにさらに細かく観点があって、それぞれ Cloud SQL だとどう？ AlloyDB だとどう？なのかという表になっております。

一番上のトランザクションワークロードの性能、普通のデータベースからテーブルをロックして読み書きをする。整合性のある読み書きをする性能ですが、Cloud SQL は標準のPostgreSQL 相当といってよくて、AlloDB は標準の4倍高速ですということをいっております。

ではまた、一方その下分析、例えば集計とかが入るような性能だと Cloud SQL って普通のPostgreSQL なので行指向データベースなのでそんなに得意じゃないような処理もあるという中、AlloyDB は100倍高速ということをいっています。

この辺りについて飛鳥さん的にお考えとか、こうなんじゃないかってありますか？

飛鳥：この根拠となっているところをみなさんすごく関心を持たれるところかなと思いますが、アーキテクチャとして製品紹介のところで解説させていただいた通り、Google が Google Cloud の上で動かすという前提で、かなりフルスクラッチに近いような形で、リホストではなくてアプリケーションを改めて作り直していますよと言ってから、それは性能がよくなるということは当然そうですよねということは一定理解ができようかというところ。これが自社自身が作ったアプリケーションによって思ったようにちょうど4倍の性能かというとそれはケースバイケースということがありますから、もし動いているものの検証を依頼したいというお話があればトップゲート社の方でご相談いただければそう言ったご相談は当然のることもできます。

また分析ワークロードの性能が高いというところがかなり100倍と、攻めの数字が記載されていますが、ここがまさにダッシュボード機能のような通常はバッチで更新しますとか、そういうようなリアルタイムに分析がというのは、なかなか実現するシステムって作るのが難しかったりしますが、BigQuery もユーザーの画面にレスポンスを表示できるようなレスポンスタイムなのかというと、10秒20秒と普通のWEBのアクセスであればタイムアウトする時間で結果がかえってくるということもあると鑑みれば、ここの分析ワークロードの性能によって、今までなしえなかったユーザー体験が可能になるようなものも場合によってはあり得るかもしれないって言ったところが期待値としてあるかと思います。

杉村：はい、ありがとうございます。

続いてその下に行くと SLA というところ。Cloud SQL は Google の SLA としては99.95%。年間停止時間にするとおよそ4時間。これに対して AlloyDB で今ドキュメントで出ているものですと99.99%というのが書いてあって、これは年間停止時間が1時間以内というようなものになっているので製品版の時、またどうなるかなんですけど、より高いミッションクリティカルなサービスにも対応できる SLA を提供しようとしていることがわかります。

その下のインターフェース、これどちらも PostgreSQL 互換で、やはり対応しているバージョンの違いはあれど、どちらもアプリケーションを絡めた同じ PostgreSQL としてみれるというようなことだと思います。

続いてその下、運用面的なところにいきますが、ストレージ、Cloud SQL は手動で拡張が可能です。減らすことはできないんですけど、増やすことはできる。事前にCloud SQL インスタンスには 100GB のストレージをつけようと事前に指定して、足りなくなったらポチッとおすと増えるというようなことが可能です。

一方で AlloyDB の方はこれも拡張とかも意識することもなく、実際に使用したストレージのボリュームに対して課金がかかるということで、 Cloud SQL よりさらに柔軟性がましているというようなところになっています。

飛鳥：ちょっとだけ補足させていただくと、 SLA は計画停止を含めるか含めないかという考え方でちょっとだけ違いがあって、 AlloyDB では99.99という数字で、さらに計画停止も込みでこの数字ですよという風に謳われているということと、 Cloud SQL 計画停止等については別で不測で止まる時間がこの時間以内で保証されていますというところと、ストレージなんですけども、下にこのコストのGBあたりの料金が0.17ドルのストレージで、 AlloyDB の場合は0.3という風に記載されているんですけど、 Cloud SQL はリードレプリカの数に応じて使用している容量は全部トータルでコストが計算されます。ですが、 AlloyDB はいくつレプリカがあるかとみたいなことを意識せずに書き込んで保存しているデータ容量に対してのみ、課金がかかるということで、実際に運用してみると、この値段が1.何倍、2倍まで行かないけれども結構高くなるようにみえますが、課金の考え方がちょっと違うというところで、実際に使ってみると、ちょっと課金の計算の仕方が違うので AlloyDB の場合には思った以上に、 Cloud SQL より料金が高くなることは、数値でこの比の場合、そのままかかるわけではないと言ったところがあります。

杉村：ありがとうございます。 Cloud SQL はリードレプリカのインスタンスをたてると、ストレージも2倍かかる。 AlloyDB だと2倍かからない。もう一個のストレージをみにいくと、いうところですよね。たしかにそう考えるとストレージ料金も安くなる可能性もある。

その下にスケーラビリティ、スケールアップとスケールアウト。スケールアップが一個のインスタンスをさらに大きくする。縦に伸ばすというところ。スケールアウトはリードレプリカインスタンスを増やして、台数を増やして、横に伸ばす概念です。スケールアップに関しては、1個のサーバーのスペックを上げるわけなのでダウンタイムを伴います。 Cloud SQL の場合は通常30秒以内。 AlloyDB の場合は通常10秒以内と書かれていて、これと若干 AlloyDB の方がここは早くなっているように公称されています。スケールアウトの方ですけども、これどちらも似ていて、リードレプリカによる読取ワークロード分散ということで、読取専用のインスタンスを複数つくる。だからさっき言ったようにストレージの料金というのは AlloyDB の場合はいくら増やしても料金は増えることはないということがございます。

その下、パッチ適用というところもこれも似ていて、ダウンタイムを伴うが、 Cloud SQL は30秒以内、 AlloyDB の方は30秒以内というようにいわれています。ちなみにこの裏の仕組みですけども、どうもインスタンスを止めて再起動している動きをしているわけではなく、ホットフェールオーバーという仕組みを使って、裏でバージョンアップされたインスタンスが立ち上がって、そっちに切り替えているという動きをしているというような仕組みになっています。ホットフェールオーバーと表現されていますね。

その下のバックアップですが、 Cloud SQL も AlloyDB もどちらも自動バックアップの機能があり、増分バックアップでバックアップを取る。必要なときにインスタンスにリストができるというようなものになっています。

杉村：料金のところは後ほど議論になるかもしれませんが、ここで見比べて頂くと AlloyDB の方が若干単価が高いようになっていることがわかると思います。

ストレージは先ほど話した通りリードレプリカが増えても AlloyDB の方は倍々になっていかないというようになっています。

まとめ

本記事では、株式会社トップゲート代表取締役CTO 飛鳥真一郎と、株式会社G-gen 執行役員 CTO / クラウドソリューション部部長杉村勇馬が、Google Cloud のデータベースでどんな観点で選べば良いのかというところと、「 AlloyDB 」と既存サービス Cloud SQL や Cloud Spanner との違いをご紹介いたしました。

次回は登壇者同士のディスカッション、そして質疑応答を交えながら AlloyDB のご紹介していきます。

ぜひ次回の記事もお楽しみにお待ちください。

次回の記事は以下よりご覧ください。

第3/3回「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポート

また、前回の記事は以下よりご覧いただけます。

第1/3回「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポート

Google Cloud のリレーショナルデータベース（RDB）は、 Cloud SQL 、 Cloud Spanner に加え、今回の AlloyDB の登場によって3種類の製品が登場しました。

本記事を参考にして、ぜひ AlloyDB for PostgreSQL 、そしてGoogle Cloud （GCP）のデータベースサービスの導入を検討してみてはいかがでしょうか。

弊社トップゲートでは、Google Cloud（GCP）の専門的な知見を活かし、ビジネスコンサルティング、デザイン、開発、保守・運用など幅広くあなたのビジネスを加速させるために、サポートをワンストップで対応することが可能です。

Google Cloud（GCP）の導入をご検討をされている方はお気軽にお問い合わせください。

お問い合わせはこちら

メール登録者数3万件！TOPGATE MAGAZINE大好評配信中！

Google Cloud（GCP）、Google Workspace（旧G Suite）、TOPGATEの最新情報が満載！

メルマガ登録はこちら

登壇講師

スピーカー

株式会社トップゲート代表取締役CTO

飛鳥真一郎

【経歴】

2017 年よりサーバーレスアーキテクチャ（ Google App Engine や Datastore など）を全面採用したシステム開発を中心に行い、インターネットサービスだけでなくさまざまな業界の業務システムや BtoB 向けの領域でも活用を広げています。近年は新規事業立ち上げ時に技術アドバイザーとして参画し、事業展開の初速やその後の成長を支えるシステム基盤としてサーバーレスの導入を積極的に推進しています。