20170822 普通のエンジニアが【Cloud Spanner】使ってみた

© 2017 SERIALGAMES inc.
普通のエンジニアが
【Cloud Spanner】使ってみ
た
1
株式会社シリアルゲームズ荒井

© 2017 SERIALGAMES inc. 2
株式会社シリアルゲームズ
http://www.serialgames.co.jp/
秋葉原で（主に）ゲーム開発しています
・ラーメン魂
・ガンスリンガーストラトス３ゲーム連動モバイルサイト
・魔法科高校の劣等生 LOST ZERO
・ファイナルファンタジーレジェンズ２
・ディシディアファイナルファンタジーオペラオムニア
・にこにこ侵略パズルピタッチ！
サーバアプリケーション：Java＋Tomcat＋MySQL＋Redis＋etc.

自己紹介
サーバサイドエンジニア
荒井翔地
1985年生まれ大阪府出身
2014年株式会社シリアルゲームズ入社
・ソーシャルゲームのサーバアプリケーション開発、運用
・Javaは3年くらい
趣味：フットサル、マラソン、トレラン、登山、旅行

Cloud Spanner とは？
4

GCP(Google Cloud Platform)のサービスのひとつ
2012年？〜 Google社内で使用
2017年2月15日 GCPでのβリリース
2017年6月17日北米リージョンGA
2017年7月16日東京リージョンGA

GCP(Google Cloud Platform)のサービスのひとつ
・完全に管理されたミッションクリティカルなRDBMSサービス
・グローバルスケールの整合性、ACIDトランザクション、SQL
・数百台、数千台に水平スケーリング可能
・99.999%の可用性
・Google社内での長期の運用実績（AdWords, Google Play）

大規模アクセスが
継続的にあるコンテンツに最適
7

大規模アクセスが継続的にあるコンテンツに最適
RDBMSとして使える上に自前でスケーリングを考える必要がない
・ノード数を増やせば自動でシャーディングされ、理論上無限にスケール可能
・性能は他のクラウドデータベースと同等に出る
（※ただしSpanner特有のクセを設計で補う必要がある）
・BigTableやDatastoreのデータ構造の上で動くRDBMS

BigTableのアーキテクチャ
Frontend Server Pool
Cloud BigTable Cluster
Colossus
Node
Shared Log
SSTable SSTable SSTable
Client
Node
Shared Log
Client
Node
Shared Log
Client

Ｓｐａｎｎｅｒ特有のクセ
10

Spanner特有のクセ
１．auto_incrementはNG
２．アクセスするテーブルをインターリーブする
３．インデックスはカバリングインデックス
４．カラム追加はFastDDL
５．Spannerのトランザクション
６．急激なUU増加は・・・？
７．集計・分析は向いてない
８．フェイルオーバー気にする必要ない。つまり・・・

１．auto_incrementはNG【重要！】

auto_incrementはバッドノウハウ
・auto_increment オプションや serial型に相当するものが無い
・Spannerでは単調増加 or 単調減少な主キーはNG
・HotSpotが発生する
・主キーを分散させることでデータが分散される

非シーケンシャルなIDを試してみた
・IDをアプリケーション制御で auto_increment
・１ノード〜５ノード：ほとんど性能が上がらず
・IDをINT64の範囲で無作為（かつユニーク）
・１ノード〜５ノード：ほぼ線形に性能があがるように

２．アクセスするテーブルをインターリーブする【超重要！！】

２．インターリーブ
外部キー制約のようなもの
・Spannerではすべてのクエリは自動的に分散処理される
・インターリーブしておくと、
物理的にまとめて格納・トランザクション処理される
・「使うとより速い」的なものではなく、
Spannerを使う以上は「ほぼ必須」なもの

player_id player_name
1 Arai
2 Obata
3 Maruyama
Relational Data Layout
player_id rule arm_front
1 Yagura C+
1 Area B
3 Hoko A-
※某ゲームとは無関係です
player player_arm_front

InterLeave Data Layout
1 Arai
1 Yagura C+
1 Area B
2 Obata
3 Maruyama
3 Hoko A- ※某ゲームとは無関係です
1 Arai
2 Obata
3 Maruyama
1 Yagura C+
1 Area B
3 Hoko A-
player
player_arm_front

BigTableのアーキテクチャ
Frontend Server Pool
Cloud BigTable Cluster
Colossus
Node
Shared Log
Client
Node
Shared Log
Client
Node
Shared Log
Client

