【CEDEC 2012】ウェブ上からイオンの状態をチェックすることも可能に―クラウドを用いた「シェルノサージュ」の可能性にも触れられた講演レポート

「シェルノサージュ」でのクラウド

本講演は、CRI・ミドルウェア 研究開発部 リードエンジニア・佐藤 修氏、ガスト 開発部、バリュービジネス事業部 マネージャー、ディレクター・土屋 暁氏、ブロックバスター 開発部 取締役 CTO/プログラマー・渡邉 幸二氏の三氏によって進められた。

まずは土屋氏から、PS Vita用ソフト「シェルノサージュ」の概要と、本作で使用されているネットワーク技術についての説明が行われた。「シェルノサージュ」は、ゲームシステムを大きく分けると、ヒロインのイオンとコミュニケーションを取る「コミュニケーションパート」、PS Vitaカードに収録されているものや追加コンテンツとして配信される物語を楽しむ「シナリオパート」、ネットワーク上でユーザー同士が協力してシャールと呼ばれる妖精を育てる「交流パート」の3つに分かれている。

これらのシステムはそれぞれ異なったネットワークシステムが使われている。例えばコミュニケーションパートでは、イオンの機嫌や着ている服、交流履歴に所持アイテムといったステータスをサーバー上で保有するクラウドが用いられている。このステータス情報はPS Vitaのローカル上にも保存されているのだが、データが更新された瞬間にサーバーのデータも更新されるようミラーリングされている。

これにより、PS Vitaだけでなく、PS3やスマートフォン、ウェブ上のアプリなど、ネットワークを介してさまざまなプラットフォームと世界を共有することが技術的に可能となっているのだ。

土屋氏はあくまで構想だと言うが、その一例として、イオンの部屋がネットワーク上にアップロードしてあれば、PS3のまったく違うRPGの一室として部屋データを使って構築することができるという。また、スマートフォンでアイテム調合だけをできるゲームを展開したり、ウェブと連動してイベントを発生させたりと「これまでのスタンドアローンゲームにはなかった面白さが追求できるのでは」と語った。

なお、実際にネットワーク上に保存されているデータには「ヒロイン情報」「アイテム情報」「イベント情報」がある。このうちのイベント情報は、プレイヤーがゲーム内で取った行動などに対してイオンがウェブ上でボイスメッセージを送ってくれるという、現状の「シェルノサージュ」においてもサービスされている内容だ。PC上でMyGustIDにログインして、ゲーム公式サイト内の「シェルノコンソール」を選択すると、送られてきたアイテム一覧をチェックすることができるという、プラットフォームを超えた試みが行われている。

クラウドの実装手法と実機デモ

この後は、「シェルノサージュ」におけるクラウド仕様や実装手法についても説明が行われた。本作でのクラウド通信は、通常の通信と比べると通信手法は同じhttps通信が用いられているが、一回のデータ送信サイズや、エラー発生時の処理に違いがある。

送信サイズは通常の場合、可変データ構成でおよそ100～30,000バイトなのに対し、本作のクラウドでは5,000バイト固定にしてあるのだ。これはメモリ上の5,000バイトの領域をそのまま切り取ってダンプして、ネットワーク上にバイナリとして送っているためだという。またエラー発生時についても、クラウドの場合は停止せず、オートリトライするようになっているとのこと。

ゲーム内では、イオンの服装が変わったり、会話中の選択肢を選んでフラグデータが溜まった時など、データの更新があった場合にバックグランドでサーバー上にデータが送られている。これにはCRI・ミドルウェアの「CRI Savebox」というミドルウェアが使われており、バックグラウンドでデータを送信する際、動作が重くなったりなどプレイヤーに負担をかけない形でネットワークが構築されている。データ通信では、ブロックバスターのACHttpライブラリと呼ばれるものがあり、これで通信を行っているという。

実機上ではどのように通信が行われているのかのデモも行われた。例えば、本作ではイオンに服を渡すとそれに着替えてもらうことが可能で、着替えが終わると日付の左横に青いアイコンが表示されるようになっている。このアイコンが、サーバー上のデータと通信を行ったサインとなっているのだ。デモでは、DLC衣装のリーベルドレスから通常のリンカージェンに着替え、通信が行われた後にイオンの状態が確認できるウェブページ上でもステータスが変更されている場面が披露された。

ウェブ上でイオンの状態を確認できる機能はまだ実装されていないが、先ほど紹介した「シェルノコンソール」内では、デモで使われたツールが近日公開予定となっているので、気になる人は機能が公開されたら試してみるのもいいだろう。

なお、先にも説明した通り本作ではhttps通信が使われているが、http+SSL通信を扱うネットワークモジュールを実装する際に守っておきたい設定について、渡邉氏から説明が行われた。

この話が「シェルノサージュ」以外でも当てはまるかは別だと前置きがされたものの、httpのポスト処理が受け付けられ、なおかつSSLエラーが返ってくることがあるという。その場合、サーバーにデータがポストされているが、クライアント上ではサーバーにデータが行っていない状態となり、クライアントとサーバーのデータに食い違いが生じてしまうのだ。

