Amazon EC2上のサーバー開発と運用方法をARMORED CORE Vのインフラで学ぶ

CEDEC2012でフロム・ソフトウェアの恵良和隆さんが「ARMORED CORE Vのオンラインサービスにおけるクラウドサーバー活用事例」というタイトルで、Amazon EC2上でゲームサーバーを運用する場合に解決しなければならない問題点と具体的な解決方法について講演しました。

恵良和隆：
「ARMORED CORE Vのオンラインサービスにおけるクラウドサーバー活用事例」というタイトルで行いますので、よろしくお願いします。

まず簡単に自己紹介をさせて頂きます。2002年にフロム・ソフトウェアに入社しまして、基本的にはライブラリの開発だったりとか、開発環境の構築とかバックエンドのサポートの仕事をしていたんですが、2007年のmeet-meぐらいから、オンライサービスの開発に携わって、そこから大体5年ぐらいオンラインゲームに関することをやっていました。今回お話する「ARMORED CORE V」で初めてクラウドサービスを使いました。

まず、本セッションの内容について、簡単にご説明します。本セッションはコンシューマーゲーム機のオンラインタイトル「ARMORED CORE V」での開発経験がベースになっています。ARMORED COREシリーズは、もともとコンシューマー機で出していたタイトルですが、ARMORED CORE Vを開発するにあたって、オンラインという要素をメインにしたいという話があり、それに合わせて、しょうがないので、サーバー周りの開発を私の方で担当しました。その中で、インフラとしてクラウドサービスを使いましょうという話になりました。今回特にコンシューマー機、オンライン、クラウドサービスを使うといったところをメインにお話します。

ARMORED CORE VはPS3とXbox360で発売されています。今回、コンシューマー機に関して、この2つのプラットフォームをベースとして説明をします。もちろん内容によっては、他のプラットフォームでも応用できるものがあると思います。あと、少し注意点があります。オンラインタイトルという言葉がよく出てきますが、ここで使うオンラインタイトルという言葉の定義は、クライアント・サーバー型のネットワークシステムとしています。

プラットフォームであらかじめ搭載しているマッチングシステムを使ったP2P接続のみのタイトルは含みません。本セッションの中で、いくつかの事例と問題点と解決方法を例として挙げていますが、あくまで一例であってベストな方法ではありませんので、ご注意頂きたいと思います。もちろんタイトルによっては、方法そのものが適切でないという可能性もありますので、その点もご注意下さい。クラウドサービスとしてIaaSのお話をするんですけど、基本的にはARMORED CORE Vで使ったAmazon EC2がベースとなっています。他のクラウドサービスもあるんですけど、Amazon EC2をベースとしてお話させて頂きます。

アジェンダとしてこういう形で進めさせて頂きます。まず、オンラインタイトル開発における注意点というところで、クラウドではなく、オンラインってどういうことか、あとコンシューマー機のオンラインタイトルってどこを注意しなきゃいけないのか、というところを先にお話させて頂きます。次にインフラに関する注意。そしてサーバーインフラについて。最後に、注意点から出てきた問題点を整理し、具体的な対応と掘り下げた問題を扱い、考察とまとめをしたいと思います。

コンシューマー機向けのオンラインタイトル開発の注意点です。

まず、気にしなければいけない点は、コンシューマープラットフォームの特殊性があげられます。プラットフォームごとにポリシーが異なってしまうので、それに合わせた特殊性が出てしまいます。この特殊性は避けては通れません。その中で2つ気にしなければならないことがあります。1つ目はセキュリティです。具体的に話すと通信プロトコルとユーザー認証です。

2つ目は、コンシューマ機独特のQAチェックがあります。QAチェックは、例えばマイクロソフトさんとかソニーさんといったプラットフォーマーで実施されるもので、ゲームにバグがあるというよりは守るべきルールに従っているのかについてのチェックです。このQAチェックをパスして初めてゲームがリリースされます。この点を特殊性として押さえておきます。どういうことかというと、PCの場合だと、QAチェックと似たものはありませんが、コンシューマー機の場合だと、必ずパスしなければならないので、バッチとかタイトルのアップデートをするときには、注意しないといけません。ポンポンとパッチを出すことができないということです。

