KLab株式会社

お問い合わせはこちら

DSAS Hosting for Social

導入事例:株式会社ケイブ様

「モバゲータウンでの会員数が100万人を超えました。KLabのコンサルティングにより、アプリケーションを高負荷対応させることができました」

(写真左から)ケイブ 淵之上絢也氏 浅見隼一氏 浜村剛氏 黒澤幸生氏

大ヒットを実現したゲーム会社、株式会社ケイブ モバイルコンテンツ部 浅見隼一氏、黒澤幸生氏、淵之上絢也氏、情報システム室 浜村剛氏に、サーバーインフラを選定した際の基準と、DSAS Hosting for Socialへの評価についてくわしく聞きました。
※「モバゲータウン」は2011年3月「Mobage」にサービス名を変更いたしましたが、本取材は2010年3月に行ったため、旧サービス名での記載となっております。ご了承ください。

「モバゲータウンでの会員数が100万人を超えました。KLabのコンサルティングにより、アプリケーションを交付か対応させることができました」ケイブ 淵之上絢也氏 浅見隼一氏 浜村剛氏 黒澤幸生氏
Contents
株式会社ケイブのロゴ、および提供アプリ「ミニ四駆チャンピオンシップ」「しろつく」のイメージ画像

株式会社ケイブについて

モバゲータウンに参入、
会員数100万人を突破。

株式会社ケイブは、ゲームや物販を主力事業とするエンターテイメント会社です。社員数は166名、年商は33.7億円です(※)。
モバイルコンテンツ事業部では、いまオープンプラットフォーム向けのモバイルオンラインゲームに注力しています。先日、1月27日には、オープン化されたモバゲータウンに、「ミニ四駆チャンピオンシップ」と「しろつく」を投入しました。おかげさまで会員数100万人突破です!
当社は、DSAS Hosting for Social(以下 DSAS)を、この二つのゲームのサーバーインフラとして使っています。

いずれも2009年のデータ

DSAS Hosting for Socialの活用状況

KLabに期待したのは、「インフラのホスティング、運用、死活監視、拡張」、「高負荷対応アプリケーションのコンサルティング」などです。課金体系はレベニューシェア型(※1)、ケイブ側のアプリケーション構成はいわゆる、LAMP仕様(※2)です。
今回、ピーク時の最大PV(※3)は私たちには未経験のPVでしたが、最初から相当規模のインフラが用意されていたので、問題なく捌けました。
発注決定は11月下旬、その後12月上旬に開発環境が整い、12月末に本番環境が整いました。DSASは、今回だけでなく、今後もケイブのモバイルオンラインゲームのインフラとして使い続けていくつもりです。

※1
売り上げの一定比率をインフラ使用料金として課金。月々のミニマム定額課金あり
※2
OSにLinux、WebサーバーにApache、データベースにMySQL、言語としてPerl、PHP、Python等を使う仕様のこと
※3
DSAS Hosting for Socailでは秒間2,000PVを超える規模のアクセスを安定して捌いている実績あり

DSASを知ったきっかけ

DSASのことはどこでご存じいただけましたか。

浜村剛氏

これまでずっと、自社ハウジングサーバーを使っていました。i-mode時代のミニ四駆も自社サーバーに載せて運用しました。
でも、去年の9月のmixiアプリのオープン化の時に、大量のトラフィックに耐えきれず、落ちたり遅くなったりするゲームが続出したと噂を聞いたんですね。自分の携帯でも、ゲームの反応が止まって、メンテナンス画面に移行してしまう様を実際に見ました。モバゲータウンもトラフィック多いんだろうなあ、これはちゃんとしたインフラを用意しておかないとヤバいよなあと考え直し、それで、新たなインフラを探していたんですね。
そんな折り、モバゲータウンのカンファレンスで、KLabがレベニューシェア型のサービスを発表している様子を見たのですね。これはいいと思いました。

