Google Cloudに関する記事

11分で読める

2024/04/30 2024/05/13

これを見れば分かる！Google Cloud データベース選定

こんにちは、Google Cloud Database Champion Innovator の高島です。

昔から Google Cloud のデータベース製品は種類が多く
「いっぱいあるけど、どれがいいの？違いは何？」という質問をよくもらいます。

本記事では、リレーショナルデータベース（以下、RDB）に焦点を当て、詳しく解説していきます。

Google Cloud データベース製品一覧

各プロダクトを４つのカテゴリ「RDB」「NoSQL」「インメモリ」「データウェアハウス」に分類し、特徴とユースケースを記載した早見表です。
今回は、この中から最も利用される、3 つの RDB の特徴と違いを見ていきます。

Cloud SQL
AlloyDB for PostgreSQL（以下、AlloyDB）
Cloud Spanner（以下、Spanner）

Cloud SQL の概要

Cloud SQL とは、2011 年にリリースされた最初期からあるマネージド RDB で
MySQL(5.0,5.6,8.0) / PostgreSQL(9〜15) / SQL Server が選択可能です。

主に、オンプレミスからの単純移行やマネージドサービスとして運用したい場合に選定されます。
最小構成では他の RDB 製品と比べて最も安価な $12 から利用可能です。

Cloud SQL のエディション

2023 年に Enterprise と Enterprise Plus の 2 つエディションが登場し、2023 年 7 月 13 日に GA（General Availability = 一般公開）となりました。
これらのエディションは従来の Cloud SQL の機能が拡張され、既存インスタンスは Enterprise に名称が変更されました。

Enterprise は、従来の Cloud SQL と同等の価格、可用性、パフォーマンスを提供します。
Enterprise ⇔ Enterprise Plus 双方向にインプレースアップグレード/ダウングレードが可能となっています。 ※ ダウンタイムは 60 秒未満

Cloud SQL Enterprise Plus の概要

Enterprise Plus は、従来の Cloud SQL 機能に加えて、最高水準のパフォーマンスと可用性を提供し
Enterprise Plus for MySQL と for PostgreSQL どちらもおおよそ 2 〜 3 倍のパフォーマンス向上が見込めます。
※ GA 時点では、SQL Server は選択できません。

Cloud SQL Enterprise Plus のマシンタイプ

Enterprise Plus は、最新の N ファミリマシンが導入されており、より安定したパフォーマンスを提供します。
※ N ファミリのマシンタイプは、比率 1:8 の⾼いメモリ⽐率を備えた最⼤ 128vCPU、864GB メモリの構成をサポート
※ GA 時点ではカスタムマシン構成をサポート対象外

Cloud SQL Enterprise Plus のデータキャッシュ（ローカルSSD）

Enterprise Plus は、ローカル SSD を追加のバッファプールとして利用可能になります。
データキャッシュ機能を明示的に有効にすると、キャッシュが⾃動的に管理され、読み取り集中型のワークロードのパフォーマンスが向上します。
※GA 時点では、マシンタイプに応じた容量固定の SSD のみサポート

Cloud SQL Enterprise Plus のSLA

Enterprise Plus は、メンテナンスダウンタイムを含む 99.99% の SLA を提供します。
Enterprise はメンテナンスダウンタイムを”含まない” 99.95% の SLA だったので、大幅に向上しています。

※ SLA はあくまでもサービスレベルの契約であり、上記のダウンタイムが必ず発生するというわけではない。

Cloud SQL Enterprise Plus の計画メンテナンスダウンタイム

これまでの Cloud SQL を採用するにあたって悩みの種だったのが、メンテナンスダウンタイムです。
ここ数年間 Google Cloud プロダクトチームも改善に非常に力を入れていて、数分かかっていたものが PostgreSQL は 30 秒未満まで短縮されていました。

データベースの数十秒の停止はアプリケーション側もメンテナンスにいれる必要がありましたが、Enterprise Plus では、メンテナンスダウンタイムはほぼゼロになり、運用コストを大幅に削減できる可能性があります。

実際のダウンタイムを検証するために、INSERT を 1 秒間隔で実行し、復帰するまでの時間を計測を検証してみました。

