[ GCP ] メガネと学ぶ GCP (12) Cloud SQL と Spanner の比較 ~ 共通点、差異、料金 ~

[ GCP ] メガネと学ぶ GCP (12) Cloud SQL と Spanner の比較 ~ 共通点、差異、料金 ~

こんばんは。七色メガネです。

今日は、GCPのデータベースサービスにおける Cloud SQL と Spanner について、その共通点や差異についての比較を行ってみたいと思います。

Cloud SQL と Spanner の概要については過去の記事でまとめていますので、そちらをご覧ください。

[ GCP ] メガネと学ぶ GCP (8) ストレージ・サービスの特徴を知る

 

共通点について

この2つのデータベースの主な共通点としては、次のようなものがあります。

RDBである

GCPには数多くのストレージサービス、またはデータベースサービスがありますが、従来用いられていたようなRDBの機能を純粋な意味で持ち合わせているのは、Cloud SQL と Spanner しかありません。これら以外は、NoSQL に該当するようになります。

複雑なクエリを発行できる

Spanner は、RDBとNoSQLの特徴を備えたRDBであると謳っています。本来、NoSQLではSQLクエリを発行できませんが、Spannerでは可能であるため、Cloud SQL と遜色のない操作を行うことができます。

なお、Cloud Datastore もNoSQLでありながら、簡単なSQLクエリに対応しています。ただし、Darastore の場合は結合操作などの複雑なクエリは実行不可能です。

Strong Consistecy (強整合性)

この2つのデータベースは、強整合性を持ちます。
強整合性とは、データ更新直後から常に最新のデータを取得することができることを保証する性質のことです。ただしトレードオフとして、データの更新完了までに少し時間がかかることがあります。

対の概念として、Eventual Consistecy (結果整合性) があります。これは Datastore などに見られる考え方で、データの更新後、必ずしも最新のデータが返されないという性質のことです。その代わり、データの処理が常に高速で行われます。

Cloud SQL の特徴

既存RDBのサポート

Cloud SQLでは、次の既存のRDBの機能をサポートしています。従って、運用実績という意味では Spanner に勝ります。

・MySQL

・Postgre SQL

・Microsoft SQL Server

垂直スケール

Cloud SQL は従来のRDBと同じようにスケールアップが可能であり、最大64 個のプロセッサコアと 400 GB 以上の RAM へと機能を向上させることができます。
また Read Replica を使用することで、スケールアウトも実現できます。

自動フェイルオーバー

Failover Replica 機能が備わっており、マスターインスタンスの障害時にフェイルオーバーすることで障害を回避することができます。

Spanner の特徴

大規模水平スケーリング機能

Spanner は RDB でありながらNoSQLの特徴を備えているため、水平スケールに対応しています。
つまり、RDBのようにリードレプリカ (read専用のノード)を増やすことで処理増加に対応するのではなく、read も write もどちらも行えるノードを用意することで処理増加に対応します。(Cloud SQL の場合は、writeを行えるのは基本的に1つのマスターインスタンスのみ。例外としてシャーディンぐは可能)

CAP定理を全て実現

基本的にCAP定理 [Consistency(整合性) / Availability(可用性) / Partion-Tolerance(分断耐性)] の全てを一度に実現することができないとされていましたが、Spanner では全てを実用レベルで実現することができている、唯一のデータベースです。

マルチリージョン対応

Cloud SQL とは異なり、単一リージョン、あるいはマルチリージョンを選択することができます。
単一リージョンを選択した場合のSLAは 99.99 、マルチリージョンを選択した場合のSLAは 99.999 です。
ただし、マルチリージョンの方が料金が高くなります。

料金体系について

Cloud SQL と Spanner に対する課金について、インスタンスとストレージの観点からまとめます。本来はネットワークにも料金が発生しますが、今回は扱わないものとします。

インスタンス(ノード)に対する課金

Cloud SQL

CloudSQL の場合、インスタンスの性能を選択することができますので、それにより課金額が変わります。次の表は、東京リージョンにおける第二世代CloudSQLを使用する場合の、1時間あたりの料金表の一部です。

当然ですが性能が高いほど料金は高くなります。db-n-standard-1 と db-n-standard64 との料金差は実に約80倍です。

マシンタイプ 仮想 CPU 数 RAM(GB) 最大ストレージ容量 最大接続数 料金(米ドル) 継続利用価格(米ドル)
db-f1-micro* 共有 0.6 3,062 GB 250 $0.0195 $0.0137
db-g1-small* 共有 1.7 3,062 GB 1,000 $0.0650 $0.0455
db-n1-standard-1 1 3.75 30,720 GB 4,000 $0.1255 $0.0878
db-n1-standard-2 2 7.5 30,720 GB 4,000 $0.2509 $0.1756
db-n1-standard-4 4 15 30,720 GB 4,000 $0.5018 $0.3513
db-n1-standard-8 8 30 30,720 GB 4,000 $1.0036 $0.6485
db-n1-standard-16 16 60 30,720 GB 4,000 $2.0079 $1.4055
db-n1-standard-32 32 120 30,720 GB 4,000 $4.0151 $2.8105
db-n1-standard-64 64 240 30,720 GB 4,000 $8.0301 $5.6211

Spanner

