株式会社コロプラの Spanner 活用事例

参考になった

レビュー投稿日の情報になります

株式会社コロプラ / 尾山貴康

メンバー / バックエンドエンジニア / 従業員規模: 501名〜1,000名 / エンジニア組織: 101名〜300名

最終更新日2025/06/10投稿日2025/06/10

利用プラン	ツールの利用規模	ツールの利用開始時期	事業形態
Enterprise	51名〜100名	2017年2月	B to C

利用プラン	Enterprise
ツールの利用規模	51名〜100名
ツールの利用開始時期	2017年2月
事業形態	B to C

アーキテクチャ

導入の背景・解決したかった問題

導入背景

ツール導入前の課題

自前で用意した MySQL を使ってゲームを運営していたが、年々ユーザーが増加し、負荷対策が複雑化していました。レプリケーション、垂直分割、水平分割など、一般的な対策は全て実施していました。それに伴い、分散トランザクションやレプリカ遅延の考慮など、考慮すべき要素が増えていきました。その結果、各エンジニアが本来の業務であるクリエイティブな要素に避ける時間が減り、テクニカルな要素に割く時間が大幅に増加してしまっていました。

どのような状態を目指していたか

メンテナンスフリーな運営
シンプルな運用体制
各エンジニアの負荷低減

選定理由

主な選定理由として、まずメンテナンスが基本的に発生しないことや、UIからボタン一つで容易にスケールイン・スケールアウトが可能であることも重要な要素でした。これにより、インフラ担当者のタスクが大幅に削減できると見込まれました。また、SQLに準拠している点が挙げられます。MySQLのクエリーとほぼ差がないため、既存のツールやライブラリーが大きな変更なく使えると判断しました。さらに、分散トランザクションの管理が不要であること、レプリカ遅延が発生しないこと、そしてトランザクション分離レベルがSERIALIZABLEであることによって期待できるアプリケーションコードの大幅な簡略化も、選定時の大きな決め手となりました。

導入の成果

８年近く使っていますが、ダウンタイムはほぼ発生しておらず、安定した運営が実現できています。スケーリングやバックアップなどを実施するのにほぼエンジニアの手を煩わせる必要がなくなり、作業負荷が軽減しました。グローバルトランザクションや SERIALIZABLE なトランザクション分離レベルのおかげでアプリケーション側の実装がかなりシンプルになりました。

導入時の苦労・悩み

AUTO_INCREMENT が存在しない（当時）
チームへのインタリーブなどの新概念やベストプラクティスの周知
一度に送れるクエリーのパラメーター数が少ない (950)
一度のトランザクションで更新できる量が少ない (当時 20k mutations、現在 80k mutations)
アクセスがバーストするとスケーリングが間に合わないので事前にウォームアップしておく必要がある
テーブルの追加・更新が非常に遅い（データベース作成時に作ると速い）
調査クエリーなどによるフルスキャンが怖い（今は DataBoost で解決済み）

導入に向けた社内への説明

上長・チームへの説明

上長に向けて

トップダウンで「どう思う？」といった軽い問いかけから始まった話だったので、むしろ説明を受けた側でした。良さそうだと回答したら専用のチームを作ってくれました。

チームに向けて

当時開発中のゲームに導入したのですが、プロジェクトマネージャーと上長に導入するための時間を確保してもらい、ゲーム開発チームには説明資料を作成して勉強会で共有し、協力を取り付けました。チームメンバーは MySQL の運営の苦労を知っていたので特に抵抗なく受け入れてくれました。また、移行がなるべくスムーズになるよう努力しました。まず、弊社で使用する Laravel フレームワーク用にSpannerのデータベースドライバーを開発し、MySQLのものと差し替えることで最小限のコード変更で移行できるようにしました。また変更が必要な部分に関しても専用のマイグレーションツールを作成し、できる限り手間を省けるよう工夫しました。