次に、PCとの違いがメインになります。ハードウェアスペックの違いがあります。CPUとメモリの違いがあるんですけど、パフォーマンスではなく構造的な違いです。Endianの違いだったりとか、メモリ容量に関しては、コンシューマー機のメモリは容量は少ないです。また、利用できるライブラリに制限があります。例えば、ライセンス的に問題ないオープンソースのライブラリーがあったとしても、基本的に、Windowsであったり、Linuxであったり、そういった一般的なプラットフォームの上で動くように作られていて、コンシューマ機で動くことが前提になっていません。コンシューマー機の上で動かそうとすると、ポーティングという作業が必要となります。この辺はやってやれないわけではないんですが、中にはハードウェア固有の特殊なものを使っているとか、OS依存のシステムコールを使っているものがあるので、流用する場合は、ポーティングの手間が掛かります。ただ、マルチプラットフォームのタイトル開発をしていれば、あまり気にならない当たり前の話ではあります。

オンラインサービスをやるにあたって、必ず考えておかなければならないこととして、運営というものがあります。まず、製品のサポートをしっかりと考えないといけません。コンシューマー機のユーザーはPCゲームのユーザーとちょっと違って、ネットワークうんぬんの話とか、技術的に詳しくない方が結構いて、そういった人のサポートをどうするかをしっかりと考えた上でサービスを提供します。また、トラブルは必ず起きるので、オンライン独自のトラブルが起きたときに、どのように対処するかも事前に考えておく必要があります。

プラットフォーム側オンラインサービスの都合。これは、PlayStation NetworkやXbox Liveには、当然メンテナンスが発生するので、プラットフォームのサービスが止まったときにどうするか、ということです。基本的に止めるしかないですけど、タイミングを合わせて止めることを気にする必要があります。

そしてサービスの稼働状況の監視について。これはコンシューマーには関係ありませんけど、オンラインサービスをやるにあたって、きちんとサービスが動いているかを監視するインフラの監視と、サーバープログラムのプロセスが死んでいないか監視になります。

オンラインサービスとは切っても切れないインフラについて。

何がサーバーインフラに求められるのか。この点について間単に整理します。一般的にクライアント・サーバ型のネットワークの場合、クライアント数が増加するとサーバーの負荷が増大します。サーバー負荷は単純にCPU負荷・メモリ使用量・帯域使用量のことを指しています。負荷はソフトが急に売れると、負荷が急に増えるので、サーバーを急いで増強する必要が出てきます。インフラを自分たちだけでハードウェアをそろえてどうにかしようとしたときには、あらかじめ余裕をもって準備しておかないといけません。ハードウェアを注文して準備ができるまで1ヶ月かかるといのはざらなので。

そして、クライアント数がどれぐらい増えるのかある程度、精度よく把握したいところですが。実際のタイトル販売数は事前に予測することが難しく、実際に問屋さんに予約が入って、発売日の1週前ぐらいにならないとリアルな数字がなかなか見えてきません。なかなかタイトルの販売数の予測は立てにくいです。これがフリーミアム、基本無料というタイトルだとなおさら困難で、ユーザーがどれだけつなぎにくるか、検討がつきません。接続するクライアント数を考えるときに、気を付けないといけない重要なことが、売れ方です。

売れ方に関して、パッケージタイトルの売れ方が独特です。売れ方が販売地域によって、大きく違います。

例えば、このなグラフがあるとします。見て分かると思いますが、日本と欧米の売れ方が全然違います。縦軸は一日当たりの販売本数であるので、ユーザー数の伸び率を表しています。よって日本の場合は、発売直後に急激に同時接続数が増えます。たちが悪いことに、この売れ方は日本だけです。特殊な売れ方をあらかじめ想定しておく必要があります。

製品寿命に関して。パッケージタイトルは内容が変わらないので、大きなアップデートがなければ飽きられてユーザーは減っていきます。アクティブユーザーさんが発売直後に急激にどっと増えて徐々に減っていきます。最終的には0に近いところで落ち着きます。この製品寿命と売れ方を把握した上で、インフラを準備しなければなりません。

