コロプラSpannerセッション

https://cloud.withgoogle.com/next/tokyo/sessions?speaker=393225A09B0C60CA

メリット

• SQL KVSのようなスケール性能
• ダウンタイムなしでScale-up/down
• オンラインでALTER

条件

• Spannerに適した設計にした場合のみメリットを享受できる

Cloudに適したスキーマ設計

• INTERLEAVE
• HotSpot

INTERLEAVE

• テーブルJoin
• 親テーブルと小テーブルの結合列データが同ーノード、同じスプリット上に生成される

INTERLEAVEしないほうがいいケース

• 大量なデータが有る場合
• 1INTERLEAVEあたり２Gまでなので
• 全領域を横断的に見る場合

途中からINTERLEAVEにはできない

HotSpot

気づくポイント

• SpannerのCPU使用率

• 全Spannerサーバーの平均値 　- つまり負荷を上げてもCPUが100%にならない場合はhotspotの可能性があり

• インデックスでもhotspotある

• インデックスhotspotは気づきづらい

対策

• だれかがインデックス警察になる
• より細かいメトリックスがほしい

だめな例

例えばログ系のTableでPKカラムが

• UserId(PK)
• CreatedAt(PK)

1.ログ系のデータはSpannerは使用しない

• BigQueryがおすすめ

2.ShardIdをPKに入れる

• ShardId(PK) (※SharedId == random % shard数)
• CreatedAt(PK)

Larabel用Spannerドライバー

https://medium.com/google-cloud-jp/laravel-spanner-4d9f20eaeea3

• Debug Query Log
• Slow Query Log
• FORCE_INDEXつけ忘れ

モニタリングのコツ

• 問題の切り分け
• クライアント・Serverどちらが原因？

Client

問題が起こりそうな箇所

• Google API認証
• Session Pool
• gRPC

対策

キャッシュを使い回す

モニタリング

OpenCensus Tracing

Server

モニタリング

Stackdriver Monitoring

CPU Utilization

• 全ノードの平均CPU使用率
• 4つの区分がある
• High, Low(priority)
• User, System
• 通常のDBアクセスはHigh+User
• Systemは内部データ圧縮やALTER

Request Latancies(p50, p95, p99)

• p95, p99が急上昇する場合
• 内部でSplit分散が多発している可能性

Spannerは急激な負荷上昇に弱い

• Data増加に応じて分散されるため
• 急激な負荷上昇が予測されるならダミーデータを事前に温めておく
• ただし、内部Splitは見れないので(感覚的判断になってしまう)

Query Status

• 遅いクエリの統計情報
• Select文のみの対応
• 平均スキャン行数