Developers Summit 2012：大ヒットソーシャルアプリ「ドラゴンコレクション」の裏側

こんにちは。くろの（福田）です。

先週、デブサミ2012の1セッションだけ聞いてきました。そのメモになります。ちょっと長め。

ほんとうは私の好きな皆さん（@kenazuma、@ykasugai、@yamaki00、@tomohn、@shin135）のセッションを聞きたかったのですが、申し込んだときは席が速攻埋まっていました。資料はブログ下部にリンクしてあります。

大ヒットソーシャルアプリ「ドラゴンコレクション」の裏側 超高トラフィックを支えるアプリ・インフラの明日から使えるテクニック

• 550万人突破!大人気ソーシャルゲーム「ドラゴンコレクション」(ドラコレ)

セッションID：16-A-2 株式会社コナミデジタルエンタテインメント ドラコレスタジオマネージャ 廣田竜平氏

廣田氏はこれまでドラムマニア、ギターフリークス、クイズマジックアカデミー等を開発してきたとの事。

■ドラゴンコレクションとは

• GREEのソーシャルゲーム
• 登録会員数は550万人
• クエスト・バトル中心のソーシャルゲームにカード収集を取り入れる
• 技術的に見るとWebサービス

■超高トラフィック

• 人気が出る＝高トラフィック
• ドラコレは超高トラフィック
• ピーク
  • 数万リクエスト/秒
  • ただし、PHPリクエストのみ

■数百台のサーバーから成るシステム

サービスを支える技術

• CentOS 5
• Apache 2
• PHP5 + APC
• MySQL
• Memcached
• LBはソフトウェアバランサ

• 基本スケールアウト（たまにスケールアップ）
• RDBMSのスケールアウト、リードレプリカ、シャーディング、ひたすら

■クラウド特有の問題

サービス当初はパブリッククラウド（IIJ GIO）を使っていた。

クラウド特有の問題

• DISK IOが不安定
• 物理ディスクを占有できるサービスが無い（無かった）
• 内部ネットワークのトラフィック限界が分からない
  • クラウド内のネットワークをパンクさせてしまっていた
• クラウドの全体メンテナンスの都合を合わせる必要がある
• パフォーマンスが悪いのではなく、パフォーマンスが不安定
• どこまでいっても自分たちでは制御できない要因がある
• 自分たちだけで調査しようと思っても限界がある（クラウド業者とのコミュニケーションが必要）

※これらは一般的なWebサイトでのクラウド利用では問題にならない問題である事に注意。

■クラウドからのシステム移行

一昨年（2010年）の12月にクラウドからのシステム移行を決断。専用システムに移行。

移行に伴うメンテナンス時間を如何に短くするか。5時間以内。

Webサーバは新しい環境に同じものをおいておけば良い。問題はDB。

• DBは数百ギガバイト
• DBは引越元と引っ越し先でレプリカをとって同期
• マスターのスレーブ/マスターを新環境のマスターにレプリケーション
• 逆の構成もとっておく（元の環境に戻すため）

実際の移行作業

• 500km離れた環境間での引越
• 結果的にはメンテナンスも短時間で終わった
• 実際の引越は去年の6月
• 検討等に半年掛けた
  • 筆者注：セッションでは言及されなかったが、震災の影響もあると思われる

■モバイルソーシャルアプリ特集の仕組み：5秒問題

★基本１：クライアント＞GREEガジェットサーバ＞KONAMIコンテンツサーバというリクエストの流れ。KONAMIコンテンツサーバーからGREEガジェットサーバーへレスポンスを5秒内に返さないと『エラー』になる。

★基本２：規定回数以上エラーが発生すると、GREEから公開停止を喰らう。この際、ゲームをDeveloper Centerから『手動』で再公開設定を行う必要がある。この再起動までの間機会損失が大量発生する。

タイムアウトが無いとGREEのガジェットサーバーのリソースが圧迫されるという問題からのルール。多くのSAPが頭を抱えている問題。

