クラウド環境を選ぶ理由

使い慣れたミドルウェアを利用するため，『⁠魔法少女リリカルなのはINNOCENT』ではIaaSクラウド環境を利用しています。IaaSクラウド環境は，クラウド事業者によって利用できる機能が異なります。サーバスペックに現れない部分は実際に利用しなければわかりません。できるだけさまざまなクラウド環境を試して，選択肢を多くすることをお勧めします。

向きと不向き

IaaSクラウド環境では仮想サーバが利用できます。仮想サーバはCPU性能やメモリ容量によって料金が異なりますが，仮想サーバは物理ホストサーバの上で動作する以上，サーバの性能を専有できず，さまざまな影響によって性能にバラつきが生じます。我々の場合，公開されているベンチマークデータを鵜呑みにせず，自分でSysBenchやfio，mysqlslapなどのベンチマークツールを用いて確認したあとは，厳密な性能の測定にはこだわらず，利用想定，仮想サーバの負荷状況に応じてサーバスペックや台数を柔軟に変化させる方針を取っています。

仮想サーバは簡単に調達でき，自分でミドルウェアをセットアップしたあとのサーバイメージをコピーすることも容易に行えます。

Webサーバはアクセス状況によって負荷が変動しますので，仮想サーバを利用した構成を取ると，急なアクセス増にも楽に対応が行えます。

DBサーバはI/Oアクセスが多いため，安定したI/O性能がないとサーバ性能への影響が大きくなります。I/O性能は仮想サーバでは安定して確保しにくいため，クラウド事業者によっては通常のストレージとは別に，高速なSSDや安定したIOPS（Input/Output Per Second）を供給するストレージを提供するところもあります。

しかしどうしても安定した性能を確保したい場合は，物理サーバの利用も選択肢になります。物理サーバは高速なI/O性能を誇るioDriveを搭載したものや，大容量のメモリが選べるものがあり，それらの性能が専有できるため，仮想サーバと比較して性能面でのバラつきが小さくなります。反面，仮想サーバのように調達が容易に行えず，納期に時間がかかったり，故障の影響を受けやすいなど柔軟な運用が行いにくいデメリットもあります。

本作品では事前登録会員数が10万人を超え，ユーザ活性が非常に高いことが想定されたため，すべて仮想サーバを利用した構成とせず，DBサーバは物理サーバを利用する構成を取りました。初期構成が図1となります。

仮想サーバと物理サーバはL3接続されているため，ルーティング設定を行えば仮想サーバと物理サーバの区別なく相互接続が可能となります。

ソーシャルゲームでのクラウド利用

小さい構成から始めて，利用状況に応じて増強する「スモールスタート」構成はクラウド環境が向いていると言われます。ソーシャルゲームもリリース後の状況が読みにくい部分はありますので，リリース初期はクラウド環境を利用し，その後ユーザ数の増加に伴い安定した性能を確保するためにオンプレミス環境へという方法を選択されている他社SAPの方も少なくありません。

もちろんオールクラウド環境だと不安定で利用に耐えないということはなく，そのソーシャルゲームをどのように成長させていくかという想定のもと，稼働環境を検討することが重要です。

本作品もそれにならい，仮想サーバと物理サーバのハイブリッドクラウドから開始し，最終的にはオンプレミス環境を利用するという成長過程の想定をしています。

クラウド事業者の違い

IaaSクラウド環境を提供する事業者はAWSをはじめ，国内にも多数あります。仮想サーバ機能はどこでも利用できますが，機能面でベンチマークとなるのはAWSです。AWSで当たり前に利用できる機能が，他社では搭載されていないことはよくあります。そのため，AWS以外のクラウド事業者を利用する場合は，ある程度機能面での不足の割り切りを行ったうえで，強みや独自性が生かせる事業者を選択しています。

本作品では，サーバとネットワーク部分はIDCフロンティアクラウドを利用し，DNSやバックアップストレージにAWSのRoute53とS3を利用しています。

