2023年8月23日~25日にわたって開催の「CEDEC2023」。本稿では23日に行われた講演“「プロジェクトセカイ カラフルステージ! feat. 初音ミク」 リアルタイム配信型バーチャルライブ「コネクトライブ」におけるリアルタイム通信基盤「Diarkis」運用の成功事例”のレポートをお届けする。

目次
  1. リアルタイム通信エンジン「Diarkis」とは?
  2. 「プロセカコネクトライブ」のインフラアーキテクチャ
  3. コネクトライブの各公演で生じたトラブルと、技術的な対策を時系列で振り返り
  4. まとめ

コネクトライブとは、「プロジェクトセカイ カラフルステージ! feat. 初音ミク」(以下、「プロセカ」)内で現在までに計6回開催されているリアルタイム配信機能を用いたライブイベント。ゲームのキャラクターたちが歌唱やトークを行い、ユーザーのコールやメッセージにキャラクターたちがその場で反応してくれる様子は臨場感抜群で、体験したことのあるユーザーは驚いたはずだ。

このイベントがどれほど多くのスタッフ・アクターによるリアルタイム連携によって実現していたかについては、昨年開催された「CEDEC2022」での講演のレポートを参照してほしい。

一方で、当初のコネクトライブは通信システムが不安定で、途中でライブが中断されるといったトラブルも少なくなかった。そして、こうした問題点はすでにほとんどが解消されている。イベントの進化の影には、リアルタイム通信のためのミドルウェア「Diarkis(ディアルキス)」の存在と、エンジニアによるさまざまな試行錯誤があった。

今回の講演では、そんな“コネクトライブの進化”の舞台裏が明かされた。本作の通信技術に興味がある人も、コネクトライブの裏側まで知りたいディープな「プロセカ」ファンも、ぜひチェックしてほしい。

登壇者はDiarkisの代表取締役CEO・高橋信頼氏と、「プロセカ」を開発・運営するColorful Paletteでシニアマネージャー/テクニカルディレクターを務める伊藤寛起氏の2名だ。

リアルタイム通信エンジン「Diarkis」とは?

そもそもDiarkisとはどんなミドルウェアなのか? Diarkisはもともと、オンラインマルチプレイなどを想定し、双方向によるリアルタイム通信をサポートするために開発されたものだという。

ネットワーク上の構造としては、ゲームの運用に用いているアプリケーションサーバーと、Diarkisの複数のサーバーが繋がり合っている“クラスタ構造”のサーバーを接続することで成り立っている。

サーバーがクラスタ構造になっていることで、いずれかのDiarkis側のサーバーが落ちてもゲーム側と繋がるサーバーが自動的に切り替わり、全体のサービスに障害が起きづらい作りになっているそうだ。また、オートスケール(負荷に応じてサーバー台数を自動で増減する機能)や“サービスを止めずに新たなコードを組み込む”といったことも可能になっているとのこと。

そんなDiarkisには複数のモジュールが搭載されており、用途別に以下のような名称がある。

・Diarkis MatchMaker:複雑なマッチングロジックでも、超高速のユーザーマッチングを実現
・Diarkis Room:バトルロイヤルなどの数百人規模のオンラインゲームでも超高速なリアルタイム通信を実現
・Diarkis Field:MMORPGなどの数千人規模のオンラインゲームでも超高速なリアルタイム通信を実現
・Diarkis Group:複数サーバーでプレイするユーザー間の大規模コミュニケーションを実現
・Diarkis P2P:高FPSが重要な格闘ゲームなどでも遅延なく超高速なリアルタイム通信を実現

これらに加え、精鋭エンジニアによるサポートも約束されているのがDiarkisの強みなのだという。

「プロセカコネクトライブ」のインフラアーキテクチャ

そんなDiarkisの機能を、「プロセカ」のコネクトライブではどのように活かしているのだろう?

コネクトライブのインフラアーキテクチャは、以下の図のようになっている。左側のストリーミングシステムが生配信用に構築されたシステムで、右側が先ほど解説があったDiarkisのサーバーだ。これらによってコネクトライブはユーザーひとりひとりの端末(User Client)に届けられている。“God's(神)”と書かれた仰々しい端末が気になるが、こちらは後ほど登場する。

コネクトライブでは、先ほど紹介したモジュールの中からDiarkis MatchMaker、Diarkis Room、Diarkis Groupの3つを活用。