これまでの話を踏まえた上で、サーバーインフラの選択肢を考えてきます。そもそもフロム・ソフトウェアはオンラインソフト開発の経験はあるんですが、自社でサーバーインフラを持って、サービスを展開していくことは初めてだったのでARMORED CORE Vを開発するにあたって、インフラをどうするのか考えなければなりませんでした。話を簡単にするためにここはオンプレミスとクラウドサービスに限定します。

オンプレミスの場合、問題となる点を考えてみると、ハードウェア、ケーブル、スイッチなどばかにならない初期コストです。ハードウェアを持つと壊れた場合の修理代やデータセンターに置く月々の保守コストなどが掛かります。コストは掛かりますが、ネットワーク部分は自由に設計できるので、特殊なことをやりたくなったときに、それに応じた設計ができます。メリット、デメリットはありますが、設計部分を設計するインフラ専門の人材が一番のネックです。

クラウドサービスの場合、使った分だけ払う従量制課金なので無駄なコストが省けます。また保守を気にしなくてもいいところがメリットとしてあります。ただ、いいことばかりではなくて、インフラの仕組みに基づいた制限がどうしても出てしまいます。今回はIaaSの話になります。

たとえば、Amazon EC2（IaaS）の制限。1つ目はサービスレベルです。IaaSの業者ごとにSLAとして値があり、Amazon EC2の年間稼働割合が99.95％を目標にしていると宣言されています。1つのIaaSのシステムの上で、サービスを展開すると、これを超えるサービスレベルは当然無理です。これより高いサービスレベルを提供するには分散サービスにしなければなりません。SLAの値がいい業者を使えば、下手にけちったオンプレミスのシステムを作るよりサービスレベルが高くできると思います。結局、品質を上げようとすると、ネットワークや機材の冗長性などを考えるとコストが掛かることもあり、なかなかできないということもあって、ここに関しては状況によって制限にならないのかもしれません。大きな話として、IaaSは基本的には仮想環境で提供されることが多いです。Amazon EC2の場合だと、Xenを使った仮想環境で提供されるゲストOSを利用することになります。基本的にXenのゲストOSでできることしかできません。どういう制限があるかというと、仮想NICが1つで、そのNICに対してIPアドレスは動的に割り当てられます。外側からアクセスするために割り当てられるグローバルIPアドレスはNATによってマッピングされます。マッピングするグローバルIPアドレス自体は予約することが可能です。

ここまでの問題の整理をします。ざっと列挙するとこのようになります。このうちハードウェアスペックの差異と利用できるライブラリの制限は、マルチプラットフォームの対策をしているところであれば当たり前のことで、それ程難しいことではないので、今回は割愛します。サービス運営に関してもオンラインであれば必ずあることで、コンシューマーであってもクラウドであっても関係ないので、これも割愛させて頂きます。

今回取り扱う要素はこの3つです。

具体的な対応方法について。

まず、プラットフォームごとのセキュリティ対応について。

セキュリティ対応で重要なところは通信プロトコルとユーザー認証をどうするかという点です。また、今回はXbox360に限定した話とします。

Xbox360の通信プロトコルについて、まずXbox360は通信プロトコルとしてXSP（Xbox Secure Protocol）を使用しなければなりません。XSPはどういうものかというと、Ethernetの上にIP、次のUDPの上に乗っているのがXSPです。アプリケーションレイヤー的にはXSPという存在自体は、あまり意識しなくてもいいですけど、下で勝手にセキュアな通信が行われています。Xbox360同士で、通信するときには、必ずXSPが使われます。

ユーザ認証に関して、Xbox360の場合はユーザー認証をするとき、XLSP（Xbox Live Server Platform）が用意されているので、これを使うとユーザー認証を気にする必要がありません。XLSPは、XSPを独自サーバで使えるようにするための仕組みになっていて、このプロトコルはそもそもオープンなものではないので、自分たちで作った独自のサーバが直接XSPを使うことはできません。その代わり、XLSPが間に挟まって、セキュアな通信を実現するプラットフォームになっています。

まとめると、Xbox360はXSPの利用が必須なんでけど、それを使うことによってセキュリティ面を気にする必要がなくなります。セキュリティの実装をしなくてもいいというメリットがあります。ゲーム開発者はセキュリティの専門家ではないので、セキュリティをどうするかということはとても難しくて、問題を発生させてしまう可能性があるので、非常に素晴らしいシステムなんですが、残念ながらクラウドサービスの制限に引っかかってしまいます。Xbox360のタイトルでクラウドを使うといったときには、クラウドの上でXLSPを動かさないとネットワークサービスが実現できません。どうやって動かすかというところをXLSPの説明をしながら、順にお話していきます。

