gumiがマイクロサービスを採用した経緯
「会社でマイクロサービスを採用している人」
幾田氏のセッションはこの問いかけから始まった。が、会場からの反応はゼロ。幾田氏は「この結果は予想外。このセッションでは大きいサービスを分割する話を紹介するので、ぜひ、みなさん今日の話を聞いて、職場でチャレンジしてほしい」と呼びかけた。
gumiがマイクロサービスの採用に至ったのは、「ビジネスの要件を満たすには他の選択肢がなかったからだ」と幾田氏は明かす。gumiでは、さまざまなゲームで共通に必要な「認証」「課金」などの機能（サービス）をマイクロサービス化している。マイクロサービスは疎結合であるため、ゲームごとに言語などの環境が異なってもいい。そのため、さまざまなチームがサービスを使えるようになる。
gumiでは「認証」「課金」などの機能をマイクロサービス化しているので、
それぞれのゲームはチームが得意な言語で開発することができる
また国外に拠点を設け、海外に対してもゲームを提供しているため、各国独自の仕様、例えば海外向けの課金サービスを新たに用意する必要がある。そのため、サービスの増える速度が非常に速い。「マイクロサービスならそれにも対応できる」と幾田氏は説明を続ける。物理ホストの障害が起きても、マイクロサービスなら特定のサービスが停止するだけですむ。「例えばAppleと通信をしているマイクロサービスがホスト障害で停止しても、Googleと通信しているマイクロサービスは停止しないため、Google関連の処理は停止しない」とマイクロサービスを採用したメリットを力強く語る。
「とはいえ、マイクロサービスは銀の弾丸ではない」と幾田氏は警鐘を鳴らす。マイクロサービスではシステム全体の構成が非常に複雑になり、データも分離されて整合性がとりにくくなるからだ。さらにホップ数も増えてしまうので、システム全体の応答速度は低下してしまう。
幾田氏はマイクロサービスへ移行する過程で、いくつもの地雷を踏んだという。「『データの整合性を守る』『システム全体の応答速度を上げる』『利用者の導入難易度を下げる』という3点を念頭に置いて設計をする教訓を得た」と語る。
gumiが出会ったモノリシック問題
幾田氏は以上のようにセッションの趣旨を紹介したのち、gumiのアーキテクチャ変遷の解説に入った。最初の基盤サービスであるv1が登場したのは2012年。2014年にv2が登場した。そして現在v3を開発している。
v1が登場した背景にあったのは、ブラウザゲームからネイティブゲームへの移行である。「当時はSNSプラットフォームに乗っかってビジネスを展開していた。当時のSNSプラットフォームにはユーザー認証や課金、ゲーム通貨管理、テキスト検証などの重要な機能が搭載されていた」と幾田氏は振り返る。しかしネイティブプラットフォームには重要な機能が課金しかなかったのである。
そこで不足している部分を作ることになり、シンガポールの開発拠点が担当することになった。このときのgumi全体の考えは「できる限りの機能を共通化したい」ということ。そうすることでゲーム作りのムダが省ける。基盤技術の仕様はゲームよりも少ないので、少人数で開発でき、さらにムダが省ける。また、ライブラリではなくサービスにすることで、さまざまなチームが使えるようになる。このように考えた結果だった。こういった思考の下で開発を進め、2012年12月にはゲーム内掲示板やプッシュ通知など、必要以上の機能がたっぷり盛り込まれた巨大な基盤サービスができ上がった。
そして10カ月間、同基盤を使ってみたところ、問題が噴出したのである。「数々の入り組んだ機能を持っているため、ゲームクライアントとの接続コードは膨大で複雑となり、ゲームAPIも膨大で複雑なコードを書かなければならなくなった」と幾田氏は振り返る。そのほかにも、「開発速度が遅い」「複雑に絡み合うバグが修正できず、障害が頻発する上に復旧も遅れる」などの問題が発生した。
さらに、これらモノリシックの問題以外も発生した。基盤サービスはシンガポールリージョンのAWSで管理していたため、ゲームクライアントと基盤サービスの間で、海を横断する通信が頻発していたのである。しかもデータが分散しているため、整合性も崩れてしまっていた。幾田氏はサービス間で発生したこれらの問題を「サービス問題」と呼称する。このサービス問題と先述のモノリシック問題を解決するため、基盤サービスの仕組みを作り替えることになり、日本で開発が始まった。
モノリシック問題とサービス問題をマイクロサービス化で解決
まず手をつけたのは、モノリシックな設計に起因する問題だ。基盤のサービスの中で外せないのは認証と課金。この2つの機能は単体でサービス化することになった。それ以外の機能については、「サービスとして開発せず、共通ライブラリとして開発するか、外部の成功しているサービスを素直に使うことにした」と幾田氏は説明する。サービス化するとデータの整合性や応答性に問題が出てしまうからだ。とはいえ、テキストの検証、ログETLなどはサービス化しているという。
次に、海を横断するキャッチボールと崩れる整合性といったサービスの問題を解決するため、「課金サービスを正しく設計し直すことにした」と幾田氏は続ける。その方策として採用したのが、ゲーム通貨を課金サービス側で管理せず、ゲーム側で管理することだった。「ゲームAPIがべき等性を保証していれば、加算した振りをしたレスポンスを返せばいい。整合性が保証される」と幾田氏は言い切る。またこの処理を繰り返しても、海を越えない通常の通信なのでゲーム全体の応答速度には影響もでない。
「これまで、自社と他社、さまざまな事例を見てきたが、ゲーム通貨の管理、いわゆるウォレットサービスと呼ばれているモノを作ろうとすると、つらい未来が待っている。ウォレットサービスを作ることはお勧めしない」（幾田氏）
こうしてサービス問題も解決。しかし、まだ問題は存在した。それは、ゲームAPIの中にプロキシーコードを書くというプロキシーコード問題である。これについては「gumi内の公式言語であるPythonにはライブラリを配布、そのほかの言語についてはドキュメントを配布している。また有志によってクライアントのSDKも開発。ゲーム開発チームから基盤開発チームに移管されて、運用されている」と幾田氏は説明する。こうして完成したv2は2014年4月にリリースされ、日本、シンガポール、フランス、韓国で使われている。
プラットフォームの急速な増加に対応する
v2リリースから3年が経過し、「わかってきたことがある」と幾田氏は言う。v2はシンプルな設計に見えるが、細部は非常に複雑になっている。その背景にあるのが、世界各国でゲームをリリースしているために対応プラットフォームが非常に速い速度で増加していくことである。それに伴いSDKやゲームAPI、認証・課金サービスのAPIが肥大化。「時間を経るごとに開発や更新するのが徐々につらくなってきた。サービスの境界線が間違っていたことに気付いた」という。
そこで今度は課金サービスから改善することになった。「サービスの境界線をプラットフォームにすることにした」と幾田氏は説明する。つまりApp Store、Google Play、Amazon Appstoreなどのプラットフォームごとに課金サービスを切り分けるのである。また、すべての課金サービスの共通部分を切り出し、新たな課金サービスを開発し易いようにフレームワーク化した。フレームワーク開発は「日本が担当した」と幾田氏。各マイクロサービスは、需要があるチームが作る。「携帯キャリア課金など、一つの国でしか需要を満たさないサービスもあるため」とその理由を語る。
この方法は一見良さそうに見えるが、プラットフォームごとにサービス化すると、通信が複雑になってしまう。そこでゲームクライアントとゲームのAPIと接続をやめてサービスをプロキシーにして直接、課金サービスと通信するようにする。つまりこれまでゲームAPIに送信していたレシートの検証結果の送受信を、フレームワークで共通化するのである。「ゲームAPIでは通貨を加算するAPIだけあればいい。今後プラットフォームの数が増えても、ゲームAPIの更新は一切発生しない。よって、ゲームAPIの開発者の負担は軽減される」と幾田氏は説明する。
認証サービスについても導入難易度を下げることを行った。認証サービスの特徴は、プラットフォームを経由しないゲストログインがあることだ。各認証サービスをプロキシーにし、ログイン時に認証トークンとユーザーIDがゲームAPIに届くようにする。そしてその後、認証トークンをSDKに返すという方法だ。ログイン後の通常アクセス時に認証トークンをゲームAPIに送ると、ゲームAPIに組み込まれている共通ライブラリが認証トークンをユーザーIDに変換するのである。
「サービスをプロキシー化しても、まだ複雑なコードが残る。ほかにもアカウントの一時停止、同一ユーザーによる複数端末の同時プレイ防止などのコードも残り続けている。納得できずもやもやしていた」と幾田氏は語る。
そこで2017年8月に開発チームに問題提起。すると開発チームから認証トークンの管理をプロキシーサービスにすべて集中させるという案が提出された。「アクセストークンから、ユーザーIDへの変換処理もこのプロキシーサービスが担っているので、ゲームクライアントは直接ゲームAPIと通信することはない。ホップ数は増えるが、ゲームAPIの開発者はHTTP Headerに常に信用できるユーザーIDが入っていると見なせるので、ゲームロジック作成に集中できる」と幾田氏は語る。
とはいえ、ホップ数が増えてシステム全体の応答速度が遅くなったり、ゲームクライアントがつらいままだったりといった懸念がある。前者に対しては「サンプルコードで実測を計測していくなど、検証していくしかない」、また後者に対しては「SDKは作り続けるしかない」と言い切る。
2017年9月現在、DMMプラットフォームの認証と課金についてのみ、マイクロサービスに変換されているが、GoogleやAppleやAmazon、Windowsストアなどのプラットフォームに関しては、少しずつ移行している段階だ。ホップ数が増える問題に関してもデバッグやロードテストをしながら、速度検証を行っている。
「v3の仕様は試行錯誤が必要。開発は志半ば。サービス改善はまだまだ続いていく。gumiには『誰よりも早くトライし、誰よりも早く失敗し、誰よりも早く立ち直ろう』という行動指針がある。この行動指針にのっとって、より良いマイクロサービス群を求めて挑戦し続けようと考えている。この行動指針に共感してくれる方はぜひ、仲間になってほしい」
最後にこう呼びかけ、セッションを締めた。
