SlideShare a Scribd company logo

エンターテイメント業界におけるAWS活用事例

•
•
Amazon Web Services Japan
Amazon Web Services Japan
1 of 28
Downloaded 168 times
エンターテイメント業界における AWS活用事例 アマゾン データ サービス ジャパン株式会社 2012.07.25 1
Entertainment & AWS SNS Social Games Facebookアプリ Top50の内 70%がAWS上で稼働 Video Streaming 2
なぜAWSが選ばれるのか？ エンターテイメント系システムの性質 ?  トラフィック量の測定が難しい  日次、週次でのピーク変動  イベント等の突発的なアクセスへの対応  業界そのものの変化の速さ 3
なぜAWSが選ばれるのか？ スケールアップ/ダウンが容易 状況を見ながらリソースの配分が可能 セルフサービスなインフラ 必要な時に、必要なだけリソース追加が可能 実際の使用分のみ支払 効率的なランニングコスト運用が可能 初期投資が不要 スモールスタート、撤退リスクが容易に取れる 4
Elastic capacity 従来の Capacity Planning Capacity Time 必要なリソース 5
Elastic capacity オンとオフ 急成長 予測できないピーク 予測可能なピーク 6
Elastic capacity 余剰キャパシティ オンとオフ 急成長 予測できないピーク 予測可能なピーク 7 機会損失
Elastic capacity 柔軟性のあるクラウドキャパシティ オンとオフ 急成長 予測できないピーク 予測可能なピーク 8
事例紹介 9
AWSを活用し、1,000万ユーザ/日を処理 するソーシャルゲーム基盤を構築 課題: 急成長による既存インフラ環境のキャ パシティ不足 ソリューション: AWSのスケールを活用し、ピーク時の アクセスの対応を容易に処理するとと もに、ピーク時間帯以外のランニング コストを削減 Amazon EC2, Amazon RDS, Amazon S3を利用. ビジネス効果: 日次で1,000万人を処理できる基盤を 実現 開発速度と、市場への製品投入速度の 10 向上
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
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
Netflixはほぼ100%のオンラインビデオサービスをAWS 上で稼働中し、ダウンタイムが限りなくゼロに実現 AWSの利用: ほぼ100%のオンラインビデオサービスを AWSで稼働 EC2、S3、SQS、EMRを組み合わせて構築 ビジネス効果: アプリケーションのダウンタイムが限りな くゼロ近づけることを実現 AWSを活用し、2010年にオンラインサービ スが37倍の成長、2011年1月には月間200 億リクエスト以上のスケールに対応 13
Netflix事例：可用性 • マルチアベイラビリティゾーン採用およびアプリケーションレイヤ ーでのSPOF削減によるダウンタイムを限りなく0に実現 • 日々可用性のチェックと改善を取組 Chaos Monkey • ランダムに商用インスタンスを停止させるツール • 定期的にツールを実行することで、サービス影響なく、システムが自動的 にリカバリするかを確認し、システムの改善ポイントを探す Latency Monkey • Frontシステムの応答を意図的に遅延させ、サービスへの影響確認を行う Conformity Monkey • ベストプラクティスに当てはまらないインスタンスを検知し、停止する Doctor Monkey • 不安定(CPU利用率など)なインスタンスを検知し、システムから切り離す Janitor Monkey • 利用されていないインスタンスを検知し、停止する Security Monkey • AWSのセキュリティグループや各種設定等で規定外の設定がなされている インスタンスを検知し、停止する 10-18 Monkey • 他リージョンや、他言語のサービス状況を確認 システム群 システム群 Chaos Gorilla マルチアベイラビリティゾーン • アベイラビリティゾーン全体を停止させるツール 14
Netflix事例：エンコーディング • AmazonS3をセンターストレージとして、様々なフォーマットにコ ンテンツを変換 • エンコーダーはオンデマンドで必要なだけ調達 中間ファイル 50以上の CDNに アップロード エンコード フォーマット プッシュ にエンコード 映画スタジオ CDN配信 15
サービス開始から9ヶ月でユニークユーザが1,800万人と 急成長するPinterestをAWSのインフラが支える AWSの利用: ほぼ100%のサービスをAWSで稼働 EC2、S3を組み合わせて構築 ビジネス効果: 急成長するサービスのインフラを少数のイ ンフラメンバーで運用 ピークに合わせたリソース配分により、ラ ンニングコストを大幅に削減 16
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
Pinterest事例：コスト効率化 Webサーバのインスタンス利用状況 Auto Scale採用によるランニングコスト 用途に合わせた価格モデル採用によるコスト削減 Auto Scale採用によるインスタンス数の効率化 18
全公開ウェブサイトをAWSで稼働させ ることで、サーバコストを50%削減 AWSの利用: 全公開ウェブサイトをAWSに移行 Amazon EC2, Amazon S3, Amazon RDS, and Amazon CloudFrontを利用 ビジネス効果: クラウドの採用により、サーバイン フラと運用コストが50％削減 新ゲームリリース後等、想定できな いスパイクアクセスに対応が可能と なった 19
セガ事例：コンテンツ配信基盤 • AmazonS3とCloudFrontを利用した簡易コンテンツ配信インフラ オンプレの コンテンツ配信サーバ ビデオファイルを AmazonS3に格納 グローバルに存在する エッジサーバから配信 CDN (Contents Distribution Network) London Amazon CloudFrontを 利用したグローバル配信 Paris 20 NY
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
AWSを活用し、3,000万アクティブ ユーザ/日を処理 AWSの利用: Zyngaは、FarmvilleやRestraunt City などの有名ゲームをAWSで稼働 Amazon EC2 and Amazon S3を利用 ビジネス効果: Farmvilleは日次で3,000万アク ティブユーザを処理できるまでス ケール CafeWorldはサービス開始の2週 間で、1,000万ユーザまで処理で きるようリソースをスケール 22
レファレンス アーキテクチャ 23
AWS レファレンスアーキテクチャ オンラインゲーム 24
AWS レファレンスアーキテクチャ メディア配信 25
AWS レファレンスアーキテクチャ ウェブホスティング 26
AWS アーキテクチャセンター http://aws.amazon.com/jp/architecture/ 27
28

