Cloud SQL 第 2 世代のパフォーマンスと機能を詳説
2016年8月23日火曜日
私たち Google は、5 年前に第 1 世代の Google Cloud SQL をリリースして以来、このサービスで多くの企業のアプリケーション構築を支援してきました。
その間、Google Cloud Platform の永続ディスクにおけるイノベーションにより、Google Compute Engine では IOPS が大幅に向上しました。そこで私たちは、永続ディスクを利用して第 2 世代の Cloud SQL を開発しました。そのおかげで、極めてパフォーマンスの高い MySQL ソリューションを安価に提供できるようになっています。
Cloud SQL 第 2 世代は、第 1 世代と比べて 7 倍高速で、ストレージ容量も最大 20 倍に増えていますが、コストは下がっています。また、スケーラビリティが向上し、データベースの自動バックアップと任意の時点へのリストアが可能で、99.95 % の可用性が保証されており、世界のどこでも利用できます。こうしたことから、お客様は IT ソリューションを気にかけることなく、アプリケーションに集中できます。
Cloud SQL 第 2 世代におけるパフォーマンスの向上は目覚ましく、各インスタンスは最大で 10 TB のデータ、20,000 IOPS、104 GB の RAM を利用できます。
Cloud SQL 第 2 世代 vs. 競合サービス
このように、Cloud SQL 第 2 世代は第 1 世代から大きく進化しています。では、Amazon Web Services のデータベース サービスと比べてどうなのでしょうか。
- テスト : 私たちは sysbench を使い、3 つのサービスで同じワークロードのシミュレーションを行いました。3 つのサービスとは、Cloud SQL 第 2 世代、Amazon RDS for MySQL、Amazon Aurora です。
- 結果 : Cloud SQL 第 2 世代は RDS for MySQL より高いパフォーマンスを発揮し、アクティブ スレッド数が少ない（多くのウェブ アプリケーションの典型的な状態です）ときに Aurora のパフォーマンスを上回りました。
Cloud SQL のスレッドあたりの TPS（トランザクション / 秒）は、RDS for MySQL より一貫して高く、16 スレッドまでの構成では Aurora をも上回っています。
詳細
同一ワークロードで Cloud SQL 第 2 世代、Amazon RDS for MySQL、Amazon Aurora のマルチゾーン（高可用性）インスタンスを比較します。いずれも各サービスで提供される最新版の MySQL が実行されています。
これら 3 つのサービスで使われるレプリケーション技術はかなり異なっており、パフォーマンスとレイテンシに大きく影響します。Cloud SQL 第 2 世代は MySQL の準同期レプリケーションを使用しており、RDS for MySQL はブロック レベルの同期レプリケーションを、Aurora はプロプライエタリなレプリケーション技術を使用しています。
スループットを測定するため、プライマリ データベース インスタンスと同じゾーン内の MySQL クライアントから sysbench の OLTP ワークロードが生成されました。ワークロードは一連のステップ ロード テストであり、1 回実行するごとにスレッド（接続）数が倍増します。使用されるデータセットは、読み込み後にディスクへの書き込みが行われるように、データベース インスタンスの総メモリの 5 倍のサイズとなっています。
TPS（トランザクション / 秒）の結果は、Cloud SQL と Aurora が RDS for MySQL より高速であることを示しています。また、16 スレッドまでは、Cloud SQL の TPS が Aurora を上回っています。しかし 32 スレッド以上では、Cloud SQL はレプリケーション ラグが大きくなっている可能性があることからパフォーマンスが低下しており、Aurora のピーク TPS が Cloud SQL の TPS を上回っています。
このワークロードは、3 つのサービスのレプリケーション技術の違いを浮き彫りにしています。Aurora はパフォーマンスの変化が最も小さく、レプリケーション ラグが一定のレベルで推移します。これに対して Cloud SQL はパフォーマンスに重点が置かれており、レプリケーション ラグを許容します。そのためフェイルオーバー時間は長くなりますが、データ損失の心配はありません。
レイテンシ
私たちは、シングル クライアント スレッドのエンド ツー エンドの平均レイテンシを測定しました（これは、いわば “純粋な” レイテンシです）。
ベンチマークの実行
私たちのテストでは、以下の環境構成と sysbench のパラメータを使用しました。
テスト インスタンス :
- Google Cloud SQL v2、db-n1-highmem-16（16 CPU、104 GB RAM）、MySQL 5.7.11、1000 GB PD（永続ディスク）SSD + フェイルオーバー レプリカ
- Amazon RDS Multi-AZ（マルチ アベイラビリティ ゾーン）、db.r3.4xlarge（16 CPU、122 GB RAM)、MySQL 5.7.11、1000 GB SSD、10,000 プロビジョンド IOPS + Multi-AZ レプリカ
- Amazon RDS Aurora、db.r3.4xlarge（16 CPU、122 GB RAM）、MySQL 5.6（最新）+ レプリカ
テスト概要 :
sysbench によるベンチマーク テストでは、それぞれ 2,000 万行の 100 テーブル（合計 20 億行）を使用しました。
このデータセットは、メモリに収まらないようにするために各インスタンスのメモリ（100 GB 強）の倍数のサイズに設定しました。これにより、テストに十分な容量のバイナリ ログがレプリケーションに使われることになりました。具体的には、ロードされる 100 テーブル × 2,000 万行のデータセットのサイズは 500 GB 強でした。
各ステップの実行時間は 30 分間で、ステップ間に 1 分間の “クールダウン” 時間を設け、実行時には 1 秒ごとにレポートが 1 行出力されるようにしました。
データのロード :
Ubuntu setup
sudo apt-get update
sudo apt-get install \
git automake autoconf libtool make gcc \
Libmysqlclient-dev mysql-client-5.6
git clone https://github.com/akopytov/sysbench.git
(apply patch)
./autogen.sh
./configure
make -j8
Test variables
export test_system=<test name>
export mysql_host=<mysql host>
export mysql_user=<mysql user>
export mysql_password=<mysql password>
export test_path=~/oltp_${test_system}_1
export test_name=01_baseline
Prepare test data
sysbench/sysbench \
--mysql-host=${mysql_host} \
--mysql-user=${mysql_user} \
--mysql-password=${mysql_password} \
--mysql-db="sbtest" \
--test=sysbench/tests/db/parallel_prepare.lua \
--oltp_tables_count=100 \
--oltp-table-size=20000000 \
--rand-init=on \
--num-threads=16 \
run
Run the benchmark:
mkdir -p ${test_path}
for threads in 1 2 4 8 16 32 64 128 256 512 1024
do
sysbench/sysbench \
--mysql-host=${mysql_host} \
--mysql-user=${mysql_user} \
--mysql-password=${mysql_password} \
--mysql-db="sbtest" \
--db-ps-mode=disable \
--rand-init=on \
--test=sysbench/tests/db/oltp.lua \
--oltp-read-only=off \
--oltp_tables_count=100 \
--oltp-table-size=20000000 \
--oltp-dist-type=uniform \
--percentile=99 \
--report-interval=1 \
--max-requests=0 \
--max-time=1800 \
--num-threads=${threads} \
run
Format the results:
Capture results in CSV format
grep "^\[" ${test_path}/${test_name}_*.out \
| cut -d] -f2 \
| sed -e 's/[a-z ]*://g' -e 's/ms//' -e 's/(99%)//' -e 's/[ ]//g' \
> ${test_path}/${test_name}_all.csv
Plot the results in R
status <- NULL # or e.g. "[DRAFT]"
config <- "Amazon RDS (MySQL Multi-AZ, Aurora) vs. Google Cloud SQL Second Generation\nsysbench 0.5, 100 x 20M rows (2B rows total), 30 minutes per step"
steps <- c(1, 2, 4, 8, 16, 32, 64, 128, 256, 512)
time_per_step <- 1800
output_path <- "~/oltp_results/"
test_name <- "01_baseline"
results <- data.frame(
stringsAsFactors = FALSE,
row.names = c(
"amazon_rds_multi_az",
"amazon_rds_aurora",
"google_cloud_sql"
),
file = c(
"~/amazon_rds_multi_az_1/01_baseline_all.csv",
"~/amazon_rds_aurora_1/01_baseline_all.csv",
"~/google_cloud_sql_1/01_baseline_all.csv"
),
name = c(
"Amazon RDS MySQL Multi-AZ",
"Amazon RDS Aurora",
"Google Cloud SQL 2nd Gen."
),
color = c(
"darkgreen",
"red",
"blue"
)
)
results$data <- lapply(results$file, read.csv, header=FALSE, sep=",", col.names=c("threads", "tps", "reads", "writes", "latency", "errors", "reconnects"))
# TPS
pdf(paste(output_path, test_name, "_tps.pdf", sep=""), width=12, height=8)
plot(0, 0,
pch=".", col="white", xaxt="n", ylim=c(0,2000), xlim=c(0,length(steps)),
main=paste(status, "Transaction Rate by Concurrent Sysbench Threads", status, "\n\n"),
xlab="Concurrent Sysbench Threads",
ylab="Transaction Rate (tps)"
)
for(result in rownames(results)) {
tps <- as.data.frame(results[result,]$data)$tps
points(1:length(tps) / time_per_step, tps, pch=".", col=results[result,]$color, xaxt="n", new=FALSE)
}
title(main=paste("\n\n", config, sep=""), font.main=3, cex.main=0.7)
axis(1, 0:(length(steps)-1), steps)
legend("topleft", results$name, bg="white", col=results$color, pch=15, horiz=FALSE)
dev.off()
# Latency
pdf(paste(output_path, test_name, "_latency.pdf", sep=""), width=12, height=8)
plot(0, 0,
pch=".", col="white", xaxt="n", ylim=c(0,2000), xlim=c(0,length(steps)),
main=paste(status, "Latency by Concurrent Sysbench Threads", status, "\n\n"),
xlab="Concurrent Sysbench Threads",
ylab="Latency (ms)"
)
for(result in rownames(results)) {
latency <- as.data.frame(results[result,]$data)$latency
points(1:length(latency) / time_per_step, latency, pch=".", col=results[result,]$color, xaxt="n", new=FALSE)
}
title(main=paste("\n\n", config, sep=""), font.main=3, cex.main=0.7)
axis(1, 0:(length(steps)-1), steps)
legend("topleft", results$name, bg="white", col=results$color, pch=15, horiz=FALSE)
dev.off()
# TPS per Thread
pdf(paste(output_path, test_name, "_tps_per_thread.pdf", sep=""), width=12, height=8)
plot(0, 0,
pch=".", col="white", xaxt="n", ylim=c(0,60), xlim=c(0,length(steps)),
main=paste(status, "Transaction Rate per Thread by Concurrent Sysbench Threads", status, "\n\n"),
xlab="Concurrent Sysbench Threads",
ylab="Transactions per thread (tps/thread)"
)
for(result in rownames(results)) {
tps <- as.data.frame(results[result,]$data)$tps
threads <- as.data.frame(results[result,]$data)$threads
points(1:length(tps) / time_per_step, tps / threads, pch=".", col=results[result,]$color, xaxt="n", new=FALSE)
}
title(main=paste("\n\n", config, sep=""), font.main=3, cex.main=0.7)
axis(1, 0:(length(steps)-1), steps)
legend("topleft", results$name, bg="white", col=results$color, pch=15, horiz=FALSE)
dev.off()
Cloud SQL 第 2 世代の機能
前節では Cloud SQL 第 2 世代のパフォーマンスの高さを紹介してきましたが、それはこのサービスの半面でしかありません。私たち Google は、フルマネージド サービスは強力であるのと同じくらい便利でなければならないと考えています。そこで私たちはこのサービスに、データを簡単に保存、保護、管理するのに役立つ新機能を追加しました。
データの保存と保護
- 柔軟なバックアップ : 日次バックアップが自動的に実行されるようにスケジューリングしたり、バックアップをオンデマンドで実行したりできます。バックアップは、パフォーマンスに影響しないように設計されています。
- 正確なリカバリ : ポイント インタイム リカバリを利用して、インスタンスを特定の時点にリカバリできます。
- 簡単なクローン : 本番環境に変更を組み込む前に、インスタンスをクローンし、コピー上で変更をテストできます。クローンはデータベースの正確なコピーですが、ソースから完全に独立しています。Cloud SQL は効率的なクローン ワークフローを提供します。
- ストレージの自動拡張 : ストレージの自動拡張を有効にしておけば、データ量が上限に迫ると、Cloud SQL がストレージ容量を追加してくれます。
接続と管理
- オープン標準 : Google は、MySQL データベースの標準接続プロトコルである MySQL Wire Protocol をサポートしています。そのため、ユーザーはほぼすべてのアプリケーションから、その実行場所にかかわらず、データベースにアクセスできます。
- 安全な接続 : Google の新しい Cloud SQL Proxy はローカル ソケットを作成し、OAuth を利用してアプリケーションや MySQL ツールとの安全な接続を確立します。これにより、動的および静的 IP アドレスからの安全な接続が容易になります。たとえば、開発者がノート PC などで動的 IP アドレスを使う場合、ファイアウォール設定を変更することなく、サービス アカウントを使って接続の安全を確保できます。静的 IP アドレスを使う場合は、もう SSL をセットアップしないで済みます。
もちろん、私たちは Cloud SQL を非常に誇りに思っています。ですが、皆さんが気になるのは、Cloud SQL 第 2 世代に対するお客様からの評価でしょう。ここでは、2 社のお客様から寄せられたコメントを紹介します。
「私たちは SaaS 企業として、お客様の数百のインスタンスを管理しています。Cloud SQL は、私たちのスタックの主要なコンポーネントです。Cloud SQL のベータ テストを行ったところ、大口のお客様に素晴らしいパフォーマンスでサービスを提供できました。そこで私たちはすぐに、大口のお客様のうち数社の環境を Cloud SQL に移行しました。これらのお客様では、クエリのパフォーマンスが 7 倍に向上したのです」
- Rajesh Manickadas 氏、Orangescape のエンジニアリング ディレクター
「モバイル アプリケーション企業である私たちにとって、お客様に最高の製品を提供するにはデータ管理が不可欠です。Cloud SQL のおかげで私たちは、データ ポイントが毎月 1 億 2,000 万 ～ 1 億 5,000 万件ずつ増えるようなデータベースを管理できています。実際、お客様の 1 社である年間売上高 60 億ドルの通信事業者のデータベースには、毎月 15 GB 以上のデータが追加されています。ピーク時には書き込み操作が毎秒 400 件程度に達しますが、API 呼び出しの平均応答時間は 73 ミリ秒 以下にとどまっています」
- Andrea Michaud 氏、www.teamtracking.us のクライアント サービス責任者
次のステップ
Cloud SQL はこれからどうなるのでしょうか。永続ディスクのパフォーマンスが今後も向上し、仮想ネットワーキングの改良も進むほか、第 1 世代ユーザーが第 2 世代にアップグレードするための移行ツールが効率化されます。ご期待ください。
Google Cloud Platform（GCP）をまだご利用でない方は、ぜひ無料トライアルにお申し込みください。300 ドル分のクレジットで Cloud SQL と他の GCP サービスを無料でお試しになれます。
有償アカウントにアップグレードするときは、手始めに安価なマイクロ インスタンスをテストや開発にお使いになるとよいでしょう。準備ができたら、それらを簡単にスケールアップして、パフォーマンス集約型アプリケーションの運用に利用できます。
また、Google のパートナーのエコシステムを利用して Cloud SQL を導入することもできます。データ転送の効率化は Talend、Attunity、Dbvisit、Xplenty が、分析データの可視化は Tableau、Looker、Yellowfin、Bime by Zendesk が、データベースの管理と監視は ScaleArc、Webyog が、専門サポートは Pythian、Percona がそれぞれ手がけています。
「Cloud SQL を導入する Tableau のお客様がますます増えています。クラウドで高速な分析ができるというメリットがあるからです。Cloud SQL 第 2 世代ではパフォーマンスが大幅に向上しており、導入にさらに拍車がかかるでしょう」
- Dan Kogan 氏、Tableau のプロダクト マーケティング & テクノロジー パートナー担当ディレクター
「Google の Cloud SQL 第 2 世代が GA（一般公開）リリースとなり、Looker 製品との高度な統合をサポートできることに、私たちはわくわくしています。Looker Data Platform のインデータベース分析のアプローチと Cloud SQL のフルマネージド データベース サービスを組み合わせることで、お客様はクラウド ベースのリアルタイム分析および可視化環境を手に入れ、社内の誰もがデータに基づく意思決定を行えるようになります」
- Keenan Rice 氏、Looker の戦略アライアンス担当バイス プレジデント
「データベース アプリケーションのクラウドへの移行は、多くのお客様にとって優先課題となっています。私たちは Attunity Replicate により、ダウンタイムを発生させることなく、Cloud SQL に容易に移行できるようにすることで、その課題の解決を後押ししています。Cloud SQL 第 2 世代では、このサービスの企業における利用拡大の鍵となるパフォーマンス、信頼性、セキュリティが一段と向上しています。お客様はこうした機能強化の恩恵を受けることができ、私たちはお客様と協力してデータ転送の障害の解消に取り組むことを楽しみにしています」
- Itamar Ankorion 氏、Attunity の最高マーケティング責任者（CMO）
Cloud SQL は大きな波を起こしつつあり、皆さんがそれに加わっていただけることを私たちは願っています。
- Posted by Brett Hesterberg, Product Manager, Google Cloud Platform
