コロプラが大切にしているポリシーと新技術導入後の構成について
「クイズRPG 魔法使いと黒猫のウィズ」「白猫プロジェクト」「ディズニー ツムツムランド」「バクレツモンスター」など数々のヒットゲームアプリを輩出しているコロプラ。その組織構成は、ゲーム事業を担うプロデューサー・ディレクター・プランナーが所属する「エンターテインメント本部」「白猫黒猫本部」と、エンジニアが所属する「エンジニアリング本部」、デザイナーが所属する「アート本部」に分かれており、インフラエンジニアはこれらとは別の組織に在籍しているという。この中で廣本氏がマネジメントしているのは、エンジニアリング本部のサーバーサイドだ。
「2年ほど前に今の機能別組織に変更しました。事業部制の頃は、各事業にエンジニアやデザイナーがひもづいて所属していましたが、ノウハウの共有が薄くなったり、人の流動性が下がってきたりしたからです」（廣本氏）
コロプラにはエンジニアリングの観点で3つの特徴があるという。1つ目は「これまでに出したものと近いゲームはあまり開発しない」。いろいろなユーザーに遊んでもらいたい思いがあり、似たゲームの開発はあえて行わない。エンジニアからすれば、ゲームのコア部分に関して使い回せるものが少ない分、大変さがある。
2つ目は「基本的にサーバーのメンテナンスはしない」。メンテナンスをすれば少なからずユーザーが確実に減る事実に基づき、できる限りメンテナンスはしないといったポリシーがある。
3つ目は「他のプラットフォームに移行できなくなるようなマネージドサービスは使わない」。これまで、マネージドサービスではチューニングポイントが限られてしまうため、使わないという選択をしてきた。
そんなコロプラの新しい技術について、何から何へ移行したのか、それぞれメリットとデメリットを挙げながら見ていった。
PHPのZend FrameworkからLaravelへの移行
- メリット：ライブラリの最適化・不要機能の棚卸し・トレンドな機能が利用できる。
- デメリット：フレームワークを並行することになり、過去タイトルとの二重管理が始まってしまった。
MySQL on VMからGoogle Cloud Spannerへの移行
- メリット：スケールアウトorダウン時のオペレーションが簡単で、大幅にオペレーションコストを削減できた。基本的にメンテナンスがないので高い可用性を得ることができた。
- デメリット：Spannerを採用した事例が少ないので、ノウハウがない。ローカルエミュレータがないため、ローカル開発もインターネット越しでSpannerに接続する必要があり、遅くなる。 Spannerは無料枠がないのでローカル開発もお金がかかる。これから改善していくと思うが、負荷が上がったときの細かいメトリクスがあまり見られないものも多く、問題発生時の理由がわかりにくい。
VMからGoogle Kubernetes Engine（＋Spinnaker）への移行
- メリット：オートヒール/オートスケールという非常に便利な機能がある。アプリケーションサーバーの増減のオペレーションが楽。
- デメリット：もともとSCPでファイルを転送していたものが、イメージのコピーという形に変わるので、デプロイにかかる時間が増加した。
新技術で動いているのは直近でリリースされた2タイトルのみであり、新技術導入以前のタイトルは元の構成で動いているというが、新技術になってからの構成は以下の図の通りだ。
フレームワークのサポート切れをきっかけに新技術導入へ
続いて導入の経緯とその過程を見ていこう。そもそもコロプラで新技術に挑戦することになった最大の理由は、フレームワークのサポート切れだった。
その際言語は、社内に書ける人が多いことからPHPを選択した。いくつかのフレームワークを検証した結果、ロングタイムサポートのあるLaravelを採用することに決定。当時開発していた新タイトルをLaravelで開発したところ、特に大きな問題が起きることもなく2017年10月に無事ローンチを果たしている。
これと並行してGCPへの全面的な移行を会社として決定していた。ライブマイグレーションをはじめとするGoogleのテクノロジーをフルで使いたいからだ。その過程で、これまで使ってこなかったマネージドサービスを積極的に活用していく方針も決まった。
Laravelを使った初のタイトルをローンチする直前にGoogle Cloud Spannerが発表された。これは、データベースを含めてできる限りメンテナンスはしないという、コロプラのニーズに非常にマッチしていたため、Spannerを導入するためのサーバー基盤チームが結成された。
廣本氏がチームメンバーとしてアサインしたのは、次の5人のメンバーだ。
- サーバーエンジニア マネージャー（運用に詳しい）
- サーバーエンジニア メンバー（Laravelの拡張をやっていた人）
- サーバーエンジニア 新卒3年目
- インフラエンジニア リーダー 新卒4年目
- インフラエンジニア 新卒3年目
導入のターゲットは、半年後にローンチされるタイトルと決めた。作業が進むうちに、運用ツールの開発や負荷試験の準備をするために、次の3人を増員した。
- サーバーエンジニア 中途（スカウトで入社）
- サーバーエンジニア 新卒1年目
- インフラエンジニア 新卒4年目
「もともとGKEを入れることは計画に入っていなかったが、ローンチ2カ月前にSpannerの導入がほぼ完了し、次にSpannerを導入するタイトルの状況を考えると、どうしてもGKE化もしたい欲が出た」と話す廣本氏。
「GKEの導入を試せないだろうか」とインフラメンバーにお願いして実現したが、のちにメンバーが社外発表で「ローンチ2カ月前にGKEを導入させられた（笑）」と話しているのを聞き、「自分としては強引に言ったつもりはなかったけれど、自分の立場を考えると伝え方はもう少し気をつけなければといけなかったと反省しています…」と当時を振り返った。
その後、ローンチ前に細かい問題はありつつも、Spanner +GKEの構成で問題なくローンチに成功したのが2018年8月。同年10月に控えていた次のタイトルもSpanner +GKE化した。
新技術導入において大切にしたい5つのこと
一連の新技術導入の体験から得た気づきとして、廣本氏は次の5つのポイントを挙げた。
1．若い人にチャレンジしてもらおう
学生時代にインフォメーションテクノロジーを学んでいる最近の新卒はかなり優秀で、授業やインターンではやりの技術を学んでいるケースも多い。若い人は新しい技術を吸収するのが速く、やる気もある。シニア層が一緒にいて気づかされることも多く、チームに活気をもたらす。経験者だけでチームを構成すれば成功の確率は上がるかもしれないが、将来的には組織として弱くなるはず。少しずつでも若い人をチームに入れて、チャレンジさせてあげることが大切だ。
2．事業における課題からテクノロジーを選定しよう
興味だけで採用したテクノロジーをプロダクトに導入すると泣きを見ることになる。今回のSpannerに関しては、事業課題にかなりフィットしていた。新たにテクノロジーを追いかけ、興味があるものを触りつつも、プロダクトで使うときは事業課題にフィットしているものを選定すべきだ。選定基準は会社のポリシーや文化など、多様な要因から考える必要がある。
3．小さい変化を積み重ねて大きな変化につなげよう
フレームワークの変更といった、あまり大きなリスクのないところをきっかけに新しいテクノロジーへ挑戦した後、プラットフォームの移行という中規模な改革を経て、マネージドサービスを利用する流れだった。小さな成果を確実に出すことで、大きな変更を認めてもらいやすくなった気がしている。データベースの移行はかなり不安が大きかったが、いけると思ったときには意識的に前のめりになって、強めにアクセルを踏んだことが良かったと思う。
4．最終目標を常に共有しよう
新技術の導入はエンジニアリングとして面白いところだが、実際に導入するとなると、細かい問題が出てきて疲弊したり、本当にこのテクノロジーを入れるべきだったのかと、途中で迷いが生じてしまったりすることもある。最終的にどういったアーキテクチャーにしたいのか、導入するメリットなどについて、雑談レベルでもいいので定期的にみんなで共有することが大事。
5．足元の課題に注力しすぎて、未来の課題をないがしろにしないようにしよう
おそらくエンジニアが余っている企業はほとんどないだろう。マネージャーは既存の業務に目がいきがちで、その状況を知っているがゆえに、そちらの優先度を上げてしまう。ダイナミックなことをやろうとすると、どうしても目の前の人たちに我慢してもらう必要が出てくる。しかし、今のままでは未来はもっと悪くなると考えて、勇気を持って慎重に人を動かさなければならないと感じた。マネジメントする人のマインドチェンジが必要。
最後に廣本氏は、今後コロプラで挑戦したいことについて、次のように語った。
「コロプラはたくさんのゲームを作っていて、開発のスピードアップやコストダウンのために、再利用性の高いマイクロサービスを作りたいと思っています。また、長く運用しているタイトルが増えてきて、定常的にやることが増えているので、やることを減らして新基盤のチームを大きくしていきたい。そしてコロプラは、GoogleのCREによるワークショップを受けたアジア初の会社として、SREの取り組みを始めているので、ゲーム開発におけるSREをしっかりとやれる会社にしていきたいです」
お問い合わせ
株式会社コロプラ