※1 定期メンテナンスのシュミレート機能は現在なく、セルフサービスメンテナンス機能で実際に更新パッチを適応させて検証できますが、今回はパッチが来ていないため未検証となります。なお、リリース当初の 2023 年 8 月 16 日に検証したもので、現在はさらに早くなっている可能性もあります。

メンテナンスダウンタイムは、ほぼゼロの 2 秒未満で、Google Cloud Next Tokyo 2023 の Cloud SQL はどのように高いパフォーマンスと可用性が求められる MySQL ワークロードを支えているかでメンテナンスダウンタイムのデモが実演されていますが、あまりに早く完了するのでログを確認しないとダウンしたことを観測できないレベルとなっています。

このことから、アプリケーション側でリトライ制御を実装すれば、無停止でメンテナンスダウンタイムに対処可能となりました。
また、フェイルオーバーは、公式ドキュメントには約 60 秒と記載がありますが、実際には 10 秒程度の結果となり、障害時の影響範囲を最小限に留めることできます。

【補足】
2024 年 4 月現在、公式ドキュメントでは Enterprise Plus のメンテナンスダウンタイムは 10 秒未満と記載されていますが、
Google Next 2024 付近のタイミングで 1 秒未満 にドキュメントが変更されており、下記表の更新も近いでしょう。

出典：Cloud SQL の各エディションの概要

Cloud SQL Enterprise Plus の料金

Enterprise Plus は Enterprise と比較して 約 1.3 倍 の価格となりますが、2〜3 倍のパフォーマンスを期待できますし、”移行してみたらコストが下がった” 事例もあります。

Cloud SQL Enterprise Plus のまとめ

従来の Cloud SQL と比較して 2 〜 3 倍のパフォーマンス
メンテナンスダウンタイムを含む 99.99% の SLA
ほぼゼロのメンテナンスダウンタイム
フェイルオーバーやマシンタイプ変更のダウンタイムも改善
従来の Cloud SQL と比較して約 1.3 倍の料金（移行でコスト減の事例あり）
Enterprise ⇔ Enterprise Plus 双方向にインプレースアップグレード/ダウングレードが可能。 ※ ダウンタイムは 60 秒未満

AlloyDB の概要

AlloyDB とは、2022 年登場の PostgreSQL 互換マネージド RDB で PostgreSQL 14、15 をサポートしています。
既存の PostgreSQL から単純移行するだけでパフォーマンス向上を見込め、料金は高可用性構成で $295〜 / 月から利用可能です。
※ MySQL はサポートしていません。

一般論として、アプリケーションから書き込みや読み取りのトランザクションを行う MySQL データベースと
BiqQuery など集計や分析に利用するデータベースを役割ごとに分けて利用するのが一般的でした。

AlloyDB は「トランザクション」と「分析」両方を得意とするアーキテクチャとなっており、データベースを 1 つにすることができます。
また、ベンダロックインや複雑なライセンスがないため、OracleDB 移行先の候補になります。

Database Migration Service（DMS）を利用すれば、Oracle を含むさまざまなデータソースから AlloyDB へスムーズな移行が可能です。

AlloyDB の特徴

AlloyDB は、従来の PostgreSQL と比較して、書き込み処理は 4 倍 高速。分析クエリは最大 100 倍 高速のパフォーマンス向上が見込めます。

AlloyDB のアーキテクチャ

次の図は、公式ドキュメントから抜粋したアーキテクチャで、通目すべきポイントは 4 つです。

Primary instance（読み書き可能なプライマリインスタンス）
Read pool instance（読み取りプールインスタンス）
Storage layer（データを分散保存するストレージ層）
AlloyDB Cluster（クラスタ ※AlloyDB の構成単位）

これだとかなり抽象的なので、より詳細な図は次となります。
まず、従来の RDB と大きく異なる点が、コンピュート層とストレージ層が別れている点になります。

従来の RDB では、単一 VM の CPU / MEM / DISK で MySQL や PostgreSQL が動作していましたが、
AlloyDB では、コンピュート層にプライマリやリードプールが複数台のインスタンスで構成されクエリを処理して、後続のストレージ層と連携します。