モバイルオンラインゲームは水物です。最初から大規模なインフラを用意するのは、外した時のリスクが高すぎて危険。初期投資リスクは低い方がいいですから。これはこれで一つの候補として、比較検討の候補に入れておこうと考えました。

どのインフラ方式がゲームに向いているのか検討

比較検討は、どのように進めていったのですか。

黒澤幸生氏

DSASみたいなレベニューシェア型を使うか、ホスティングを使うか、最近、クラウドなども流行っているし、それも検討しようということで、それら三方式について、見積もりを取って社内で比較しました。

それぞれの方式を、「機会損失の最小化」、「耐高負荷性」、「初期投資リスク」、「実稼働後の費用リスク」、「ゲームづくりへの専念」などの基準に照らし て比較しました。その結果、レベニューシェア型が、水物であるモバイルオンラインゲームのインフラに一番向いているように思えました。

さらに各社のサービスを比較検討した結果、KLabさんがいちばん良いだろうということになり、DSASの採用が決定した次第です。

最後にKLabが選ばれた本当の理由

DSASが選ばれたのは、レベニューシェア型だったからですか?

淵之上絢也氏

いえ、実は理由はそれじゃないんです。というのも、他社様からも、初期投資リスクを軽減できるご提案をいただいていたんですね。だから、価格体系という意味では、KLabも他のホスティング会社も土俵は同じでした。

じゃあ、どうしてKLabを選んだかというと、KLabには、サービスメニューの中に「高負荷対応アプリケーションの作り方に関するコンサルティング」などコンサルティングが含まれていたからです。ケイブは、ソーシャルは未経験です。一方、KLabは、自社ですでにいくつかのソーシャルを経験しているじゃないですか。それに携帯電話のシステムの世界では、昔から活動していて、一目置くべき技術もあるようです。そういう会社に、アプリケーションの組み方を教えてもらえるのなら、これはありがたいなと。

実際、コンサルティングの内容は、非常に具体的でした。例えば「ミニ四駆チャンピオンシップ」と「しろつく」は、データベース負荷という点では、けっこう正反対のゲームなんですね。「ミニ四駆チャンピオンシップ」の方は、対戦ゲームだから、ページ遷移やDB処理回数は多いけど、一回あたりの処理量は少ない。一方、一種の育成ゲームである「しろつく」はその逆で、DB処理回数は少ないけれど、処理量は多い。真逆です。この二つのゲームに対し、それぞれのゲーム特性にあったコンサルティングがあったので、やっぱりさすがだなと思いました。

おかげで、「ミニ四駆チャンピオンシップ」と「しろつく」も会員数100万人を突破。とりあえずは「ヒットしたゲーム」が作れました。サービスインの時は、皆でせーので開始ボタンを押しました。しばらくして会員数が増えてきたけど、「どうせ今だけでしょ。一過性のことでしょ」と思えて、なかなかヒットの確信が持てなかった。でも当日夜半を過ぎても勢いが衰えないので、これはまずは大丈夫だろうと、ひとまず安心でした。でも、当日はぼくら開発者よりも企画部の方がそわそわしていましたね。「今、会員、何人になった?」と何度も聞きに来るので、プログラマはけむたがっていました(笑)。

サービス開始後、会員数が増えていく中でも、インフラのことは1ミリも気にせずにすみました。「安心して背中を任せられる」という感覚でした。途中、トラブルもなく100万人を超えた今もDSASはビクともしません。まずは選択に間違いなし、でした。

つきあってみて分かったKLab

つきあってみて分かったKLabの良さなどあればお聞かせください。

技術者と直接に話せるところ、開発者としてはそれがいちばん有り難いことでした。後は、レベニューシェア型の場合、必然的に一種の運命共同体になります。それって、ケイブにとってもプレッシャーなんですが、同じプレッシャーはKLabさんも感じていたようで(笑)、オープン当日は、いつでもホットラインで連絡可能な「厳戒態勢」で臨んでくれました。それ以外では、サービスが始まってからも、バックボーンやインフラ体制が常に進化していて、これは心強いなと感じました。