コネクトライブ開催前後の待機場所でもあるロビーとライブ会場は、それぞれDiarkis Roomによってロビールーム、ステージルームとして管理されているという。

ひとつのルームに接続できる人数は最大で100人。基本的に情報のやりとりは同じルーム内でしかできないのだが、Diarkis Groupを併用することで、別々のルーム間でのスタンプやペンライトカラーといった情報伝達を可能にしているとのこと。これによって、すべてのユーザーがひとつのライブ会場で盛り上がっているような一体感を実現しているのだ。

ここでGod's端末が登場。God's端末では、ステージを暗転させたり、アナウンスを流したり、入場制限を設けるといった手動の制御をリアルタイムで行っている。これらの操作の反映にもDiarkis Groupを活用しているという。

そして、Diarkis MatchMakerはクラスタ内から各ユーザーが入れるルームを検索し、適切にマッチングするために活用。これらにより、ひとりひとりのユーザーのコネクトライブ体験が実現されているということだった。

コネクトライブの各公演で生じたトラブルと、技術的な対策を時系列で振り返り

ここからはいよいよ、コネクトライブの各公演を時系列順に振り返り、そこで発生したトラブル・技術課題や、これに対するDiarkisを用いた改善の過程が明らかとなった。

β1、β2公演

コネクトライブの本公演より前に「テクニカルテスト」として行われたβ1、β2公演。参加したユーザーならご存知かもしれないが、これらのテストでは正常な稼働はできなかった。

β1公演では実装そのものの不備や内部リソースの枯渇が問題に。β2公演ではβ1での課題に対策を講じて比較的安定した稼働を実現できたものの、一部のサーバー(Virtul Live Pod)に負荷が偏るなどして不具合が発生。対策を試みたが、解消には至らなかったということだった。

そもそもルームへのマッチングの流れは以下のようになっている。各サーバーが作ったルームにユーザーが入っていき、最初に接続されたサーバーに入れるルームが無かった場合は、Diarkis MatchMakerでクラスタ全体を検索、別サーバーにある入室可能なルームへとマッチングするという仕組みだ。β1、β2公演では、この機構が最適な動作をせず、結果的にサーバーごとの偏りを生み出してしまったのだという。

なお、こうなった原因としてはDiarkis内部に潜在していたバグが、数百のサーバーを一挙に使用したことで顕在化したのだそう。これによりクラスタの一部として認められないサーバーがたくさん生じてしまい、処理が不安定になったのだった。

ユーザーの人数に見合ったサーバーを用意できても、正常にユーザーが振り分けられなければ、偏りは解消されない。こうした偏りはバグだけではなく「ひとつのルームにより多くの人が集まってほしい」という各ルームの“賑わい”を狙った設計が想定以上に優位に働いてしまったという部分もあったようだ。

ほかにもDiarkisの内部的な問題は生じていた。本来不要なサーバー同士での通信などの発生で、CPUの負荷が非常に大きくなってしまい、こうした高負荷のときにのみ発生するバグも顕在化したのだという。

2022-06-11 Vivid BAD SQUAD

2022年6月11日に行われたVivid BAD SQUADによる1回目の正規のコネクトライブではβ公演で生じた問題を踏まえ、Colorful Palette、Diarkis双方により対策が講じられた。

Colorful Palette側では検索によりルームがほとんど作成されていないサーバーを見つけ出し、このサーバーにリモートでルームを作る“Remote Create”機能を実装。Diarkis側ではリソースの効率化による高負荷の解消と、発見されたバグの修正を実施し、ライブに臨んだ。

これらの対策をもってしても計3公演のライブでは、それぞれにいくつかの問題が発生した。第1公演ではRemote Createの導入によりかえってパケットを増大させ、ネットワークを圧迫。第2公演ではネットワークの圧迫を避けるため、β2公演に近い環境で実施して比較的安定するも、第3公演ではまたもや新たなバグが顕在化。

全公演を通し、CPU負荷が高まったことでGod'sによる制御も一部できなくなり、有料視聴コンテンツの一部が閲覧可能になってしまったりと、重大な問題も露呈してしまった。このあたりはユーザーからの指摘の声も届いており、さまざまな反省点・課題点を次回のコネクトライブへと持ち越すこととなった。

2022-10-09 2周年公演

