コンテンツに移動
Google Cloud

ゲスト投稿 : Smash.gg が Firebase と GCP に移行した理由

2017年10月10日
Google Cloud Japan Team

編集部注 : Smash.gg は世界中のプレーヤーや組織に利用されている e スポーツ プラットフォームです。毎月 2,000 件ほど開催され、合計で 6 万人以上が参加するオンライン イベントをサポートしています。最近では、世界最大規模の格闘ゲーム大会 “EVO 2017” をホストしました。この投稿は Google Cloud Platform(GCP)に移行した企業をシリーズでお伝えするもので、今回が第 1 回目です。GCP に関心を持った経緯、移行の理由、移行によって得られたメリットなどを Smash.gg の共同創設者に語っていただきました。今後は、特定サービスの移行に関する技術の詳細についてもお伝えしていきます。お楽しみに。

Smash.gg 上で運営されているオンライン トーナメントでは、プレーヤーがリアルタイムで対話できるようにする必要があります。参加者が双方共にその場にいることを確認し、ゲームをセットアップし、対戦の結果を受け入れてもらうためです。また、対戦への参加やレポートにまつわる問題を解決したり、対戦相手やモデレーターとやりとりしたりするときのためにシンプルなチャット サービスも必要です。

私たちが最初に構築したオンライン対戦レポーティング サービスは、既製のチャット サービスと UI によるやりとりを利用したもので、完全なリアルタイムではありませんでした。そのチャット サービスがライブでの大会中に不具合を起こし、もっと優れたソリューションが必要だということになりました。

私たちは、WebSocket ベースのアプローチや、PubNubFirebase などを使って自らサービスを構築することを検討しました。そして最終的に、Firebase を採用することにしたのです。Firebase は幅広く利用されているのに加え、Google という “後ろ盾” を持ち、価格面でも非常に優れていたからです。

https://storage.googleapis.com/gweb-cloudblog-publish/original_images/image1zzhw.GIF
Firebase Realtime Database を使用したオンライン対戦の様子。2 人のプレーヤーがリアルタイムでゲームにチェックインし、セットアップし、レポートまで行っている。

私たちは昨年 5 月、まず Firebase から移行に着手しました。最初のリリースでは、Firebase Realtime Database をリアルタイム キャッシュのように使用し、参加者の対戦データを同期させていました。Smash.gg のバックエンド側で対戦が更新されたりレポートされたりすると、その更新された対戦データが Firebase にも書き込まれます。私たちは ReactFlux を使うことで、ラッパ コンポーネントが Firebase を確認し、更新された対戦データを Flux ストアに送信できるようにしました。

Firebase によるチャット サービスの実装も同様に簡単でした。Firechat からヒントを得たことで、最初の実装は 1 日で完了し、本番環境への対応準備もさらに 1 日あれば十分でした。

独自のソリューションを構築する場合と比較して考えると、Firebase を選択するのは当然だと言えます。開発が容易で、時間もコストも節約できるからです。Firebase により、最終的にはサーバーの負荷が低減され、レポーティングのフローもシンプルになり、対戦のエクスペリエンスは真にリアルタイム化されました。

その年の後半、Smash.gg では Firebase Cloud Messaging(FCM)の利用を開始し、Firebase のデータが変更されると Google Cloud Functions のトリガーを使ってブラウザにプッシュ通知を送るようにしました(たとえば、モデレーターのリクエストを管理者に知らせるといった目的で通知しています)。

Firebase Realtime Database と同様、Cloud Functions は非常に使いやすく、初めて使ったときには魔法のように感じました。さらに、Google Cloud Pub/SubGoogle BigQuery などの GCP サービスと Firebase をうまく連携させる方法についても、Cloud Functions を通じて深く知ることができました。

GCP への移行

今年 3 月、私たちは Cloud Functions に関する発表を見届けるためにGoogle Cloud Next '17 に参加しました。そこでわかったのは、他の GCP サービスでも、開発者のエクスペリエンスを向上させ、開発コストを下げるといった点に注力していたことです。

Cloud Pub/Sub や Stackdriver TraceStackdriver LoggingGoogle Cloud Datastore などは、Smash.gg に求められる当面のニーズを一部解決してくれるものでした。これらの GCP サービスは、既存のサービス プロバイダーの製品を補完することを目的に、私たちが自ら開発の計画を立てていたものと同じだったのです。おおまかに言うと、GCP サービスは、開発者のワークフローを改善することに重点を置き、開発やメンテナンスに要する時間の削減に貢献しているように思えました。