発売当初から本作をプレイしているなら知っている方も多いかもしれないが、本作でも一度そういった事態が発生しており、PS Vitaとサーバー上のデータに食い違いが生じたことに起因するエラーが発生していた。そのため、SSLエラーなどによりデータの整合性が保たれなくなっても、次に通信できる状態になって通信した際、サーバーから返ってくるデータとクライアントに保存されたデータの整合性が保たれるように修正する設計を行う必要があったとのこと。

「シェルノサージュ」のために制作された「CRI Savebox」

佐藤氏からは、先に少しだけ触れたミドルウェア「CRI Savebox」の説明が行われた。これは「『シェルノサージュ』向けに開発したゲームデータの同期通信モジュール」であり、ネットワークを介してPS Vita上にあるゲームデータと「シェルノサージュ」サーバーの同期通信を行うというもの。サーバーの先にはほかのプレイヤーのPS Vitaのゲームデータのやり取りもあるため、今後ゲームデータを使った秘密の展開が行われる可能性もあるという。

このSaveboxには、ソースコードがたったの2行でゲームデータの同期通信を始めらる簡単なAPIであったり、データ変更があった時だけ通信を行うので無駄なネットワークアクセスをしないといった特徴がある。また、ダブルバッファ化と、バッファ同士の排他制御がされていることで、更新途中のデータをアプリ側に扱わせないようにして、データを保護する役割もあるようだ。

サーバーダウンの原因とそこから得られた経験

ここまでさまざまな内容が語られてきたが、「シェルノサージュ」は発売日にサーバーダウンを起こしてしまったという面もある。最後には土屋氏が登壇し、サーバーダウンを起こした原因や、その経験を踏まえたサーバー運用に関する話の総括を行った。

まずは「シェルノサージュ」のサーバー構成について。APIサーバーとDB（データベース）サーバーを分けており、APIサーバーは処理するスクリプトを動かすようになっている。DBサーバーはデータベースをテーブルごとに分けて格納し、各マシンを内部LANによって接続して運用しているという。

APIサーバーは状況に応じて柔軟に数を調節することができ、数分もあればサーバーを一個増やしてミラーリングして増設することも可能だという。そのため、急なアクセス負荷に合わせて増設したり、逆に負荷が少ないときはサーバーを減らすてコストダウンできるようだ。DBサーバーは、テーブルによって負荷が大きく変わってくるため、分けてデータを格納するようにしているとのこと。

続いては、サーバーダウンを起こしてしまった原因についても触れられた。

原因1：DBサーバーの能力超過

当初はユーザーのアクセス数が多すぎてデータベースの処理速度が追いつかず、それが原因でサーバーダウンを引き起こしたという。最初は少ない数で運用していたようだが、巨大なテーブルを抱えていると非常に重くなってしまうため、処理に時間が掛かるテーブルは一個で一つのサーバーに、軽いテーブルは複数個をまとめて一つのサーバーに入れることで、負荷分散が行われている。

原因2：DB取得レコード数の増大

本作において妖精のような存在のシャールはすべてデータベースのレコードとなっている。これも数千件までなら問題ないようだが、プレイヤー1人につきシャールは6体まで保有できるので、件数が数万件にまで増加すると状況が変わってしまうという。大量にあるシャールの情報からデータを抽出することになるので、レコードの取得数に必ずLIMIT（リミット）を付けるべきだとした。

また、ゲームに限らずネットワークを利用するものにはどれだけ利用者が来るか予測しづらいため、予想を超えた人数が来ると一瞬でサーバーの処理速度が追いつかない状況になってしまうのだとか。そのため、あらかじめレコード数の最大取得数にリミットを付けて制限することで、急な増加にも耐えられるという。

原因3：スクリプトの負荷増大

現在使用しているサーバーは性能がよく、通常の処理で重くなることはあまりないと言うが、プログラムにバグがあって永久ループに陥って参照回数が増えると、予期せぬ事態が発生することもあるようだ。消極的になるが、その防御策として、永久ループ処理を極力採用しないようにしたり、一定回数ループしたら強制的に離脱する処理を入れておくのがいいと話す。

というのも、サーバーの場合は30秒程度実行し続けてからタイムアウトするが、30秒間もゲームサーバーが止まってしまうと、高速道路で渋滞が起きる現象のようにほかのユーザーが一緒にせき止められてしまうので、サーバーパンクの原因になってしまうのだ。

主なサーバーダウンの原因を踏まえ、これから運用する人向けのアドバイスも語られた。そして最後には、「これまではネットワークが特別な存在でしたが、現在はスタンドアローン以外の可能性でゲームを作ることが自然にできるようになりました。新しいゲームプレイを作っていきたいですし、そういったところにゲームの新しい可能性があると思っています」と講演を締めくくった。