ベンチマーク

ベンチマーク

MySQLの標準ベンチマークツールmysqlslapを使ってCloud SQLの性能を測定しました。比較するのは、GCEのインスタンスから立ち上げた通常のMySQLです。またCloud SQLの中でも、レプリケーション設定などを変えながら数パターン実行しました。実行元となるのは、GCEの別インスタンスです。

クエリ数：10,000、同時接続クライアント数：3、実行回数：10で、read と writeの処理を行い、それぞれのかかった秒数の平均を出しました。

表1：GCEインスタンスのMySQLとCloud SQLの処理速度の比較

Cloud SQL ではGCEインスタンスに比べて書き込み処理に時間がかかっていますが、実運用では連続したデータの書き込みが頻繁に発生するシステムでない限り、それほど影響を及ぼすレベルではないと思われます。さすがにインスタンスタイプ（階層）がD0だと遅さが顕著に現れています。ある程度読み書きが多く発生するシステムでは、D2以上が適切と思われます。

Cloud SQLインスタンスの設定項目（図4）で「ファイル システム レプリケーション」を同期・非同期に設定するオプションがありました。同期レプリケーションに設定した場合、データの書き込み後、他のゾーンにデータのコピーが完了した時点で、クライアントに返答するため処理速度は遅くなります。一方の非同期レプリケーションは、レプリケーションが終わる前にクライアントに返答するので、処理速度は速くなります（表1の2、3行目または4、5行目を比較）。

バックアップを無効にしている時は、有効にしている時より速くなるという結果が得られました（表1の2、4行目または3、5行目を比較）。

料金について

課金体型は、従量制とパッケージ（定額制）から選択できるようになっています。従量制では、データへのアクセス時間によって課金されるようになっています。データベースの使用頻度が高くない場合には、低コストが期待できます。これに対してパッケージは、1日あたりの利用料金が固定されているため、データベースの使用頻度が高い場合の利用が想定されています。

データセンターの場所は、GCEやGCSと同様に、ヨーロッパ、アメリカ、アジアから、利用しているサービスの位置に合わせて選択できます。

インスタンスタイプ（階層）は2015年5月時点ではD0〜D32の7種類あり、RAMのサイズや同時接続数などが異なります。例えば、RAMは最小サイズのD0では0.125GB、最大サイズのD32では16GBとなっています。課金は、このインスタンスタイプに基づいて行われます。ストレージサイズは自動で増加していきますが、1インスタンスあたり500GBが上限です（自動で増加するのは250GBまでで、これを超える場合はGoogleに連絡しなければなりません）。インスタンスタイプの切り替えはいつでも可能ですが、数分のダウンタイムが発生します。

課金については、GCEやGCSと同様に、プロジェクト単位で行われるようになっています。一方、アクセス制限はインスタンスごとに行うようになっています。IPアドレスや、Google App EngineのIDなどによってアクセスを制限可能です。例えばGCEから利用する場合は、IPアドレスによる制限を行います。

まとめ

Cloud SQLの一番の魅力は、データのバックアップと復元や、レプリケーションの設定など、手動で行うと面倒なデータベース管理作業が、Webインターフェースで簡単にできることです。これにより、データベース管理に費やす時間やコストの大幅な削減が期待できます。また、Google App EngineでCloud SQLを使用できるのも大きな魅力です。GAEを使ってみたいけれどKey-Value型のCloud Datastoreには抵抗があると感じている開発者は、少なからずいると思います。また、システムの構造上RDBが必要な場合や、MySQLで作られている既存システムから移植する場合にも、Cloud SQLが使用できます。是非この機会にCloud SQLに触れてみてはいかがでしょうか？

【参考文献】

Google Cloud SQL 公式ドキュメント （アクセス：2015/06）
https://cloud.google.com/sql/docs/