ストレージ層では、Colossus と呼ばれる Google 分散ファイルシステムを基盤としたデータの永続化を担当し、AlloyDB Intelligent Storage Engineが書き込みログを処理します。詳細は公式ブログをご覧ください。

AlloyDB for PostgreSQL の仕組み: データベース対応のインテリジェントなストレージ | Google Cloud 公式ブログ

AlloyDB のカラム型エンジン（Columnar Engine）

カラム型エンジンとは、データを効率的に処理するためのベクトル化クエリ処理エンジンです。
「行」と「列」両方のキャッシュを持つ高度な機能を備えたシステムという認識でまずは大丈夫です。

上述の図では、プライマリとリードプールインスタンスに小さく記載していますが、これでは分かりづらいので拡大した図が次となります。

DRAM 上には、通常のトランザクションでよく使われる行ベースのキャッシュの他に、AI / ML によって自動的に列指向のキャッシュが作られ、分析や集計などの列レベルで取得するクエリを自動で最適化することが可能です。

また、AlloyDB は統合された AI/ML によるインデックスアドバイザー機能を利用すると 実行クエリを分析して適切なインデックスを推奨してくれます。
AlloyDB に推奨されたインデックスを追加するだけなので、熟練のエンジニアでなくても簡単にチューニングが可能となります。

カラム型エンジンやインデックスアドバイザーのパフォーマンス検証結果を弊社エンジニアが Next 2022 で発表しております。
700 倍高速化したクエリもあるので、ぜひご覧ください。
ベンチマーク結果から見る AlloyDB とカラムナエンジン

AlloyDB のSLA

AlloyDB は、メンテナンスダウンタイムを含む 99.99% の SLA を提供します。

AlloyDB の計画メンテナンスダウンタイム

実際のダウンタイムを検証するために、INSERT を 1 秒間隔で実行し、復帰するまでの時間を計測を検証してみました。

検証結果と、Cloud SQL Enterprise Plus との比較です。
フォールトインジェクションとは、実際のインスタンスをクラッシュさせた挙動から復元するまでのプロセスをシミュレートする機能で、Cloud SQL にはこの機能がありません。

AlloyDB は、公式ドキュメントでは無停止でインスタンスのサイズ変更とデータベースのメンテナンスに対応と明記されていますが、実際には瞬断しますが、
アプリケーション側でリトライ制御を実装すれば、無停止でメンテナンスダウンタイムに対処可能です。

AlloyDB のまとめ

コンピュート層とストレージ層が分離したアーキテクチャで PostgreSQL のみ
従来の PostgreSQL と比較して、書き込み処理は 4 倍高速、分析クエリは最大 100 倍高速のパフォーマンス向上が見込める
AI/ML によって最適化したインデックスを推奨してくれる
メンテナンスダウンタイムを含む 99.99% の SLA
ほぼゼロのメンテナンスダウンタイム
高可用性構成で $295〜 / 月から利用可能

Spanner の概要

Spanner とは、2017 年にリリースされた分散型マネージド RDB。

ノーメンテナンス・ノーダウンタイムで SLA は最大 99.999% となっており $90 から利用可能で、大量の読み書き性能が必要な場合や 1 秒でも停止できない場合に選択される。

クエリは ANSI 2011 規格に準拠する為、これまでの SQL の経験を活かせるが、
データを分散させるためのスキーマ設計が必要となるので、既存 RDB からの単純移行するだけではパフォーマンスを発揮できない。

スキーマ設計のハードルを乗り越えた先には、フェイルオーバーやメンテナンスダウンタイムを気にしなくてよい、夢のようなデータベースです。

Spanner のアーキテクチャ

従来の RDB では、基本的に単一 VM の CPU / MEM / DISK で MySQL 等が動作していました。
左側の Cloud SQL Enterprise の高可用性構成では、MySQL 等がインストールされた単一の VM にリージョン永続ディスクがアタッチされた構成になっており、アクセスやデータ量の増加によって、処理の限界に至ります。

