2017年2月に Google が提供開始した Cloud Spanner（以下、Spanner）。Googleが提供する様々なサービスを世界的に支えている技術ですが、国内における導入実績はまだ少なく、ノウハウの共有が求められています。

スマホゲームの開発・運用をしているコロプラでは、2017年から18年にかけて、新作および運用中のゲーム全タイトルのプラットフォームをすべて GCP（Google Cloud Platform）に移行させたこともあり、Spanner もローンチ直後から導入検討を開始。翌年にリリースされた新作タイトルでは実装に成功しました。

そこで今回は、先日の『Google Cloud Next '19 in Tokyo』にも登壇したサーバーサイドエンジニアの粟田さんと、本プロジェクトを先導した廣本さんに、Spanner の導入を決めた理由からメリット & デメリット、導入後の変化、新規プロジェクトのメンバーをアサインした際のポイントまで聞いてきました。

具体的なコードについては以下で公開中ですので、あわせてご参照いただければと思います !
◆ GitHub　https://github.com/colopl/laravel-spanner

Spanner 導入メリット & デメリットまとめ

まず、「Spannerとは」というところからお話しいただきたいのですが、ざっくり言うと「Googleのサーバー上で使える、分散データベース」という解釈で合っていますか？

廣本　非常に「ざっくり」ですけど、まあ大体そんな感じですね。あと無料枠が存在しないので、それは最初に言っておくほうが（これから導入を検討される方には）親切かもしれません。

粟田　そうですね。どういうものか検証するために、試験的に使うだけでもお金がかかるので、なかなか個人では導入しづらいというか......おおむね企業向けのシステムだと思います。ビジネスでスケールの問題に直面していないのであれば、MySQLでいいのではないでしょうか。

"スケールの問題" とは？

廣本　たとえばスマホゲームのユーザー数が大きくなったとき、基本的にはシャーディング（データベースサーバを複数のサーバーに分散させる形）で対応するんですが、新作のCMを打ったり既存ゲームで新イベントを開催したりすると、ものすごい勢いでユーザーさまが増えるんですね。

粟田　これまではユーザー数が増えるピークを予測してサーバーを準備してきましたが、それを一つ一つ設定するとなるとどうしても時間が掛かりますし、かつ急がないといけない状況下で対応することになるので、エンジニアにとっては精神的にも肉体的にも大変な負担がありました（苦笑）。

廣本　コロプラにはユーザーさまを第一に「メンテナンスタイムを設けずに、ゲームをプレイされている裏側でデータベースを分割すべき」という強い思いがあるので、かなり難易度が高くなります。かといって初めにデータベースを大きくしすぎると、ピークが終わったあとにもサーバー維持費が掛かりますし、また小さくするのも簡単ではないんですよね。それが Spanner の場合、ユーザー数の増減に合わせてサーバの大きさをすぐにフィットさせられる（シャーディングを自動で管理してくれる）ので費用を圧縮できますし、エンジニアの負担も最小限で済みます。

なにやら画期的な分散データベースのようですが、デメリットや注意ポイントはないのでしょうか。

廣本　それでいうと、ゲームの "運用" の観点では申し分ないのですが、ゲームのアプリケーションを作っている "開発" の観点ではまだ「100%素晴らしい」とは言えないかもしれません。たとえば MySQL はオープンソースで、自分のPCにインストールできるタイプのデータベースですけど、Spanner はサーバー上にしか存在しないので、自分のローカルマシンで開発しているときに Google のサーバーと通信しなければいけないんですね。インターネット越しで作業しなくてはならず、何度もデータベースにアクセスするのはエンジニア的に快適ではないのが、デメリットの一つではあるという感じでしょうか。

粟田　それも改善されるといいですよね。あと、「対戦ゲーム」とか「位置ゲー」といったゲームの特性によって注意ポイントが変わったりするので、そこの検証は必要ですね。

