大ヒットゲーム「ドラゴンコレクション」を支えるインフラ
スタジオITセンター長
正延光弘 氏
11月25日、「mobidec 2011」においてコナミデジタルエンタテインメントのスタジオITセンター長である正延光弘氏によるセッション「大ヒットSNSゲーム『ドラゴンコレクション』を支えるコナミのクラウド技術の活用」が行われました。
ドラゴンコレクションは、GREEで提供されている携帯電話向けのカードゲームタイプのRPG。プレイヤーは、エリアごとにある複数のクエストをクリアしていき、モンスターカードや「秘宝」を手に入れ、さらに「ドラゴンカード」を集めていきます。また、ほかのプレイヤーとバトルすることでも秘宝を入手できるというSNS要素も取り入れられていました。2010年9月のサービス開始後、順調にプレイヤー数を伸ばし、現在では登録人数が500万人を超えています。
サービス開始当初は社内でサーバを構築し、フロントエンドに6台のサーバ、バックエンドに3台のデータベースサーバ、そしてロードバランサという構成で、コストパフォーマンスを重視していたといいます。それがサービスが好調になってくると、「構築スピード」「スケーラビリティ」「システムの信頼性」が重視されるようになりました。さらにPVが増えてくると自前のサーバとネットワークでは追いつかなくなり、同時に大規模ネットワークに対するノウハウの不足、エンジニアの不足が課題になってきました。オンラインゲームでは快適なアクセスが最重要となるのです。そこで同社はクラウド（IaaS）の活用に踏み切ります。
複数のクラウドサービスを比較した結果、IIJの「IIJ GIO」を採用しました。正延氏はその理由として、「コストパフォーマンス」「安定したネットワーク」「仮想・物理のハイブリッドによるディスクI/Oの解決」「両社間での運用体制構築」を挙げています。しかし、それでも急増していくアクセスに対し、さまざまなチューニングを行ったといいます。具体的には、データベースの水平垂直分割、RDBMSとキャッシュサーバのハイブリッド化、オープンソースコードのチューニング、徹底した負荷試験とサーバの需要予測を行ったのです。それでもアクセス対策には苦労が続き、最終的には「IIJ GIO」内に専用ネットワークを構築するに至りました。これにより、ドラゴンコレクションに最適化されたシステムの構築が可能になるとともに、アクセス対策の問題も解決できたといいます。最終的にクラウド利用をやめた形ですが、チューニングの苦労はノウハウとして蓄積できたと正延氏はいいます。
今後は、スマートフォンへの対応を強化していくとともに、HTML5への対応、認証とセキュリティの強化、ワールドワイド展開に向けてのコンテンツ、ファシリティ、パートナーシップの強化を行っていくとしました。パートナーシップでは、ゲームにおける企画や運営、デザイン、データ分析、サーバ、プログラムといった要素をコナミ1社で行うのではなく、それぞれの要素に強みを持つ会社と連携することで1社ではできないことを実現していくというビジョンを打ち出しています。つまり、サービスの提供はコナミが行い、パートナー各社が協力できる環境を準備します。これにより、それぞれのパートナーにはゲーム全体の経験が不要になり、強い部分だけに注力していけるわけです。こうして正延氏のセッションは終了しました。
セッション終了後、正延氏に大規模ゲーム運営のノウハウについてお話をうかがうことができました。正延氏はポイントとして、オープンソースコードのチューニング、データベースのチューニング、そして運用面を挙げました。それぞれについて、さらに詳しく掘り下げてみます。
大規模ゲーム運営のポイント：オープンソースコードのチューニング
オープンソースコードのチューニングについては、GREEやmobageでゲームが大ヒットすると通信レスポンスがシビアになるため、特に対策が必要になります。そのポイントは「5秒ルール」への対応（2種類）と、「原因不明のエラー画面」への対応です。
1：SYN再送を短く固定
SNSプラットフォームでは、5秒以内に応答を返さなければならないというルールがあり、5秒を超えてしまうとサービスが止められてしまいます。アクセスの増加によって、ドラゴンコレクションのネットワーク内でパケットロスが発生しました。SYN再送が繰り返される際に、1回目の再送で3秒使ってしまい、プラットフォームの5秒ルールに抵触したのです。ドラゴンコレクションのアクセス規模では、一瞬にして1000エラーをカウントしてしまい、プラットフォーム側でシステム障害と判定され、メンテナンスステータスにされてしまいます。この問題に対し、コナミでは2つの処理を行いました。一つは、SYN再送を1秒に固定するようOSカーネルの設定を変更しました。
2：スクリプトの実行時間を制限
もう一つは、5秒以上かかりそうな応答をキャンセルする仕組みを組み込みました。例えばPHPを使うアプリケーションの場合、set_time_limit()関数を使えばスクリプトの実行時間を制限できます。ただし、この関数はWindowsとLinuxで挙動が異なるので注意が必要です。Linux上で動作するPHPでは、「PHPのプロセスが処理に費やした時間だけ」が計測の対象になり、サーバとの接続待ち、応答待ちの時間などは計測されず、タイムアウトしません。タイムアウトの実装にsetitimer()関数が使われていて、第1引数に指定できる3種類のタイマーのうちITIMER_PROFを使っているためです。
引数にITIMER_REALを指定すれば計測の挙動を変更できますが、PHPは100％非同期シグナルセーフとはいえないため、変更にはリスクも伴います。ですが、そのリスクを承知した上でソースコードに「POSIXタイマーとPOSIXリアルタイムシグナルを使う」ように手を入れ、さらに「時間指定の単位を1秒未満の精度にする」「タイムアウト時のHTTP応答を変更可能にする」といった動作の変更・追加も行いました。
3：TIME_WAITでセッションリサイクルを調整
また、ゲームプレー中にコンテンツ側では出力をしていない謎のエラー画面が出るという事象については、ピーク時間帯においてプラットフォームとコナミ間の通信で1,000セッション/秒を超えてセッションリサイクルが間に合わない状況が発生することを突き止めました。単純にリサイクルが間に合わないだけではなく、プラットフォーム側のTIME_WAITがLinuxデフォルト60秒より短い設定になっていると推測され、Linuxデフォルト60秒のコナミ側がセッションを回収するより前に新しい接続が送信されてきて、ぶつかってしまうことが原因と判断しました。そこで、TIME_WAITを60秒から5秒にOSカーネルの設定を変更、ぶつかる頻度を軽減させたのです。
続いて、データベースのチューニングポイントです。
大規模ゲーム運営のポイント：データベースのチューニング
データベースのチューニングについて、正延氏は次の7つのポイントを挙げました。
1：net_slave_timeoutは短くする
スレーブサーバでは、しばしばレプリケーションが行われなくなっていることがあります。これは何らかの原因でマスターとスレーブ間のコネクションが失われたためですが、MySQLはこのことを認識しません。しかも、レプリケーション通信が行われない場合のコネクション再接続時間が、標準で3,600秒と非常に長く実質的ではありません。net_slave_timeoutの時間を短くすることで、レプリケーションが止まってもすぐに再開できるようになります。
2：max_binlog_sizeは小さくする
max_binlog_sizeはバイナリログがローテーションされるサイズのしきい値を指定しますが、標準で1GBが設定されています。しかし、これではI/O負荷が高くなり、処理の滞留が発生することがあります。この値を200～300MB程度に減らすことで1回あたりのログ削除負荷を軽減し、処理滞留を防止できます。
3：innodb_log_file_sizeは最大に
MySQL5.1＋InnoDB Plugin、あるいはMySQL5.5を使う前提では、innodb_log_file_sizeとinnodb_log_files_in_groupでInnoDBログのファイルサイズが常に最大の約4GBになっています。コナミでは、この値を標準でinnodb_log_file_size = 2047MB、innodb_log_files_in_group = 2とギリギリまで拡大しています。実際のところ、シャットダウン時のクラッシュリカバリ時間には、あまり影響しません。
4：MySQLの通信は圧縮する
MySQLサーバとの通信はプロトコルがほぼテキスト形式であるため、zlibによる圧縮が有効です。非圧縮時に比べ40％程度まで帯域を節約できます。同様に、マスターとスレーブの両方でslave_compressed_protocolを有効にすることで、レプリケーション通信も圧縮可能です。CPU負荷の上昇は影響を与えるレベルではないため、帯域が従量課金制の場合や、通信が安定しづらいクラウドサービスで非常に有効です（PHPでPDO+mysqlndの組み合わせで接続している場合、圧縮機能が実装されていません）。
5. パーティションは有効に
MySQL5.1系からパーティショニング機能が使えるようになりました。このパーティショニング機能はテーブルをIDや日次ごとなどに分割する機能ですが、この機能はバトルログなどが溜まりがちなソーシャルゲームでは非常に有効で、古いログを削除するために大量のDELETEを行う必要がありません。ただし、バグの少ない最新版を使うようにします。
6：my-innodb-heavy-4G.cnfは使わない
ソースディレクトリのsupport-filesディレクトリ内のmy.cnfテンプレートにあるものですが、OLTP系のサーバにはまったく不適です。そもそもMySQLには今となってはあまりよい設定テンプレートがついていないのですが、ベースにするのであればmy-huge.cnfがおすすめです。
7：slow_query_log_file, log-errorは必ず指定する
この2つの設定はそれぞれスロークエリログのファイル名、エラーログのファイル名を指定します。指定しないとログ名にホスト名が入ってしまうため、ログのローテーションやログ監視が煩雑になります。システムを使うにつれて響いてくるポイントです。
最後に、監視とインフラ運用のポイントを紹介します。
大規模ゲーム運営のポイント：監視とインフラ運用
監視では、コンテンツに影響を与えないことが前提となります。また、規模が大きいため監視の追加で手作業を減らすことがポイントです。コナミでは、アラート通知は「Nagios」、統計情報は「Cacti」を利用し、商用の監視システムや用途不明なエージェントは利用しません。また、OS標準の仕組み（SNMP）を利用します。安易に監視スクリプトなどを作るとシステムに影響が出るので注意が必要です。アクセスログは1日で1GBに達することもあるので、すべてのログを読み込むものはまったく適しません。差分でログ内容を精査します。
また、インフラ運用については、以下の3つをポイントとして挙げました。
1：コンテンツとしっかり歩調を合わせること
コンテンツのイベントの計画や更新等のスケジュールを把握し、しっかりと追随していくこと。また、エラーログやslow query、dead_lockなどの情報はコンテンツチームと共有し、問題が大きくなる前に改良改善のサイクルを確立します。下請け、言われっぱなしのインフラは絶対にダメです。
2：監視で収集可能な情報は全部取ること
これにより、インフラでボトルネックになっているポイントやサービス規模の拡大に伴う増強のタイミングを知るための一次情報となります。仮想サーバを中心に構築している場合は、各サーバのDisk I/Oがサーバ増強の判断基準になりました。また、レプリケーション遅延やslow queryをグラフ化することも対処の時間が早くなり有効でした。
3：インフラ設定、構築、運用の効率化を常に考えること
サービス規模、コンテンツ数など、SNSの世界はヒットコンテンツが生まれると、あっという間に物凄いスピードで走り出します。サーバ構築の効率化など、新規コンテンツが来る前から時間があるときに準備を進めておくことが大事です。人を増やすことが容易でないケースも多いため、効率化によって人手に頼らず業務を回せるようにしておきます。
大規模ゲーム運営のポイント：パブリッククラウドを上手に使いこなす
最後に、パブリッククラウドの選び方や使い方のコツをうかがいました。正延氏は5つのポイントを挙げています。
1：クラウド業者はポイントを絞って選定する
- クラウドならではのフレキシブルな料金体系を持っている（SNSのサービス期間が短命なこともあるため、1か月単位でしか料金を出せないようなクラウド事業者の利用は避ける）。
- クラウドならではの機能やオプションが豊富であること。サーバスペックのアップダウン、サーバイメージのクローニングは必須。また保険として、物理サーバを利用できるオプションは絶対にあった方がいい。
- サーバの納期が早いこと。SNSはスピード感が非常に大切。サービスの投入や増強、縮小などにタイムラグが発生するようなクラウド事業者は使えない。
2：クラウドで便利な機能は最大限活用する
サーバスペックのアップダウン、サーバイメージのクローン、上流回線の増減など、コンテンツの規模に合わせてより短時間で、より低コストで実現することが求められます。
3：サーバ費用は上手に圧縮する
開発時点は、低スペックなサーバでスタートします。負荷テスト時などは本番相当のサーバへスペックアップを実施し、本番開始直前までは低スペックに落とす。そして本番直前にスペックをアップする。サーバ台数の見直しも、こまめに行います。
4：パブリッククラウドを使う上でのリスク管理をしっかりする
セキュリティの確保は重要な要素。クラウド事業者のメンテナンス情報をこまめにチェックし、在庫切れなどの情報は営業経由で聞き出します。
5：パブリッククラウド間の引越しも検討する
サービス規模が大きくなったり、現在のクラウド事業者のメニューだけではサービスを提供できなくなった際には、引越しの決断も必要。例えば、仮想サーバから物理サーバに引っ越せば、大幅なスペックアップを図れます。ただし、データベースサーバのデータ移行は、かなり困難。インターネットをまたいだMySQLレプリケーションが非常にスムーズでよいです。
まとめ
ソーシャルゲーム開発・運用にまつわるノウハウをいくつかご紹介してきましたが、このように大規模Webサービスの最前線を支えるエンジニアを、コナミデジタルエンタテインメントでは積極的に募集しています（2011年12月現在）。Webアプリ開発、運用、ネットワーク管理と幅広いエンジニアを求めていますので、意欲のある方は採用ページから奮ってご応募ください。
