大規模ゲーム運営のポイント：オープンソースコードのチューニング
オープンソースコードのチューニングについては、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カーネルの設定を変更、ぶつかる頻度を軽減させたのです。
続いて、データベースのチューニングポイントです。
