こんにちは。コロプラのバックエンドエンジニア部の山田です。
2022年2月16日に、『Cloud Spanner への挑戦と今』というエンジニア向け勉強会をconnpassで実施させていただきました。
当日のYouTube配信はこちらからご視聴いただけます。
勉強会の内容
今回の勉強会では次のようなお話をさせていただきました。
- Cloud Spanner 導入の裏話
- Cloud Spanner 開発・運用で得られたノウハウ
- Spannerウォームアップについて
前半(1) では、コロプラ内で当たり前のように使われている Google Cloud Spanner に関して、『そもそもSpannerとは何か』『採用までの経緯・技術的ハードル』『検証段階で発見したこと』についてお話させていただきました。
後半(2,3)では、約4年間 Spanner での開発・運用をしてきた上での『導入による変化』『開発などで得られたノウハウ・注意事項』や、負荷対策に関して『Spannerの特性』『ウォームアップと負荷試験』についてご紹介いたしました。
資料はこちらになります。
質問への回答
当日は多くの質問をいただきありがとうございました。
時間の都合により回答できなかったご質問に関してこちらで回答させていただきます。
ノード数の管理はどうしていますか？オートスケーラー等ありますか？
直近の負荷傾向とイベント等の予定を考慮してノード数を調整しています。
Cloud Spanner 公式ドキュメントではシングルリージョンで 65% までに収めるようにとありますが、弊社ではスパイクを考慮して多少バッファを持たせて 40~45% 程度になるようにしています。
また、オートスケーラーに関しては残念ながら導入していません。現在は手動での調整となります。
実運用でのSpannerは、どれくらいの秒間アクセスまで耐えられますでしょうか？
公式には以下のように書かれています。
1ノードあたり最大 10,000 QPS の読み取りまたは最大 2,000 QPS の書き込み（行ごとに 1 KB データ）を実現できます。
ただ、実際のアプリケーションでは特定のテーブルにアクセスが集中したり、クエリサイズも異なるため、もう少し控えめなスループットになる傾向があると思います。上記の数値を参考にしつつも実測が必要です。
サービス全断になったことはありますでしょうか？
こちらで紹介されているように、Spanner は p99 のテールレイテンシーが荒れることはあります。
ただ、運用中のサービスがSpanner 起因でサービス全断に至ったことは一度もございません。
Monitoring はどのようにしていますか？
CPU, read/write QPS, latency, session数あたりをよく監視しており、stackdriver_exporter を使って Grafana で確認できるようにしています。
イベント開催前にもウォームアップは実行されているのでしょうか？
イベント等により新規にインターリーブ外のテーブルをリリースする場合には、事前に本番環境に影響を与えないようにウォームアップを実施しています。
ウォームアップは負荷試験で実際の規模のリクエストを投げるだけで十分ではないでしょうか？
負荷試験によるアプリケーション経由だとアプリケーションを動かすためのリソース（ロードバランサー, DB, Redis, アプリケーション自体など）が必要になるため、直接 Spanner にクエリを投げられる専用のツールでやったほうが効率良く負荷をかけることができます。
また、コロプラのこれまでの実績では、ウォームアップなしで負荷試験を始めるとスループットが出ずアプリケーションが詰まったりしてより多くのリソースが必要になりがちでした。
そのため『ウォームアップツールでのウォームアップ』と『実際の負荷試験によるウォームアップ』を併用しています。
最後に
コロプラとしては2回目の勉強会でしたが、第1回と同様に多くの方々にご視聴いただき大変感謝しています。今後も勉強会や技術ブログを通して、エンジニアの方々に役立つコロプラの取り組みや技術情報を幅広く発信していきます。
次回はこちらの勉強会を計画しておりますので、興味を持っていただけましたらご参加よろしくお願いいたします。