gumiがマイクロサービスを採用した経緯
「会社でマイクロサービスを採用している人」
幾田氏のセッションはこの問いかけから始まった。が、会場からの反応はゼロ。幾田氏は「この結果は予想外。このセッションでは大きいサービスを分割する話を紹介するので、ぜひ、みなさん今日の話を聞いて、職場でチャレンジしてほしい」と呼びかけた。
gumiがマイクロサービスの採用に至ったのは、「ビジネスの要件を満たすには他の選択肢がなかったからだ」と幾田氏は明かす。gumiでは、さまざまなゲームで共通に必要な「認証」「課金」などの機能（サービス）をマイクロサービス化している。マイクロサービスは疎結合であるため、ゲームごとに言語などの環境が異なってもいい。そのため、さまざまなチームがサービスを使えるようになる。
gumiでは「認証」「課金」などの機能をマイクロサービス化しているので、
それぞれのゲームはチームが得意な言語で開発することができる
また国外に拠点を設け、海外に対してもゲームを提供しているため、各国独自の仕様、例えば海外向けの課金サービスを新たに用意する必要がある。そのため、サービスの増える速度が非常に速い。「マイクロサービスならそれにも対応できる」と幾田氏は説明を続ける。物理ホストの障害が起きても、マイクロサービスなら特定のサービスが停止するだけですむ。「例えばAppleと通信をしているマイクロサービスがホスト障害で停止しても、Googleと通信しているマイクロサービスは停止しないため、Google関連の処理は停止しない」とマイクロサービスを採用したメリットを力強く語る。
「とはいえ、マイクロサービスは銀の弾丸ではない」と幾田氏は警鐘を鳴らす。マイクロサービスではシステム全体の構成が非常に複雑になり、データも分離されて整合性がとりにくくなるからだ。さらにホップ数も増えてしまうので、システム全体の応答速度は低下してしまう。
幾田氏はマイクロサービスへ移行する過程で、いくつもの地雷を踏んだという。「『データの整合性を守る』『システム全体の応答速度を上げる』『利用者の導入難易度を下げる』という3点を念頭に置いて設計をする教訓を得た」と語る。
gumiが出会ったモノリシック問題
幾田氏は以上のようにセッションの趣旨を紹介したのち、gumiのアーキテクチャ変遷の解説に入った。最初の基盤サービスであるv1が登場したのは2012年。2014年にv2が登場した。そして現在v3を開発している。
v1が登場した背景にあったのは、ブラウザゲームからネイティブゲームへの移行である。「当時はSNSプラットフォームに乗っかってビジネスを展開していた。当時のSNSプラットフォームにはユーザー認証や課金、ゲーム通貨管理、テキスト検証などの重要な機能が搭載されていた」と幾田氏は振り返る。しかしネイティブプラットフォームには重要な機能が課金しかなかったのである。
そこで不足している部分を作ることになり、シンガポールの開発拠点が担当することになった。このときのgumi全体の考えは「できる限りの機能を共通化したい」ということ。そうすることでゲーム作りのムダが省ける。基盤技術の仕様はゲームよりも少ないので、少人数で開発でき、さらにムダが省ける。また、ライブラリではなくサービスにすることで、さまざまなチームが使えるようになる。このように考えた結果だった。こういった思考の下で開発を進め、2012年12月にはゲーム内掲示板やプッシュ通知など、必要以上の機能がたっぷり盛り込まれた巨大な基盤サービスができ上がった。
そして10カ月間、同基盤を使ってみたところ、問題が噴出したのである。「数々の入り組んだ機能を持っているため、ゲームクライアントとの接続コードは膨大で複雑となり、ゲームAPIも膨大で複雑なコードを書かなければならなくなった」と幾田氏は振り返る。そのほかにも、「開発速度が遅い」「複雑に絡み合うバグが修正できず、障害が頻発する上に復旧も遅れる」などの問題が発生した。
さらに、これらモノリシックの問題以外も発生した。基盤サービスはシンガポールリージョンのAWSで管理していたため、ゲームクライアントと基盤サービスの間で、海を横断する通信が頻発していたのである。しかもデータが分散しているため、整合性も崩れてしまっていた。幾田氏はサービス間で発生したこれらの問題を「サービス問題」と呼称する。このサービス問題と先述のモノリシック問題を解決するため、基盤サービスの仕組みを作り替えることになり、日本で開発が始まった。