XLSPとは、真ん中にある赤い点線で囲んだ2つのサーバー部分を指します。Windowsで動くプログラムなんですけど、Web ProxyとSecurity Gatewayの2つのモジュールで構成されています。Windowsのプログラムでサービスとして動かすことができるんですが、基本的にWindows Serverの上で動かします。ネットワークの構成上、InternetとData Centerの間に配置されます。Web ProxyとSecurity GatewayにはInternet側とデータセンター側に2つのNICが用意されてあって、それぞれプライベートIP、グローバルIPを割り当てます。

動きについて、Web Proxyは名前の通り、Proxyとして動きますが、基本的にはXbox Live Serverと通信ができます。Security Gateway自体は直接Xbox Live Serverと通信はできないんですけど、Web Proxyを通して通信ができる仕組みになっています。Security Gatewayはクライアントから直接接続されるノードとなるんですが、クライアント数が増えてくると当然スケールアウトできるようになっています。スケールアウトすると、IPアドレスが増えたり接続するエンドポイントが増えたりします。その点をどうするかというと、Security Gatewayは起動すると自分自身のグローバルIPアドレスをWeb Proxy経由で、Xbox Live Server方に登録します。その登録されたグローバルIPアドレスをクライアントが取りにいって、取得した情報を使ってSecurity Gatewayに接続します。Security Gatewayに対して、飛んできたクライアントからのパケットはユーザー認証をしたあとに、パケットを復号化してクラウド独自サーバーの方に流す動きになります。ここで重要なことは、Security Gatewayがどう動くかということです。

Security Gatewayとは、文字通りGatewayとしての役割を担っています。基本的にはプロトコル変換をしてくれます。Xbox360から飛んできたXSPのパケットをデコードしてUDP/TCPの生パケットに変換してくれます。そして裏のサーバーから飛んできた生パケットをXSPに変換して返すといったプロトコル変換をします。プロトコル変換をするので、ヘッダーの書き換えをし、宛先と送り主を書き換える動きをしています。クライアントから最初にパケットが飛んでくると、ユーザー認証をしてくれて、正しくログインをしているXbox Live ユーザーだと確認できれば、そのパケットを複合化して、裏に流します。認証されていないパケットは却下されます。WindowsのIPスタックとは完全に分離されていて、OS側のネットワーク設定とは完全に無関係に動くモジュールです。

クライアント1とクライアント2とSG（Security Gateway）と独自サーバーがあるとします。ユーザー認証が完了した状態で、それぞれIPアドレスとポート番号が設定されているとします。まず、クライアント1からパケットが飛んできます。XSPに従ったパケットがSecurity Gatewayに飛んでくると、Security Gatewayでこれを複合化して生のUDPパケットに戻し、ヘッダーを書き換えて、独自サーバーに投げてくれます。同じようクライアント2に対しても復号して独自サーバーに投げますが、Fromのポート情報が1001になり、他の人からきたパケットだと認識できる仕組みです。ポイントは、Security GatewayはInternet側のグローバルIPアドレスと、Data Center側のプライべートIPアドレスはリンクする点です。グローバルIPとプライベートIPに関して、Security Gatewayは自分自身でNICに対して指定した範囲のIPをアサインしてしまいます。先ほどWindowsのIPスタックとは分かれていることが、ここで起こります。Security Gatewayはドライバーのように動いて、勝手にIPアドレスを設定して、勝手にそこに飛んできたパケットを拾ってしまう動きをします。Windowsが何をしようが、関係なしにパケットを横取りしたり、投げたりします。Windownsのネットワークを殺しても、Security Gatewayで動いてしまうものです。ここはネックな部分で、XLSPの稼働条件が出てきてしまいます。

