このページの本文へ

いよいよ始まる日本のIaaS-2010年版- 第6回

ソーシャルゲーム事業者は、クラウド選びにここまでチェックする

モバレボがクラウドへ引っ越した理由とは?

2010年10月07日 09時00分更新

文● 大谷イビサ/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

現在、パブリッククラウドへの導入意欲がもっとも高い事業者として、ソーシャルゲームやSNSを運用するプロバイダが挙げられる。今回は運用中の多くのサーバーをIIJ GIOに移したインターネットレボリューションに、ユーザーの立場からクラウドへの移行やサービス選定のノウハウについて聞いた。

メンテナンスコスト削減と集約化の威力

i-revoのモバイルサイト「モバレボ」

 インターネットレボリューション(以下、i-revo)は、コナミデジタルエンタテインメントとインターネットイニシアティブ(IIJ)の合弁会社で、ソーシャルゲームやSNS、アバターなどを提供するモバイルサイト「モバレボ」を展開している。自分の海賊を率いて世界中のお宝を発見する「海賊WARS」や20~30代女性をターゲットとする「ちょこっと★農園」「リアル クローズ」のほか、書くだけダイエットをサービス化した「めもるダイエット」など多彩なサービスが魅力。一見違和感のある組み合わせだが、コナミの企画力、IIJの技術力を考えれば、なかなか強力なタッグといえるだろう。

 さて、このi-revoは、ソーシャルゲームやSNS、アバターなどのサーバーをIIJのパブリッククラウドサービス「IIJ GIO」に移行している。サービス開始から3年あまりが経ち、これまで使ってきた80台くらいのサーバーがスペック的に陳腐化してきた。そのため、移行の際には集約できるところは集約しようということで、IIJ GIOのサービス開始から3カ月くらいでいくつかのサービスを移行したのだ。

 もとより、i-revoのようなプロバイダは、従来から複数サービスの展開のために数多くのサーバーを運用しなければならず、会員の増減によりトラフィックも大きく増減するという課題を持っていた。サーバーやストレージにリソースをオンデマンドで調達できるクラウドのメリットは、こうしたプロバイダにジャストミートするものだ。i-revo 取締役副社長の谷口崇氏は「技術者が少ないとやはりアウトソーシングせざるをえません。しかし、ハードウェアが陳腐化すると、やはり保守や障害対応などでメンテナンスコストがかかります。クラウドに移行すると、このリスクがかなり低減されるのです」と語る。

 IIJが親会社ということもあり、IIJ GIO選定は当然のような気もするが、実際のサービス選定はニフティやビットアイル等とコストパフォーマンスや機能を比べて選定したという。そして、IIJ GIOに仮決めし、仮想サーバーと専有サーバー、いろいろなスペックの評価機を借りたところ、ある特徴があきらかになったという。「ベンチマークを走らせるとCPUやメモリはOKなのですが、i-revoが求めるレベルに対して、ストレージやI/Oがやや弱いんです」ということ。そのため、システム全体ではI/O性能の高い専有サーバーと、コストパフォーマンスのよい仮想サーバーのハイブリッドで組んだり、メモリにコンテンツをキャッシュするようにしたりしています。ゲームやSNSは外部とAPIを介して連携するので、やはりI/Oに神経を使う必要がある。そのため、こうした適材適所でサービスを変えるのはクラウドサービス使いこなしの1つの鍵のようだ。「実際はIIJ GIOに限らず、ネットワークやストレージ面での制限により、自分が描いている構成が実現できないこともあります」(谷口氏)とのことで、こうした実環境での試用がきわめて重要である。

i-revo 取締役副社長 谷口崇氏

移行は1週間!
サーバー自体も3分の2にまで集約

 2010年の7月にシステムをクラウドに移行したが、インフラの調達は1週間程度で済んだ。「通常、これだけのハードウェアを調達しようと思うと早くても1カ月はかかります」(谷口氏)ということで、スピーディな移行というメリットも享受できた。また、サーバー自体も全体の3分の2にまで集約でき、「自前で調達する場合に比べて、やはりコストは落とせましたし、会員の増減にあわせてリソースを調整できるようになりました」(谷口氏)とのこと。さらに、IIJ GIOの場合、単に貸すだけではなく、きちんと監視されているのも評価したポイントだという。「やはり、ITリソースが見えないという不安はありましたので、監視やレポートがきちんとしているのはありがたいです」(谷口氏)というわけだ。

 クラウド移行への最大の課題であるセキュリティに関しては、やはり他のユーザーとリソースを共有している点に注意が必要だと語る。たとえば、同一LAN上にあった他のユーザーのリソースが見えたりしないか、リソースを再利用する際に前のユーザーのリソースが残っていないかといった点だ。この点、IIJ GIOは「相当細かくフィルタリングしているようですし、私たちのパケットしか見えないようになっています。あと、リソースについてもミドルウェアレベルでワイプ(消去)しており、再マウントされる際にはきちんと消去されています」(谷口氏)ということで、安心して導入に踏み切れたという。こうしたマニアックな部分はインフラを作っているエンジニアのセンスに負うところが多いため、実際に試用しないとわからない部分のようだ。導入の際には胆に銘じておきたい。

■関連サイト

カテゴリートップへ

この連載の記事
  • 角川アスキー総合研究所
  • アスキーカード