株式会社gumiは2007年に設立された会社で、主にソーシャルアプリケーションの分野で多くのサービスを展開しており、約1,000万人のユーザに利用されています。
現在サービス中のソーシャルゲームにて、EC2, ELB, RDS, S3, SQSを使っています。 サーバ構成図は下記のとおりとなります。
データセンターにラックを借り、1Uサーバを使い、Webサーバ1台、DBサーバ1台という構成でサービスを提供していました。 現在は静的画像の配信以外のサービスをAWS上で稼動させています。画像についてはもともと借用しているデータセンター(日本)に設置したサーバから配信 しています。 アメリカ東海岸からの配信だと、体感的に画像の表示が遅かったので、EC2での配信は断念し、 Cloud Frontへのリプレイスも検討しましたが、(すでに設置済みのサーバを利用したため)コストの面で既存のサーバから配信する方を選択しました。
mixiに提供したソーシャルアプリのトラフィックがものすごく、既存のサーバ台数ではさばききれないが、 サーバを購入し設置している時間も場所もないといった状況に遭遇したためです。 AWSならばトラフィックが増大した際にすぐにサーバを増強できること、また考えたくないですが、人気がなくなり、 トラフィックが減少した際にすぐにサーバを減らすことができることが決め手となりました。 RDSを採用した理由は、すぐに使用することができ、バックアップ等の運用にリソースを避く必要がなくなるためです。 コマンドひとつですぐにインスタンスを起動でき、バックアップを自動で行ってくれるRDSはリソースの少ない弊社にとって、 もうひとりのインフラエンジニアの役割をはたしてくれたため、プログラムの開発等のメインの作業にリソースを使うことができました 。
AWS上に構築したソーシャルゲームが2500万PV/日程度のアクセスをさばいています。 ユーザー数は現在ものびており、それに伴うアクセス増に対してサーバを増やすことで対応できています。 また前述のとおり、RDSを採用したことにより、データベースの構築、メンテナンスを行う時間を節約でき、 開発に時間を投資することができたため、1ヶ月という短期間でソーシャルゲームを開発、リリースすることができました。
AWS を利用することで、問題の解決方法を探す際に、物理的なサーバ台数の制限を考えなくてすむようになります。 例えばDBの負荷が高くなってきたらmemcachedやRedisのサーバインスタンスを立ちあげて、 トラフィックを逃がすという方法を気軽に行えますし、それがうまくいかなかった場合も、 そのインスタンスを破棄するだけで、それ以上のコストを発生させずに、なかったことにできます。 社内に低レベルのインフラに詳しい人間がいない場合、それをすべてAWS にまかせることができます。
テストや検証が容易にできるのが気にいっています。 DBの負荷対策として、key-valueストアの導入を検討した際、 いくつかの候補を実際にEC2上で実際に試し、すばやく検証することができました。 また、様々な操作をコマンドラインから行えるツールが揃っていることも魅力的です。
今後リリース予定のソーシャルアプリについてもAWS を使っていく予定です。
さらに詳しくは、https://gu3.co.jp/