CREATE TABLE player (
player_id INT64 NOT NULL,
player_name STRING(64),
player_info BYTES(MAX),
player_comment STRING(1024)
) PRIMARY KEY (player_id);
CREATE TABLE player_udemae (
rule INT64 NOT NULL,
arm_front STRING(64)
) PRIMARY KEY (player_id, rule),
INTERLEAVE IN PARENT player ON DELETE CASCADE;

サロゲートキーは使えないぞ！
21

・セカンダリインデックスによるアクセスではインデックスキー列と主キー列しか参照
できない
→ 強制的にカバリングインデックス
・STORINGインデックスというものもある
ビューのようなもの

CREATE TABLE player (
player_name STRING(64),
player_info BYTES(MAX),
player_comment STRING(1024)
) PRIMARY KEY (player_id);
CREATE INDEX storing ON player (
player_name
) STORING (
player_info,
player_comment
)
３．インデックスはカバリングインデックス－ STORINGインデックス

・ALTERでのカラム追加はテーブルの大きさに関係なく一瞬
ただし NOT NULL 指定ができない
・スキーマ変更は即時、レコードへの反映はアクセス時
≒ Amazon Aurora の FastDDL

重くなりそうな設計・処理は禁止？
27

アルゴリズムの詳細は割愛。他を参照してください＞＜
トランザクションの種類
・Read-Onlyトランザクション
参照のみであればこちらを使う
・Read/Writeトランザクション
書き込みする場合はこちらを使う
・（ただのReadもある）

自動リトライ（クライアントライブラリに組み込まれた挙動）
・Txは正常にcommitされるまで何度もリトライされる
・必ず最初のクエリからリトライされる
分離レベルはシリアライザブル？
・並行したTxの厳格なアボート＋クライアントライブラリでの上記挙動も含めてよ
しなにやる仕組み
・ロストアップデートは発生しない
・明示的なロックはできない
・分離レベルの変更も、もちろんできない

５．Spannerのトランザクション(自動リトライ)
Cloud Spanner API でトランザクションを使用するときは、関数オブジェクトの形式でトランザクションの本体
（つまり、データベースの 1 つ以上のテーブルに対して実行する読み取りと書き込み）を定義します。Cloud
Spanner では、トランザクションが commit するまで、または再試行不可能なエラーが発生するまで、関数の
実行を繰り返します。
static void writeWithTransaction(DatabaseClient dbClient) {
dbClient
.readWriteTransaction()
.run(
new TransactionCallable<Void>() {
@Override
public Void run(TransactionContext transaction) throws Exception {
// selectする
Struct row = transaction.readRow(“player_arm_front”, Key.of(1, “Yagura”));
long armFrontPoint = row.getLong(“point”);
// 条件にもとづいてupdateする
if (armFrontPoint <= 900 && armFrontPoint < 1000){
transaction.buffer(
Mutation.newUpdateBuilder(“player_arm_front”)
.set(“player_id”).to(1)
.set(“rule”).to(“Yagura”)
.set(“arm_front”).to(“B+”)
.build());
return null;
}
}
}); // 問題なければcommitされる
}

６．急激なUU増加
データのシャーディングに関して
・インターリーブされるキーに対して一定量のデータがたまることでスプリットされる
・たまり始めてから３０分〜６０分ラグがある
・データが十分たまることで性能が出てくる
・UUの急激な増加をさばきたいサービスには向いていないかも

７．集計・分析
向いていない
・インターリーブされたキーに対する自動シャーディングがSpannerの特徴
・ユーザ毎の処理の負荷分散、スケーリングが本業
・集計、分析はほかに向いているサービスに任せよう
・GCPならBigQuery、BigTable

８．フェイルオーバー
全部やってくれる
・・・逆にいうと
・アプリケーションレベルでの致命的ミスがリカバリできない？
・巻き戻し＋ロールフォワードの代わりになるものは？

まとめ
38

Spanner使ってみた結果
・フルマネージドのスケーラブルなRDBMS
・実際の使い勝手はRDBMSと結構違う
・大量のアクティブユーザを抱えるサービスなら向いてる

・Unityエンジニア
・サーバエンジニア
秋葉原でゲーム開発したい人、お待ちしてます。

ご清聴ありがとうございました。
41

20170822 普通のエンジニアが【Cloud Spanner】使ってみた

Recommended

Recommended

More Related Content

Featured

Featured (20)

20170822 普通のエンジニアが【Cloud Spanner】使ってみた

Editor's Notes