I/O Adventure Google Cloud アーキテクチャ

※この投稿は米国時間 2022 年 7 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

2020 年以来、主催者、講演者、参加者の誰もが、生活や仕事に対するアプローチを新たに考え直す中で、会議の多くはすべて、または一部がオンラインで行われるようになっています。Google I/O Adventure では、現実世界のイベントの良い部分をデジタルの世界に持ち込んだ、バーチャルな会議を体験できます。

I/O Adventure では、イベント参加者はプロダクトデモの視聴、Google 社員や他の参加者とのチャット、バーチャル アイテムの取得、デベロッパー コミュニティとの交流、個人用アバターの作成、イースター エッグの発見ができます。

この投稿では、Google Cloud を使用して I/O Adventure エクスペリエンスをどのように実現しているかについて詳しく説明します。

フロントエンドは、参加者が一種の「オフライン モード」で、I/O Adventure を単独で楽しむのに十分な静的アセットで構成されています。

ブラウザのグラフィックスとアニメーションは、一般的なライブラリ（React、PixieJS、GSAP、Spine）を使用してレンダリングされています。

もし、I/O Adventure で提供されるのが、静的なアセットと外部リソースへのリンクだけを含む「オフライン モード」にすぎないのであれば、バックエンドは最小限のウェブサーバーで十分です。

言うまでもなく、他の参加者と同じ世界に浸り、テキスト チャットやボイスチャットで交流する方がより楽しめます。

このマルチプレーヤー型のオンライン エクスペリエンスを実現するには、ゲームサーバーを Google Kubernetes Engine（GKE）のステートフル Pod としてデプロイした、より高機能なバックエンドが必要でした。

この会議の世界地図は大きく、下の図のように 12 種類のゾーンがあります。

この地図の各ゾーンでは、それぞれ独立した Pod が使用されています。

つまり、ゾーン（仮想世界での所在地）に応じて、任意の参加者が単一のゲームサーバーに接続されます。

トラフィック量が多いときは、各ゾーンに複数あるシャードの一つに参加者がディスパッチされます。

I/O 2022 では、イベント開始前に多くのシャード サーバーを立ち上げ、必要なときにすぐに使用できるように、オーバープロビジョニングすることにしました。スケーラビリティに関する戦略は、容量のしきい値に達するまで参加者をシャードに接続し、その後、次の空のシャードを使い始めるというシンプルなものでした。

シャード サーバーはステートフルです。それぞれが独立して小さな世界を動かしていて、他のシャードとの通信は最小限に抑えられています。シャードの状態（出席者の現在位置など）は、シャード サーバーの実行ファイルによってメモリ内に維持され、Go で記述されます。

シャード サーバーは、一部の情報（例: 特定のシャードに接続している参加者の人数）を中央サーバーと共有し、中央サーバーは新しい参加者をシャードにルーティングする役割を担っています。この情報は、グローバルな Memorystore for Redis インスタンスに保持されます。

参加者のクライアント ブラウザがシャードに割り当てられると、シャード サーバーと WebSocket 接続を確立して、エクスペリエンス全体を通じて双方向で通信を行い、参加者のアクションを送信し、環境状態の更新情報を受信します。

各 GKE ノードには、音声サーバーとの通信に使用されるローカル Redis インスタンスがあります。

アーキテクチャを簡素化するため、すべてのサーバーは同じ Google Cloud リージョン（us-central1）に配置されています。この設計を選択することで、すべてのサーバー コンポーネント間で低レイテンシの通信が実現します。また、ヨーロッパ、アフリカ、アジア、オセアニア、南米の参加者は、遠く離れた海外のサーバーに接続することになりますが、他の参加者の動きやテキスト チャットのメッセージのやり取りなどで発生するレイテンシは最大で数百ミリ秒と許容範囲内なので、問題ありません。

I/O Adventure にアクセスするには、参加者は Google アカウントでログインする必要があります。これには、Firebase Authentication サービスを使用しています。すべてのアバターは、帽子、肌の色、ハンド アクセサリーなどをカスタマイズできます。カスタマイズされたアバターの特徴や、ゲームの進行状況、完了したクエストなどを含む、参加者のプロフィールは、Firestore ドキュメント データベースに保存されます。また参加者は任意で、Google デベロッパー プロフィールを自分のアバターにリンクさせてバッジ関連の情報を提供し、他の参加者に示すことも可能です。

I/O Adventure のコアサーバーやコンポーネントに加え、この会議では以下のような動的要素も活用されています。

• 技術セッション（YouTube）

• Flutter コーディング チャレンジ（DartPad）

• ゲーム内エクスペリエンス（マテリアル デザイン、Google Cloud、Google Pay など向け）

• 他のコンテンツ（インタラクティブな体験、Codelab、ドキュメント）を新しいブラウザタブで開くリンク

こうしたインテグレーションの多くは、I/O Adventure のフロントエンド（つまりブラウザ）で直接処理され、コアサーバーのアーキテクチャから切り離されています。

まとめ

I/O Adventure のウェブ エクスペリエンスの構築は、Google 社員である Tom Greenaway と Google I/O チームが主導し、Set Snail スタジオの才能あるデザイナーとデベロッパーによって実現した並々ならぬ努力の賜です。

結果は上々でした。サーバーはすべて Google Cloud 上で完全にホストされていて、負荷に適切に対応し、ソーシャル メディアの反応は非常に好意的なものでした。人々は、バーチャルな形であっても、アイテムが大好きだということがわかりました。