株式会社グルーヴノーツの導入事例（前半）：モバイルのための次世代のクラウド プラットフォームを Google Cloud Platform で

（写真左: 株式会社グルーヴノーツ 代表取締役会長の佐々木 久美子さん、写真右: 同じく代表取締役社長の最首 英裕さん）

スマートフォンのゲーム市場は既に家庭用ゲーム機を超えていると言われほど大きくなり、その中でも人気のあるゲームのバックエンドのトランザクションはどれほどのものなのか、実際に運用しないことには ”想像もできないほど” なのでしょう。

こういう状況がゲームだけなのかというと、例えば自動車におけるテレマティクス分野で、数百万台の車から走行データが送られてくる状況や、年内にもより身近になってくるであろう IoT 分野でセンシング データが大量送信される状況が思い浮かびます。共通しているのは、モバイル、頻繁なアクセス、そして大量のデータ。

このような状況に当てはまる事業を始めようとしたとき、長い時間とコストを費やしバックエンド インフラストラクチャーを構築するよりも、それがウェアラブル デバイスならその利用体験に、なんらかのセンサーであるならその状況を伝えるアプリケーションに注力したいでしょうし、運用に費やす時間を事業の成長のために使いたいと考えるのではないでしょうか？

株式会社グルーヴノーツの MAGELLAN は、Google Cloud Platform を使い構築され、まさにその問題を解決するクラウド プラットフォームとして、昨年末に公開されました。その MAGELLAN について、代表取締役会長の佐々木 久美子さん、代表取締役社長の最首 英裕さんに話を聞きました。その様子を、前半、後半と 2 回に分けてお伝えします。

新しい時代に適用したコンピューター アーキテクチャーとしての MAGELLAN

2 人ともそれぞれ会社を経営してきた中で、グルーヴノーツを設立されたわけですが、設立にいたった背景と事業内容を教えてください。

最首さん: 僕らが、分散系技術を使って企業システムに取り組んでいた時、佐々木は福岡でゲーム会社を作っていて、僕のチームと佐々木のチームを一緒にすると面白いことができると思ったんですよ。なぜかというと、モバイル ゲームには未来の（サーバサイド）コンピューティングの形があるように思えたんです。モバイル デバイスが前提で、四六時中使う大勢の人から大量のアクセスがあり、そのレスポンスが要求される。その裏側では高速に分析をしたり、頻繁な機能の更新をしていく。それを見てると、これからはきっとパソコンも使われなくなって、未来の形がどんどん変わっていくだろうと。それを先取りしていく必要があると強く思って、ゲームのバックエンドに特化して事業をはじめました。

それからオンライン ゲームのバックエンドとなるクラウドサービスを提供していると、その安定したデータ収集の仕組みと、それを高速に処理するという仕組は、センサーデータや POS データといった大量のデータが絶え間なく集まるような、ハードウェアを作っている企業や、自動車向けサービスを行う企業、それに流通、特に物流データを扱う企業の用途にも共通性があって、モバイルデバイスであり、アクセス数が非常多い世界なので、製造業とか IoT 系の会社からの問い合わせが非常に多く、そういった企業にもサービスを提供しています。

MAGELLAN も、そのようなオンライン ゲームの経験から生まれたものなのですか？

最首さん: そうですね。いろいろな案件をやるなかで、一時期は 1 日ごとに数万人ずつユーザーが増えるサービスをやったりもしました。そこで知ったのが、これまでやってきた金融系や製造業の、いわゆる業務システムレベルでの大規模システム技術では、全く通用しないということ。そのくらいの凄まじいことが起きていることを実感をして、こういうことが未来にどんどん起きていくのだとするならば、たぶん今までのコンピューター アーキテクチャは全然通用しなくなる。それならば、新しい時代に適用した形を作っていこうと試行錯誤して、そこでもいろんな問題が出てきて、それを乗り越えるためにはもっといろいろなことを考えて、そういう繰り返しを経験したことからできあがってのが MAGELLAN です。

パートナーとしての Google

その MAGELLAN を動かす環境として、Google Cloud Platform を選んでいただきました。また、最首さんは Blog にもクラウド ベンダーの違いについて書かれていましたが、Google Cloud Platform を選択した理由がなんであったのか教えてください。

最首さん: 根っこにあるのは、ゲームの凄まじいトランザクションを従来の発想で乗り越えるのがとても大変だったということ。それは普通に Web サーバや、アプリケーションサーバ、DB サーバなどを置いていくだけでは済まない、もっと高いレベルでの対応が必要だったんです。もちろん Google 以外のクラウド ベンダーを知らないわけじゃないですけど、ぼくらが直面していたことからすると、違和感を感じざるを得なかった。そんな中、Google の人達と話をすると、考えているのは安いコンピューターとか性能の良いサーバとかそういう話じゃなくて、何か本質的なことを考えている気がして…

