【CEDEC 2021】真のグローバル版を実現した『シノアリス』が「ワールド統合」の裏側を大公開！　24時間に渡るメンテナンスで起きたトラブルや解決法も紹介

コンピュータエンターテインメント協会（CESA）は、8月24日～26日の期間、オンラインにて、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2021」（CEDEC 2021）を開催した。

本稿では、8月25日に行われた、ポケラボ・ゲーム事業本部／エンジニアマネージャーの覚張泰幸氏による「SINoALICE -シノアリス- グローバル版 「ワールド統合」の裏側 大公開!!」をレポートしていく。


▲ポケラボ・ゲーム事業本部／エンジニアマネージャーの覚張泰幸氏。『シノアリス』エンジニア統括として立ち上げから参画。現在は同タイトルのグローバル版のエンジニア統括を担当している。

『シノアリス』は、2020年7月1日にグローバル版を2ワールド(リージョン) / 1バイナリでリリース。アジアを担うシンガポールワールド、アメリカ/ヨーロッパを担うオハイオワールドの2つを運用していたが、2021年1月26日にワールド統合(リージョン統合)を実施している。本セッションでは、ワールド統合で利用したAWSの機能の紹介(クロスリージョンレプリケーション、クロスアカウントクローン、global accelerator)、ワールド統合の経緯、ワールド統合の流れまで、全てを公開した。


▲国内版『シノアリス』がローカライズされたグローバル版は、2020年7月1日に139ヶ国・6言語でリリースされた。国内版には存在しない、ワールドチャット機能の実装や海外の独自施策を展開している。

本講演の題材になっている「ワールド統合」はProject FUSIONとして進められ、統合の発案～完了までを綴ったドキュメンタリー動画も公開されている。

 

さて、ここからは講演の本題へ。

まず、『シノアリス』グローバル版リリース時には2つのワールドで展開を行っていた。アジア圏をカバーする「シンガポールリージョン」と、アメリカ・ヨーロッパをカバーする「オハイオリージョン」だ。2つのリージョンを展開した主な理由はレイテンシで、ポケラボとしてここ数年の海外展開での実績がなかったことに起因すると覚張氏は説明した。過去には海外展開も行っていたポケラボだが、内部に残っているナレッジが新しくなく、多くも残っていなかったため、今回は安全に進める手法を選んだとのことだ。

その後、リリースされてからの運用やレイテンシの調査が進むにあたり、ひとつのワールドでの展開も可能だということが分かり、GvG（ギルド対戦）をよりグローバルに楽しんでもらうためにも”真のグローバル版を実現する”という目的でワールド統合の計画が立ち上がったのだと覚張氏は語った。そして、2021年1月26日にこれを完遂している。

なお、内容としてはオハイオリージョンの方が活性化されていたため、シンガポールリージョンをオハイオリージョンに寄せるという対応を行った。そのほか発案時の段階では、西海岸に新たなリージョンを作成する案や、東京リージョンに統合ワールドを作成しようという話もあったが、総合的に検討した結果、オハイオリージョンはそのまま残しつつ、シンガポールリージョンを寄せる形が良いのではないかと話が収まったとのことだ。


※本講演では、「ワールド」と「リージョン」は基本的には同じ概念として扱っている。

基本的にこの2つのワールドは同じイベントを実施する運用だったが、2つの場所でピーク時間が異なるため、コロシアムのタイムスロットをどう設定するかは最も気を遣ったポイントだったと振り返った。結果として、タイムスロットのマージと拡張を行い、突発イベントの発生時刻の調整も行った。

ここで覚張氏は本講演を行うに至った理由として、世の中に出ているゲームの中でワールドが分割されているアプリは珍しくないが、ワールドを統合したアプリは珍しく、この経緯やナレッジをCEDECで公開したいと考えたと説明した。

なお、シンガポールとオハイオでは双方にシステムを構築しており、完全に独立した異なる世界を作っていたため、アプリの初回起動時に接続先を選択する形となっていた。



また、ワールド統合前は全ての構成が分かれていたため、開発者はどちらのワールドでも正しく動作するように作りこまなければならないうえ、メンテナンスに関しても2つのワールドに対して同じ作業を行う必要があった。そういった意味では、開発・運用工数の削減、インフラ費用の削減、利益率の向上など、ユーザーだけでなく開発としてもメリットの大きい試みとなったとのことだ。

続いて覚張氏はワールド統合に際しての懸念点を紹介。元々ワールド統合を前提にシステムを作っていたわけではなかったため、大量のテーブルやデコードのキーが被っていることが何よりボトルネックになったと話した。

一方、クライアントも1バイナリ＝1ワールド＝1アカウントという造りになっているため、データのコンバートミスやスイッチミスをしてしまうとユーザーのデータの特定が困難になり、最悪だと復旧不可能な状態になってしまうような状況だったという。こちらに関しても、統合を前提としていないため仕方のない部分ではあるが、統合を行うのであれば別の設計もあったのではないかと覚張氏は話した。



ここからは、ワールド統合に関するより具体的な内容を紹介。

まずは外部的な統合（インフラ面）について。システムは全てAWSを採用。実際に統合作業を行う際のレイテンシを考慮して、事前にシンガポールリージョンとオハイオリージョンのデータベースを「クロスリージョンレプリケーション」した。統合作業を開始してからは、リージョンごとにAWSアカウントが別になっていたため、「クロスアカウントクローン」をしてデータを統合している。さらに、統合した後、アジア圏のユーザーがオハイオリージョンに接続する際、太平洋側ではなくヨーロッパ側をホップしてしまい遅延が見られたため、ホップの改善を狙ってAWSの機能から「AWS Global Accelerator」を導入したと覚張氏は話す。




