More Related Content
Similar to エンターテイメント業界におけるAWS活用事例
Similar to エンターテイメント業界におけるAWS活用事例 (20)
More from Amazon Web Services Japan
More from Amazon Web Services Japan (20)
エンターテイメント業界におけるAWS活用事例
- 3. なぜAWSが選ばれるのか？
エンターテイメント系システムの性質
?
トラフィック量の測定が難しい
日次、週次でのピーク変動
イベント等の突発的なアクセスへの対応
業界そのものの変化の速さ
3
- 4. なぜAWSが選ばれるのか？
スケールアップ/ダウンが容易
状況を見ながらリソースの配分が可能
セルフサービスなインフラ
必要な時に、必要なだけリソース追加が可能
実際の使用分のみ支払
効率的なランニングコスト運用が可能
初期投資が不要
スモールスタート、撤退リスクが容易に取れる
4
- 10. AWSを活用し、1,000万ユーザ/日を処理
するソーシャルゲーム基盤を構築
課題:
急成長による既存インフラ環境のキャ
パシティ不足
ソリューション:
AWSのスケールを活用し、ピーク時の
アクセスの対応を容易に処理するとと
もに、ピーク時間帯以外のランニング
コストを削減
Amazon EC2, Amazon RDS,
Amazon S3を利用.
ビジネス効果:
日次で1,000万人を処理できる基盤を
実現
開発速度と、市場への製品投入速度の
10
向上
- 11. gumi事例：AWS運用モデル
• ゲームのライフサイクルにあわせて、サーバー台数、サーバースペ
ックを調整
開発時 申請時 公開時
ロードバランサー ロードバランサー
APサーバ
APサーバ
APサーバ c1.xlarge
1台にまとめて
開発者毎に準備
Cacheサーバ KVSサーバ
DBサーバ
最少構成で準備
Cacheサーバ DBサーバ
DBサーバ
m1.large (マスター)
(スレーブ)
KVSサーバ m1.large
m1.large
APサーバ群を増強し、DBをマルチAZ構成に変更
11
- 12. gumi事例：ピーク時のさばき方
• 突発的な対応が必要なときは、EC2、RDSの台数増加や、スペック
を上げて、時間をかせぐ
ロードバランサー
APサーバ c1.xlarge → 60台
m1.large m2.4xlarge
メモリ 7.5GB メモリ 68GB
CPU 4ECU CPU 26ECU
Cacheサーバ DBサーバ DBサーバ
m1.large → 4台 (マスター) (マスター)
KVSサーバ m1.large m2.4large
m1.large → 8台
12
- 14. Netflix事例：可用性
• マルチアベイラビリティゾーン採用およびアプリケーションレイヤ
ーでのSPOF削減によるダウンタイムを限りなく0に実現
• 日々可用性のチェックと改善を取組
Chaos Monkey
• ランダムに商用インスタンスを停止させるツール
• 定期的にツールを実行することで、サービス影響なく、システムが自動的
にリカバリするかを確認し、システムの改善ポイントを探す
Latency Monkey
• Frontシステムの応答を意図的に遅延させ、サービスへの影響確認を行う
Conformity Monkey
• ベストプラクティスに当てはまらないインスタンスを検知し、停止する
Doctor Monkey
• 不安定(CPU利用率など)なインスタンスを検知し、システムから切り離す
Janitor Monkey
• 利用されていないインスタンスを検知し、停止する
Security Monkey
• AWSのセキュリティグループや各種設定等で規定外の設定がなされている
インスタンスを検知し、停止する
10-18 Monkey
• 他リージョンや、他言語のサービス状況を確認
システム群 システム群 Chaos Gorilla
マルチアベイラビリティゾーン • アベイラビリティゾーン全体を停止させるツール
14
- 15. Netflix事例：エンコーディング
• AmazonS3をセンターストレージとして、様々なフォーマットにコ
ンテンツを変換
• エンコーダーはオンデマンドで必要なだけ調達
中間ファイル 50以上の CDNに
アップロード エンコード フォーマット プッシュ
にエンコード
映画スタジオ CDN配信
15
- 17. Pinterest事例：スケールする基盤
Web Application HighCPU EC2 Instance 150台
Servers • ELBのAPIを利用して、サーバリ
ソースの追加や障害時の切り離し
を自動化
HighCPU EC2 Instance 35台 HighMemory EC2 Instance 90台
• ビジネスロジック部分をSOA化し、 • DBへのアクセスを軽減させるため、
サービス拡張の柔軟性を確保 RedisとMemcacheを採用
Internal
Cache Servers
Web Services
AmazonS3 File Storage
• 80億オブジェクトで410TBの
データを格納
Sharded
Database
File Storage
MySQL Server on EC2 140台
• マスター70台/スレーブ70台で、簡単にシャーディン
グによるスケールができるよう、テーブル設計に工夫
17
- 18. Pinterest事例：コスト効率化
Webサーバのインスタンス利用状況 Auto Scale採用によるランニングコスト
用途に合わせた価格モデル採用によるコスト削減
Auto Scale採用によるインスタンス数の効率化
18
- 19. 全公開ウェブサイトをAWSで稼働させ
ることで、サーバコストを50%削減
AWSの利用:
全公開ウェブサイトをAWSに移行
Amazon EC2, Amazon S3, Amazon
RDS, and Amazon CloudFrontを利用
ビジネス効果:
クラウドの採用により、サーバイン
フラと運用コストが50％削減
新ゲームリリース後等、想定できな
いスパイクアクセスに対応が可能と
なった
19
- 20. セガ事例：コンテンツ配信基盤
• AmazonS3とCloudFrontを利用した簡易コンテンツ配信インフラ
オンプレの
コンテンツ配信サーバ
ビデオファイルを
AmazonS3に格納
グローバルに存在する
エッジサーバから配信
CDN
(Contents Distribution Network)
London
Amazon CloudFrontを
利用したグローバル配信
Paris
20
NY
- 21. 3日間で40から5,000サーバへ
ピーク時にEC2が5,000
インスタンスにスケール
アップロードした写真、動画、音楽をもとに、
ビデオクリップをオンラインで作成できるサービス
Number of EC2 Instances
Facebookで
アプリを公開
40インスタンス以下で
サービスを開始
4/12/2008 4/13/2008 4/14/2008 4/15/2008 4/16/2008 4/17/2008 4/18/2008 4/19/2008 4/20/2008
21
- 22. AWSを活用し、3,000万アクティブ
ユーザ/日を処理
AWSの利用:
Zyngaは、FarmvilleやRestraunt City
などの有名ゲームをAWSで稼働
Amazon EC2 and Amazon S3を利用
ビジネス効果:
Farmvilleは日次で3,000万アク
ティブユーザを処理できるまでス
ケール
CafeWorldはサービス開始の2週
間で、1,000万ユーザまで処理で
きるようリソースをスケール
22