それが Google と同じインフラストラクチャーで動かせるということ、最首さんたちの経験が MAGELLAN に還元されたように、Google のサービス提供者としての経験がそのまま Google Cloud Platform に還元されているということなのかもしれません。

最首さん: だから組む相手としてふさわしく、やっぱり何をやろうとしているかを聞いておく、知っておくことで凄い勉強になって、新しい性能の良いサーバーが出ました、値段半分になりましたとかだと、あまり勉強する必要はないわけですよ。あ、凄いですね、というだけなんですけど、Google はもっと違うことを考えているので、そこは僕にとってもの凄く刺激的だし、面白いですね。

例えば、Hadoop で作ったプログラム。クロス集計的な機能を高速にしましたという類のプログラムを BigQuery に置き換えたら、とても簡単に置き換わってしまった。しかも、速度が桁違いに速く、運用コストは殆どかからない。サーバのセットアップをする必要もない。データを投入してコマンドを打つと、知らないあいだに数千台のサーバが勝手に動いて、何十億件のデータ処理をするのに 3 秒くらいで答えが帰ってきて、値段が 30 円ですと。集計を組み合わせるというレベルだったら（締め処理のようなこと）BigQuery が Hadoop の代わりになると気がついたときに半日くらい考えこみましたね、これなんなんだと（笑）。これまで結構頑張ってやってきたことが、ほんの僅かな時間で構築できて、コストはお小遣い程度。あまりにもドラスティックすぎて、みんな怖くて口にできないんじゃないかと思ってしまった。

しかもクエリーを書くのは簡単なので、僕らがプログラムを作るのではなくて、お客様に開発してもらっているんです。やってくださいって説明したらできてるんですよ。しかも日常的にプログラム組んでない人たちじゃないんです。でも BigQuery でバッチ作って流している。そういうことが目の前で起きているということを正確に理解して、受け入れないといけない。

大量のトランザクション処理は WhatsApp を参考に

あらためて MAGELLAN の話を聞かせていただきたのですが、Google App Engine のようにアプリケーションさえ作れば、あとは MAGELLAN がスケーリングだとか運用に必要なことをやってくれると理解しています。

そうですね。今の形は App Engine に似たところがあるけど Ruby on Rails で開発できる、これから他の言語プラットフォームも出していきますが、App Engine だけど Node.js で書ける、というような形です。しかも App Engine は App Engine アプリケーションを書く流儀がありますが、流儀がないのですよね。普通の Web アプリケーションとして書くとそのまま動きます、という形です。プロトコルも HTTP じゃなくて MQTT でも動いてしまう。HTTP じゃないのに何故か Web アプリケーションのように書ける。これって IoT では結構重要なことです。なぜかというと、デバイスは PC のように HTTP のようなリッチなプロトコルを自由に使えない状況にあるし、メーカーや業界独自のプロトコルだとかの存在もありますし、メモリサイズの問題や消費電力など、つまりデバイスの価格にも影響してきます。そのため MAGELLAN では通信プロトコルには依存しないような作りにしました。このおかげで、独自プロトコルを組込んでも、サーバーロジックはそのまま行けるであるとか、そういうことを考えられるようになりました。

先ほど話にあった、大量のトランザクション処理を MAGELLAN ではどう処理しているのですか？

MAGELLAN の中にトランザクション ルーターというものがあって、そこで処理しています。そこで大量のトランザクション処理をいかにこなすかというときに参考にしたのが WhatsApp。なぜ彼らはあれだけの処理を非常に少ないサーバーの台数で処理できるのか、それを調べたときに、Erlang OTP という電話交換機などの制御のための仕組みがあり、それがとても大きな効果を発揮するということを知って、じゃあその構造を見習って実装していこうと。おかげで非常に高性能なエンジンが完成しました。

最もふさわしい形として選んだ Docker

MAGELLAN で特徴的なのは Docker コンテナを使われていることだと思います。まだ実サービスとして使っているところはあまり多くはありませんが、今回 Docker を選択したというのはどういう理由からだったのですか？

最首さん: 開発に自由度を与えるにはどうしたらいいか、というときに、開発の自由度を下げて、開発流儀を縛るとやりやすくはなるんです。App Engine のように。でも自由に書けるように、いろんなライブラリを使えるようにしようとすると、プログラムソースを上げるというよりは、環境をあげられなければ、うまくデプロイできない。では、環境をどうやってあげるのか、というときに、Docker イメージを作ってあげれば、環境ごとあがるわけです。そういう形がふさわしいと使ったので、いち早く使ったつもりもなく、ただいろんな選択肢の中でこれが一番ふさわしいと選択しただけで、その準備している間に世の中が Docker ブームになってきて、あれあれ、みたいな（笑）

Google は Kubernetes をリリースしていますが、そういうものは使わずにクラスタリングマネージメントを？

最首さん: そうですね。Kubernetes がオープンソースでリリースされたのは、MAGELLAN が結構できてからで、今後だんだん融合していくのかと思います。

