【レポート】バーチャルSNS「cluster(クラスター」の裏側

こんにちは、コンサルティング部の後藤です。

皆さん、AWS Summit Online 2020楽しんでいますか？今年のAWS Summitはオンラインで開催されており、150を超えるオンデマンドセッションをいつでもどこでも9/30まで視聴することが出来ます。

今回はその中から、クラスター株式会社が運営しているバーチャルSNS「Cluster(クラスター)」におけるAWS活用の事例セッションを見てきましたので、セッションレポートとして投稿させて頂きます。

バーチャル SNS の裏側

セッション概要

クラスター株式会社は、スマホや PC、VR といった好きなデバイスから数万人が同時に接続することができる、バーチャル SNS「cluster(クラスター)」の運営をおこなっています。2018 年には世界で初めてバーチャル空間での音楽ライブを実施し、2020 年 3 月にはマルチプレイ対応のゲーム空間をアップロードできる常設ワールド機能をリリース。バーチャルで"集まる"体験を再定義し、全く新しいエンタメと熱狂体験を提供し続けています。本セッションでは、クラスターでの AWS を利用したサービス構築事例をご紹介します。

スピーカー

クラスター株式会社 ソフトウェア開発部 ソフトウェアエンジニア 浦川 智洋 氏

バーチャルSNS「cluster」について

clusterとはバーチャル空間で音楽ライブや発表会等のイベントを開催し、多くの人達と体験を共有できるサービスです。
2017年6月リリース当初はバーチャルイベントプラットフォーム「cluster」としてPC/VR向けにサービスを提供していましたが、より多くのユーザにコンテンツを体験できるよう、2020年3月にスマートフォン(iOS/Android)にも完全対応したバーチャルSNS「cluster」へリニューアルしました。

バーチャルプラットフォーム時代の事例紹介

バーチャルSNSへリニューアルする前、バーチャルプラットフォーム時代のAWS構成図は以下の通りです。

• Web部分
  S3をOriginとしてCloudFrontで配信している。
  clusterのWebサイトはここから配信されており、イベントの検索や作成が行える。

• File Upload Service部分
  イベントで使用する動画、BGM、スライド、画像等のファイルがS3にアップロードされた場合、Lambdaが受け取りエンコード等の処理を行っている。

• Databases
  DynamoDB / Auroraを使用

• HTTP API部分
  外向けのAPIとなっており、Go言語で開発したAPIが積まれているECSとAPI Gateway / Lambda(C#)を使用したサーバレスAPIの2種類がある。
  サーバレスAPIではユーザがバーチャル空間で使用するアバターをアップロードするAPIとなっており、ECSはそれ以外のAPI(イベント内の特定行動やWebサイト等)全てを担当。

• Internal HTTP API部分
  ECS / ELBで構築されている内部APIで、アップロードされたファイルの登録や一部の管理オペレーションで呼び出される。

• Real-time Servers部分
  MQTTサーバ群。clusterのイベント空間内の体験はクライアントアプリケーションがMQTTサーバを通して位置情報や音声情報を他の参加者と通信することで実現している。

• Recording Service部分
  イベントアーカイブサービスとして利用（詳細は後述）

• Scheduled Batch部分
  ECS Fargate / CloudWatchEventでバッチ処理

イベントのライブ配信について

次に、当時代表的な機能である「イベントのライブ配信」がどのように実装されていたかを紹介。

当時のclusterはイベントに参加するためにはPC環境が必須となっており、参加したくても参加できないユーザが多数いた。
そこで、当時日常的になっていた動画配信をclusterでも利用することで、スマートフォンのブラウザからでもイベントに参加することが出来ると考えたが、動画配信サービスをどのように構築、運用するかが課題だった。

そこで動画配信サービスの負荷を高めないために、AWS Media ServicesとしてMedia Live / Media Storeを活用した。

動画配信サービスで必要なエンコードや配信先、監視やバックアップの設定は殆どのMedia Liveで対応できた。
また有料チケット制のイベントもあり、再生可能なユーザを制限する要件にあったが、Media Liveが暗号化HLSに対応していたため助かった。

イベントアーカイブシステムについて

当時の代表的な機能のもう一つであるイベントアーカイブシステムの紹介。

バーチャルイベントに限らず、イベントでは開催時間が決まっているが、その開催時間が参加したい人たち全員にとって都合の良い時間とはならない。
そこで、clusterではただイベント動画をアーカイブとして残すのではなく、過去のイベントをもう一度体験できる新しい体験を提供した。

イベントアーカイブシステムの基本的な戦略は「リアルタイムで保存されたデータを再度流す」
しかし、上記戦略を行うには幾つか懸念事項があった。

• 保存されたデータは必ずしもそのまま使えるわけではないため、何らかの変換処理が必要

• サーバサイドをリアルタイム配信と同じ仕組み(MQTTサーバ)を使用するのが単純だが、アーカイブ配信用にMQTTサーバが追加で必要となる。データ量もリアルタイムのイベントと同様となるため規模の大きなイベントではアーカイブ配信でも相当な負荷がかかるため構築、運用は困難

• 複数人でアーカイブを体験する仕様にした場合、シーク処理や一時停止等の仕様が複雑化するのが目に見えていた

こういった懸念事項から、イベントアーカイブシステムではリアルタイム時と同様の構成は取らず、一人でのみ体験する方針として以下の構成で構築した。

• クライアントアプリケーションと同じデータを受信するRecorder ServiceをECSで作成し、イベントに関するデータをKinesis Firehoseへ流し込み、S3にRaw Dataとして保存

• 保存されたRaw Dataは日次でバッチ処理が動き、アーカイブデータを作成

• アーカイブの実データはS3に保存し、CloudFrontで配信

• アーカイブシステムは動画配信(HLS)と似た形式で、ダウンロードしながら逐次再生が可能

しかし、このイベントアーカイブシステムは当時予定していた大規模アップデート(バーチャルSNSへのリニューアル)による変更に対応するのが困難となったため、現在は稼働していない。

バーチャルSNS「cluster」へのリニューアル対応について

次にバーチャルSNSとしてリニューアルした「cluster」について紹介。

バーチャルSNS「cluster」ではスマートフォン完全対応や従来のバーチャルイベントだけではなく、クリエイターが自由に作成できるワールド機能が追加された。

追加された「ワールド」は従来の「イベント」とは用途が異なるため、通信内容も異なる。
「イベント」では少数の演者と多数の観客で分けることができ、演者のパフォーマンスは全ての観客に届ける必要があるが、逆は必ずしもそうではない。イベントの規模が大きくなるほど、演者から観客への単方向通信が主となる。

「ワールド」では参加者が対等な関係となる。ワールド内でゲーム等を実現するためにより密な通信が必要となるため、1ワールドに参加できるのは12人までと制限が設けられている。

元々のバーチャルプラットフォームは数千人規模に対応できていたため、ベースとなる部分はリニューアル後も殆ど変わっていないが、従来のままでは安定的な運用は困難であったため、以下3点を重点的に対応した。

・ データベース(Aurora)への負荷対策としてDynamoDBの利用を拡大

スマートフォン対応による同時接続数増加やイベントの更なる大規模化が見込まれ、それに伴いAPIアクセスが増加してDBの更新処理が遅延した場合、様々な部分で影響が出てきてしまう。それを防ぐためデータベースの負荷対策が必要だった。

特に問題となったAPIの一つとして、誰が何処に接続しているかを管理するHeartBeatのAPIだった。
HeartBeatのAPIはクライアントアプリケーションから定期的に呼び出し、Auroraで接続中のユーザを管理していた。しかしイベントの大規模化や複数イベントの同時開催、様々なワールドで遊ぶユーザ増加により同時接続数が大幅に増加、結果HeartBeatの更新が過剰な負荷となってしまっていた。

そこで、接続中を管理するデータベースをAuroraからDynamoDBに変更し、Auroraの負荷を軽減した。セッション情報にはElastiCacheを用いる事が多いが、運用の単純化や既に使用していた事もありDynamoDBを採用した。

またDynamoDBではデータに有効期限(TTL)を設ける事も出来るため、有効期限が切れたセッション情報はDynamoDB Streamsを使用してLambdaで受け取り、分析に活用した。

・ MQTTサーバの負荷対策としてスケールアウト実装、及びイベント/ワールドでサーバの割り当て処理改善

clusterの安定運用にはMQTTサーバの安定化が重要。従来はイベントのみだったため、MQTTサーバをスケジュールによるスケールアップで対応できたが、ワールド機能の追加で今までの方法では安定的な運用は困難となっていた。

イベントとワールドでは求められる通信特性が異なるため、常に異なるサーバを使用する必要があった。そこで、AutoScalingGroupやSystemsManager、ECS、CloudWatchEvent、Lambdaを使用してMQTTサーバ割り当てシステムを作成し、接続数の増加に合わせ必要な数だけMQTTサーバを利用できるようにした。

今後はスポットインスタンスの活用も行い、コスト面の改善も行っていく。

・ 全体のモニタリング強化

従来はCloudWatchのみを使用していたが、リニューアルするに伴い上記機能が増えたためCloudWatchのモニタリングだけでは困難となった。

そこで、モニタリングや監視にはPrometheus/Grafanaを利用、CloudWatchのグラフもGarafanaに集約した。
また、ほぼ全てのサービスログをElasticsearchに集約。ElasticSearchを使用することでGrafanaに連携することができるためログを利用したモニタリングやアラートの設定にも活用。 ElasticSearchへの集約は本番環境だけでなく、別アカウントやAWS以外のUnity環境のログも全て集約させている。

サービス間連携の分析としてX-Rayを全体に導入しており、ElasticSearchの出力される一部ログにX-Rayのリンクを出力されることで問題解決の時間が短縮された。

まとめ

バーチャルSNS「cluster」はまだまだ始まったばかりで、今後は以下を対応していきたい。
- SNSとしての機能充実化
- より大規模なイベントの実施
- よりリアルタイム性の高いワールドの実現
等々

最後に

以上、バーチャル SNS「cluster(クラスター)」の裏側に関する事例セッションでした。私自身clusterは興味があり、何度が利用したことがありますが、裏側が知ることが出来る貴重なセッションになっていると思います。
また、リニューアル時の懸念事項や対応に関しても非常に参考になると思いますので、気になる方は是非セッションを見てみてください！