【特別企画】ソーシャルゲームのDevOpsを支える技術(後編)~魔法少女リリカルなのはINNOCENTの舞台裏~

この記事を読むのに必要な時間:およそ 6 分

[Part2:クラウド事業者サイド]ソーシャルゲームの恐ろしい負荷

ソーシャルゲームをサーバや運用サイドから見たとき,最も注意し事前に対策を検討しておくべき1つに,急激な負荷への対策が挙げられます。急激な負荷が生じる例として,

  • ゲームのサービスリリース当初
  • ゲーム内イベントの開始直後と終了間際
  • 機器故障や不具合での構成縮退時

と言ったケースが考えられます。このような急激な負荷への対策として,クラウドサービスを利用し,スケーラブルなシステムを構成することが一般的になってきました。フロントのWebサーバやアプリケーションサーバは簡単にスケーラブルな構成を組める一方で,ボトルネックになりやすい,つまりスケールが難しいポイントがおもに2つ挙げられます。1つ目にDBなどのディスクI/O,2つ目にサーバからのトラフィックです。

『魔法少女リリカルなのはINNOCENT』では,(株)IDCフロンティアのクラウドサービスセルフタイプ(以下,IDCFクラウド)を採用していただきましたので,スケールが難しいポイントへの対策をどのようにとられたか,クラウドプラットフォーム側から一部を紹介させていただきます。

数万IOPSをさばくには

クラウドでも速いディスクI/O

最近の各社クラウドサービスでは,IOPSを保証するオプションやフラッシュドライブを用いたディスクを提供する事業者が出てきており,クラウドサービスを利用したとしてもディスクI/Oに対して高いパフォーマンスを出せるようになってきました。

IDCFクラウドの仮想マシンでは,自動階層化にてフラッシュドライブ(SSD)をキャッシュとして利用する機能を搭載したストレージを利用しています。つまり,I/O数が多いディスク領域は自動でフラッシュドライブにキャッシュされます。これにより,仮想マシンはより高パフォーマンスなディスクI/Oを発揮することができます。また,I/O数が多いディスク領域がフラッシュドライブに退避されることで,キャッシュされなかったディスクでも安定したIOPSを得られます。これにより数千~1万IOPS程度は出すことが可能です。データベース用途でも十分な性能を出すことが可能です。

ioDriveはやっぱり速い

本作品でも,構築当初はDBサーバを仮想マシンの構成で進めていました。しかし,サービスリリースを目前にして,ゲームの事前登録の人数が多いことから高負荷によるシステム停止を起こさせないための再検討が行われ,DBにより高いI/O性能が求められてきました。

そこで,DBサーバを仮想マシンからFusionIO ioDriveを搭載した物理サーバへ変更し,構築し直しました。IDCFクラウドでは,物理サーバを選択できるオプション(プライベートコネクト)を提供しており,これを利用しています。ioDriveを利用するメリットとして,仮想マシンと比較して低レイテンシーかつ大量のIOPSを処理できるため,高速なディスクI/Oを手に入れることができます。その性能は他のフラッシュドライブを圧倒し,数万~10万IOPS以上の性能が得られますので,DBサーバとしてディスクI/Oがボトルネックになることは回避できることでしょう。

もう1つのメリットに,仮想マシンのようなパブリック環境ではなく物理サーバ占有環境であるため,ほかからの負荷の影響を受けることによるパフォーマンス低下を避けることができるという点もあります。

1Gbpsオーバーのトラフィックをさばくには

物理サーバと接続したIDCFクラウドでは図3のようなネットワーク構成となります。ここからは,図中に①~③として記したポイントについて紹介します。

図3 IDCFクラウドのネットワーク構成

図3 IDCFクラウドのネットワーク構成

高帯域な仮想マシン間通信:①

10Gbps対応機器が普及してきた昨今,各社クラウドサービスでも10Gbpsのネットワークで構成されている環境が出てきています。IDCFクラウドでは,物理環境としては,すべてのネットワークを10Gbpsで構成しています。仮想マシンから見ると,そのスペックタイプに応じて100Mbps,500Mbps,1Gbpsとプランを用意しています。本作品の環境でも使われていますが,オプションで2Gbpsを提供することも可能です。大容量の物理ネットワークと仮想マシンのトラフィックを一定の値で制限することにより,高速かつ安定したネットワークを提供しています。