GCP サービスのインタラクティブなデモ(Google Container EngineGoogle App Engine と Stackdriver Trace / Logging を使ったデモ、Cloud Pub/Sub や BigQuery と Stackdriver とのデモなど)を見た後で、私たちは GCP への全面的な移行を検討することにしました。

アプリケーションの移行は 5 月中旬に開始しました。そのときに利用した GCP サービスは、Container Engine、Cloud Pub/Sub、Google Cloud SQL、Cloud Datastore、BigQuery、Stackdriver です。移行の際、コア サービスの一部を再構築することにし、Kubernetes の環境へと移行しました。アプリケーションの大半はすでにコンテナ化していましたが、以前は PaaS のようなサービスの上で動かしていたため、Kubernetes への変更はとても大きなことでした。

Kubernetes には多くの利点がありましたが(業界標準であり、クラウド インスタンスをより効率的に使える点や、アプリケーションの移植性、コードで定義されたイミュータブル インフラストラクチャなどが利点の一例です)、それへの変更と同時に、変更前の PaaS で提供されていたトップレベルのアプリケーション指標をいくつか失うことになりました。たとえば、全体的な RPS(Requests Per Second : 1 秒間に処理されるリクエスト数)や、ステータスごとの RPS、レイテンシなどです。

もっとも、こうした指標のグラフは、log-based metrics(ログ ベースの指標)や、Stackdriver から BigQuery へのログのエクスポート機能を活用することで、コンテナのログから簡単に作成することができます。別のサービスを使っても同じようなことが可能ですが、私たちにとっては GCP だけで完遂することが、GCP を評価しながら迅速かつ自由に目的を達成する方法だったのです。

Stackdriver Trace を使ったリクエストの計時や分析も GCP のセールスポイントで、過去に利用していたサービスにはなかった機能でした。ただし、Smash.gg の移行時には、PHP 用の Trace SDK が非同期トレースをサポートしていませんでした(Smash.gg のバックエンド サービスは PHP で構築されており、とても良い PHP だと思います)。その後 PHP 向けの Google Cloud SDK は非同期トレースをサポートするようになりましたが、Smash.gg では次のように GCP サービスをいくつか組み合わせ、非同期トレースのシステムを構築しました。

  1. トレースを JSON の形でログ出力するようにトレース レポータを作成
  2. その後、Stackdriver のログ エクスポート機能を用いて、トレースを Pub/Sub トピックに送信
  3. 最後に、Cloud Functions の Pub/Sub サブスクライバが REST API を利用してトレースをレポート

本番環境向けのトレース機能を実装するにあたっては、Google Cloud SDK がより最適なソリューションであることは明らかです。とはいえ、GCP サービスの組み合わせがうまく機能していることからも、GCP での開発がどれだけ簡単かがおわかりいただけると思います。

移行の結果

GCP を本番環境で運用して 1 か月が経過し、私たちは時間とコストを共に節約できたことを実感しています。全体的なコストは、確約利用割引が適用されていなくても、予備のシステム容量を確保したうえで最大 10 % 低くなりました。

Stackdriver のロギング / モニタリング機能や Container Engine、そして Kubernetes により、DevOps による作業が容易になり、チーム全体のレベルも向上しました。また、一元管理された形ですべてのログの検索が可能で、複数システム間でログを相互参照し、問題の根本原因をより迅速に特定できるようになりました。さらに、Cloud Datastore や Firebase のようなフルマネージドの従量制サービスとの組み合わせは、Smash.gg の全エンジニアにとって、GCP での開発をより簡単でアプローチしやすいものにしています。

私たちは GCP に移行したことを本当にうれしく思っており、今後のブログ投稿で移行の詳細をお伝えするのが楽しみです。皆さんが、競争力の高いゲームが好きな開発者で、GCP 上で面白いものを開発している私たちに協力してくれるのであれば、ぜひ Smash.gg までご連絡ください。Smash.gg は先ごろ Spark CapitalAccelHorizons Ventures よりシリーズ A の投資を受け、人材を募集中です。

* この投稿は米国時間 9 月 8 日、Smash.gg の Engineering Director/Co-founder である Nathan Welch によって投稿されたもの(投稿はこちら)の抄訳です。

- By Nathan Welch, Engineering Director/Co-founder, Smash.gg

投稿先