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