［GDC 2016］110万人が同時接続する「World of Tanks」のバトルを支えるサーバーアーキテクチャとは

　Wargaming.netの「World of Tanks」（PC / PlayStation 4 / Xbox One）は，同時接続者数のギネス記録を持つオンライン戦車アクションゲームだ。多数のプレイヤーが接続してリアルタイムバトルを繰り広げる裏には，それを支える高度なサーバー技術があるわけだが，いったいどんなものなのだろうか。
　GDC 2016の最終日（北米時間の2016年3月18日），「Engineering Decisions Behind World of Tanks Server」と題するセッションで，ピーク時には110万人が接続するというWorld of Tanksのサーバー概要が語られた。

「World of Tanks」公式サイト

マップを分割してサーバーの負荷を分散化

Maksim Baryshnikov氏（Solutions Architect, Wargaming）

　2010年にロシアで正式サービスがスタートしたWorld of Tanksは，ワールドワイドでサービスを展開中のタイトルとして最大規模のMOタイトルと言っていいだろう。そのサーバー技術を解説してくれたのは，WargamingのMaksim Baryshnikov氏である。

　Baryshnikov氏によると，World of TanksはBigWorld Technologyが提供している大規模オンラインゲーム向けのソリューションを用いて開発されている。サーバーは大規模なクラスタを用いており，そこで動作しているコンポーネントの設計は以下のスライドのようなものだという。

クラスターで動作している各コンポーネントの関係を示したスライド

　それぞれのコンポーネントの機能を説明しておくと，LoginAppはユーザーのログインを制御，DBAppはユーザー情報のデータベース，BaseAppはゲームのスタートと共に起動されるコンポーネントで，ユーザーとCellAppを仲介する役目を持つ。そして，CellAppがオンラインバトルを司るコンポーネントである。また，BaseAppやCellAppには，それぞれを管理するBaseAppMgr，CellAppMgrといったマネージャコンポーネントが存在している。

コンポーネントの役割分担は，このスライドのようになっている

　「それぞれのコンポーネントは，クラスタ上で別のプロセスとして動いている」（Baryshnikov氏）とのこと。ユーザーがWorld of Tanksに接続すると，LoginAppがログインを受け持ち，DBAppによってユーザー情報を参照，ゲームをスタートするとBaseAppMgrがBaseAppを起動する。そして，バトルが行われるCellAppに接続するというイメージで動作しているようだ。

ユーザーがログインしてから，CellAppに接続するまでの流れを示したスライド

　これらのコンポーネントの中でも，非常にユニークなのがCellAppだ。World of Tanksの戦場（Battle Arena）を複数の区画（Cell）に分け，それぞれを1つのCellAppが担当する形になっている。このようにして，広大な戦場のバトルで生じる負荷をサーバー上で分散しているというわけだ。
　さらに，ある区画のバトルが激しくなり，CellAppの負荷が高まったことを検出すると，CellAppMgrによってその区画が分割される。そして，新たなCellAppが起動するという。CellAppMgrは100ms（ミリ秒）単位で，それぞれの区画で起きるイベントを監視しており，負荷に応じて柔軟にCellAppを起動することで，サーバーの負荷分散を行っている，とBaryshnikov氏は説明していた。

CellAppMgrは，それぞれのCellAppの負荷が一定以下になるように監視し，しきい値を超えると新たな区画に分割してCellAppを起動する

例として挙げられたCellの変化。左から，Cell 3の負荷が高まったことで，新たなCellと分割され，新たなCellAppが起動（中央）。さらに負荷の大きさに応じて，Cellの大きさを変化させていく（左）

　戦場が区分されていて，サーバー上でそれぞれ別のプロセスとしてバトルが行われているならば，「区画の境界で問題が生じるのでは？」と疑問に思われるかもしれない。
　Baryshnikov氏によると，World of Tanksではプレイヤーを中心とした1km（500m×2）四方の正方形を「Area of Interest（AoI）」というエリアに設定しているという。このAoIはプレイヤーから見える範囲というわけではなく，「ゲームロジックの都合で設定しているエリア」。そしてプレイヤーから見える範囲は，AoIの内側になっている。

　AoIが先のCellをまたぐとどうなるかだが，隣りのCellにいる敵（など）がGhost（ゴースト）として見える仕組みになっているそうだ。

ゲームロジックのために設定しているArea of Interest（AoI）は，プレイヤーを中心とした1km四方の正方形だ。このAoIがセルをまたいだ場合に，隣りのセルにいる敵はGhostとして見える仕組み

隣りのCellの敵がGhostとして見えるように，それぞれのCellを取り囲む500m幅の区画内の情報を取得してきている。これぞ，まさしく「GHOST IN THE CELL」（！）

　BaseAppは，プレイヤーがいるCellに対応するCellAppのほかに，Ghostがいる隣りのCellのCellAppからも情報を取得している。また，隣り合うCellApp同士も情報をやり取りしているという。そして，プレイヤーが移動して隣りのエリアに入ると，Ghostがリアルな実体に切り替わる仕掛けである。

