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

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

AlloyDB
PostgreSQL
RDB
データベース

公開年月日: 2023.02.21

更新年月日: 2024.09.26

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

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

今回の記事では、登壇者同士のディスカッション、そして質疑応答を交えながら AlloyDB をご紹介しています。ぜひ、最後までご覧ください。

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

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

ディスカッション

杉村：ここまで来て、色々ご説明しましたが、実際 AlloyDB を使って見たりしてるかと

飛鳥さんの方で思いますが、このあたりお気づきのところなどありますか？

飛鳥：今まで実際 AlloyDB の導入を検討している複数のプロジェクトは社内にありますが、かつ例えば、例示した場合に普通の業務システムでも、そこまでミッションクリティカルなものというか Cloud SQL や AlloyDB でもどちらでも動くので、あんまり積極的に「AlloyDB に置き換えましょうね。」とはなりづらい。

では、どういうものであれば AlloyDB に対して優位性があり、おすすめですよと話ができるかというと BtoB の SaaS や BtoC のサービスのような外の利用されるクライアントの方（エンドユーザー）が自分の好きなタイミングで好きなように使いたいというシステムはSLA の高い方が望ましいですし、ちょうどダウンタイムの話が出ていましたけれども、急にユーザーが増えて来たときに、それに対応できるようスケールアップの操作をダウンタイムをあまり気負わずにできるような仕組みが望ましい。だからと言って NoSQL でフルスクラッチで作り直すには、莫大なコストや期間がかかる事から AlloyDB にまず移して、そういったことが柔軟にできるようにしましょうねと、こういった話は割と出てきがちである。ここのスライドの中でも記載させていただいている通り、特にそういった内容が顕著なものとしてはチケットの販売システムみたいなものもあります。

例えば、日本のアーティストでもめちゃくちゃ人気の高いアーティストの方のチケット販売って、結構画面が止まるとか、エラー画面になるというご体験された方もいらっしゃると思いますが、これは作るのが結構大変です。1つの講演のチケットを抑えに行くといったときに書き込みの性能に対して、凄く負荷がかかりますから、そこはどうやって解消するのかシステムの作り方にも知恵が必要な部分だったりします。元々の書き込み性能が上げられるというところでいくと AlloyDB は望ましい。

さらに、大物のチケットの販売が行われる当日にスケールアップするとか終わったら落とすとか。といったことができないと常に365日負荷が高いわけではないので、当然終わったらそれを利用しているサーバーのコストを負担している側としては、通常の平常時に戻したいわけですね。

そういった操作をするときにすごくダウンタイムが長いとユーザー側にエラー画面をかえしてしまうので、そういった意味でダウンタイムを短くスケールのアップ、またはダウン構成変更といったことがしやすい AlloyDB は向いてるといえるだろうと言えます。

それ以外にも BtoC 、 BtoB の領域におきましてもユーザー数が増えてくれば当然性能はアップさせたいところです。。一旦こういったシチュエーションに対して AlloyDB は応えることができるだろうというところがあります。

今色々検証しているところでありながらも現在正式サービス前といったところから、出てきた検証結果通りの性能が全く同じものが将来に渡って利用されるかどうかというところもありますから、なかなか数値として全てをお話しするのは難しいのですが、確かにCloud SQL の PostgreSQL に対して性能面で優位性があるといったところが、どちらの方でも確認ができてるところでございます。

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

やはり AlloyDB vs Cloud SQL という観点でみたときは、割と重いワークロード、激しいワークロードがあるインターネットサービスみたいなものが結構見えてくると。

飛鳥：高い信頼性、または性能どちらかで高いものが求められるケースにおいておすすめといったところがあるかなと思います。

もうちょっと踏み込んだ話をするとデータベースにいったいどれだけ月額お金かけますか？といったときにそこそこ金額が見込めるようなシステムの規模感というのもあるかなと思っていまして10万円、20万円ぐらいのデータベースに対して、ミニマムでも大体月にコストがかかるといったことが許容できるぐらいのシステム規模から検討が走るというところで、規模が少ないうちにおいては、一旦 Cloud SQL からスタートするといったところが無難かなとここも目安に入れて頂けばと思います。

杉村：そうですね、若干 Cloud SQL よりコストがかかる、金額がかかるところでですので、そことの・・・

飛鳥：そうですね、スタートラインが割と高めです。これも将来的に Cloud Spanner もそうですけど料金改定されたり、安いプランから1/10からスタートできるようになったりとかあるので、将来そこの敷居は下がってくることはあると思いますけど、現状においてはそういったところでしょう。

杉村：なるほど、ありがとうございます。以上になります。

質疑応答

Q1. WAL logs ではレプリカに同期する仕組みをとっていますが、他社サービス（ Amazon Aurora ）に比べての優位点を聞きたい。

A.杉村：レプリカに同期するという観点で優位点というところですが、やはりちょっと仕組みの違いということがありますし、厳密にベンチマークをしないとわからないですし、どんなワークフローにするかによって変わってくるので、なんともここが優位点です。というのは言いづらいかなという風に思ってます。