ユーザーにわかりやすい仕組みとしてのコンテナ

最首さんは、イーシー・ワン時代にコンポーネントという形で機能の部品化を進めらていました。コンテナも大きな単位の部品化という考え方もできるかと思います。コンテナについてどうお考えですか？

最首さん: プログラム モジュールをコンポーネント化し、再利用性を高めていくということは、うまく言った部分もあったかもしれませんが、考える粒度が小さすぎたのは問題だったのかなと。それにロジックがビューと切り離しにくく、結局うまく再利用ということろまでは踏み込めませんでした。その後出てきた流れ、SOA や、Web API、RESTful インターフェイスだとかのように、機能を比較的大きな単位で分割し、疎結合にして再利用を図るという流れは、うまくいったとは思うのですが、あの当時、やはりネットワークがボトルネックになりやすく、通信に冗長性を持たせることはなかなかできなかった。とはいえ今や、ある企業で使っている機能や、あるサービスで使っている機能を API 化することによって、機能分割して再利用性を高めるということは、当たり前のようになってきています。もっと時間をかけて考えていくべきテーマだったんでしょうね。

コンテナに関していうなら、VM で頑張る必要がなかった、ハードウェアレベルまで完全にエミュレーションする必要はなかったということだと思います。結局上位層で使っている部分というのはハードウェア I/O しているわけでもないし、もっと抽象化されているので、コンテナのような発想で十分だといえば確かにそうだと。昔 Google は VM を使ってないと聞いたんですけど、それは当たってたたわけですよね。全部ハードでやってるらしいと、それは嘘だったわけですね（笑）。

コンテナ時代の開発の仕方というのは、作っている側からするとまた違ったパラダイムなのかと思うのですが、実際に利用していていかがですか？

最首さん: そうですね、デプロイし易いというか、どうですか？開発責任者として

佐々木さん: 自分たちがどうかということより、ユーザーさんが何か作るというときに、使わせやすいかというのはありますね。ここだけ作ればいいという説明ができて、ユーザーさんでも自分が開発したいもののためには、ここだけやればいいというのがわかるので、今までインフラよりのことまで全部やらなければいけなかったことが、コンテナによって上辺だけでよくなっている、作るアプリケーションだけ見ていればよくなるというユーザー視点では、私たちがサービス提供する上では凄くよかった。

最首さん: ワーカーを開発するとき MAGELLAN に上げる前に、その Docker イメージのままローカルで動かすことができるんですよ。Web インターフェイスをエミュレートしているので、とりあえず Web インターフェイスのままテストして、これでOKとなってデプロイすると全然違うインターフェイスで動く。

佐々木さん: 技術もそうですけど、私はどちらかというとユーザーさんの使い易さの方が重要だと思っていて、そこが吸収される技術であれば、どちらかというとなんでもいいと言ってしまうタイプなんですけど、それが Docker だと本当にわかりやすい。単純にもう、そこが今は一番。

結局運用がどれだけ簡単になるか、というところですよね。

佐々木さん: 結局は技術がどうかよりも、運用のしやすさをお客様も求めるので、最初の開発で完了じゃなくて、その後継続していくものなので、ゲームもそうだし、一般のシステムもそうですけど、やっぱり継続した運用を考えたときには、メンテナンスのしやすさ。そのための人材を確保するよりは、Docker 部分だけ考えていられた方がいいですよね。

Google App Engine を使っているお客様も同じことを話していて、とりあえずデプロイしておけば、あとは運用する必要もなく、アプリケーションを良くすることだけを考えられると仰っています。

最首さん: 例えば、オンライン ゲームだと、来週からテレビコマーシャルを打ちますとなると、確実にユーザーが増えるのが見えていて、その増設規模が 100 台とか 200 台とか三桁単位で増設していったりとかで大変なんですよ。環境作って、最終的に性能とかも確認してリリースしてとか、もうそれだけで 10 時間、20 時間がまたたく間に過ぎていく。台数が多くなると、面倒見なきゃいけないことの負担はもの凄く多くなってきますし。また、サービスを止めないで機能を変えたり、あとは 例えば Apple に iOS のアプリを審査に出すと、そのために審査用のサーバを建てないといけない、でも終わったら本番に切り替えないといけないとか、そういう運用上の面倒くささ、というのは今までの企業システムでは考えられないレベルで出てくる。そういうことをいかに楽にできるかというのを MAGELLAN ではかなり考えて作っていますね。それが大変だと思ってない人には、なかなかわかりにくいかもしれませんが。

Google Cloud Platform でもそうですが、品質であったり運用を考慮した機能は、それができたストーリーに共感できる人でないと、使ってもらう前に伝えることは難しいですね。

最首さん：そうですね。

(後半に続く。)

- Posted by Google Cloud Platform Japan Team

■ Google Cloud Platform のその他の導入事例はこちらから