いまいるCellのCellAppから情報を得るほかに，隣りのCellのCellAppからもBaseAppが情報を得ている。それにより，500メートル以内にいる敵がGhostとして見えるというわけだ

　隣りのCellへの攻撃も同様で，CellAppが攻撃に対応する「ProjectileMover」（弾道移動とでも訳せばいいだろうか）という実体をセットし，その弾道がCellの境界を超えた先のGhostに当たったかを計算できる仕組みになっているという。

Cellをまたいだ攻撃では，ProjectileMoverという弾道を描く実体をセットしてGhostへの攻撃を判定する仕組み

110万人の同時接続に耐える堅牢なバックアップシステム

　World of Tanksにとって，戦場を区分けするCellと，そのCellでの戦いを実現するCellAppがとても重要な仕組みであるということが分かったと思う。さらに非常に巧妙だと感心させられたのは，このモジュールに分散させている構造を一種のバックアップシステムとして活用している点だ。

　あるユーザーのBaseAppは，ユーザーを囲むAoIの範囲内の敵の情報を持っている。そのため，あるCellAppがクラッシュしても，BaseAppに残っている情報からCellAppを即座に復帰させることができるそうである。一方，BaseAppにはバックアップが用意されており，仮にBaseAppがクラッシュしても復帰できると，Baryshnikov氏は説明する。

CellAppがクラッシュしても，BaseAppに情報が存在しているため，CellAppを迅速に復帰させることができるとのこと。BaseAppがクラッシュした場合には，バックアップから復帰させる仕組みになっている

　CellAppがクラッシュした場合の復帰プロセスを示したのが下のスライドだ。CellAppMgrが，クラッシュしたCellの隣りのCellを拡張して，BaseAppに残っている情報からリカバリを行うのである。スライドにも記されているように，このプロセスには1，2秒の時間がかかるが，大きな問題にならない程度の短時間で復帰できるというわけだ。

Cell 2を受け持つCellApp #1がクラッシュした場合，CellAppMgrによって隣りのCell 4を受け持つCellApp #2のエリアを拡張してリカバリを図る。リカバリするプレイヤーの位置などの情報は，BaseAppから取得できる

　さて，そのWorld of Tanksのクラスタサーバー群はどのように運用されているのだろうか。下のスライドは東欧の分散クラスタを示したものだが，モスクワやクラスノヤルスク，フランクフルト，アムステルダムにサーバー群が設置されているという。
　Baryshnikov氏によると，この分散クラスタをCAP定理※から，CPアプローチ※で運用しているという。というのも，World of Tanksにおいてはユーザー情報の一貫性が，何よりも重要だからだである。

※CAP定理とは，分散システムにおけるマシン間の情報複製の定理のこと。一貫性＝Consistency，可用性＝Availability，分断耐性＝Partition-toleranceの3つは同時に実現できないというもの。つまり，CPアプローチは可用性以外の2つを重視したアプローチを指す。

World of Tanksの東欧における分散クラスタの配置を示したスライド。4つの都市に分散させて，CPアプローチで運用しているという

　また，World of Tanksではe-SportsやClanに関連する外部サービスを行っているが，これらにはイベント駆動型アーキテクチャ（Event-Driven SOA）を構築しているとのこと。イベントをやり取りするEvent Busには，VMWareの「RabbitMQ」や「Apache Kafka」といったメッセージングシステムを利用しているそうだ。

e-Sportsなどを外部サービスで実現するために構築されているイベント駆動型アーキテクチャ。World of Tanksだけでなく，「World of Warships」「World of Warplanes」という3つのタイトルが，このアーキテクチャによるシステムを利用している

Event Busには，VMWareのRabbitMQやApache Kafakaを利用しているそうだ

　ちなみに，現在，World of Tanksは3000万人のプレイヤーを抱え，ピーク時には全世界で110万人が同時に接続してバトルを繰り広げている。ログイン数は1秒あたり200以上，最大ログイン数は1秒あたり1000を超えるという。

　こうした大規模なバトルが分散システムで動いているのだが，「ある物理マシン上で起きた（ゲームの）イベントは2ms（ミリ秒）以内には，ほかの物理マシンに伝達される」とのこと。極めて高速なモジュール群によって，クラスタが構成されていることがうかがえる。
　今回のセッションは，典型的なMOゲームのサーバー事例として，開発者にとって貴重なものと言えるだろう。もちろん，World of Tanksのプレイヤーにとっても，プレイ中にちょっとしたラグが発生したら「CellAppがクラッシュしたのかな？」などと思ってみると，ゲームをより楽しめるかも……しれない。

World of Tanksは登録プレイヤー数が3000万人，1秒あたりのログイン数はピーク時に1000を超える。世界随一のMOタイトルだ

「World of Tanks」公式サイト

4Gamer GDC 2016関連記事一覧