最大人気のソーシャル・ゲーム、FarmVilleにおけるスケールアウト

作者 Abel Avram , 翻訳者 渡嘉敷 満理子 投稿日 2010年3月26日

セクション

設計/アーキテクチャ

トピック

パフォーマンス&スケーラビリティ ,

Architecture

タグ

ソーシャルネットワーキング ,

Facebook ,

Caching

原文(投稿日：2010/03/20)へのリンク

月間アクティブ・ユーザ数8375万人のFarmVilleは、Facebookで最も人気のあるゲームであると同時に、Webベースのインターネット・ゲームの中でも最も人気のあるゲームの一つだ。スケールアウトを実現するため、アプリケーションはクラウド内に配置され、キャッシュを大々的に使用している。また、ピーク時には一部の機能を停止できるような機能を備え、パフォーマンスの監視や管理も可能だ。

このゲームを制作したZynga社の開発者、Luke Rajlich氏によると、FarmVilleは、2009年6月のサービス開始以降、4日で100万ユーザ、60日後には1000万ユーザに達したという。月間のアクティブ・プレーヤが8000万を超える中、FarmVilleは、全Facebookユーザの20%、世界人口の1%を超えるユーザへのサービス提供に努めている。この規模、さらにはこのような短期間でスケールアウトを行うには、ハードウェアおよびソフトウェアに対し、多少なりともソリューションが必要となる。

InfoQはLuke Rajlich氏にインタビューを行い、アーキテクチャの詳細を解明した。第一に、このアプリケーションは、仮想化されたLinuxサーバのクラウド環境で稼働している。そのため、処理能力を追加する際に、リクエストと受入れが極めて容易に行える。アプリケーションはベーシックなLAMP(PはPHPを表す)スタックで動作し、キャッシュを大々的に使用している。

基本的にはオブジェクト指向に準じており、カスタマイズされたDB/キャッシュインターフェースのMVCアプリケーションになっています。また、ワークロードに対応するため、キャッシング、特にmemcacheに強く依存しています。さらに、分散共有データベースも使用しています。

通信量の急増に対処するにあたり、アプリケーションは短時間での容量追加に大きく依存している。

アーキテクチャ面では、アプリケーションのワークロードは、どのレイヤ(ロードバランサ、Webサーバ、memcache、データベース)においても分割できるため、迅速な容量の追加が可能です。さらに、任意のレイヤに容量を追加する上で、非常に明確で定型化された手順も持ち合わせています。そのため、容量追加を行うための管理が容易で、直ちに実行できます。さらに、仮想環境で稼働しているため、ハードウェアを直接プロビジョニングせずに容量を追加できます。これにより、容量追加の決定から必要なハードウェアを実際に利用できるようにするまでの時間を大幅に短縮できます。また、puppetなどの構成管理ツールも取り入れており、ハードウェアの追加にかかるオーバヘッドを削減しています。残されている課題の難しい部分として、パフォーマンスの観点から、まずアプリケーションのどの部分に障害が生じるかを認識し検出することがあります。この課題を解消するため、前述のサービス劣化への対応に時間をかけてきました。また、アプリケーションのパフォーマンス監視への取組みにも相当な時間を費やしています。

このゲームには多くのコンポーネントが使用されていることから、パフォーマンスにボトルネックが生じた場合、「プラットフォームで使用する重要度の低い機能を効率良く停止」し、アプリケーションへの要求を軽減している。

[ゲームそのもの以外に]友達の紹介やギフトのリクエストなど、多くのコンポーネントがあります。それらの要素をゲームから切り離すことができるため、ゲームの基本部分はこれらのコンポーネントのパフォーマンスによる影響を受けません。弊社のゲームは、本質的にユーザが特定のアクションを行うために特定の時間にゲームに戻ってくるような、タイミングベースのゲームであるため、この点は極めて重要です。このような特定のアクションは、ダウンタイムが生じた場合、ユーザ・エクスペリエンスに大きく影響するため、ユーザにそのような事態が起こらないようにする必要があります。

アプリケーションにおける読込みと書込みの比率は、3:1と書き込みの割合が高いことから、キャッシングを大々的に使用することで対処している。Rajlich氏は、Todd Hoffとのインタビューについて明らかにした。

ユーザの状態の多くは、緻密で複雑なリレーションシップを含むデータで構成されています。たとえば、農場のオブジェクトは他のオブジェクトと重なることはできません。このため、あるユーザが自分の農場に家を配置すると、そのユーザの農場の該当スペースに他のオブジェクトが置かれていないかバックエンドでチェックする必要があります。GoogleやFacebookなど、大体のメジャーサイトでは読込み量が著しくなるのとは異なり、FarmVilleでは、書込みによるワークロードが非常に多く、データの読込みと書込みの割合は3:1です。これは、書込みの割合が著しく高いことを示しています。FarmVilleのバックエンドで行われるリクエストの大半は、プレー中のユーザの状態を何らかの形で更新するものです。この処理をスケーラブルにするために、アプリケーションのやり取りが主にキャッシュ・コンポーネントと行われるように取り組んできました。

FarmVilleとFacebookプラットフォーム間の通信量は、ピーク時でおよそ3ギガビット/秒になる。したがって、クライアント・アプリケーションはプラットフォームに対するコールをある程度停止し、通信リンクの妨げにならないようにする必要がある。

FarmVilleとFacebookプラットフォーム間の通信量は膨大です。FarmVilleとFacebook間で行き交う通信量は、ピーク時にはおよそ3ギガビット/秒、さらにキャッシング・クラスタとの通信量として1.5ギガビット/秒が加わります。また、パフォーマンスの変動に備えて、アプリケーションにはプラットフォームへのコールバックを動的に停止する機能が用意されています。プラットフォームへのコールバックをより段階的に停止するよう調整可能なダイアルを設けています。また、プラットフォームへのすべてのコールバックについて、アプリケーションそのもののロードを妨げることがないようにするために取り組んできました。ここでの考え方は、「ロード以外の処理に失敗した場合でも、プレーヤは少なくともゲームのプレーを維持できる」とするものです。

パフォーマンスの監視および管理については、「アラートにはnagios、監視にはmunin、構成管理にはpuppetを使用しています。主に内部の統計システムを利用して、アプリケーションが使用するサービス(Facebook、DB、Memcacheなど)のパフォーマンスを追跡しています。さらに、パフォーマンスの劣化が確認された場合は、リクエストのIOイベントをサンプルベースでプロファイルします。」とのことだ。

補足事項として、Inside Social Gamesのアナリスト、Justin Smith氏によると、FarmVilleを提供するZynga社は、昨年4億9000万ドルの収益をあげており、今年は8億3500万ドルを見込んでいるという

• 次へ >