先述のとおり,DBサーバのディスクI/Oボトルネックが解消することで,サーバ間の通信が増えることが想定されます。また,キャッシュサーバのように通信が集中する用途のサーバもありますので,サーバ間の通信においても安定した高帯域が必要になってきます。

物理サーバが1Gbpsで輻輳(ふくそう)した:②

ioDriveによってディスクI/Oのボトルネックが解消されたDBサーバが,ゲーム内のイベント開始直後に1Gbpsで輻輳するという事態がありました図4)。物理サーバは1000BASE-Tにて1Gbps接続されており,2つのNICにてBondingのActive-Backup(mode=1)で冗長化しています。つまり,最大1Gbpsまでしか出せませんでした。

図4 物理サーバの接続先L2スイッチでみたトラフィック

図4 物理サーバの接続先L2スイッチでみたトラフィック

このときの回避策は,BondingのBalance-TLB(mode=5)によって「アクティブ-アクティブ」の構成に設定を変更するというものでした。これによってサーバからの送信については1Gbpsを2本使えるようになり,最大2Gbps出せるようになりました。あわせて,データベース側からはMySQLの通信圧縮も設定され,物理サーバからの通信ボトルネックも解消されました。

上位も10Gbps:③

インターネット側の帯域はボトルネックになりやすいポイントです。たとえば,共有の回線だったり,100Mbpsの回線だったりするかもしれません。IDCFクラウドでは,10Gbpsの共有回線を提供していますので帯域としては充分に余裕がありますが,帯域の前に上位のファイアウォール,つまり仮想ルータ注1の処理性能がボトルネックになる可能性が想定されます。

本作品でもサービスリリース直後から,トラフィックがぐんぐん伸びていきました。図5はサービスリリース直後の仮想ルータのリソース状況です。このままのペースでトラフィックが増えていくと,アクセスのピークの時間帯である22~23時には仮想ルータがボトルネックになる可能性も出てきました。仮想ルータはパケット数や新規コネクションにより,CPUがボトルネックになることがほとんどです。

図5 リリース直後の仮想ルータ

図5 リリース直後の仮想ルータ

このとき,ユーザアクセスが多かったのはもちろんですが,コンテンツがCDNのキャッシュに想定したとおりにのらない問題がありました。すぐに修正されてCDNのキャッシュにのりはじめると,そのとき最大で500Mbps近いトラフィックが約半分まで下がりました。実際に今回のゲームに限らず,サービスリリースやメンテナンス直後に,想定どおりにCDNのキャッシュにのらないということはしばしば見かけますので,とくにサービスリリース時には充分な上位の帯域を確保しておくと良いでしょう。

その後,本作品ではイベント終了間際の大量のアクセスに対応するにあたり,1Gbps以上のトラフィックを出すためにファイアウォールを外して,10Gbpsの回線へ直結するネットワークオプションを利用しています。

注1)
IDCFクラウドはApache CloudStackをベースとしたCitrix CloudPlatformを利用して構築していますが,この機能の1つとして仮想ルータが提供されています。Debian系のLinuxをベースとした仮想アプライアンスであり,機能としてファイアウォール,ロードバランサ,NATやポートフォワーディング,VPNなどが利用できます。各アカウントに占有する形で提供されます。また,冗長構成をとることも可能で,IDCFクラウドでは冗長構成で提供しています。

おわりに

ここまで,クラウド上でもスケールが難しい,ディスクI/Oとネットワーク帯域について,本作品にて実際に行ったプラットフォーム側からの対応について紹介しました。ボトルネックを解消してもいつかは次のボトルネックが出てきます。そのほかにも,開発期間が短く,充分な構築やチューニングができないこともあるかもしれません。そんなときは,ミドルウェアやアプリケーション側からの対策とあわせ,プラットフォーム側からも対策ができないか検討してみてはいかがでしょうか。

著者プロフィール

水野拓宏(みずのたくひろ)

(株)ユビキタスエンターテインメント 取締役 CTO

Facebook:https://facebook.com/takuhiro.mizuno
Twitter:https://twitter.com/mizunon


宮嶋史尋(みやじまふみひろ)

(株)ユビキタスエンターテインメント R&Dディビジョン 第2セクション


藤城拓哉(ふじしろたくや)

(株)IDCフロンティア カスタマーサービス本部 ソリューションアーキテクト

バックナンバー

仮想化

  • 【特別企画】ソーシャルゲームのDevOpsを支える技術(後編)~魔法少女リリカルなのはINNOCENTの舞台裏~

コメント

コメントの記入