ページトップへ

概要

SoftLayerをゲームサイト用の基盤として使う方法をご紹介します。 スマートフォンで遊べるリアルタイム・オンライン対戦用ゲームは、UnityとPhoton Serverを組みあわせて使うことが一般的になりつつあります。 Unityは、スマートフォンやパソコンなど、さまざまな実行環境に対応するゲームエンジンで、 Photon Server は、ゲームをオンラインで動作させるためのサーバーです。 いずれも世界中で広く使われているものです。 以下では、ある開発会社を例に、初期の開発段階から、ゲーム基盤が成長して信頼性を高めていくケースを見ていきます。

オンライン・ゲームに必要な環境とは?

ここは、とあるシステム開発を行っているA社。 ウェブ系のシステム開発が収益の柱であり、ゲーム開発は手がけたことがありません。 ある日、開発メンバーB君に日本ゲームショウの招待状が届きます。 知り合いのお客さまからの紹介で、新しいサイトの企画がゲームと連動するため、参考にしてほしいとのこと。 B君は、元々スマートフォンのゲームを毎日遊ぶ程度には触れていたので興味津々。

ゲーム展示会場では色々展示されていますが、興味を持ったのは勿論スマートフォン向け。 ゲームの開発担当者と話していると、何やらUnityなるゲームエンジンを使って開発しているとのこと。 元々システム開発で使っている言語と構造が近いこともあり、簡単に作れそうな予感。

帰りの電車の中、B君の中では、ちょっとしたゲームのアイディアが浮かびました。 考えているのは、複数のプレイヤーがリアルタイムに通信するオンライン対戦もの。 帰社後、試しにコードを書いたところ、あまり時間をかけずにゲームを作れることがわかります。 B君は他の開発メンバーに見せたところ、意外と好評。 そこに通りかかったB君の課長から、社長にプレゼンしてみては?と声をかけられます。 前々からゲームに興味のあったB君は、提案用の資料を作り始めます。

Unityを使ってオンライン・ゲームを配信するには、どのような環境が必要なのか整理しました。 想定しているゲームは、複数のプレイヤーがリアルタイムに通信するオンライン型のものです。 このUnityゲームをインターネット上で動かすためには、次のようなサーバーとミドルウェアを準備することがわかりました。

オンライン・ゲーム配信環境

  • ウェブ・サーバー … ゲームの公式サイトや、お知らせなどの静的なコンテンツを配信します。 Apache、Nginx、IISなどのウェブ・サーバーを動かすためのサーバーです。
  • ゲームサーバー … Unityのゲームエンジンをオンラインに対応するPhoton Serverです。 リアルタイム通信、複数プレイヤー、マッチメイキングなど、オンライン・ゲームに必要なネットワーク機能を提供します。
  • アプリ・サーバー … ユーザーの属性を参照・更新したりするために使うアプリケーション向けのHTTPサーバーで、JSONやXML形式のデータをやりとりします。 サーバーはNode.js、PHP、Ruby on Railsなどの言語を使って記述し、Unityのゲームエンジンからの要求をRESTfulなAPIで受け付け、データベースへのデータ保管や参照を仲介する役割があります。
  • データベース … ユーザー情報やスコアなどを保存します。 アプリ・サーバーからのリクエストを受け付け、保存したりデータを返します。 MySQL、PostgreSQL、MongoDBなどが使われます。

監視

  • 稼働監視サーバー … 各サーバーの状況や、サービスのレスポンスなどを監視します(例:Zabbix、Nagios等)。

さらに調べていくと、全ての環境を揃える必要がないことがわかります。 1台だけのスタートであれば、開発にあたって必要なインフラコストをできるだけ抑えられます。 その1台のサーバー上に、最低限必要なPhoton Serverとアプリ、そしてデータベースサーバーとしてMySQLをセットアップ。 この最小構成で、社内プレゼンに提案することにします。

そして、企画書をしたため、社長ほか経営陣が同席する企画会議でプレゼンに挑みます。 A社は、ちょうどスマートフォン市場向けのサービス展開が喫緊の経営課題になっていたので、B君のプレゼンはアッサリと通ってしまいました。 社長から直々に、これはいけそうだ、期待しているよ!ということで、ゲーム開発が正式なプロジェクトとして動き出します。 ただし、できるだけ費用をかけずにスタートすることと、最小限の人員で行うことが条件となりました。