今後の期待

DSAS Hosting for SocialおよびKLabへの今後の期待をお聞かせください。

庄司容崇氏

今回、会員数100万人を超えが達成でき、レベニューシェアの運命共同体として互いに良い結果が収められて、まずはよかったと思っています。ケイブでは、今後も、もっと面白いゲームを作ります。KLabさんはインフラの方でご支援ください。これからもよろしくお願いします。

ケイブ様、本日はお忙しい中、貴重なお話をありがとうございました。

KLabはどのような技術支援を行ったのか~
KLab技術者よりコメント

読者の皆様への参考情報として、今回のコンサルティング(ケイブ様とのディスカッション)の内容をキーワードでお伝えしたいと思います(要所は伏せますが、ご了承ください)

  • まずゲームの企画書を見せていただき、その上で、想定会員数(強読み)、アクティブユーザー割合、最多アクセス時間帯での同時接続数を予想しました。さらにゲーム内で最多ページ遷移処理箇所、その箇所での参照/更新クエリ数を算出、その後、計算式を通じて1秒当たり参照/更新クエリ数を試算しました。
  • 今回のクエリ数試算結果は、過去KLabが経験した最大クエリ数を下回っていました。その経験を根拠とし、ハードウェアを必要十分かつ最小の構成で提案しました(最小構成の提案は「過去の経験」がないと怖くてできません)
  • まずミニ四駆チャンピオンシップでは、 [レース → 結果表示]の部分が、高負荷処理のキモであると予測されました。先ほど述べた計算式により、マスターDBの「必要十分かつ最小の台数」を算出し、その台数で開始しました。
  • 一方、「しろつく」は、時間制でターンが回るゲームシステムであり、連続して書き込みが起こることは基本なく、参照が多くなります。また書き込みは、ユーザーのゲーム操作に関係なく定期的にバッチ処理として発生します。この定期バッチをどう捌くかがポイントでした。KLabとしては、参照系処理と、書込処理のにおいて、それぞれ合理的と思われるDB構成を提案しました。
  • モバゲーAPIと通信遅延などが、サイトパフォーマンス上のボトルネックとなることは、当初から、ある程度予測できていました。そこでモバゲーAPIの呼び出し回数を減らすために、memcachedの使用を勧めました。
  • DSAS Hosting for Socialでは、サーバーリソース・モニタリングツールを標準装備しています。同ツールは、サイトの負荷状態を確認するためのオープンソースのツールで、高負荷サイトの観測用にカスタマイズした形で搭載しています。KLabでは、このツールを使ってサイトの現状分析と定点観測をすることをお客様にお勧めしています。
  • サービス開始後、サーバーリソース・モニタリングツールのグラフを見て、「トラブルの芽」を発見することができました。同ツールはグラフが多く、漫然とそれを見ていても、グラフの状態とその時の状態との相関関係を見出すことは困難であり、それができるようになるには、ある程度の経験(場数)が必要です。今回は、ケイブの皆様にグラフの見方を細かくアドバイスさせていただき、サイトに問題がある場合の予兆を自身で検知できるようになるための支援をいたしました。
  • KLabのインフラ担当者とケイブ様のWEBアプリ開発者のコミュニケーションは、IRC(Internet Relay Chat)を使ってリアルタイムに行いました。一般的なアプリケーション開発では、メールでコミュニケーションを取ることが多いのですが、モバイルオンラインゲームアプリの開発はスピードが信条です。お客様の質問や要求に素早く答えるために導入したIRCですが、ケイブ様をはじめとしてご好評をいただいています。

以上、プロジェクトにおけるコンサルティング(ディスカッション)の内容をかいつまんで記しました。

※『ミニ四駆』は株式会社タミヤの登録商標です。
※掲載の会社名、サービス名は各社の商標、商標登録です。