コンピュータエンターテインメント協会(CESA)は、9月4日~6日の期間、パシフィコ横浜(神奈川県横浜市)にて、国内最大のゲーム開発者向けカンファレンス「コンピュータ・エンターテインメント・デベロッパーズ・カンファレンス 2019」(CEDEC 2019)を開催した。
本稿では、9月5日に実施された講演「ロマサガRSをどのようにクイックにスケールさせたか 〜Elixir, Amazon ECS 等の技術要素を交えて〜」についてのレポートをお届けしていく。
本セッションには、アカツキ・モバイルゲーム事業部 テクニカルディレクター/クリエイティブプロデューサーの島崎清山氏が登壇。ローンチ前にアクセス規模を見積もることが難しいモバイルゲームにおいて、『ロマンシング サガ リ・ユニバース』(以下、『ロマサガRS』)はどのようにして大きな障害を出さずに乗り切ったのか。また、スピーディな機能開発や、安定した品質での提供を損なわないための効率的なスケールをどのようにして達成したのかについて、ElixirやAmazon ECSなどの技術要素を交えて解説した。
▲アカツキ・モバイルゲーム事業部 テクニカルディレクター/クリエイティブプロデューサーの島崎清山氏。『ロマサガRS』においては現在、開発の方向性の検討・調整やユーザーとの対話などを担っている。
まず登壇した島崎氏は、改めて『ロマサガRS』を紹介した。2018年12月にリリースされた『ロマサガRS』は、「ロマンシング サガ」シリーズとして実に23年ぶりの完全新作となる。『ロマンシング サガ3』から300年後の世界を舞台に、シリーズの枠を越えて歴代キャラクターたちが集い、オリジナルストーリーを展開する。
▲本作は、スクウェア・エニックスが配信、アカツキが共同開発を担っているタイトルである。
講演を始める前に島崎氏は、今回のテーマは「大規模スケールするサーバー技術」としているものの、まだまだできていないことは多いと話す。しかし、その中でも自分たちが得てきた知見や教訓を本講演から持ち帰ってほしいと来場者に伝えた。
▲なお、『ロマサガRS』に関する技術は各種イベント・セミナーで積極的に発信している。
●課題と結果
最初のテーマ「ゲームサーバーの課題」でまず言及されたのは、ピーク時のトラフィックがどれくらいになるかが読みづらいということ。
▲特に、リリース直後のトラフィックは凄まじく、業界内では予想の10倍のトラフィックがあったという話も流れているとか。
そこで、『ロマサガRS』ができたこととして下記の数字が挙げられた。
『ロマサガRS』では、最大ピーク時には1分間で100万件以上のリクエストが来ることがあると島崎氏は話す。フェイルオーバーなどで一部サーバーがダメになったことはあるものの、計画メンテナンス以外でシステム全停止はすることなく、アベイラビリティ100%を維持できていると明かした。
▲併せて、レイテンシ分布についても資料を公開した。
続いて、アーキテクチャの全体像を公開。『ロマサガRS』では、ゲームサーバーを中心に、お知らせサーバーと認証サーバーは切り出す形をとっている。アプリケーション/ミドルウェアに関しては、基本的に全てAmazon ECSで構成しているとのこと。
▲主なプレイヤーデータに関してはAuroraに、セッションはElastiCacheに乗せている。また、認証に関してはDynamoDBを採用している。
そのほか上図に記載がないところで、課金処理に関してはアカツキの共通サービスがあり、それがGCPの方でApp Engineとデータストア(Cloud Datastore)での運用という形になっているという。そのため、仮想通貨に関わる処理を行う際はGCPに対する通信が走るようになっていると説明した。
次に『ロマサガRS』の設計の基本方針として下記の2つを挙げた。
・ゲームロジックは、全てサーバーに持たせる。
・クライアントは、描画・UIに専念する。
例えば、バトルではクライアントがコマンドを送り、サーバーがそのコマンドを実行してバトル処理を計算する。その処理結果をレスポンスに詰めて受け取ったクライアントが演出を描画するという動きになっている。この意図としては、「チート対策」や「開発工数の分散」、クライアントよりサーバーの方が「自動テストしやすい」ため検証の効率化が狙えるという理由があると島崎氏は語った。
●スケールの要点
次は「スケールの要点」について。
まずクイックにスケールさせるために最も重要なのはアプリケーションの性能であると考えていると島崎氏は述べる。その中でも、主な問題は「N+1クエリ」と呼ばれているもので、データベースの処理の最適化になる。これを全て解決し切ることが大切だと説いた。
サーバー1台の性能を上げることでリソース効率が向上し、かつ処理時間が短くなる。ここでひとつ注意点として、サーバー台数は無限にスケールアウトさせられるものではないと述べる。例えば、データベースのコネクション数は上限があるため、それを越えることはない。そのため、1台のサーバーで処理できる容量を増やすということは凄く大切なことであると説明を行った。
▲上記は元々1秒近く掛かっていた処理の改善に取り組んだ図。
また、機能追加をしていくとパフォーマンスが劣化するというのはよくある話である。この劣化が著しい場合は通知がされるようになっているという。実際、本番にパフォーマンス劣化が入ってしまったこともあったが、それに関してはすぐに気付くことができたため最適解を直してすぐに後半を反映させて直すという形で対応はできた。しかし、これはプロダクションに出る前に気付けた方が良いため、今後は常に負荷試験をヘビーに回して劣化チェックをできるようにしたいと展望を語った。現在はその準備をしており、もうすぐ実現できそうだと島崎氏は話した。
次にインフラ側の要点について。Auroraの利点について島崎氏はフェイルオーバーの速さなどを挙げた。仮に、何かトラブルでデータベースに問題が起きたとしても約1分で返ってきてくれることや、IAWSといえども事故はあり得るためデータの6重化は安心だと述べた。
さらに島崎氏は「シャーディングも議論が分かれるところだと思うが、我々は必須だと言い切っている」とコメント。理由として、もしアクセスが増えた場合に準備をしておかなければ全く手が打てない状態になるからだと説明した。社内のメンバーからも「インフラの基本はMAXまで使ってはいけない」「何かあった時の手段を残しておくのがインフラ屋の仕事である」という話があったとのことだ。そのため、インスタンス数が1つで充分だという見積もりだったとしてもシャーディングの準備はしておくこと。後からでは大変な作業となるため、予め何かあったらシャードを増やすことができるように準備しておくことが重要だと強調した。
▲ちなみに、Elixirではそれ用のライブラリが存在し、マイグレーションなども良い感じに設定してくれるため楽ができたとのこと。
●プログラミング言語Elixir
3つ目のテーマは「プログラミング言語Elixir」について。この項目を語るにあたって、島崎氏はまずElixirや、その前身となったErlang VMの紹介を行った。
▲Erlangは文法が独特に見えることから敬遠されがちだったが、ElixirはRubyに似た形の構文であることが広く受け入れられる要因になったという。現在はLINEやDiscordなど大規模なメッセージングで使用されているほか、『Fate/Grand Order』が負荷試験で使用していることも公開されている。
次に、アカツキがElixirを選定した理由について下記のように語った。
▲リアルタイムやマルチに強いため、いざそういったシステムを入れたいとなった時にすぐに動けることは重要だと考えていると明かした。また、アカツキは元々Rubyで開発を行っていたこともあり適応しやすかったというのもElixirに決める要因となったようだ。
ここからはElixirを使用するメリットについて。
1.生産性
Elixirは、モダンな関数型言語であるため、結果的にコードの密度や可読性を非常に高くできるという。コードの密度や可読性が高いことは新しいメンバーが合流した際の立ち上がりにも有用で、バグの修正スピードなどが違ってくるため品質向上にも繋がっている。また、『ロマサガRS』ではコードを書くよりもメンテナンスを重視したいという想いから可読性を大切にしているとの話だった。そのほか、フォーマッタ―が標準装備されていることにより、「ここはこう描きたい」という議論になった際の時間を削減できると利点を述べた。また、似たところでデファクトのライブラリを育てるにあたって中心メンバーが力を入れてくれているため迷う余地がないので比較調査をする必要がないという。
2.安全性
コンパイラがクロスリファレンスチェックで存在しない関数呼び出しを全て防いでくれる。また、型解析ツールを走らせることで、いわゆる型エラーのような間違いが起きなくなる。これによって、静的型付き言語の利点である安全性を受け取ることができる。テストは基本的に他の言語と同じく書けることに加えて、EtoEを書きやすいというメリットがある。これは、テストを開始する際にテスト用サーバーをすぐに立ち上げてテストクライアントからリクエストを送りレスポンスを返してもらい、そのレスポンスの中身をチェックするというものを簡単に書けると説明した。また、もうひとつの特徴としてプロパティベースのテストというものが存在するが、『ロマサガRS』に関してはまだ未導入とのこと。安全性については、こういった機能があるからこそ、安心して手を入れることができるとまとめた。
3.並行性
性能面では、結果としてRuby on Railsを利用している別プロジェクトと比べて、サーバー台数を半分程度で抑えられていると明かす。良い結果が出ている要因として島崎氏は、マルチコアでスケールしてマシン性能を使い切ってくれるといった点を挙げた。また、マスターデータに関しては、VMに組み込みのオンメモリDBがあり、そこに全てを入れているのだという。そこから1インスタンス内の全ての軽量プロセスから見てもらう形にしていることが性能に効いていると工夫している点を述べた。
【まとめ】
・スパイクは読めない→スケールさせられるように
・スケールする技術を選定する
・負荷試験と最適化を繰り返す
・Elixirは速いし安全で良かった
●裏 泥くさい話
しかし、生産性が高いからといって簡単に会社のプログラミング言語を変えられるのか。最後の項目では、島崎氏がElixirを導入するためにどのようにして会社を説得したかなど、当時の裏話を披露した。
裏・1 なぜElixirか どう入れたか
島崎氏は、当時はまだElixirの事例も少なかった中で、そのプログラミング言語を利用するというのは重い決断だったと話す。これを断行できた理由として、以前、プログラミング言語がボトルネックになるという経験をしたことがあると述べた。これは「もっと快適にプレイしたい」という要望に対して、そのプログラミング言語である以上は応えられないという状況だったのだとか。これ以来、島崎氏は性能が良いことはゲームに使う言語としてとても大切にしたいと考えるようになったという。
さらに、元々自身が「サガ」シリーズの熱烈なファンであったということから、当時は別部署に所属していたが「サガ」にベストなサーバーを開発したいとの想いで移動を願い出てチームに合流したという経緯があると振り返った。そのため、最初に自分がやるべきことはチームからの信頼を得ることだったという。周りから信頼を得るため、難しいプロトタイプを短い納期で、バグ0で行うことを達成できた結果、色々な風向きが変わってゲームサーバーをElixirにするという決断ができたのだという。
特に、この中で大事だったのはバグ0で行うということで、言語が良いというだけでは採用するのは難しい。だからこそ、導入の参考事例を自分が作ることで、それほど完璧な仕事をするのであれば周りからも「確かに」と納得してもらえると順序立てて説明を行った。
裏・2 負荷試験、最適化を前にして
リリース前の夏前頃に本格的な負荷試験のコードを書いていたという島崎氏。最適化をしようとしていた折、コードが複雑になってきており、すぐには最適化できる状態じゃないかもしれないという報告を受ける。当時、既に島崎氏はプロデューサー業務を担当していたが、そこから2ヶ月ほどサーバー開発に戻ってリファクタを進めていたとのこと。結果的に、作業は1カ月半ほどで完了し、その後の最適化にも入れたが、改めてここがこのプロジェクトの山場だったと語った。
裏・3 最適化 これからの課題
前述した努力の甲斐もあり、最適化に関しても1カ月ほどで一通り行うことができたという島崎氏。しかし、リリース後も困難は連続しており、常に何かしらの反省はあるという。「速くお客様に価値を届けたい」という想いはあるものの、速度だけのことを考えてしまうと結果的に不具合や内部品質の低下を招いてしまうことがある。そこで最近は、優先順位のグラデーションを調整することが非常に大切であると強く感じているという。
最後に島崎氏は、テストや静的解析のツールを盾にリファクタリングして内部品質をしっかり上げていき、それによって最適化や機能実装で価値を届けるというサイクルをバランス良く続けていくことこそが、ゲーム開発という難しい課題に対してとても重要なことであると結論をまとめて講演の締めとした。
なお、Social Game Infoでは以前、島崎氏を含む『ロマサガRS』開発陣へのインタビュー記事も掲載している。興味がある方は、是非こちらの記事も併せてチェックしてほしい。
【関連記事】
・【インタビュー】スクエニ×アカツキの強力タッグによって誕生した『ロマサガRS』…そのヒットの秘密に迫る!(前編)
・【インタビュー】開発陣の考える『サガ』の魅力とは?そして、ソーシャルゲームのジレンマを乗り越えた先に生まれた『ロマサガRS』のシステムにも言及
(取材・文 編集部:山岡広樹)
■『ロマンシング サガ リ・ユニバース』
© SQUARE ENIX CO., LTD. All Rights Reserved.
Powered by Akatsuki Inc.
ILLUSTRATION: TOMOMI KOBAYASHI
会社情報
- 会社名
- 株式会社アカツキ
- 設立
- 2010年6月
- 代表者
- 代表取締役CEO 香田 哲朗
- 決算期
- 3月
- 直近業績
- 売上高239億7200万円、営業利益26億7600万円、経常利益28億3400万円、最終利益12億8800万円(2024年3月期)
- 上場区分
- 東証プライム
- 証券コード
- 3932