対してSpannerはインスタンス(ノード)の性能を指定する必要がありませんので、インスタンスに対する課金は一律です。

リージョン構成 説明
ストレージ(GB 単位/月)
アジア太平洋
asia-northeast1 東京 $0.39

 

データ使用量に対する料金表

次の図とグラフでは、1GB / 1月 に課金される料金を示したものです。データ使用量に対する課金
基本的には Spanner の方が高額であることがわかります。特に MultiRegion タイプのストレージについては、他を倍以上引き離す料金設定になっています。

料金表
Name Cloud SQL Cloud SQL Spanner Spanner
Region Tokyo Tokyo Tokyo nam-eur-asia1
Type SQL(HDD) SQL(SSD) Spanner(Region) Spanner(Multi Region)
Payment(per GB/month) $0.12 $0.22 $0.39 $0.90

 

実際に発生すると思われる料金の比較

では実際に、CloudSQL と Spanner において発生すると思われる金額を比較してみたいと思います。

観点

・インスタンスの数とデータ量が等しい時、CloudSQL と Spanner ではどれだけ料金の差が出るのか確認する。
・Cloud SQL では対応できないペタバイトクラスのデータを扱う際の料金の伸び率はどのようなものであるのか確認する。

前提

・料金計算は、次の公式ツールを用いる。
https://cloud.google.com/products/calculator/?hl=ja
・テストアクターは次の4種とする。

使用するストレージサービス
テスト連番
インスタンス性能
ストレージ
性能 キャパシティ
CloudSQL A db-n-standard-8 SSD 3T
CloudSQL B db-n-standard-64 SSD 3T
Spanner A 2T
Spanner B 2T

・テストパターンは次の6種とする。

Test No
ストレージサイズ
インスタンス(ノード)数
Cloud SQL の A/B Spanner の A/B
1 1TB 3(リードレプリカ込) 3
2 2TB 3(リードレプリカ込) 3
3 3TB 3(リードレプリカ込) 3
4 6TB 3
5 60TB 30
6 6PB 3100

 

*Cloud SQL の最大ストレージ量は3TBであるため、3TB以上のテストは行わない。
*インスタンス課金を比較するため、Cloud SQL と Spannerの比較では、Spanner の推奨最小ノード構成である 3 で統一する。

テスト結果
Payment($) per 1 month
Test No Cloud SQL-A Spanner-A Cloud SQL-B Spanner-B
1 2,214 2,961 12,985 20,631
2 2,890 3,361 13,661 21,553
3 3,566 3,760 14,337 22,474
4 4,958 25,239
5 49,584 252,396
6 5,101,377 26,029,310
(考察1) Cloud SQL と Spanner による料金の違い

テストNO 1 ~ 3 では、インスタンスの数とデータ容量をCloudSQLとSpannerで揃えているので、これらを比較できる。
一般的な性能の比較、という意味では CloudSQL-A と Spanner-A の比較が有用である。


この2つを比較すると、データ量が1TBである時には2者間の料金の乖離が大きいが、CloudSQL のストレージ限界である3TBに近づくにつれて、乖離が少なくなっていることがわかる。
つまり、データが少ない時には CloudSQL に料金的な軍配が多くあるが、データが増加するにつれて、そのメリットは徐々に失われていくと言うことができる。

なお、Cloud SQL のインスタンス性能を高めると、Spanner の料金よりも高額となる。
(CloudSQL-A = db-standard-n-8 / CloudSQL-B = db-standard-n-64)

(考察2) Spanner におけるペタバイトクラスのデータ処理時の料金について

ペタバイトに対応はできるが、料金がものすごいと言うことがわかった。(小並)
今回のテストでは一段飛びでペタバイトクラスのテストパターンに移行したので変化が急激だが、それを考慮しても、ペタバイト級のデータの取り扱いには料金が相当量かかることが窺いしれる。
なお単位はドルです。
テストNo6 は 6ペタバイトのデータ量でMultiRegion構成をとった例で、26,029,310$ ですね…。

まとめ

・GCPでRDBを使いたい時には、選択肢として Cloud SQL と Spanner が挙げられる。

・3テラバイトまでの使用想定ならば、Cloud SQL の方が安価である。
(ただし3テラと言うのは理論上の限界値なので、使用量70%程度を想定するとしたら、2テラまでがCloudSQLの範囲かもしれない)

・Cloud SQL での読み込みは、リードレプリカを使用することで処理を分散することができる。(インスタンスを増やせば、自動的にリードレプリカとなる)
対して書き込みは、マスターインスタンスでしか行えない。したがって、書き込み性能を上げるためにはマスターインスタンスの性能を上げるしかない。

・Spanner は NoSQL 的なRDBであり、データを分散させて処理することができる。つまり、読み込み処理も、書き込み処理も、分散させて行うことができる。つまりインスタンスの性能を上げなくても、高負荷な書き込み処理に対応できる。(もちろん、分散するためのノード数は一定数必要だが)

参考

料金計算

https://cloud.google.com/products/calculator/?hl=ja#id=7d9a6e3a-edde-4a45-a355-bfb0b845951e

Cloud SQL について

https://cloud.google.com/sql/pricing?hl=ja#2nd-gen-pricing

Spanner について

https://cloud.google.com/spanner/pricing?hl=ja

GoogleCloudPlatformカテゴリの最新記事