本日、ベルサール汐留で開催された『アマゾンウェブサービス クラウドアドバンテージセミナー』に参加してきました。主な目的は、昨今のソーシャル&ウェブサービスにおいて、AWSがどういう位置付けでどの程度使われているのか、を聴くためです。また先日リリースされた東京リージョンの評判も聞いてみたいと思っていました。
クラウドがもたらす新潮流 -「黒船」をビジネスに生かせ -
- AWSの発展の歴史を紹介していました。数年前にデータセンターが所有していたリソースの量が、今では1日に追加するリソースの量だということで、非常にハイペースで拡大している様子が伺えました。
- よいクラウドベンダーの条件。「継続の歴史があること」「大規模なシステムを運用している実績があること」「顧客の声を聞き、ハイペースで新機能の導入やイノベーションを行っていること」「薄利多売のビジネスモデルとして提供していること」。
- 時期的にDRの話題が多かったです。
- 今年の流行語大賞?「夏までに!」（DRを実現したい）という相談が多い。
- 従来のデータセンターでは間に合わないが、AWSなら実現できる。
- オンデマンドで数千台のサーバーを用意することもできる。
- 物理的に離れた拠点（世界に5箇所のリージョン）を選んで配置できる。
- 同一リージョン内でも独立した拠点（AZ）を選んで配置できる。
- 構築後、待機系はAMIを作ってインスタンスを停止すれば、EC2の費用は発生しない。
日本のソーシャルアプリケーションにおけるAWSの使いどころ
gumiにおけるソーシャルアプリのKPI
| DAU | 課金率 | ARPU |
| 新規登録数 | 継続率 | |
| PF導線 | 招待 | フィード | |
ソーシャルアプリの昔と今
- 流入数が少なく、その大部分をプラットフォームからの導線に頼る状況である。
- 競合するソーシャルアプリが非常に増えたことが原因である。
- 新着アプリから落ちたら、ほぼ流入がなくなる。
- 新着アプリに載る最初の一週間でユーザーを獲れなければ、負けが決まる。
- 最初の一週間でユーザーを獲るために、完成度を高めてリリースする必要がある。
|
昔 |
今 |
| 流入 |
10万人/日 |
5千人/日 |
| 結果が出るまでの時間 |
1ヶ月 |
1週間 |
| リリース時の完成度 |
70%でリリース |
なるべく100%でリリース |
| インフラ |
落ちなければヒット |
落ちなくて当たり前 |
サーバー構成
- memcachedは大容量メモリを積んだ1台に集約することも考えたが、負荷分散と冗長性を考え、m1.smallの複数台構成にしている。
- Tokyo Tyrantは最近ちょっと悪さをしている。
- インフラエンジニア1名で1000台近くのサーバーの面倒を見ている。
- AMIには基本的な構成だけを組み込み、用途に応じた個々の設定はPuppetを使って自動化している。
- 現在、複数のAZへの分散は行っていない。
- 当初は耐障害性を考慮して複数のAZに分散していた。
- 運用しているうちに、あるAZではサーバー負荷が跳ね上がる一方、別のAZではサーバー負荷がスカスカということがあるとわかってきたため、ひとつのAZにまとめるようにした。
RDS
- 使い倒している。RDSに置いているデータの大きさは世界有数と言われている。
- チューニングやバックアップを考慮しなくても良いため、インフラエンジニアの負荷が大幅に軽減される。
- CPU性能は2ECU〜26ECU、ディスク容量は5GB〜1TBの間で容易にスケールアップできる。
- 専用サーバーで構築すると、数年でハードが陳腐化する。当初は高性能を求めて専用サーバーで構築した筈が、数年後には専用サーバーのために乗り換えることができず、低性能で我慢しなければならないというジレンマに陥る。
- 1日1回のバックアップ（メンテナンスウィンドウ）時やスケールアップの実行時、短時間*1だが、I/Oフリーズが発生する。Multi-AZを導入することでこれを回避できるが、コストも2倍かかる。
- Multi-AZにより、物理的に独立した拠点でのホットスタンバイ、障害発生時にスレーブからマスタへの自動昇格による無停止運用、といった夢の機能を実現できる。これらを自力で実現しようとすると、膨大なお金と時間と手間が必要になる。
- 頓智ドット株式会社 CTO 近藤純司氏
- 同社 エンジニア 内原章氏
AWS 東京リージョン上でのソーシャルアプリの構築について