開発環境の構築

いよいよプロジェクトがスタート。 開発メンバーはB君と同僚のC君の2名だけ。 一週間ほど集中して開発したところ、ゲームの設計と開発用コードはほぼ書き上がります。 あとは、ネット上で実機を通した開発が必要になってきます。 社内では他のウェブ案件で既にSoftLayerを使っていましたので、今回の環境もSoftLayer上に展開することになります。

社内プレゼン時は最小構成で考えていましたが、ゲーム配信環境を考慮して、スムーズに拡張できるようWindowsサーバーとLinuxサーバーの2台構成にします。 1台はゲームサーバーで、Photon Serverを動かすために必要なWindows Serverを利用します。 もう1台はウェブ・サーバー、アプリ・サーバー、DBサーバーを動かすための開発環境やミドルウェアが充実しているLinuxを利用します。

B君はSoftLayerのカスタマーポータル上で注文を進めます。 2台のサーバーは画面をクリックするだけで、すぐに起動してきます。 開発環境とはいえ、セキュリティ上の危険性は減らしたいところ。 Linuxサーバーは、プロビジョニング・スクリプトの機能を使って、外部ネットワークとのポートを自動遮断しました。 (ご参考: コンフィグレーション・ガイド 1.2.2 設定スクリプトの自動実行 )Windows Serverは無償のアンチウイルス・ソフトウェアを活用することにしました。 (ご参考: コンフィグレーション・ガイド 2.6 Windowsサーバーのセキュリティを強化するには?

一通りの開発が進むと、いつでも環境を初期状態に戻せるようにイメージ・テンプレートを作成しておきます。 イメージ・テンプレートがあれば、それを元にサーバーの状態を戻せるだけでなく、運用時にサーバーを増やす必要があったとき、比較的短時間に展開できるようになるからです。 (ご参考: コンフィグレーション・ガイド 1.5.1 仮想サーバーのOSバックアップを取るには?

ゲームの正式リリースに向けての準備

B君とC君の奮闘により、対戦機能を備えたオンライン・ゲームとしては形になってきました。 あとは、リリースに向けて本番環境を作ることになります。 本番環境を簡単に作るには、次の図のように、それぞれの役割ごとにサーバーを分割する方法です。 開発環境では既にイメージ・テンプレートを作成していましたので、LinuxサーバーからDBサーバーを切り離すこともスムーズに行えます。 イメージ・テンプレートを元にDBサーバーを起動したあと、それぞれのサーバーで不要なサービスを停止し、簡単に役割を分けることができます。


もう1つ本番環境に欠かせないのは稼働監視サーバーです。 こちらは、他の環境で利用していたZabbixがセットアップ済みのイメージ・テンプレートがありましたので、それを元にすぐに稼働させることができます。 A社ではシステム開発でZabbixの利用経験があったのと、ゲームアプリ環境の監視のために、より細かな監視項目の設定やアラートの設定を行えるためです。

このように準備をしたおかげで、無事A社の初アプリは無事にサービスインを迎えることができました。

急なアクセスピークを乗り切るために

サービス開始から1ヶ月たち、徐々にプレイヤーが増え始めてきました。 SNSを使った告知が功を奏し、徐々にプレイヤーが増えていきます。 月例の企画会議で社長に報告したところ、このままプロジェクトは継続となりました。 A社としては、全くヒットしなければサービス終了も視野にいれていたので、B君も安心です。

ゲームの運用も軌道に乗ってきたかなと思っていた矢先、稼働監視サーバーからアラートを知らせるメールが届き始めました。 B君があらかじめ導入していたZabbixの監視状況を調べ始めたところ、アプリ・サーバーの稼働率が高く、そこがネックになってくることが把握できます。 C君によると、どうやら大手のゲーム紹介サイトで注目ゲームとして紹介されてしまい、利用者が急増してしまったのが原因です。

アラートと同時に、ゲームを遊べないという苦情のメールも届き始めます。 せっかく軌道に乗ってきたかと思いきや、ゲームで遊べない人が続出してしまうと、せっかく多くの人に認知してもらえるチャンスを逃してしまいます。

そこでB君が取った対策は、ロードバランサーを導入してウェブ・サーバーの負荷分散です。 ローカル・ロードバランサーをオンラインで注文すると同時に、ウェブ・サーバーをイメージ・テンプレートを元に追加しました。 1時間もしないうちに環境が整いましたので、ゲームサーバーの設定とDNSを切り替えて、アクセスピークを乗り越えることができました。

快適なゲーム環境を目指して

急激な利用者の増加を乗り切りましたが、快適なアクセス環境の提供が喫緊の課題となってきました。 今後もアクセスが増えても前回のような問題を繰り返さないため、負荷テストを実施し、次のような課題があることが分かりました。

  • ウェブ・アプリ・サーバー … メモリ不足でスラッシング状態となり、リソース不足によるCPU負荷の上昇
  • DBサーバー … ディスクI/Oの頻発による速度劣化

ウェブ・サーバーやアプリ・サーバーに対する負荷に対しては、仮想サーバーのCPUやメモリを増やして1台あたりの処理能力を高める方法を検討します。 仮想サーバー1台では限界がありますので、ロードバランサーやLVSを使ってスケールさせる方法が効果的だからです。 ゲームの中のイベントやキャンペーン期間など、一時的にプレイヤーが増えても簡単にスケールアップできますし、プレイヤーが減ってきたら、また減らせることも手軽にできます。 ここでは、オートスケーリング機能を導入することにします。 (ご参考: コンフィグレーション・ガイド 3.7 オートスケールを利用するには?

また、DBサーバーの負荷に対しては、MySQLサーバーであればメモリを増やしてチューニングをしたり、CPUのコア数を増やす方法もあります。 一方、ディスクI/Oに関しては単純に仮想サーバーのスペックを増やすだけでは解決が難しく、将来的に頻繁なスペックアップが必要になりそうです。 そこで、仮想サーバーから物理サーバーへの入れ替えを行うことにしました。 物理サーバーであれば、RAID1の構成が選べたり、より高速なSSDを選ぶことができるからです。 入れ替え作業そのものも、フレックス・イメージを使うことで簡単に行えます。 (ご参考: コンフィグレーション・ガイド 1.5.5 仮想サーバーから物理サーバーへ移行するには?

これまで、ゲーム機能のアップデートによってシステム全体の負荷が高くなる傾向がみえてきました。 新機能アップデート時のメンテナンス期間にあわせ、インフラ側のシステム強化も順次行いました。 構成強化後は、ゲームのプレイが安定しただけでなく、新しいリアルタイム・チャット機能もスムーズに動作し、プレイヤーからの評判も上々。 一時的にアクセスが集中してもトラブルが起こることはなくなりました。

可用性の高いゲーム環境を提供するには?

A社のゲームはランキング上位に掲載されたり、SNSで話題になるほどゲームがヒットし、常に一定数のプレイヤーがゲーム上に集まるようになってきます。 こうなってくると大切なのは、可用性を高めて、常に安定したゲーム環境を提供することです。 ゲームで遊べなくなる事故が発生すると、せっかく定着した常連さんもゲームから離れていってしまうかもしれません。 そうならないよう、可用性高めて安定してさせることが経営的課題になってきました。

アプリ・サーバーは、比較的負荷が低いので二重化するだけで対策がとれます。 そのためには、ロードバランサーやLVSの導入によって可用性を簡単に高めることができます。 あらかじめアプリがセットアップ済みのイメージ・テンプレートを用意しておくことで、それを元に何台ものサーバーを追加することができます。 ロードバランサーやLVS自身の可用性を高めるために、冗長構成にすることも効果があります。

ウェブ・サーバーは、サーバー上でHTMLページや画像データなどの静的なコンテンツしか持っていなければ、オブジェクト・ストレージ上のCDNを利用する方法がよい選択肢です。 これは、アクセスが集中すると、ウェブ・サーバーからのトラフィックが増えてしまい、課金も心配になります。 またウェブ・サーバーの可用性を高めようとすると、複数台のウェブ・サーバーにコンテンツを同期する必要があり、管理上の煩雑さが増えます。 そこでCDNを使えば、トラフィックを迂回させられるだけでなく、コンテンツの管理も一元化できる利点があるので検討することにしました。 (ご参考: コンフィグレーション・ガイド 5.1 オブジェクト・ストレージを利用するには?)

Photon Server は障害に備え、コールドスタンバイ用の予備サーバーを用意し、稼働系と待機系の構成にしておくことがお勧めです。 Portable IPアドレスの機能を使えば、コールドスタンバイ機への切り替えもスムーズに行えます。 (ご参考: コンフィグレーション・ガイド 4.2 サーバーを替えても同じIPアドレスを継続するには?

DBサーバーは複数のレプリカを配置する方法であれば、マスターの負荷を下げられて、読み取りだけを複数のサーバーに分散できるので効果的です。 しかも、開発においてコードを書き換える必要がなく、インフラだけで負荷の分散もできます。 一方、マスターサーバーはレプリカの元本となり書き込みが発生するため、アクティブ・スタンバイ構成を検討することになりました。 (ご参考: コンフィグレーション・ガイド 3.4 アクティブ・スタンバイのクラスタを構成するには?

さらに可用性を高めるためには、専用のロードバランサーの導入も検討要素になります。 ウェブ・サーバーやアプリ・サーバーに対するアクセスをセッションごとに細かくバランシングしたり、仮にウェブ・サーバーにアクセスできなくなればオブジェクト・ストレージ上に静的なコンテンツとして置いているSorryサーバーにリダイレクトし、CDNも使えるのでSorryサーバーにアクセス集中をすることも回避できます。 専用ロードバランサーは冗長構成を取ることもできますので、機器自身の可用性も高められます。 (ご参考: コンフィグレーション・ガイド 3.3 ロードバランサーを利用するには?

さらに、アクセスが増えてくるとゲームに対する攻撃やセキュリティに対する懸念も増えてきます。 個別にハードウェア・ファイアウォールを導入していくと、サーバーの台数分だけ料金が加算されてしまうので、ネットワーク・ファイアウォールを使いVLAN単位で保護することが決まりました。 同じVLAN内であればサーバーが何台増えても料金が変わらないため、ハードウェア・ファイアウォールより安くなっただけでなく、オートスケールで増減するサーバーにも自動的に適用されるため、安全性を高めることもできます。 (ご参考: コンフィグレーション・ガイド 3.3.2 専用ロードバランサー(NetScaler)を使うには?)ここでは、NetScalerのWAFと組みあわせて、いろいろな攻撃に対応ができるようにするため、セキュリティ上の保護も考慮し、少し料金は高いのですがNetScalerを導入することにしました

こうやって、環境を整えたおかげで会員数や売り上げも順調に伸びていきました。

海外展開を考えるときの構成は?

ゲームも安定稼働し、A社の企画会議では業績向上につながったこともあり、ゲームに対する評判も上々。 企画会議では社長による「もしかして、海外でもいけるんじゃないの?」という一言で、海外展開が次の課題になりました。 海外展開を行う際も、SoftLayer であれば、時間をかけず迅速な環境構築を行えます。 同時プレイ型のオンライン・ゲームを海外に展開するにあたって、どのように環境を構築したらよいでしょうか。

海外展開時の大きな課題は、ゲームを世界で同時に行えるようにするか、国や地域ごとにわけるといった言語や文化にどのように対応するかです。 今回は手始めに、同時プレイは特定の国や地域で分けますが、ゲームスコアのランキングは、世界中で統一させることにします。

手始めに最小構成の仕組みを各地に配置し、ゲームサーバーの環境を展開することにしました。 この構成の特長は、ゲーム開始時、プレイヤー同士のマッチングを行うためのゲームサーバーは、1箇所に集中する必要があります。 接続元のIPアドレスを参照することで、それぞれの地域で稼働しているアプリ・サーバーに処理を分散します。 ランキング情報の同期や、世界各地のゲームサーバーを結びつける場合に、プライベート・ネットワークの利用が役に立ちます。 データーセンターをまたがったデータのやりとりの際、トラフィック量に対する制限や課金はありません。 RabbitMQなどのキュー・サーバーを使って、ランキングの同期を行うことにしました。

こうして、B君のちょっとしたアイディアでスタートしたゲームは、海外にも展開するようになります。 A社はウェブ系のシステム開発会社というよりは、もうゲームメーカーとして認知されています。 A社やB君達の挑戦は、まだまだ続きます。