スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ～メディア露出時のピーク対策編～ 先生：高山 博史・今井 雄太
•
145 j'aime•31,155 vues
ーーーーーーーーーーーーーーーーーーーーーーー schoo WEB-campusは「WEBに誕生した、学校の新しいカタチ」。 ＷＥＢ生放送の授業を無料で配信しています。 ▼こちらから授業に参加すると、先生への質問や、ユーザーとのチャット、資料の拡大表示等が可能です。 https://schoo.jp/class/356/room ーーーーーーーーーーーーーーーーーーーーーーー
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ～メディア露出時のピーク対策編～ 先生：高山 博史・今井 雄太
Similaire à スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ～メディア露出時のピーク対策編～ 先生：高山 博史・今井 雄太 (20)
Plus de schoowebcampus
Plus de schoowebcampus (20)
Dernier
Dernier (12)
スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ～メディア露出時のピーク対策編～ 先生：高山 博史・今井 雄太
- 1. スタートアップならおさえておきたい AWS(Amazon Web Services)⼊入⾨門 〜～メディア露露出時のピーク対策編〜～ 2014年年1⽉月10⽇日 アマゾンデータサービスジャパン株式会社 髙⼭山博史 今井雄太
- 2. ⾃自⼰己紹介 ! 名前： ・髙⼭山 博史 / テクニカルインキュベーター ! 役割： ・スタートアップ向け技術⽀支援やコスト削減提案担当 ・以前はSIerや通信キャリアで”SE”をやってました 「AWSでのWBS砲対策まとめ」http://www.hiroshix.net/archives/1645
- 3. ⾃自⼰己紹介 ! 名前： ・今井 雄太 / ソリューションアーキテクト ! 役割： ・スタートアップ、アドテク、メディア向け技術⽀支援 ・以前はSIerやSNS提供会社でエンジニアをやってました
- 4. 本⽇日の⽬目次 ! AWSとは？ ! メディア露露出時のピーク対策 ! 質疑応答 4
- 5. AWSとは？ ! はじめに ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか… 5
- 6. ! はじめに ! はじめに ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか…
- 8. ?
- 10. たとえば…
- 25. ! 具体的にAWSの場合は…
- 27. どれくらいの規模なのか？ ストレージサービス(Amazon S3)で お預かりしているファイルの数はどれくらい？ ! 1：29億個 ! 2：140億個 ! 3：2兆個
- 30. ! スタートアップに選ばれるAWS ! はじめに ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか…
- 32. もう少し具体的に… ! 初期費⽤用不不要で使った分だけの 従量量課⾦金金(⻑⾧長期契約不不要) ! スケールアップ/ダウンが容易易 ! 汎⽤用的な技術で構成 ! 便便利利なマネージドサービスが豊富 ! 世界中のデータセンタ群を利利⽤用出来る 32
- 33. スタートアップに最適！ ! 初期費⽤用不不要で使った分だけの スモールスタートが出来る！ 従量量課⾦金金(⻑⾧長期契約不不要) 急なサービス成⻑⾧長にも対応出来る！ ! スケールアップ/ダウンが容易易 効率率率的な利利⽤用でコスト削減も可能！ ! 汎⽤用的な技術で構成 既存の技術知識識で、すぐに始められる ! 便便利利なマネージドサービスが豊富 少ない⼈人数で効率率率的に運⽤用出来る！ グローバル展開も容易易 ! 世界中のデータセンタ群を利利⽤用出来る 33
- 34. サービススタート当初は利利⽤用企業数がどのようなスピードでどの 程度度まで増えるか分からず、「Start Small, Scale Fast, Think Big」を実現できるインフラ環境が必須でした。 34 トークノート株式会社 CTO 杉浦 正明 様
- 35. 例例えば、⼤大きなイベントへの EventRegist の採⽤用が決まった際に も、すばやくスケールアップ・スケールアウトが可能なため、 「使いたい時に使いたいだけコンピューティングリソースを確保 し、使った分だけのコストで済む」というシステム構成を組むこ とができました。 35 イベントレジスト株式会社 CTO 池⽥田 ⼤大輔様
- 36. それまでAWSの利利⽤用実績はなかったものの、参照できる情報も多 数ありましたので、スムーズに実運⽤用に移ることができました。 サーバーサイドに関してはLinux, Ruby (Padrino), MySQL等 を使って開発しているため、AWSがもつアセットとの相性の良良さ もありました。 36 株式会社スマートエデュケーション CTO ⾕谷川 裕之様
- 37. Amazon S3およびAmazon Gracierを利利⽤用することで、ディスク 容量量を管理理する必要がなくなった点や、Multi-‐‑‒AZ対応のAmazon RDSを導⼊入したことにより、MySQLの管理理コストをほぼゼロに できた点等、運⽤用⼯工数削減に関する効果も⼤大きいと感じています。 株式会社クラウドワークス 取締役 野村 真⼀一 様 37
- 38. 世界中のデータセンタ群 (リージョン) GovCloud US West (US ITAR Region) US West US East (Northern California) (Oregon) (Northern Virginia) South America (Sao Paulo) EU (Ireland) Asia Pacific (Singapore) Asia Pacific (Tokyo) AWS Regions AWS Edge Locations どのリージョンでも同じ使い勝⼿手 同じやり⽅方で⽇日本から利利⽤用可能 Asia Pacific (Sydney)
- 39. リージョン＝データセンタ”群”？ ! Tokyoリージョンは2つのデータセンタ(AZ) ! 2つのAZを利利⽤用した冗⻑⾧長構成も簡単 US East (Northern Virginia) Availability Zone E Availability Zone A Availability Zone D Availability Zone B Availability Zone B Asia Pacific (Sydney) Availability Zone A 39 Availability Zone A Availability Zone B Asia Pacific (Tokyo) Availability Zone B Availability Zone A Availability Zone B US West (Oregon) Availability Zone A Availability Zone B Availability Zone C Availability Zone C US West(Northern California) Availability Zone A EU (Ireland) Asia Pacific (Singapore) Availability Zone A Availability Zone B AWS GovCloud (US) Availability Zone A Availability Zone B South America (Sao Paulo) Availability Zone A Availability Zone B ＊AZ=Availability Zoneの略略 距離離の離離れたデータセンタ
- 41. ! 使ってみよう！…のお悩み ! はじめに… ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか…
- 42. ! お悩みポイント1 豊富なサービス！ 1.サービスが多すぎて… ! はじめに ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか…
- 43. AWSの豊富なサービス お客様のアプリケーション ライブラリ & SDKs Java, PHP, .NET, Python, Ruby, node.js IDEプラグイン Eclipse Visual Studio メッセージ Amazon SNS Amazon SQS Amazon SES コンテンツ配信 Amazon CloudFront コンピュータ処理理 Amazon EC2 Auto Scale Web管理理画⾯面 Management Console 認証 AWS IAM デプロイと⾃自動化 モニタリング Amazon CloudWatch 検索索エンジン Amazon Cloud Search 分散処理理 AWS Elastic Beanstalk AWS Cloud Formation AWS OpsWorks ワークフロー管理理 Amazon SWF トランスコード Elastic MapReduce ストレージ Amazon S3 データベース Amazon EBS Amazon Glacier AWS StorageGateway Amazon RDS Amazon DynamoDB Amazon ElastiCache Amazon Redshift ネットワーク & ルーティング AZ Application Service Amazon Elastic Transcoder Amazon VPC / ELB / Amazon Route 53 /AWS Direct Connect Region Development & Administration AWS グローバルインフラ Geographical Regions, Availability Zones, Points of Presence Infrastructure Service
- 44. ログインするとこんな感じ…
- 45. ! サービス多すぎ…orz
- 46. とりあえず、おさえておきたいサービス4つ お客様のアプリケーション ライブラリ & SDKs Java, PHP, .NET, Python, Ruby, node.js IDEプラグイン Eclipse Visual Studio Web管理理画⾯面 Management Console メッセージ 認証 AWS IAM 検索索エンジン Amazon Cloud Search Amazon SNS Amazon SQS Amazon SES コンテンツ配信 デプロイと⾃自動化 モニタリング Amazon CloudWatch 分散処理理 AWS Elastic Beanstalk AWS Cloud Formation AWS OpsWorks ワークフロー管理理 Amazon SWF トランスコード Elastic MapReduce コンピュータ処理理 データベース Amazon S3 Amazon EC2 Amazon EBS Amazon Glacier AWS StorageGateway Auto Scale Amazon RDS Amazon DynamoDB Amazon ElastiCache Amazon Redshift ネットワーク & ルーティング ELB / Amazon Route 53 /AWS Direct Connect Amazon VPC / Region AZ Application Service Amazon Elastic Transcoder ストレージ Amazon CloudFront Development & Administration AWS グローバルインフラ Geographical Regions, Availability Zones, Points of Presence Infrastructure Service
- 48. とりあえず、おさえておきたいサービス4つ Amazon S3 ・容量量無制限のオンラインストレージ 1 ・⾃自動的に複数DCに保存し、 ⾼高い耐久性を実現 ELB(Elastic Load Balancing) ・従量量課⾦金金で使えるロードバランサー 1 ・GUIで各種操作可能 ・AZをまたいだロードバランシングも可能
- 49. いずれも既存の知識識で使えます！ Amazon EC2 1ｃ ・必要なときに必要なだけ使えるLinux/Windowsサーバ ・プラスアルファで便便利利な機能 Amazon S3 1 ・業界標準APIで操作するストレージ ・プラスアルファで便便利利な機能や⾼高い耐久性 Amazon RDS 1 ・⼀一般的なMySQLまたはPostgreSQL ・プラスアルファで便便利利な機能 ELB(Elastic Load Balancing) 1 ・GUIで操作出来るL4のロードバランサ ・プラスアルファで便便利利な機能
- 50. ! お悩みポイント2 使った分だけの従量量課⾦金金 2.料料⾦金金がわからない… ! はじめに ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか…
- 52. 主要サービスの価格 ①サーバ データベース ②ストレージ ③データ転送 Amazon EC2 約3円〜～ / 1時間 Amazon RDS 約4円〜～ / 1時間 Amazon S3 Amazon EBS （ダウンロードのみ課⾦金金対象） ※サーバスペックによって異異なります 1GB1ヶ⽉月保存で 約10円 約20円 / 1GB
- 54. サーバ課⾦金金で知っておきたいこと ! 起動時間1時間単位の課⾦金金 単価はスペックにより異異なる ! 例例えば1台を1ヶ⽉月利利⽤用し続けた場合は… 単価×24(時間)×31(⽇日) がサーバ利利⽤用料料となる ! 継続的に起動するサーバは⻑⾧長期利利⽤用オプ ション(リザーブドインスタンス)で最⼤大 60%程度度コスト削減可能
- 56. ! お悩みポイント3 わかりやすい資料料あります！ 3.どこから⼿手をつけていいのか… ! はじめに ! スタートアップに選ばれるAWS ! 使ってみよう！のお悩み 1.サービスが多すぎて… 2.料料⾦金金がわからない… 3.どこから⼿手をつけていいのか…
- 60. メディア露露出時のピーク対策 ! AWSでWebアプリケーション つくるなら？ • AWSでのオススメ構成 • アンチパターンも紹介 ! 突発的なピーク対策 どうすればいいの？ • ピークはチャンス • チャンスを逃さないための対策 60
- 61. ! AWSでWebアプリケーションつくるなら？ AWSでのオススメ構成 ! AWSでWebアプリケーションつくるなら？ • • AWSでのオススメ構成 アンチパターンも紹介 ! 突発的なピーク対策どうすればいいの？ • • ピークはチャンス チャンスを逃さないための対策
- 66. よく⾒見見かけるWebアプリの構成 LB or Proxy HA Proxy, LVS, nginx Apache, nginx Web Web + unicorn, passenger, fpm, thin + Ruby, PHP, Python DB MySQL, PostgreSQL
- 68. AWSでの基本的な構成 HA Proxy, LVS, nginx →ELBで置き換え ELB Web Web EC2 EC2 RDS Availability Zone RDS Availability Zone AWS Cloud アプリはいままでと同じ ようにApacheやnginx などをEC2に⼊入れて利利⽤用 MySQL, PostgreSQLは RDSを活⽤用する
- 69. AWSでの基本的な構成 HA Proxy, LVS, nginx →ELBで置き換え ELB Web Web EC2 EC2 RDS Availability Zone RDS Availability Zone AWS Cloud アプリはいままでと同じ 更更に、複数の ようにApacheやnginx Availability Zoneに などをEC2に⼊入れて利利⽤用 システムを分散させる MySQL, PostgreSQLは RDSを活⽤用する
- 70. とりあえず、おさえておきたいサービス お客様のアプリケーション ライブラリ & SDKs Java, PHP, .NET, Python, Ruby, node.js IDEプラグイン Eclipse Visual Studio Web管理理画⾯面 Management Console メッセージ 認証 AWS IAM 検索索エンジン Amazon Cloud Search Amazon SNS Amazon SQS Amazon SES コンテンツ配信 デプロイと⾃自動化 モニタリング Amazon CloudWatch 分散処理理 AWS Elastic Beanstalk AWS Cloud Formation AWS OpsWorks ワークフロー管理理 Amazon SWF トランスコード Elastic MapReduce コンピュータ処理理 データベース Amazon S3 Amazon EC2 Amazon EBS Amazon Glacier AWS StorageGateway Auto Scale Amazon RDS Amazon DynamoDB Amazon ElastiCache Amazon Redshift ネットワーク & ルーティング ELB / Amazon Route 53 /AWS Direct Connect Amazon VPC / Region AZ Application Service Amazon Elastic Transcoder ストレージ Amazon CloudFront Development & Administration AWS グローバルインフラ Geographical Regions, Availability Zones, Points of Presence Infrastructure Service
- 71. いずれも既存の知識識で使えます！ Amazon EC2 1ｃ ・必要なときに必要なだけ使えるLinux/Windowsサーバ ・プラスアルファで便便利利な機能 Amazon S3 1 ・業界標準APIで操作するストレージ ・プラスアルファで便便利利な機能や⾼高い耐久性 Amazon RDS 1 ・⼀一般的なMySQLまたはPostgreSQL ・プラスアルファで便便利利な機能 ELB(Elastic Load Balancing) 1 ・GUIで操作出来るL4のロードバランサ ・プラスアルファで便便利利な機能
- 74. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒ トラフィックが増えた時に EC2の台数を増やして対応するのが簡単 Web Web Web Web Web Web EC2 EC2 EC2 EC2 EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud RDS Availability Zone RDS Availability Zone AWS Cloud
- 75. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒ トラフィックが増えた時に EC2の台数を増やして対応するのが簡単 1台（前提で動いているもの）を４台に するのは⾮非常に⼿手間ですが、 Web Web Web Web Web Web ２台（複数台前提で動いているもの）を EC2 EC2 EC2 EC2 EC2 EC2 ４台にするのは簡単です！ RDS Availability Zone RDS Availability Zone AWS Cloud RDS Availability Zone RDS Availability Zone AWS Cloud
- 79. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの？-‐‑‒ Web Web Web Web EC2 EC2 EC2 EC2 RDS RDS Availability Zone Availability Zone Availability Zone Availability Zone AWS Cloud AWS Cloud DBのスペックを⼀一時的/恒久的に⾼高低させたり、 ストレージ容量量を簡単に追加できる
- 82. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの？-‐‑‒ アベイラビリティゾーンB アベイラビリティゾーンA ⾃自動バッ スナップ クアップ ショット(⾃自 データ同期 ⾃自動フェイルオーバー 動/⼿手動) Binlog ⾮非同期レプリケーション Binlog Binlog (トランザクショ (トランザクショ ンログ) ンログ) （5分間隔) （5分間隔) S3 Availability Zone A スレーブの構築と管理理も簡単 Availability Zone B （MySQLでのみ利利⽤用可能）
- 85. AWSでの基本的な構成 -‐‑‒複数ゾーンでのサービス構築-‐‑‒ ゾーンがまるごと死んでも サービスは⽌止まらない Web Web EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud それぞれのゾーンは地理理的に別の場所にあるので、 ⼤大きな災害やDC単位の障害にも強い
- 88. AWSでの基本的な構成 -‐‑‒まずはこの構成に！-‐‑‒ ベストプラクティス！ Web Web EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud ! EC2単体はもちろん、データ センターレベルの障害があっ てもサービスが⽌止まらない耐 久性 ! 必要なときにクイックにリ ソースを増減できる柔軟性 ! インフラ管理理の⼿手間は最⼩小化
- 89. ! AWSでWebアプリケーションつくるなら？ 3.どこから⼿手をつけていいのか… アンチパターンも紹介 ! AWSでWebアプリケーションつくるなら？ • • AWSでのオススメ構成 アンチパターンも紹介 ! ピーク対策どうすればいいの？ • • ピークはチャンス チャンスを逃さないための対策
- 106. ! AWSでWebアプリケーションつくるなら？ 3.どこから⼿手をつけていいのか… まとめ ! AWSでWebアプリケーションつくるなら？ • • AWSでのオススメ構成 アンチパターンも紹介 ! 突発的なピーク対策どうすればいいの？ • • ピークはチャンス チャンスを逃さないための対策
- 107. ! AWSでWebアプリケーションつくるなら？ 3.どこから⼿手をつけていいのか… まとめ ! ELB+EC2+RDSがWebア プリの基本構成 Web Web EC2 EC2 RDS Availability Zone RDS Availability Zone AWS Cloud ! ⾼高い耐久性、拡張性、メン テナンス性がキーワード ! まず最初に⼿手間をかけてベ ストプラクティスの構成に。
- 108. ! 突発的なピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… ピークはチャンス ! AWSでWebアプリケーションつくるなら？ • • AWSでのオススメ構成 アンチパターンも紹介 ! ピーク対策どうすればいいの？ • • ピークはチャンス チャンスを逃さないための対策
- 109. 突発的なピークはなぜ起こる？ ! テレビやソーシャルでバズって突発的か つ⼀一時的にユーザーが集まる ! 広告出稿の結果としてユーザーが急増す る ! イベントやキャンペーンで（ｒｙ
- 111. ピークトラフィックを扱う難しさ ! テレビなどで発⽣生する突発的なピークは 普段の50倍だったり100倍のトラフィッ クが発⽣生する！ ! これを捌けるようなリソースを予め準備 しておくのは無駄！もしくは（予算的 に）無理理！ ! なので既存のリソースで何とかしなきゃ いけない・・・
- 112. 結果として、エンジニアから⾒見見ると・・・ ! 急なメディア掲載とかやめてほしい ! 「絶対に落落ちちゃダメなキャンペーン」 とか絶対やめてほしい ! 「○○万⼈人が⼀一⻫斉にアクセスするイベン ト」とか（ｒｙ
- 113. 結果として、エンジニアから⾒見見ると・・・ ! 急なメディア掲載とかやめてほしい ! 「絶対に落落ちちゃダメなキャンペーン」 とか絶対やめてほしい これって機会損失ですよね？ ! 「○○万⼈人が⼀一⻫斉にアクセスするイベン 突発的なピークをうまく捌いてチャンスを ト」とか（ｒｙ 積極的にものにしましょう。
- 114. ! ピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… チャンスを逃さないための対策 ! AWSでWebアプリケーションつくるなら？ • • AWSでのオススメ構成 アンチパターンも紹介 ! ピーク対策どうすればいいの？ • • ピークはチャンス チャンスを逃さないための対策
- 115. 対策１ -‐‑‒EC2とRDSをスケールさせる-‐‑‒ EC2はスケールアウト（台数増やす） RDSはスケールアップ（スペック上げる） Web Web Web Web Web Web EC2 EC2 EC2 EC2 EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud Availability Zone Availability Zone AWS Cloud
- 116. 対策１ -‐‑‒EC2とRDSをスケールさせる-‐‑‒ EC2はスケールアウト（台数増やす） RDSはスケールアップ（スペック上げる） Web Web Web Web Web EC2 EC2 EC2 EC2 EC2 終わったら元に戻すのも忘れずに！ EC2 RDS Web Availability Zone RDS Availability Zone AWS Cloud Availability Zone Availability Zone AWS Cloud
- 117. 対策１ -‐‑‒EC2とRDSをスケールさせる-‐‑‒ 参考）ELBはトラフィックに 合わせて⾃自動的にスケールします Web Web Web Web Web Web EC2 EC2 EC2 EC2 EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud Availability Zone Availability Zone AWS Cloud
- 118. 対策１ -‐‑‒EC2とRDSをスケールさせる-‐‑‒ 参考）ELBはトラフィックに 合わせて⾃自動的にスケールします 注意１ ELBのスケーリングには時間が掛かりま す。予定がわかっているのであればサ Web Web Web Web Web Web ポートに連絡してプリウォーム（事前時 EC2 EC2 EC2 EC2 ケーリング）を。 EC2 EC2 ※要ビジネスサポート RDS Availability Zone RDS Availability Zone AWS Cloud Availability Zone Availability Zone AWS Cloud
- 119. 対策１ -‐‑‒EC2とRDSをスケールさせる-‐‑‒ 注意２ EC2のAuto Scalingも5〜～10分の時間 がかかります。予めピークが予測できる Web Web Web Web Web Web のであれば⼿手動でスケールさせておきま EC2 EC2 EC2 EC2 EC2 EC2 しょう。 RDS Availability Zone RDS Availability Zone AWS Cloud Availability Zone Availability Zone AWS Cloud
- 120. 対策１ -‐‑‒EC2とRDSをスケールさせる-‐‑‒ Web EC2 RDS メディア掲載前に対策、 翌⽇日などアクセスが戻ったら、 元に戻せば、最⼩小限のコストで Web Web Web Web Web サーバ落落ち/レスポンス低下による EC2 EC2 EC2 EC2 EC2 機会損失を防げる Availability Zone RDS Availability Zone AWS Cloud Availability Zone Availability Zone AWS Cloud
- 123. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 動的コンテンツ Web Web EC2 EC2 RDS RDS 画像やJSなどの 静的コンテンツ Availability Zone Availability Zone AWS Cloud Amazon S3 ! S3のWeb Site Hosting機能を使 うと、S3が静的な HTTPサーバーとし て動作する ! S3は⼤大規模なアク セスに耐えるよう に設計され、AWS 側で運⽤用されてい る
- 124. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 動的コンテンツ 画像やJSなどの 静的コンテンツ CloudFront Web Web EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud Amazon S3 ! 更更に、CDNサービ スである CloudFrontを組み 合わせるとレイテ ンシの向上も図れ る
- 125. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 画像やJSなどの 静的コンテンツ 動的コンテンツ ! 更更にCloudFrontを 組み合わせるとレ ELB+EC2は動的コンテンツの配信だけ CloudFront イテンシの向上も に役割を絞り、静的コンテンツは Web Web 図れる S3(+CloudFront)に任せてしまう！ EC2 Amazon EC2 RDS S3 Availability Zone RDS Availability Zone AWS Cloud
- 126. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 画像やJSなどの 静的コンテンツ 動的コンテンツ 更更に・・・ ! 更更にCloudFrontを トラフィック流流⼊入のランディングページ 組み合わせるとレ CloudFront を完全に静的なものにして イテンシの向上も Web Web S3(+CloudFront)でホスティングして 図れる EC2 しまえばEC2側へのトラフィックを⼤大幅 Amazon EC2 S3 に減らせます RDS Availability Zone RDS Availability Zone AWS Cloud
- 128. ! 突発的なピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… まとめ ! AWSでWebアプリケーションつくるなら？ • • AWSでのオススメ構成 アンチパターンも紹介 ! 突発的なピーク対策どうすればいいの？ • • ピークはチャンス チャンスを逃さないための対策
- 129. ! 突発的なピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… まとめ ! ⼤大前提 • システムが柔軟な拡張性を持っていることが必須な ので、ベストプラクティスに沿ったシステム構成で あること ! 対策１ • EC2とRDSは負荷を予測し、予めスケールさせておく • 終わったらもとに戻す ! 対策２ • S3（とCloudFront）を使って静的ファイルを配信する • ELBとEC2は動的コンテンツの配信だけに役割を絞っ ておく
- 130. メディア露露出時のピーク対策 今⽇日お話したこと ! AWSでWebアプリケーションつくるなら？ • AWSでのオススメ構成 • アンチパターンも紹介 ! 突発的なピーク対策どうすればいいの？ • ピークはチャンス • チャンスを逃さないための対策 130
- 131. ! 質疑応答
- 132. ! 宿題
- 134. ありがとうございました！
- 135. ! 参考資料料
- 136. AWSサポート ! ⽇日本語での技術サポートもご提供(オプション) ベーシック デベロッパー ビジネス エンタープライズ 利利⽤用可能 利利⽤用可能 利利⽤用可能 利利⽤用可能 サポートへの コンタクト EC2の 健全性エラーが発 ⽣生した場合 コンタクト フォーム 電話、チャット コンタクト フォーム 電話、チャット コンタクト フォーム 初回応答時間 不不可 12時間 （営業時間内） 1時間 １５分 -‐‑‒ 1 5 無制限 24/365対応 なし なし あり あり Trusted Advisor なし なし あり あり 専任スタッフ 特別サポート なし なし なし あり フォーラム 連絡先登録 料料⾦金金（⽉月額） 無料料 $49 AWS利利⽤用総額の $0~∼$10K: 10% $10K~∼$80K: 7% $80K~∼$250K: 5% $250K~∼: 3% （最低$100） AWS利利⽤用総額の10% （最低$15000） 〜～たとえばローンチ前後だけ「ビジネス」にすることも可能〜～
- 137. リソース監視 ! AWSのリソース監視機能 CloudWatchでもOKですが、 サードパーティーのリソース 監視SaaSを利利⽤用する⽅方法も あります ! たとえば”NewRelic”など ・15⽇日以上の履履歴参照が出来る ・メモリ使⽤用量量がわかる ・下記リンクから申し込むと無料料利利⽤用枠あり(2013/7/1現在) http://newrelic.com/aws 137
- 139. 基本的な操作⽅方法 ! AWS Basic トレーニング資料料 →オフラインでのハンズオンも 定期的にやっています http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ ! ハンズオン情報 →いろいろなハンズオンイベントも 実施中です http://aws.amazon.com/jp/event_̲schedule/ 139
- 140. 各サービスの説明 ! AWS マイスターシリーズ ・EC2&EBS編 ・RDS編 ・ELB編 ・CloudWatch/Auto Scaling編 ・Cloudfront編 ! AWS上でのWeb アプリケーションデプロイ http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ 140
- 141. コスト削減 ! AWS マイスターシリーズ ・リザーブドインスタンス& スポットインスタンス編 http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ 141
- 142. ! ご利利⽤用料料⾦金金イメージ
- 143. ご利利⽤用料料⾦金金イメージ ざっくりの⽬目安ですが… (動画や⾼高画質写真を扱わない⼀一般的なWebサービスの場合) ! ELB →25$/⽉月程度度 ELB Web App Web App EC2 EC2 DB ! RDS(Small) →100$/⽉月程度度 合計：250〜～300$/⽉月程度度 RDS AZ① AZ② AWS Cloud 143 ! EC2(Small) ×2 →130$/⽉月程度度 *データ転送量量等で価格は上下します。⽬目安としてご覧ください *2014年年1⽉月10⽇日現在、東京リージョンの価格です *リザーブドインスタンスご活⽤用で、さらにお安くなります SIMPLE MONTHLY CALCULATOR⾒見見積もり例例
- 144. さらにMicroなら… ! ELB →25$/⽉月程度度 ! EC2(Small) ×2 →60$/⽉月程度度 ELB Web App Web App EC2 EC2 合計：130〜～150$/⽉月程度度 無料料枠適⽤用で：30〜～50$/⽉月程度度 DB RDS AZ① AZ② AWS Cloud 144 ! RDS(Small) →35$/⽉月程度度 *データ転送量量等で価格は上下します。⽬目安としてご覧ください *2014年年1⽉月10⽇日現在、東京リージョンの価格です *リザーブドインスタンスご活⽤用で、さらにお安くなります SIMPLE MONTHLY CALCULATOR⾒見見積もり例例
- 145. 無料料使⽤用枠 ! アカウント作成から12か⽉月間の間は、 無料料でご利利⽤用いただける利利⽤用範囲があります ! http://aws.amazon.com/jp/free/ 145
- 146. ⻑⾧長期ご利利⽤用の割引プランもあります ! オンデマンド・インスタンス • 時間単位でのインスタンス購⼊入 • ⻑⾧長期のコミットメントなし L・M・Hの3種類 ⼀一時⾦金金と時間当たりのご利利⽤用料料⾦金金が異異なる ! リザーブド・インスタンス • 1年年間 or 3年年間での「インスタンス割引権利利」の購⼊入 • ⼤大幅割引(3~∼5割引)が適⽤用 • ⻑⾧長期間稼動が⾒見見込まれる処理理に最適 積算料料⾦金金 オンデマンド インスタンス リザーブド インスタンス ⼀一時⾦金金 期間 14 6 146