More Related Content

エンターテイメント業界におけるAWS活用事例

  • 1. エンターテイメント業界における AWS活用事例 アマゾン データ サービス ジャパン株式会社 2012.07.25 1
  • 2. Entertainment & AWS SNS Social Games Facebookアプリ Top50の内 70%がAWS上で稼働 Video Streaming 2
  • 3. なぜAWSが選ばれるのか？ エンターテイメント系システムの性質 ?  トラフィック量の測定が難しい  日次、週次でのピーク変動  イベント等の突発的なアクセスへの対応  業界そのものの変化の速さ 3
  • 4. なぜAWSが選ばれるのか？ スケールアップ/ダウンが容易 状況を見ながらリソースの配分が可能 セルフサービスなインフラ 必要な時に、必要なだけリソース追加が可能 実際の使用分のみ支払 効率的なランニングコスト運用が可能 初期投資が不要 スモールスタート、撤退リスクが容易に取れる 4
  • 5. Elastic capacity 従来の Capacity Planning Capacity Time 必要なリソース 5
  • 6. Elastic capacity オンとオフ 急成長 予測できないピーク 予測可能なピーク 6
  • 7. Elastic capacity 余剰キャパシティ オンとオフ 急成長 予測できないピーク 予測可能なピーク 7 機会損失
  • 8. Elastic capacity 柔軟性のあるクラウドキャパシティ オンとオフ 急成長 予測できないピーク 予測可能なピーク 8
  • 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
  • 13. Netflixはほぼ100%のオンラインビデオサービスをAWS 上で稼働中し、ダウンタイムが限りなくゼロに実現 AWSの利用: ほぼ100%のオンラインビデオサービスを AWSで稼働 EC2、S3、SQS、EMRを組み合わせて構築 ビジネス効果: アプリケーションのダウンタイムが限りな くゼロ近づけることを実現 AWSを活用し、2010年にオンラインサービ スが37倍の成長、2011年1月には月間200 億リクエスト以上のスケールに対応 13
  • 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
  • 16. サービス開始から9ヶ月でユニークユーザが1,800万人と 急成長するPinterestをAWSのインフラが支える AWSの利用: ほぼ100%のサービスをAWSで稼働 EC2、S3を組み合わせて構築 ビジネス効果: 急成長するサービスのインフラを少数のイ ンフラメンバーで運用 ピークに合わせたリソース配分により、ラ ンニングコストを大幅に削減 16
  • 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
  • 23. レファレンス アーキテクチャ 23
  • 24. AWS レファレンスアーキテクチャ オンラインゲーム 24
  • 26. AWS レファレンスアーキテクチャ ウェブホスティング 26
  • 27. AWS アーキテクチャセンター http://aws.amazon.com/jp/architecture/ 27
  • 28. 28