杉村：ここはなんともということありますが、Aurora に比べての優位点という意味で言えば、単純にレプリカとかに限らず、 Aurora の優位点と言えるのは AlloyDB の方が「BigQuery にデータを連携したいです。」とかそういうときに Google Cloud のネイティブとの統合性が高いので、そういったところで、サービス関連系という意味だと確実に AlloyDB の方が強いのかなと思ったりしますね。

Q2. 現在プレビュー版とのことですが、いつ一般提供版になるか情報がありましたら教えていただきたいです。

A.飛鳥：こちら公表されているもの以外の情報は中々お話しづらいところもありまして、一般提供の前に GA（General Availability）等の期間が入ったりしたりするんですけども、こういったアナウンスを希望の個人・会社問わず方がいらっしゃいましたら、是非とも本日アンケートがございますので、こちらの中で一般提供等の情報のアップデートを希望される方はそのように記載頂ければ、当社の方からご案内させていただきますので、是非とも一言いただければと思います。

Q3. AlloyDB と他データベース製品で、根本的にデータベースの構造などの概念が違う部分、抑えて置くべきポイントあれば

A.杉村：データベース、アプリケーションから見たとき、インターフェース的に見たときには、やっぱり PostgreSQL ですので、根本的に見え方が違うということはないと思いますが、インフラの観点から行ったら今日ご紹介した通り、いろんな運用が自動化されていたり堅牢性、可用性が優秀だったり、カラム型のキャッシュを持っていて、分析クエリが物凄い性能が高い、そう行ったところで違いはあるかなと思っています。

A.飛鳥：実際、例えば AlloyDB 使うシステム開発なんで、「 AlloyDB の開発経験がある方じゃないと対応できないですか？」みたいな結構心配のポイントになるのかなと思いますが、そういった点においては、全く不安になる点はないかなと思います。普通に PostgreSQL で開発できるスキルを持った方であれば AlloyDB 上での開発はなんの苦労もなくできるかなというところですね。

またローカル開発の環境が普通に Windows であったり Mac であったり Linux であったり

PostgreSQL をインストールした状態で、Webアプリケーションであったり他のアプリケーションを開発していて、実際の本番環境ではクラウド上の検証環境 AlloyDB といったものでも差し支えなく開発できるというところです。非常に PostgreSQL の互換性が高いというところから、そこの点においては特に新たな教育やキャッチアップがないと使えないものではないといったところでございます。

Q4. ファイルメーカーを愛用しております。もしかしたらリプレース出来るかな？と期待しております。可能性はありますでしょうか？

A.飛鳥：ファイルメーカーというと GUI（ Graphical User Interface ）上から UI をドラックアンドドロップで登録フォームを作ったり検索フォームを作ったりと行った形で MS Access のような製品なのかなと思いますが、 AlloyDB が担っている役割はデータソースの部分だけなので、このインターフェースの部分については、何かしらのものを自作するか、製品を利用するのかしないと置き換えはできないかなと行ったところと思います。

A.杉村：ファイルメーカーは今風にいうとローコード開発ツールみたいなものになるかなと思いますが、そのデータベース部分を AlloyDB に置き換えるのであれば、画面の部分は別で作る必要があります。AlloyDB で置き換えることも出来ますが、おそらくファイルメーカーで担えるぐらいのボリュームであれば、Cloud SQL でもいいのかなとか別の選択肢もある気がします。

Q5. 1-今後、BigQuery の外部データソースに加えられる予定でしょうか。

2-Azure Database for PostgreSQL Hyperscale のように、TimescaleDB との互換性を持っているのでしょうか。

A.杉村：（1）はおそらく、BigQuery から外部ケーブルテレビを AlloyDB にしてフェデレーテッドクエリでクエリを投げるようなイメージかと思いますが、ここまだ未発表ですので、予定はわからないのですが、個人的な私見としては加えられる可能性は高いのではないかと感じております。

（※ Google Cloud /AlloyDB / マニュアル画面）

（2）は TimescaleDB は PostgreSQL のエクステンションとして実装するものと思いますが、

ちょっと画面（※参照画面）違うところに行きまして、こちら Google Cloud の AlloyDB のマニュアルなんですが、 AlloyDB でサポートされているエクステンションっていうのは決まっていまして、リスト化されています。ここに上がっているエクステンション以外は、今は対応していないので、この中に TimescaleDB の対応が書いていませんのでおそらく現時点では対応していないというご回答になると思います。

今後どうなるかわかりませんが、今の所そういうご回答になります。

Q6. Cloud SQL から移行する際に注意する点はあるでしょうか。

AlloyDB でマルチリージョンに対応することは可能でしょうか。

A.飛鳥：マルチリージョンは対応していないということで、これははっきり記載されているという事から、残念ながら Cloud Spanner を利用する必要がありますね。という形になります。マルチリージョンといっても、その製品が対応しているマルチリージョンではなくて、あくまで東京 - 大阪間で独自でバックアップしたものを何かの時のためにクラウドストレージにデータをバックアップ持っていってそこから戻すとか、そういった事自体全く出来ない訳ではないですけども、製品がマルチリージョン対応をネイティブでやっているかという観点ではしていないという回答になります。

