モノリシック問題とサービス問題をマイクロサービス化で解決
まず手をつけたのは、モノリシックな設計に起因する問題だ。基盤のサービスの中で外せないのは認証と課金。この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には『誰よりも早くトライし、誰よりも早く失敗し、誰よりも早く立ち直ろう』という行動指針がある。この行動指針にのっとって、より良いマイクロサービス群を求めて挑戦し続けようと考えている。この行動指針に共感してくれる方はぜひ、仲間になってほしい」
最後にこう呼びかけ、セッションを締めた。
