1000万ダウンロード規模の「ロマサガRS」が障害を回避できた理由：「負荷テスト」や「自動復旧」を活用（1/3 ページ）

アカツキでエンジニアを務める駒井祐人氏が、スマートフォンゲームアプリ「ロマサガRS」でどのように障害を回避したのか紹介した。

[石川俊明，＠IT]

　2018年12月にスクウェア・エニックスからリリースされたスマートフォンゲームアプリ「ロマンシング サガ リ・ユニバース」（以下、ロマサガRS）。リリースから約3週間で1000万ダウンロードを達成したロマサガRSは、Amazon Web Services（AWS）のサービスをフル活用して構築。障害を回避して運用できているという。

　ロマサガRSではどのようにシステムを設計し、どのように障害を回避したのか。ロマサガRSを開発したアカツキのエンジニアである駒井祐人氏が「AWS Summit Tokyo 2019」で語った。

ロマサガRSのアーキテクチャ

アカツキ モバイルゲーム事業部 エンジニア 駒井祐人氏

　「ゲームシステムは最大ピークを見積もりづらい。公開されてからどれくらいのプレイヤーに遊ばれるか分からないからだ。これはサービス開始後も同様だ。例えば、ある日の正午にイベントが始まった結果、一時的にアクセス数が2倍に跳ね上がることもある。イベントなどに伴う急激なプレイヤー数の増加に合わせてスケールできるAPIやデータベース（DB）などを設計する必要がある」

　駒井氏はゲームシステム開発の特徴について説明した後、ロマサガRSのアーキテクチャを振り返った。

　ロマサガRSではサーバで実行する言語やミドルウェアなどの全プロセスをDockerコンテナで構築し、それらを「Amazon Elastic Container Service（ECS）」で運用している。

　サーバはそれぞれ、イベント通知用のお知らせサーバ、ロジックを管理するゲームサーバ、認証用の認証サーバを用意。ゲーム内のプレイヤーデータはマネージドリレーショナルデータベースの「Amazon Aurora」を水平分割し、認証データは「Amazon DynamoDB」に保存、キャッシュには「Amazon ElastiCache（のMemcached）」を採用している。

ロマサガRSのアーキテクチャ

　「Kubernetesを実行するマネージドサービスの『Amazon Elastic Kubernetes Service（EKS）』を採用しなかったのは、構築当時に東京リージョンで正式リリースされていなかったからだ。一部のサービスではサーバレスでコンテナを実行できる『AWS Fargate』を採用したが、ロマサガRSのリリース当時のFargateは、スケールアウトにかかる時間が『Amazon EC2（Amazon Elastic Compute Cloud）』と変わりなく、ログ管理も『Amazon CloudWatch Logs』のサポートのみだった。運用のしづらさもあり、最終的にFargateをやめ、EC2とECSを活用する形を採った」

　サーバサイドの開発言語はElixirを採用。並列性が高く、ゲームAPIを実現するには十分に高速だという。インフラ構成管理は「AWS CloudFormation」を、Ruby製のラッパーツール「Kumogata2」を用いて管理し、AWSで運用する各種サービスのインフラ環境を自動構築している。

　「ゲームシステム開発では、『バトルの難易度調整用』環境など、複数の開発環境を用意する必要がある。ロマサガRSの構成だと、コマンド1つで同じ環境を構築できるため、環境間の差分が発生せず、構築に関する大きな問題も起きずに済んだ。Kumogata2を利用するのは、CloudFormationで条件分岐などのコードを書けるからだ。例えば、『ステージングと本番環境は冗長構成で、開発環境はシングルノードで十分』というときなどに、条件を変えて構築できる。構成管理がレガシーだと、環境変数の設定がおかしいままサーバを起動して運用しているケースも少なくないだろう。この構成ではそのような状況も起きないため、デプロイやスケーリングが安定している環境といえる」

AWSのサービスやDatadogなどを組み合わせる形で、ロギングと運用監視を実現