Cloud SQL からの移行は、本当に普通にダンプしてロードすれば使えれるようになりますよ。というところですが冒頭で申し上げました通り、対応しているバージョンが異なりますので、最新の PostgreSQL にロードできるかというところと、利用している拡張機能がサポート外の格納機能を利用している場合においては移行が出来ない可能性があります。

導入にあたってはやはり一度検証の上、決定いただくのが安全かといったところでございます。

こちらも実際にデータやプログラムを見ながらアドバイスをすることも当社はやっておりますから、ご相談いただければ対応できるかなと思っている次第でございます。

A.杉村：後は Cloud SQL の移行の注意点でインフラの観点から言うと利用料金が違ってくるので費用のポイントですとか、後はほとんど似通っているんですが、バックアップとかパッチ当てのあたり、こちらの運用手順も変わってきますので、そういったインフラ的な運用は変わると言うところも着眼しても良いではないのかなと思いました。

Q7.既存のマネージド RDB サービスと比較した時の差異、メリット、技術選定の時に AlloyDB が採用・利用となりそうなポイントなど実務上必要な観点についてお聞きしたいです。

A.杉村：ここも結構今日お話し出来たところかなと思いますが、やはり既存のマネージド RDB サービス Amazon Aurora もそうですし、 Amazon RDS 、Google の Cloud SQL など比較して独特なストレージ機構を持っていてパフォーマンスが高いとか、ここは特殊ですけど列指向のインメモリキャッシュを持っていて、集計の分析クエリが得意ですとか、ホット・フェイルオーバーによる VIM 置換が早いとか、そういったところで非常に高いミッションクリティカルな効果や要請を求められるサービスですとか、そういったところに採用理由になるんじゃないかなと思っています。

A.飛鳥：ここは製品の紹介だったり Cloud SQL の比較のところでも話してきたポイントでありますが、私が実際採用するとすれば BtoC 、BtoB の SaaS。またゲームとかありますけども、そういった一定のスケールが求められ、SLA の高さが求められ、その柔軟性が求められるシーンにおいて採用するといったところが有力になるのではないか。 Cloud SQL も最初から高いスペックで構築してしまえば、相当な負荷には耐えられるんですね実際、なんですけども AlloyDB のような「スケールスケールといって、なんでみんなスケールしたいのですか？」と言う話になってくると、負荷が低い時には安い料金で済ませたいからスケールが欲しいということはあります。

なので上限値に近いようなシミュレートの数で本当に静的にインスタンスやスペック決めてしまって「月100万円です。」という形よりも実際使った分といったら「そんなにいかないでしょ？」といったところから実際アクセスがあれば、高い性能発揮して欲しいけれどもコストは実際実需と言いますか、実際利用分で済ませたいといった時に Cloud SQL でシステム組む場合に比べれば「構成変更のオペレーションを夜間じゃないとダメだよね。」とかいうことなくアグレッシブに変更ができるという点から採用の理由になりやすいかなと思っています。

そこのベースとなるようなアクセスについて大体データベースのコストにして、数千円、数万円レベルであれば、全く Cloud SQL で必要差し支えないと思いますが、それを超えてきたところから、より具体的な AlloyDB にするかどうか検討があるかなと、さらにより大規模なグローバルで展開する大規模なサービスで負荷も高くてという話になってくれば、いよいよ Cloud Spanner を想定しましょうかという話が出てくると。

もちろん AlloyDB は高い性能を誇りますが、リージョンがマルチリージョンでありませんから、海外でも同じデータソースを見るようなグローバルサービスを作りたいといった話になってくれば、今度は「マルチリージョンサービスを使いましょうか？」という話になってくる AlloyDB といったところでやはり一番ピタッとハマるといったところでいうと、例えば日本国内の中ですごく高いミッションクリティカルだったり、負荷だったり、まず確保数についても最適な実際使ったデータ分でコストをコントロールしたいといったニーズに対しては、かなり今ある中ではバチっとはまっている製品なのかなと思っております。

まとめ

本記事では、株式会社トップゲート代表取締役CTO 飛鳥真一郎と、株式会社G-gen 執行役員 CTO / クラウドソリューション部部長杉村勇馬が、登壇者同士のディスカッション、そして質疑応答を交えながらAlloyDBをご紹介いたしました。

今回で「2022年Google発表 AlloyDB とは？リレーショナルDBの選定基準を徹底解説」セミナーレポートのシリーズ全3回は最終回となりました。ここまでご覧いただきありがとうございました。

また過去の記事は以下よりご覧いただけます。

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 向けの領域でも活用を広げています。近年は新規事業立ち上げ時に技術アドバイザーとして参画し、事業展開の初速やその後の成長を支えるシステム基盤としてサーバーレスの導入を積極的に推進しています。