続く2回目のコネクトライブは「プロセカ」の2周年を記念した、すべての作中ユニットが総出演するライブ。前回公演のトラブルを受け、Colorful PaletteとDiarkisが共同でタスクフォースを結成。二人三脚での根本的なシステムの見直しを測った。

まずはRemote Createをネットワークへの負荷が少ないエコな仕組みで再構築。まずは一定閾値まで最初のサーバーでルーム作成や順位付けを試みる“Current Join”方式にすることで、サーバー間の通信が減るようにしたという。共同戦線によって以前よりも深いレイヤーでの負荷試験も可能となり、アーキテクトやコアモジュールといった普段は手を加えないニッチな部分への対策も講じられた。

負荷試験の結果を活かして、さまざまなシチュエーションに対応するための機能を追加。とくに動作中の“ログレベル変更”を可能とする機能は、任意でログの情報量を絞り、情報が多すぎることで変な挙動が記録されても追い切れないといった状況を解消し、問題点の可視化に役立ったとのこと。

特定の条件で起きる問題を解消するため、“Static Group”(各サーバーで一度生成されたらなくならないグループのこと)が大量に生成された際の負荷軽減や、“User Module”(1クライアント1ユーザーに対応している基礎モジュールのこと)の側で発生するバグの発見・解消といった策も講じていった。

これらの対応が功を奏し、2周年公演は高負荷の中でも安定稼働を実現。Current Join方式によってユーザーは各サーバーへと綺麗に分散し、それでも負荷は高かったものの、ほぼ想定外の問題は起きなかった。一点、ライブ内でコール&レスポンス的に楽しめる“ペンライトトーク機能”による双方向的な大量の情報伝達による、瞬間的な高負荷が想定外のトラブルとなり、この点は次回への課題となった。

2023-03-24 MORE MORE JUMP!

年が明け、2023年3月に開催されたMORE MORE JUMP!のコネクトライブでは、より高負荷な状況でも耐えられるよう、ペンライトトーク機能の改修が課題に。

Colorful Palette側では情報量が増大する原因となっていたデータの送受信部分の仕様を変更。欠損が起きた際のリカバリ手段を設けることで、より臨機応変なトラブルへの対処を可能にした。

Diarkis側ではアプリケーションをいったん停止することなしにプロファイラーの有効/無効を切り替える仕組みを導入。必要なときに必要なプロファイラーをいつでも使えるようにし、こちら側でもトラブルの特定が容易になる仕組みが追加された。

新たなペンライトトーク機能の仕組みは以下の通り。これまではルーム間の連携とGod'sの情報収集を同一グループで実施していたが、それを分割。各ルームごとに“ペンライトデータの集計”および“集計データの各ユーザーへの反映”に用いる通信方式を変更したことで、総合的な通信量をグッと削減できたのだという。

結果として、各公演は目立った問題は生じることなく成功。ここまでのコネクトライブの経験から、不必要な部分にまでオーバースペックな技術を使わずに、各部で適切なプロトコルを導入するのが大事だという知見が得られたと振り返った。

まとめ

その後「プロセカ」では、Leo/need、25時、ナイトコードで。、ワンダーランズ×ショウタイムのコネクトライブも行い、いずれも大きなトラブルは起きずに公演は成功している。

スマートフォンのゲーム内イベントとしてはリアルタイムで送受信する情報の量・種類ともに異例の試みを行っているコネクトライブ。伊藤氏は当初、その難しさをかなり痛感したものの、例がないものだったとしても必ず成功させる方法はあるという手応えも感じられたとのこと。

そしてこの成功体験はDiarkisというミドルウェアを導入したからこそのものであり、同じエンジニアとしていっしょに課題解決に取り組んでくれた高橋氏をはじめとしたDiarkisのエンジニア陣の存在はとてもありがたかったと振り返った。

一方の高橋氏は、いくつかのDiarkis側のバグが顕在化してしまったことに関して謝罪。その上で、「柔軟なミドルウェアを目指すとそのぶん選択肢が増え、複雑で使いづらくなる」といった点を解消するためのツールの充実など、これからもDiarkisをより良いミドルウェアにするための試行錯誤は続けていくとした。

※メーカー発表情報を基に掲載しています。掲載画像には、開発中のものが含まれている場合があります。

コメントを投稿する

この記事に関する意見や疑問などコメントを投稿してください。コメントポリシー

関連ワード
  • 取材
  • CEDEC2023