CodeZine(コードジン)

特集ページ一覧

複雑なゲームサービス基盤の刷新でgumiが直面した壁――マイクロサービス化実現の鍵とは?【デブサミ関西2017】

【B-4】gumiのゲームを支えるアーキテクチャ設計思想~モノリシックからマイクロサービスへの変遷

  • LINEで送る
  • このエントリーをはてなブックマークに追加
2017/10/27 14:00

 2007年に設立され、世界各国でソーシャルゲームを開発、提供しているgumi。同社ではゲームに必要な「認証」「課金」などの機能を、モノリシックな設計からマイクロサービスに移行し、基盤を新しく設計している。マイクロサービス化するメリットとしては、疎結合であるため、適した技術を選択できることや再利用しやすいこと、障害を限定的にできること、置き換えしやすいこと、少人数で開発でき、品質が良くなることなどが挙げられる。しかし、デメリットもある。gumiではマイクロサービス化するにあたり、数々の地雷を踏んできたという。マイクロサービス化する際の落とし穴とは? また気をつけるべきポイントなどについて、株式会社gumi CTOの幾田雅仁氏が解説を行った。

目次
株式会社gumi CTO 幾田雅仁氏
株式会社gumi CTO 幾田雅仁氏

gumiがマイクロサービスを採用した経緯

 「会社でマイクロサービスを採用している人」

 幾田氏のセッションはこの問いかけから始まった。が、会場からの反応はゼロ。幾田氏は「この結果は予想外。このセッションでは大きいサービスを分割する話を紹介するので、ぜひ、みなさん今日の話を聞いて、職場でチャレンジしてほしい」と呼びかけた。

 gumiがマイクロサービスの採用に至ったのは、「ビジネスの要件を満たすには他の選択肢がなかったからだ」と幾田氏は明かす。gumiでは、さまざまなゲームで共通に必要な「認証」「課金」などの機能(サービス)をマイクロサービス化している。マイクロサービスは疎結合であるため、ゲームごとに言語などの環境が異なってもいい。そのため、さまざまなチームがサービスを使えるようになる。

gumiでは「認証」「課金」などの機能をマイクロサービス化しているので、それぞれのゲームはチームが得意な言語で開発することができる

gumiでは「認証」「課金」などの機能をマイクロサービス化しているので、
それぞれのゲームはチームが得意な言語で開発することができる

 また国外に拠点を設け、海外に対してもゲームを提供しているため、各国独自の仕様、例えば海外向けの課金サービスを新たに用意する必要がある。そのため、サービスの増える速度が非常に速い。「マイクロサービスならそれにも対応できる」と幾田氏は説明を続ける。物理ホストの障害が起きても、マイクロサービスなら特定のサービスが停止するだけですむ。「例えばAppleと通信をしているマイクロサービスがホスト障害で停止しても、Googleと通信しているマイクロサービスは停止しないため、Google関連の処理は停止しない」とマイクロサービスを採用したメリットを力強く語る。

 「とはいえ、マイクロサービスは銀の弾丸ではない」と幾田氏は警鐘を鳴らす。マイクロサービスではシステム全体の構成が非常に複雑になり、データも分離されて整合性がとりにくくなるからだ。さらにホップ数も増えてしまうので、システム全体の応答速度は低下してしまう。

 幾田氏はマイクロサービスへ移行する過程で、いくつもの地雷を踏んだという。「『データの整合性を守る』『システム全体の応答速度を上げる』『利用者の導入難易度を下げる』という3点を念頭に置いて設計をする教訓を得た」と語る。

gumiが出会ったモノリシック問題

 幾田氏は以上のようにセッションの趣旨を紹介したのち、gumiのアーキテクチャ変遷の解説に入った。最初の基盤サービスであるv1が登場したのは2012年。2014年にv2が登場した。そして現在v3を開発している。

gumiのサービス基盤アーキテクチャの変遷
gumiのサービス基盤アーキテクチャの変遷

 v1が登場した背景にあったのは、ブラウザゲームからネイティブゲームへの移行である。「当時はSNSプラットフォームに乗っかってビジネスを展開していた。当時のSNSプラットフォームにはユーザー認証や課金、ゲーム通貨管理、テキスト検証などの重要な機能が搭載されていた」と幾田氏は振り返る。しかしネイティブプラットフォームには重要な機能が課金しかなかったのである。

 そこで不足している部分を作ることになり、シンガポールの開発拠点が担当することになった。このときのgumi全体の考えは「できる限りの機能を共通化したい」ということ。そうすることでゲーム作りのムダが省ける。基盤技術の仕様はゲームよりも少ないので、少人数で開発でき、さらにムダが省ける。また、ライブラリではなくサービスにすることで、さまざまなチームが使えるようになる。このように考えた結果だった。こういった思考の下で開発を進め、2012年12月にはゲーム内掲示板やプッシュ通知など、必要以上の機能がたっぷり盛り込まれた巨大な基盤サービスができ上がった。

 そして10カ月間、同基盤を使ってみたところ、問題が噴出したのである。「数々の入り組んだ機能を持っているため、ゲームクライアントとの接続コードは膨大で複雑となり、ゲームAPIも膨大で複雑なコードを書かなければならなくなった」と幾田氏は振り返る。そのほかにも、「開発速度が遅い」「複雑に絡み合うバグが修正できず、障害が頻発する上に復旧も遅れる」などの問題が発生した。

 さらに、これらモノリシックの問題以外も発生した。基盤サービスはシンガポールリージョンのAWSで管理していたため、ゲームクライアントと基盤サービスの間で、海を横断する通信が頻発していたのである。しかもデータが分散しているため、整合性も崩れてしまっていた。幾田氏はサービス間で発生したこれらの問題を「サービス問題」と呼称する。このサービス問題と先述のモノリシック問題を解決するため、基盤サービスの仕組みを作り替えることになり、日本で開発が始まった。


  • LINEで送る
  • このエントリーをはてなブックマークに追加

バックナンバー

連載:【デブサミ関西2017】セッションレポート

著者プロフィール

  • CodeZine編集部(コードジンヘンシュウブ)

    CodeZineは、株式会社翔泳社が運営するソフトウェア開発者向けのWebメディアです。「デベロッパーの成長と課題解決に貢献するメディア」をコンセプトに、現場で役立つ最新情報を日々お届けします。

あなたにオススメ

All contents copyright © 2005-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5