［CEDEC 2012］クラウドが生み出す新しい可能性〜「シェルノサージュ」におけるネットワーク実装とトラブル対策

　「シェルノサージュ 〜失われた星へ捧ぐ詩〜」（以下，シェルノサージュ）は，7つの次元を越えた先にいる少女「イオン」とPS Vitaを通じてコミュニケーションをとるというゲームで，ガストが2012年4月26日に発売した。タッチスクリーンを使ってイオンとコミュニケーションがとれるだけでなく，Wi-Fiや3G回線を使ってほかのプレイヤーと交流も可能。さらに，ネットワークを利用して他機種のゲームやスマートフォン用アプリとの連携などができるように設計されているという。

　2012年8月20日から22日に横浜で開催されたCEDEC 2012では，「コンシューマゲームでの挑戦！ネットワークを活用したゲームの構築と運用『シェルノサージュ』の事例」という講演が行われた。ガスト開発部バリュービジネス事業部 マネージャーディレクターである土屋 暁氏，ブロックバスター開発部 取締役 CTO/プログラマーの渡邉幸二氏，CRI・ミドルウェア 研究開発部 リードエンジニアの佐藤 修氏らによって，同作におけるネットワーク技術の活用方法が語られた本公演の内容をお伝えしよう。

ガストの土屋氏。「シェルノサージュ」におけるクラウドの実装やサーバートラブルなどに関して語った

　「シェルノサージュ」は「ネットワークを活用したコミュニケーションゲーム」であり，ネットワーク上に保存したセーブデータを活用することで，ハードの枠を越えてその世界が可能と，土屋氏は説明した。
　「シェルノサージュ」のセーブデータには「着ている服」「交流履歴」「機嫌」「所持アイテム」といった情報が記録されている。土屋氏は，このデータを利用して，ほかのゲームやアプリで利用するという構想があるそうだ。例えば「プレイヤーが作ったイオンの部屋データを，PlayStation 3用のRPGにも登場させる」「移動中にスマートフォンのアプリでアイテム調合を行い，帰宅してからシェルノサージュでそのアイテムを使う」といった活用法が考えられているそうだ。


　「シェルノサージュ」のクラウドと通常のネットワーク通信には違いがある。通常は通信していることをユーザーに分かりやすく知らせ，送信するデータのサイズも状況によって異なる。だが，「シェルノサージュ」の場合は，イオンとのコミュニケーションで選択肢を選ぶ，服を着替えてもらうなど，データに更新があった場合，自動的にクラウド用ライブラリを呼び出して通信が行われる。ただし，通信時にアナウンスを行わないし，エラーが起きてもメッセージを出すことなくバックグラウンドで常にリトライの機会を狙う。また，送信サイズも5000バイトと固定されたものになっているという。普通にゲームを遊ぶだけで，知らない間にクラウド上のセーブデータが更新されているというわけだ。


　会場ではPS VitaとWEBの連携がデモンストレーションされた。WEB上にはイオンがどんな服を着ているかという情報が表示されている。PS Vita上でイオンの服を変えると，WEB上の情報もリアルタイムで更新された。この際，PS Vita側では特別な操作をしていない。これがクラウドによるセーブデータ共有の具体的なイメージだ。

画面上のイオンの服と，右下に見えるWEBのデータが同一のものであることに注目だ。イオンが服を変えると，クラウド上のセーブデータも更新され，これを参照しているWEB上のデータも変化する

　「シェルノサージュ」には，CRI・ミドルウェアが開発した「CRI Savebox」と呼ばれる同期通信モジュールが組み込まれている。佐藤氏はCRI Saveboxの特徴として，無駄なネットワークアクセスをしないことや，データ保護機能を持っていることなどを挙げた。これを使うとわずか2行の命令でセーブデータの同期が可能で，受信中および送信中のデータをバッファすることにより，セーブデータの保護を行えるという。佐藤氏はCRI Saveboxがプレイヤーにストレスを与えないクラウド環境を作り出し，自然なセーブデータの連動を可能とすると説明した。

円滑なサーバー運用のために〜トラブルから得られた教訓〜

　こういった構想をかかげて開発された「シェルノサージュ」だが，残念ながら発売直後にサーバーダウンなどのトラブルが起きてしまったのはご存じのとおり。

　土屋氏によると，「シェルノサージュ」で使用したサーバーは，クラウドサービスを利用したバーチャルサーバーで，処理用スクリプトのAPIサーバーと実際のゲームデータを扱うDBサーバーは分けられているという。アクセスが集中したときにAPIサーバーを簡単に増やすことができるのがバーチャルサーバーのメリットなのだが，実際には佐藤氏の予想を遙かに超えたアクセスがあり，データベースの処理が追いつかなくなり，サーバーダウンが発生してしまった。そこでDBサーバーを4台に分割し，関連したデータを同一サーバーに記録するといった対策を取ったという。


　ゲーム内の廃墟を修復するため，プレイヤーがバーコードから生み出す妖精「シャール」の数も，事前の想定を大きく上回るものだった。予想を超えた数のプレイヤーそれぞれが，シャールのデータを呼び出したことも処理速度の低下に拍車をかけ，サーバーダウンの原因となったそうだ。なお，この事態にはデータベースから取得できるレコードの数にリミットを設けるという対応が取られた。土屋氏はは，負荷テストでは問題がなくても，実際に運用したときに予想を超えたアクセスが集中する可能性があるとし，「絶対に（予想を超えたアクセスが）ないと思っても，リミットを設定しておいたほうがいい」と語った。

　第3の原因として挙げられたのは，スクリプトの負荷増大だ。アクセスが集中しただけでなく，スクリプトに永久ループが発生したため，負荷が大きくなったのだ。永久ループとは，特定条件下でスクリプト（プログラム）が処理を完了できず，同じところを繰り返し（ループ）実行し続けること。永久ループが発生するとほかのプレイヤーの要求も止められてしまうため，全体に与える影響は非常に大きい。土屋氏は「永久ループにつながりやすいwhile文を使わない」「使うとしても実行回数をカウントし，もしも永久ループに陥りそうになったときに自動で離脱できるようにする」といった対策を勧めていた。


　土屋氏は一連のトラブルから「サーバーは一瞬で止まってしまう。数分前に問題なく動いていたとしても，アクセスが集中すればすぐ止まるものだ」という教訓を得たそうだ。こうした体験から，サーバーを円滑に動かすためのノウハウが導き出された。それは，プログラム的には，「データベースには適切なインデックスを付けて処理時間を短くする」「意識していないうちにアクセス回数が増えていることがあるので，事前にこれをチェックする」ことなどだ。
　またインフラ整備時には，「1回のレコード取得量に制限を付ける」「24時間サポートをしている業者を選ぶ」「ゲームの発売時にはサーバーのリソースをできるだけ多くしておく」ことを勧めた。

　とくにインフラ整備時には初期投資を節約しないことが重要だと強調していた。クラウドサービスの業者の中にはEメールでのみサポートを受け付けるところもあるが，ゲーム用のサーバーは1時間停止すると大きな問題になるため，それでは柔軟な対応は難しいからだ。

　土屋氏は「これからはネットも特別なものではなくなり，ゲームに対するスタンスも変わっていく。新しい可能性のあるゲームを作っていきたい」と語り，講演を締めくくった。