▲なお、「AWS Global Accelerator」を利用した結果、条件に合ったときにデータベースが公表している値以上の効果があり、特に東南アジアの改善が著しかったと感想を述べた。

また、コロナ禍のため現地に直接伺うことはできず、外部の協力会社や海外で遊んでいるユーザーからの申告、クライアントにログを仕込むことで総合的に判断し、解決に至ったと補足した。

次に内部的な統合（データ面）について。本番環境のスナップショットを利用して、度重なるリハーサルを行った。リハーサルの内容は以下の通り。 



開発環境にt3.smallを採用した理由は、ずばり”価格とバースト”であると覚張氏は述べる。本番で利用しているインスタンスタイプが大きなものであるため、長期間抱えるとインフラコストが莫大なものになってしまう。そこで、安くてコスパが良いt3.smallを選定したと説明した。また、本番環境よりも性能の低いインスタンスを利用することで本番環境でも余裕を持って対応ができるほか、t3.smallはバーストするため、クレジットが残っていればある程度は性能も出るという。



続いて、統合処理の流れに関して。1バイナリ＝1ワールド＝1アカウントという状況のため、一度、起動時にAPサーバーにログインを行う。このとき、移行の同意を行うと共に、APサーバーとUSサーバー間の裏で通信を走らせて移行の状態を転送している。そして、再起動の後、内部的にUSサーバーに繋がる状態に切り替えて起動する。ここで、引き渡した情報を嚙み合わせてAPサーバーからUSサーバーに移行を完了するという形で進めている。


▲なお、「APサーバー」、「USサーバー」という書き方をしているが、シンガポールとオハイオのことであると覚張氏は補足した。

以下は統合処理の流れを簡単に図解したもの。



統合同意のタイミングで、APサーバーとUSサーバー間で通信を行っており、そこでmigration idを生成。クライアント側は、このmigration idを保持した状態でリセットをかけ、空の状態に。その後、USサーバーに対してユーザーを新規作成し、USサーバーにログインしたタイミングで先ほど生成したmigration idを引き渡して移行ユーザーであること、APサーバーにてどのユーザーであったかを特定して新規作成されたUSサーバーのユーザーに対して統合されたAPサーバーのユーザー情報を上書きするようなイメージであると覚張氏は説明した。

こうして24時間に及ぶメンテナンスの末、ワールド統合が行われた。以下で実際の流れと共にポイントになった部分を紹介していく。


▲クロスリージョンレプリケーションとクロスアカウントクローンに関しては先で述べられた通り。

テンポラリの作成に関して覚張氏は、度重なる検証を行っているため大丈夫だろうとは思いながらも、念のため、クロスアカウントクローンを行ったデータベースではなく、そこからコピーを作成し、コピーに対してスクリプトを走らせてデータを変えていくという方法を取っていると解説。これにより、万が一のことが生じた場合にもスナップショットからの復元より手軽に対応できるほか、オリジナルデータと加工済データを簡単に比較できることがテンポラリ作成に至った主な理由になったという。



ID重複の抽出と書き換えの処理に関して、auto incrementが重複するのは当たり前だが、auto increment以外の重複も少しあったと覚張氏は話す。具体的にはユーザーIDが重複しており、アイテムやカードのデータなどにもカラムが存在していたため、これらに関連する全てのユーザーIDを書き換える必要があったとのこと。

さらに、最も難易度が高く、時間を要した作業として「auto incrementの再採番のための下準備」を挙げた。理由として、『シノアリス』ではshardingされているテーブルが多いと覚張氏は語る。USサーバーで作られた新しいユーザーはshardの番号が変わってしまうため、一度全てのshardを仮想的に結合し、そのうえでIDを振り直して作業となる。適応するインスタンスが分散しており、時間も限られる中、ターミナルを20個ほど展開しながら並行して作業を行っていたという。



5つ目の工程となる再採番処理は、先ほど4のフェーズで作成した内容を適用していく処理になる。

最後に、テンポラリテーブルで番号を全て書き換えて加工したレコードをオハイオ側のテーブルにインポートしていく作業を行う。単純なdump,importではあるものの、データの整形ミスがあると正常にインポートされないため、最もヒヤヒヤした時間だったと覚張氏は振り返った。

実際、この24時間の間にはトラブルも発生しており、3つのフェーズにあたる「ID重複の抽出,書き換え処理」にて、同じコマンドを2回叩いてしまうという痛恨のミスがあり、作業をやり直すという事態に陥った。幸いにも早めの工程であったためロスも少なく、テンポラリテーブルでの作業であったため、オリジナルからの再作成も容易であったと覚張氏は当時の対応状況も明かしてくれた。このミスから、1度叩かれたコマンドは2度目は叩けないようにする仕組みがあっても面白いのではないかと感じたとの話だった。



このように、大規模運用タイトルのワールド統合の難易度は想定していたより高かったが、進め方や工夫を行って完遂することができたとまとめた。ワールド統合失敗からのクローズという話もある中、今回、時間通りにワールド統合を完遂できたことは大きな成果であると感じているという。また、ソーシャルゲームの特性上、ユーザーが多い状態の方が面白くなることが多いと考えており、ワールド統合自体は必然であったと述べる。



最後に覚張氏は、この登壇が皆様の糧になれば幸いだとして講演の締めとした。

（取材・文 編集部：山岡広樹）