IDCフロンティアクラウドは仮想サーバの費用対性能が高く，iDC（Internet Data Center）も運用し，クラウド環境と物理サーバのハイブリッド利用オプションがあるためソーシャルゲームの成長過程の想定に合致していました。

AWSは基本的にインターネット越しにはなりますが，AWS外からもサービスの利用が可能なため，クラウド事業者間でハイブリッド利用することが可能です。

IaaSクラウドはベンダーロックインのような縛りがほとんどないため，事業者ごとに有利な部分を選択的に使うと運用面でも費用面でもコストを下げることができます。

イベント中の運営で何が起きているのか？

『魔法少女リリカルなのはINNOCENT』では現状，月に1回程度イベントを実施しています。イベントは約1週間程度実施され，その期間中の活動ポイントによって報酬が異なります。イベント期間中は普段の数倍のトラフィックが生じることも珍しくなく，イベントの参加者だけでなくイベント運営側にとっても，大変忙しい期間となります。

イベント準備期間では

本作品では原作者の方が監修し，企画後に毎回イベントを新規に実装しています。そのため，使い回しのイベントがほぼありません。企画ごとに新規実装しているため，企画内容によってサーバにかかる負荷パターンが異なります。

たとえば，Flashアニメーションを多用したイベントの場合は，Flashのリアルタイム合成を行っているWebサーバに負荷がかかり，ユーザ間対戦型イベントの場合はユーザのプレイデータを保持するDBサーバに負荷がかかるなど，増強するサーバタイプが異なる性質を持ちます。

どのサーバをどのようなタイミングで増強して行くのかは悩ましいところではありますが，DBサーバに物理サーバを選択しているため，場合によっては調達に時間がかかる恐れがあります。増強に遅れを生じさせないためには，できるだけ事前の負荷想定が重要になってきます。

イベント時の負荷推定を行うためには，日頃からサーバとネットワークの負荷状況を把握しておく必要があります。リソースの利用状況の把握にはZabbixを利用し，可視化しています。

イベントの開始

イベントの開始から終了までのロードバランシングサーバのトラフィックの一例が図2のグラフとなります。イベント直前の50Mbps前後のトラフィックから，7月20日18時から19時のイベント開始直後に，一気に200Mbps超のトラフィックに急増しています。

このとき運営側では，事前想定と負荷状況がどの程度違うかを調査しています。調査ではFluentdを利用したサーバのログ収集と，MySQLのクエリ状況を中心に確認しています。

ソーシャルゲームではWebアプリケーションのレスポンスタイムが重要な指標となります。Apacheのログフォーマットを変更し，「⁠%D」を付与するとマイクロ秒単位でレスポンスタイムの記録が可能です。Combinedフォーマットを利用している場合の変更例は次のようになります。

LogFormat "%h %l %u %t \"%r\" %>s %b ｭ\"%{Referer}i\" \"%{User-Agent}i\" %D" ｭcombined

レスポンスタイムに5秒以上要しているレスポンスが一定数以上あると，ソーシャルゲームのプラットフォーム側から強制的にメンテナンス状態に移行される恐れがあります。この状況を避けるために1秒以上レスポンスに時間を要しているものは調査対象に分類します。

MySQLでは処理に時間がかかったクエリを記録することができ，そのクエリをスロークエリログに記録することができます。スロークエリの記録しきい値はMySQL 5.1以降であれば，動的に変更することができます。通常は0.5秒程度をしきい値に設定していますが，より詳細に調査したい場合は次のようにしきい値をゼロ秒に設定し，一時的にすべてのクエリ状況を記録することも行います。

mysql>set global long_query_time=0;

すべてのクエリを記録すると負荷が大きいため，確認後は必ず元のしきい値に戻しておくことが重要です。

見つかった問題点は開発側にフィードバックし修正を行います。残念ながらイベント開始後に発覚した問題点には，改善に時間を要するものもあります。その場合は，ゲームの一部機能停止や，影響が大きい場合は緊急メンテナンスを行い，イベントの一時休止を行うこともあります。