廣本　たとえばリアルタイムゲームのフレンド（友達システム）などは特殊な入れ方になりますね。「1つのデータを何人で触るか」というのが重要な要素としてあって、「このデータは1人しか触りません」という場合はいいんですけど、「他の人も同じデータを触ります」という場合は結構シビアに考えないといけないところがあります。どのゲームでも毎回均一にできることはないですし、MySQL と違う部分も多いので、それについては理解して作らないといけないですね。

具体的に、どれくらいのスケールだったら導入を勧めますか。

粟田　具体的なスケールというより、僕に言えるのは「オンラインゲームを運用している企業には向いているのでは」ということですね。導入すれば、限られた数のエンジニアで、安定的に運用できるようになるはずです。

廣本　ゲームの場合、小さなパブリッシャーさんが出してもバズってユーザー数が一気に増えたりしますからね。アクセスの波が大きい中で、限りなくローコストでフィットさせられるのは素晴らしいと思います。

なるほど。それ以外にも導入後の変化があったら教えていただけますか。

廣本　まず Spanner を導入したタイトルに関しては、データベース起因の障害が起こらなくなりました。これは間違いなく Spanner のおかげです。あと、データベースの台数が多ければ多いほど障害が起こるものなんですが、仮にサーバーがダウンしても自動的にサーバーを移動してサービス自体を維持してくれる仕組みも入っているので、稼働率が上がりましたね。

粟田　本来なら数人のエンジニアが何日もかけて準備しないといけないようなことが、1分くらいでできるようになりましたので、魔法のようなシステムだと思っています。

「Spanner チーム」は存在しない？
　初期メンバーが選ばれた理由とは。

ところで、Spanner の導入検討を始めたのはいつ頃なんでしょうか。

廣本　2017年2月にGoogleさんが提供開始した直後から、まず私が検証を始めました。そしてすぐに「これを導入すれば、我々の課題が解決されるのでは」という考えに至ったので、社内承認を進めました。

そして「Spanner チーム」が発足した、と。

廣本　あ、今さらですけど、「Spannerチーム」というチームは存在しないんですよ。強いて言えば Spanner に限らず、 Google Kubernetes Engine（以下、 Kubernetes）などのマネージドサービスを導入するための作業をしているエンジニアが十数名いて、社内では「新基盤チーム」と呼ばれることがありますが......それも俗称で、正式名称ではありません。

粟田　以前から同じエリアに座ってはいましたが、僕が廣本さんの部に所属するようになったのは最近ですしね（笑）。広く言うとバックエンドエンジニア（インフラとサーバーサイドエンジニア）の集まりで、新卒と中途も混ざっている感じです。

察するに「Spanner などの新しい技術に関心のある人が集まっている」という感じなんでしょうか。

廣本　いえ、そういうわけでもなくて。1人、また1人......と私がこっそり集めてきたメンバーで構成されています。そもそも当時、 Spannerに興味持ってました？

粟田　いえ。Spannerの存在自体、まったく知りませんでした（笑）。2018年の3月にOさんと一緒に呼び出されて、「データベースを乗り換えようと思っているので、その基礎となる部分、ライブラリを開発してほしい」と言われたような気がします。

廣本　そんな誘い文句でしたっけ（笑）。机を用意したのはなんとなく覚えてるんですけど。

粟田　はい。ある日とつぜんOさんと隣の席になりました。新しいデータベースなので、もちろん関連書籍などもないわけで......ひたすらGoogleの公式ドキュメントを読み込んで、2人で相談しながら実際に組んでみて、テスト用のサーバーで試す......ということを繰り返しました。

粟田さんとOさんを初期メンバーとして呼んだ理由を教えていただけますか。

廣本　整理して答えますと、2人に初期メンバーになってもらったのは
　1　新しいテクノロジーに興味がある
　2　ソースコードの綺麗さが一定水準を超えている
　3　ライブラリを書くための知識および実務経験がある
　4　アプリケーションを書いたことがある（＝ゲームでどう使われるかを想像して取り組める）
　5　ゴールまで持っていける力がある
......というポイントをクリアしていたからなんですが、粟田さんは元気がいい、よくできる若者代表で、Oさんは中途代表という感じでした。