XLSPの稼働条件の1つ目は、自由にアドレス設定できる2枚のNICが必要になります。また自由に使えるプライベートIPアドレス空間が必要です。そして、空いているグローバルIPアドレスも必要です。この稼働条件がAmazon EC2の制限に引っかかってしまいます。Amazon EC2では、NICが1つしかありません。しかもその仮想NICに対して、自由にIPアドレスをアサインできません。よってSecurity Gatewayがコントロールできないネットワークになってしまいます。

この部分をどうにかしないと、Amazon EC2の上で動かすことができません。ではどうやって動かすかというと、まずXLSPに必要なものを考えてみます。NICが2つ必要といことは、正しくなくて、Security Gatewayの立ち位置上はInternet側とData Center側にまたがるところにあるので、Data Center側とInternet側の通信がセキュアな通信ではないため、パケットが盗み見られないように、物理的にちゃんとネットワークを遮断しましょうというもくろみがあるので用意することになっているだけです。動くかという意味では、NICが1つでも動きます。まとめると、XLSPに必要なものは、自由に使えるプライベートIPアドレス空間、グローバルIPアドレス、自由にアドレスをアサインできるNICという3つがあれば大丈夫になります。結局Amazon EC2では実現できないんですけど。要するにネットワーク設定を自由に行いたいということなので、仮想ネットワークを使ってあげれば何とかなるのでは、という推測ができました。

そこで、Amazon EC2の上でVPNを乗せることを実行してみました。Amazon EC2にはもともとVPNのサービスがあって、これを使えば、仮想的なネットワークの構築ができるんですけど、Amazon EC2のVPNサービスはアプリケーションからIPアドレス設定ができません。管理コンソールからIPアドレスを設定することはできますが、独自にいじることはできないので、OpenVPNを使ってみました。完全なソフトウェアなのでAmazon EC2上で動きます。OpenVPNは仮想インターフェース（TAP）を持っているので、そのTAPを使えばアプリケーションからIPアドレスを設定できます。よって1つ問題が解決できます。ただ、ソフトウェアでVPNを実現するので、オーバーヘッドが大きいです。オーバーヘッドが大きいですが、なんとかできそうなので、試してみました。

ここにWeb ProxyとSecurity Gatewayと独自サーバーの3つがあるとします。Amazon EC2側でアドレスが勝手にアサインされます。この上にOpenVPNを展開すると、TAPインターフェースが192.168.x.xのプライベートアドレスを割り振ることができます。ネットワークの部分に設定が自由にできるので、TAPインターフェースをSecurity Gatewayに使わせることでXLSPの要件を充足できるので、XLSPを動かしてみたら動きました。

ただ、XLSPは動きますが、Security GatewayはTAPインターフェースしか見ていません。そのため、インターネットとVPNが完全に遮断されてしまうのでXbox360からパケットが到達しません。どのようにSecurity Gatewayに対してパケットを到達するようにするかというと、Internet側とVPN側をつなぐ必要があるのでパケットリピータで中継します。

パケットリピータがパケットを受け取ったら、TAPインターフェースを経由してSecurity Gatewayに投げ直してあげれば、Xbox360から独自サーバーまでキレイに流れます。ここまでやって、Amazon EC2上で、XLSPを動かすことができます。ARMORED CORE Vではこの形で、運用しています。これだけ重なれば、余計なスループットやオーバーヘッドが生じますが、やむなしとしています。どういうサービスをこの上で提供するかによって要件が変わってくるのですが、ARMORED CORE Vの場合は帯域がそこまでヘビーではないので、こういった形で動かすようにしました。

次はQAチェック対応について。

製品をリリースする前に必ず通らなければならない関門です。製品をリリースするためのチェックなので、基本的にQAチェックは製品版と同じになります。製品の中で、設定されている接続先も製品と同じです。製品がリリースされて、その後に機能追加や不具合修正のためのパッチを適応する場合にもQAチェックを適応しないといけません。リリース後にQAチェックを行う場合、接続先が本番と同じものになるので、QAチェックが本番サーバーに接続してしまう問題があります。そこで、接続先をコントロールしなければなりません。

どういうことかというと、HTTPでWebサーバーから情報を取得することがあると、アクセス先のURLをどうするかという話があります。ソースコードにハードコードを埋め込むのか、何らかの形で動的に取得するのか。QAチェックのために用意した専用のWebサーバにアクセスさせる必要があるので、その部分のかじ取りをきちんとやる必要があります。