一方で、分散データベースと呼ばれる Spanner はコンピュート層とストレージ層で分離して、1 つのデータベースとして成り立っています。

Spanner のノードとスプリット

Spanner の各ノードはクエリを処理し、スプリットとよばれる連続したデータ範囲（チャンク）を担当します。
例えば、Node1 は Split1 に格納されているデータの読み書きを処理しています。

Spanner ノードの増減

Spanner は、ノード数を増やすことで水平スケールし、処理性能を向上させることが可能です。

ノードは別名、処理ユニット（PU: Processing Units）と呼ばれ、 1ノード = 1000 PU となります。
利用者は CPU やメモリを気にする必要はなく、ノードを増やすか減らすかだけです。

ノードを追加すると、Spanner はスプリットを分割するか担当を変更します。

次の例では、追加した Node 4 が Split 3 に読み書きを行っていて、データベース全体で処理が分散することでスケールアウトしています。
読み取りだけでなく、書き込みも水平スケールするのがポイントです。

※図では、分かりやすさのためにノードとスプリットに番号を振っています。

Spanner のデータ分割

Spanner はデータの増減によっても、スプリットを自動的に分割します。
次の図は Split 4 が肥大化して自動分割される挙動を表現しています。

Spanner のスプリット範囲

スプリットは、連続したデータ範囲（チャンク）を主キーの辞書順ソートで格納します。
「歌手テーブル主キーの ID 列の 1 〜 3 までの範囲データは Split1 で、この範囲の読み書き担当は Node1 である」という考え方になります。

抽象的に説明すると、「ノードを先生とすると、 “あ行” の生徒たち（スプリット）を担任する」という感じです。

Spanner のホットスポット

スプリットは、主キーのプレフィックスで分割されるので、仮に Node 1 が 1 スタートの値、
Node 2 が 2 スタート、Node 3 が 3 スタートのような単調増加する値を主キーに選択すると肥大化するにつれて偏りが発生します。

これをホットスポットといい、最も避けるべきアンチパターンでになります。

> データを分散させるためのスキーマ設計が必要となるので、既存 RDB からの単純移行するだけではパフォーマンスを発揮できない。
既存のデータベースで主キーが連番になっている場合のホットスポットや、フルスキャンとなるクエリは全ノードに問い合わせるのでパフォーマンスが非常に悪くなります。これが、単純移行でパフォーマンスを発揮できない原因です。

Spanner のホットスポット回避のベストプラクティス

主キー（PK: Primary Key）に UUID v4 を利用するのが最も良い方法ですが、
連番の主キーをハッシュ化したり、元の値を算出できるようにビット演算ロジックを実装するなど回避策は多々あるので、アプリケーションの要件によって選択すれば良いでしょう。

Spanner のまとめ

コンピュート層とストレージ層の分散データベース
ホットスポットなど、分散データベースならではの設計が必要
ノーメンテナンス・ノーダウンタイム
SLA は最大 99.999%
$90 / 月から利用可能

非機能要件の比較

データ量で見るデータベース選定

Cloud SQL、AlloyDB、Spanner で取り扱うデータ量の目安とレイテンシを表現したグラフです。

※ あくまでもデータ量の観点での目安であり「 10 TB 以下は Cloud SQL 」という表現ではないことにご注意ください
※ アプリケーションの要件によって最適なデータベースを選択する必要があります

機能・非機能要件表

さいごに

本記事では、それぞれの RDB の特徴と機能を簡単に解説しました。
本記事の内容をまとめた資料はこちらから無料でダウンロード可能です。

もし、Spanner にご興味があれば、クラウドエースは Google Cloud 公式の Spanner トレーニングを実施しており、2 日間で Spanner の概要から運用までを座学とハンズオンで学ぶことも可能です。

Understanding Google Spanner（中級） | クラウドエース株式会社

不明点や「このプロダクトについて詳しく知りたい」等ございましたら、お気軽にお問い合わせください。

※Google Cloud、BigQuery、Cloud Spanner、Firestore、Bigtable、は Google LLC の商標です。
※Oracle、Oracle Database 、MySQLは Oracle Corporation およびその関連企業の登録商標です。

この記事を共有する