超高トラフィックになってくると、瞬間的なパフォーマンス低下も絶対に許されない！

★対応策：レスポンスが4.7秒かかりそうなときは、PHPの処理を中断して、『ページを再度開いて下さいメッセージ』を返すようにした。

スクリプト実行時間の制限にset_time_limit()を採用。

時間指定を1秒未満の精度に変更するため、mod_phpの修正を行った。

■マイクロバースト問題

一部レスポンスが極端に遅くなっている処理がった。法則が無いので困った。なぜかすべて9秒前後で処理が完了している

原因：Webサーバ＞DB接続のTCP接続で時間がかかっている

SYNパケットをLOSTしていた。その際の再送、再再送に時間がかかっていた。

• RTTが確定する前のRTOは3秒
• RTOは1度再送する度に倍々になる
• SYNパケットを2回ロストするとTCP接続に9秒かかる
• 3秒かかっていたケースも実はあったが「5秒ルール内」なので気づいていなかった

パケロスはスイッチのキューで瞬間的にパケットがあふれて『マイクロバースト』していることが原因であることが判明。

定常的なトラフィックでは十分に余裕があったため、発見に時間がかかってしまった。クラウドを利用していた頃なので、クラウド業者と相談して調査してもらった

具体的には：

• 内部側ネットワークに対するRTOを変更した
• 初期RTO3秒、再送の度に倍々＞＞＞初期RTO1秒、再送の度に倍にしない
• 初期RTOの変更だけであればカーネルの修正
• 再送の度にRTOを増やさないようにするにはソースの変更も必要

オープンソース改造、ミドルウェアパフォーマンスチューニングを行い、サービス停止になるようなことは無くなった

■いざというときの『輪番アクセス』

新しい機能を追加する際の負荷テストが難しい。

規模が小さいとスケールダウンした環境でテストして、計数をかける。しかし、大規模になるとそうはいかない。

基本的には、過去の実績、各種パラメータから総合的に判断して、既存のシステムで対応できるかシステム増強を行うかを判断している。

それでも経験に基づいて予測できないケースがある。

そのため、『輪番アクセス』の仕組みを仕込んでいる。

お客様のuseridからいくつかのグループに分けて、定期的に利用できる範囲を変えていく。

（記憶ベースで適当に書いたものです。雰囲気はこんな感じかと。。。）

サービス全体の開放率をコントロールすることが出来る。ゲーム全体へのアクセスだけで無く、特定の機能などにこの仕組みを導入するケースもある。

例えば、イベント後のプレゼント配布等に輪番アクセスの仕組みを利用する。

■おまけ

筆者のドラゴンコレクションのレベル：LV78

参考記事

• 大規模ソーシャルゲーム「ドラゴンコレクション」運営の最前線で得られたノウハウ　～チューニングと運用、18のポイント～（1/4）：CodeZine

筆者の好きなデブサミ2012プレゼンテーション集

【16-D-1】UI のこれまでの10年とこれから

[slideshare id=11624282&doc=20120216devsumiazuma-0215-120216223107-phpapp01]

【16-C-4】次期Internet Explorer、IE10とHTML5 API

[slideshare id=11601611&doc=internetexplorerie10html5api-120216014630-phpapp01]

どうなる？Windows 8時代の業務アプリ開発

[slideshare id=11656440&doc=devsumi12grapecity-slideshare-120219023843-phpapp02]

【17-A-2】 10年後も通用する開発環境の秘訣 ＜デブサミ2012＞

[slideshare id=11616727&doc=2012-02-17devsumi2012p-120216095202-phpapp01]

【17-B-4】マイクロソフトの変化を体現するAzureエバンジェリスト2名が語る今後10年を見越したオープン戦略

[slideshare id=11628372&doc=devsumi2012azureslideshare-120217023957-phpapp02]

おしまい

@Cronoloves