話は簡単で、NATでパケット転送すればいいだけです。これだけということではないですが、サーバー側でできる手っ取り早い方法がパケット転送になります。本番サーバーの入り口にiptablesを設定し、QAチェック用の専用サーバを用意して、QAチームから飛んできたパケットをQAサーバーの方へ転送して、戻ってきたパケットをQAチームに転送する形でパケット転送すればうまく振り分けることができます。そうすれば、ユーザーさんのパケットは本番サーバーへ飛んでいって、QAチームのパケットはQA用のサーバーに飛んでいきます。単純な接続であればこのようにしのぐことができます。

最後にサーバー負荷の大きな変動についてです。

要するに負荷分散の話になります。まず、Amazon EC2にインスタンスを作成すると、このようにIPアドレスが作成されます。

EC2の外からDNSで参照してみると、このホスト名は、グローバルIPアドレスに置き換えられます。内から参照すると、ローカルIPアドレスに置き換えられます。Amazon EC2の中からは完全にグローバルIPアドレスが見えなくなっています。完全にローカルのIPアドレスしか扱わない仕様になっています。

プライベートIPは内部だけで使い、グローバルIPアドレスは外部とEC2の接続のときに使います。ホスト名を使う場合は、Public DNSのホスト名を使えばいつでもちゃんと接続してくれます。ただし、Public DNSのホスト名をEC2のインスタンス自身は知りませんので何らかの形で、教える必要があります。

ARMORED CORE VではIPアドレスを使用しました。開発中のサーバーや独自のサーバーを使うなどEC2以外の環境で稼働させるためです。グローバルIPアドレスとプライベートIPアドレスを各サーバープロセスの設定ファイルに記述しました。サーバープロセスは設定ファイルから読み込み、それをDBに記録すれば、接続先のIPアドレスが分かる形になります。

ここから負荷分散の話をしていきます。Amazon EC2にはELB（Elastic Load Balancing）というロードバランサーのような仕組みが備わっているので、これを使っていれば勝手に負荷分散してくれて、裏側のIPアドレスを気にしなくていいもので、非常に便利なものがあります。

ただELBには問題があって、セッションベースのプロトコルのみにしか対応していません。TCP、HTTPなどには使えますがUDPでは使えません。Xbox360のXLSPはUDPの上に乗っかっているので使えません。あと、iptablesのように、パケット転送ができません。よってQAチェックのときにパケット転送が使えないということです。クライアントからの接続を分散する目的で利用できないので、自分でやりましょうということです。

ARMORED CORE Vでは、最初に接続するサーバー（ログインサーバー）を固定して、ログインサーバーが本当につなぐべきサーバー情報を教えることにしました。

考察です。実際に運用して分かったことについて、Amazon EC2は非常に安定していました。EC2が原因のトラブルは数えるほどで2、3回しか起きていません。もう1つはコンシューマ機のタイトルはユーザーがものすごく集中します。集中するときには、クラウドによるスケールアウトが非常に効果的に使えました。スケールアップも容易にできるのが利点です。スポットでサーバーを準備できるので、開発用やQAチェック用のサーバをすぐに用意できることは非常に便利でした。

課題について、今回説明したXLSPを稼働させる方法ではスループットが出ません。大量データの送受信が必要となる動画を配信したいとしても無理なので、諦めてオンプレミスにするしかありません。クラウドを使うとサーバーを簡単に増やすことができ、非常にありがたいことですが、サーバーのインスタンスが増えるとその上で動くプロセスのが増えるので、プロセスの起動や停止が大変です。簡単な操作で大量のインスタンスやプロセスを動かせる仕組みが必要です。要するに、クラウドを効率良く扱うためのシステムが必要です。ここは有料のサービスがあるので、そういったものを使う対応をしなければならないと思います。

まとめです。コンシューマー機向けのオンラインタイトルでの注意点は、プラットフォームごとに異なります。クラウドサービスの制約はあるが、工夫次第で回避することが可能です。サービス開始後のQAチェックもしっかりと考慮したした上で作りましょう。負荷分散は自分でやらないといけません。結論として、クラウドサービスは、コンシューマ機向けオンラインタイトルに最適なインフラの1つになり得るのではないかと思います。