粟田　補足しますと、Oさんは複数のゲームの運用に携わった後、Zend Framework のサポートが切れるタイミングで次のフレームワークとして Laravel を選び、コロプラのゲーム開発を容易にするためのライブラリを作った方です。

廣本　そして粟田さんは新卒サーバーサイド開発研修試験の最高得点者でしたよね。40〜50名くらいいる新卒エンジニアのうちのトップでしたから、ものすごく覚えています。

粟田さん、Oさんともに力強いメンバーだったわけですね。

廣本　はい。しかしライブラリ開発が進むうちに2人では足りなくなりまして、社内の精鋭たちに少しずつ声をかけて......今に至ります。導入を決めた当初は「次の新作を Spanner 化します」という明確な目標がありまして、MySQL で開発していたものを Spanner に置き換えた状態でローンチしました。そしてその後も、"新作をローンチするときに新しいテクノロジーを検証するエンジニアたち" という感じで、ゆるく結合している感じです。

改めて、Spanner の導入を振り返る。

改めて Spanner 導入を振り返って、どんなことを思いますか。

廣本　コロプラのエンジニアたちの中で、ある種、国策に近いくらい大事なプロジェクトでしたが、一定の成果が出たのではと思っています。

粟田　"国策" ですか（笑）。......でもたしかに、バックエンドエンジニアの数が限られている中で新作が増えていくことを考えると、切実な課題だったかもしれませんね。

廣本　始められるタイミングも限られていましたしね。コロプラでピュアにパブリッシングもやっている新作でまず行うことができて、それから今、また大きな新作に向かっているのはものすごく価値があったなと。

粟田　そうですね。今後も新しいプロジェクトはどんどん Spanner で作られていきますので、社内はもちろん、グループ会社の方にもノウハウの共有などをしていければと思っています。個人的に本も書き始めていますし、外部発表なども積極的にしていきたいですね。

廣本　業界に向けて、オープンソースも公開しているしね。Spanner に限らず、 Kubernetes などの新しいテクノロジーを使うことによって仲間になってくれる人もいるので、今はものすごくいい傾向にあると思います。

Spannerを導入したことで、好循環になっているんですね。最後に、このプロジェクトに関連するところで、コロプラらしい教訓のようなものがあったら教えていただけますか。

廣本　うーん...... "将来のデファクトスタンダードになりそうなものに、世の中より少し早めに、必要に駆られてアクセスしていった" という点はコロプラらしい気がします。

粟田　ああ、なんとなくわかります（笑）。

廣本　この言い方が社外の方に伝わるかわかりませんが......あえて言うとコロプラのスタンスって、ただ "新しい技術" というだけでは導入しないというか、今まで使ってきた技術で実現できるものであれば、オーバーヘッドがかかるだけなのでわざわざリプレイスしないんですね。しかし一方で、ゲームで実現したいことと技術の進化が合致する場合は導入してきたというか。

粟田　これまでもネイティブゲームにチャレンジするときは Unity を入れたり、リアルタイムゲームを作るときは Node.js を入れたりとか、要所要所で新しいものを入れてきたと伝え聞いています。

廣本　そう、だから Spanner も新しい技術とはいえ、半分は必要に駆られて入れた気がします（笑）。

粟田　そういう中で、"今こういう人に入ってほしい" 具体的なイメージってあります？

廣本　うーん、今はそれなりに上手く回っているので、「出会った人の中に面白い人がいれば」という感じですね。仮に明日なにか問題が起きても、今いるメンバーにお願いしたら解決できそうという心強さはあるので。

粟田　正式なチームではありませんが、いろんな技術に長けた人が集まっていますからね（笑）。

廣本　あとは漠然とした言い方になりますが、尖ったところがあって、コロプラのテクノロジーを推し進めてくれそうな人には常に会いたいと思っています。

"尖ったところがあって、テクノロジーを推進するような人" が入社されたら、またお話を聞かせていただきたいと思います。今日はありがとうございました！