• Save
スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ~メディア露出時のピーク対策編~ 先生:高山 博史・今井 雄太
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ~メディア露出時のピーク対策編~ 先生:高山 博史・今井 雄太

on

  • 22,635 views

ーーーーーーーーーーーーーーーーーーーーーーー ...

ーーーーーーーーーーーーーーーーーーーーーーー
schoo WEB-campusは「WEBに誕生した、学校の新しいカタチ」。
WEB生放送の授業を無料で配信しています。
▼こちらから授業に参加すると、先生への質問や、ユーザーとのチャット、資料の拡大表示等が可能です。
https://schoo.jp/class/356/room
ーーーーーーーーーーーーーーーーーーーーーーー

Statistics

Views

Total Views
22,635
Views on SlideShare
19,202
Embed Views
3,433

Actions

Likes
120
Downloads
0
Comments
1

27 Embeds 3,433

http://bikkuri.me 1865
http://whitech0c0late.hatenablog.com 751
http://schoo.jp 425
http://s.deeeki.com 147
http://asklife.info 81
https://twitter.com 80
https://cybozulive.com 28
http://stg.eventdots.jp 12
https://www.facebook.com 9
http://localhost 7
http://tqs.jp 4
https://schoo.jp 4
http://t.co 3
http://tweetedtimes.com 3
http://b.hatena.ne.jp 2
https://m.facebook.com&_=1390030099608 HTTP 1
https://m.facebook.com&_=1390019797561 HTTP 1
http://www.google.co.jp 1
http://nuevospowerpoints.blogspot.com 1
http://feedly.com 1
https://www.chatwork.com 1
https://m.facebook.com&_=1389407715614 HTTP 1
https://m.facebook.com&_=1389394352616 HTTP 1
https://m.facebook.com&_=1389394141910 HTTP 1
https://m.facebook.com&_=1389365596519 HTTP 1
https://m.facebook.com&_=1389358010080 HTTP 1
https://m.facebook.com 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

スタートアップならおさえておきたいAWS(Amazon Web Services)入門 ~メディア露出時のピーク対策編~ 先生:高山 博史・今井 雄太 Presentation Transcript

  • 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.どこから⼿手をつけていいのか…
  • 7. ?
  • 8. !  実は⽣生徒の皆さんも すでに(間接的に)ご利利⽤用かも?
  • 9. たとえば…
  • 10. !  Amazonがクラウド? ITインフラ?
  • 11. Amazonの代表的なサービス ビジネス観点の お話
  • 12. Amazonの代表的なサービス amazon.co.jp おなじみの通販サイト
  • 13. Amazonの代表的なサービス amazon  services 出品/出店サービス
  • 14. Amazonの代表的なサービス amazon  web  services ITインフラサービス
  • 15. 初期のAmazon.com amazon.com, 1995
  • 16. amazon.co.jp 2014
  • 17. 10年年以上にわたるAmazon.comの ITインフラ運⽤用ノウハウをサービスに!  2006年年  AWSサービス開始  2011年年  Tokyoリージョンサービス開始
  • 18. さて、ここで質問です 3つのサービスのビジネス的な 共通点は何でしょうか? !  1:Amazon余剰サーバの有効活⽤用 !  2:薄利利多売のビジネス !  3:法⼈人向けサービス
  • 19. 規模の拡⼤大とイノベーションのサイクル 資本 投資 より多く の 顧客獲得 値下げ 技術 投資 効率率率 改善
  • 20. !  具体的にAWSの場合は…
  • 21. 規模の拡⼤大とイノベーション 資本 投資 より多く の 顧客獲得 技術 投資 現在AWSでは、Amazon.com  が 年年商約7,000  億円($7B)企業であった際と 効率率率 値下げ 同等のサーバー数を毎⽇日追加するスピードで成⻑⾧長 改善
  • 22. どれくらいの規模なのか? ストレージサービス(Amazon  S3)で お預かりしているファイルの数はどれくらい? !  1:29億個 !  2:140億個 !  3:2兆個
  • 23. 規模の拡⼤大とイノベーション 2013年年だけでも、 資本 250を超える新サービスや新機能を追加 投資 より多く の 顧客獲得 値下げ 技術 投資 効率率率 改善
  • 24. 規模の拡⼤大とイノベーション 資本 投資 より多く の 2006年年のサービス開始から 顧客獲得 38 値下げ 技術 回の値下げを実施 投資 効率率率 改善
  • 25. !  スタートアップに選ばれるAWS !   はじめに !   スタートアップに選ばれるAWS !   使ってみよう!のお悩み   1.サービスが多すぎて…   2.料料⾦金金がわからない…   3.どこから⼿手をつけていいのか…
  • 26. なぜスタートアップに選ばれるのか? スタートアップである               が 急成⻑⾧長するなかで、 ITインフラで苦労し、解決したことを           としてサービス提供 しているから
  • 27. もう少し具体的に… !  初期費⽤用不不要で使った分だけの 従量量課⾦金金(⻑⾧長期契約不不要) !  スケールアップ/ダウンが容易易 !  汎⽤用的な技術で構成 !  便便利利なマネージドサービスが豊富 !  世界中のデータセンタ群を利利⽤用出来る 32
  • 28. スタートアップに最適! !  初期費⽤用不不要で使った分だけの スモールスタートが出来る! 従量量課⾦金金(⻑⾧長期契約不不要) 急なサービス成⻑⾧長にも対応出来る! !  スケールアップ/ダウンが容易易 効率率率的な利利⽤用でコスト削減も可能! !  汎⽤用的な技術で構成 既存の技術知識識で、すぐに始められる !  便便利利なマネージドサービスが豊富 少ない⼈人数で効率率率的に運⽤用出来る! グローバル展開も容易易 !  世界中のデータセンタ群を利利⽤用出来る 33
  • 29. サービススタート当初は利利⽤用企業数がどのようなスピードでどの 程度度まで増えるか分からず、「Start  Small,  Scale  Fast,   Think  Big」を実現できるインフラ環境が必須でした。 34 トークノート株式会社  CTO  杉浦  正明  様
  • 30. 例例えば、⼤大きなイベントへの  EventRegist  の採⽤用が決まった際に も、すばやくスケールアップ・スケールアウトが可能なため、 「使いたい時に使いたいだけコンピューティングリソースを確保 し、使った分だけのコストで済む」というシステム構成を組むこ とができました。 35 イベントレジスト株式会社  CTO  池⽥田  ⼤大輔様
  • 31. それまでAWSの利利⽤用実績はなかったものの、参照できる情報も多 数ありましたので、スムーズに実運⽤用に移ることができました。 サーバーサイドに関してはLinux,  Ruby  (Padrino),  MySQL等 を使って開発しているため、AWSがもつアセットとの相性の良良さ もありました。 36 株式会社スマートエデュケーション  CTO  ⾕谷川  裕之様
  • 32. Amazon  S3およびAmazon  Gracierを利利⽤用することで、ディスク 容量量を管理理する必要がなくなった点や、Multi-‐‑‒AZ対応のAmazon   RDSを導⼊入したことにより、MySQLの管理理コストをほぼゼロに できた点等、運⽤用⼯工数削減に関する効果も⼤大きいと感じています。 株式会社クラウドワークス  取締役  野村  真⼀一  様 37
  • 33. 世界中のデータセンタ群 (リージョン) 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)
  • 34. リージョン=データセンタ”群”? !  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の略略   距離離の離離れたデータセンタ
  • 35. !  よさそうですよね? それでは早速使ってみましょう!
  • 36. !  使ってみよう!…のお悩み !   はじめに… !   スタートアップに選ばれるAWS !   使ってみよう!のお悩み   1.サービスが多すぎて…   2.料料⾦金金がわからない…   3.どこから⼿手をつけていいのか…
  • 37. !  お悩みポイント1 豊富なサービス! 1.サービスが多すぎて… !   はじめに !   スタートアップに選ばれるAWS !   使ってみよう!のお悩み   1.サービスが多すぎて…   2.料料⾦金金がわからない…   3.どこから⼿手をつけていいのか…
  • 38. 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
  • 39. ログインするとこんな感じ…
  • 40. !  サービス多すぎ…orz
  • 41. とりあえず、おさえておきたいサービス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
  • 42. とりあえず、おさえておきたいサービス4つ Amazon  EC2 ・台数やスペックを柔軟に変更更可能な仮想 1c   サーバ(各種Linux/Windows) ・必要な時に、必要な台数を時間課⾦金金で   利利⽤用可能 Amazon  RDS ・マネージドデータベースサービス 1   (MySQL/PostgreSQLなどに対応) ・冗⻑⾧長構成、マスタ/スレーブ構成や   ⾃自動バックアップなどご利利⽤用可能
  • 43. とりあえず、おさえておきたいサービス4つ Amazon  S3 ・容量量無制限のオンラインストレージ 1 ・⾃自動的に複数DCに保存し、   ⾼高い耐久性を実現 ELB(Elastic  Load  Balancing) ・従量量課⾦金金で使えるロードバランサー   1 ・GUIで各種操作可能 ・AZをまたいだロードバランシングも可能
  • 44. いずれも既存の知識識で使えます! Amazon  EC2 1c ・必要なときに必要なだけ使えるLinux/Windowsサーバ ・プラスアルファで便便利利な機能 Amazon  S3 1 ・業界標準APIで操作するストレージ ・プラスアルファで便便利利な機能や⾼高い耐久性 Amazon  RDS 1 ・⼀一般的なMySQLまたはPostgreSQL ・プラスアルファで便便利利な機能 ELB(Elastic  Load  Balancing) 1 ・GUIで操作出来るL4のロードバランサ ・プラスアルファで便便利利な機能
  • 45. !  お悩みポイント2 使った分だけの従量量課⾦金金 2.料料⾦金金がわからない… !   はじめに !   スタートアップに選ばれるAWS !   使ってみよう!のお悩み   1.サービスが多すぎて…   2.料料⾦金金がわからない…   3.どこから⼿手をつけていいのか…
  • 46. !  個⼈人でもスタートアップでも、 エンタープライズでも同じ価格 値切切る必要なし!フェアな料料⾦金金!
  • 47. 主要サービスの価格 ①サーバ     データベース ②ストレージ ③データ転送 Amazon  EC2 約3円〜~  /  1時間 Amazon  RDS 約4円〜~  /  1時間 Amazon  S3 Amazon  EBS (ダウンロードのみ課⾦金金対象) ※サーバスペックによって異異なります 1GB1ヶ⽉月保存で 約10円 約20円  /  1GB  
  • 48. AWS利利⽤用料料の⼀一般的な内訳例例 !  ⼀一般的に「サーバ/DB」が 全体の9割程度度を占めるケースが多い AWSにはいろいろな課⾦金金箇所があるが、サーバ/DB利利⽤用料料、 データ転送料料が想定できれば、⼤大体の⾦金金額は算出できる
  • 49. サーバ課⾦金金で知っておきたいこと !  起動時間1時間単位の課⾦金金   単価はスペックにより異異なる !  例例えば1台を1ヶ⽉月利利⽤用し続けた場合は…   単価×24(時間)×31(⽇日)   がサーバ利利⽤用料料となる !  継続的に起動するサーバは⻑⾧長期利利⽤用オプ ション(リザーブドインスタンス)で最⼤大 60%程度度コスト削減可能
  • 50. データ転送課⾦金金で知っておきたいこと !  回線費⽤用100Mbpsで⽉月額○○円という ような固定料料⾦金金ではなく「実際にダウン ロードしたデータ量量1GBあたり $0.201」といったフェアな課⾦金金⽅方式 帯域 ピークを想定した帯域で固定料料⾦金金 帯域 実際のトラフィック 使った分だけの課⾦金金 実際のトラフィック 時間 時間
  • 51. !  お悩みポイント3 わかりやすい資料料あります! 3.どこから⼿手をつけていいのか… !   はじめに !   スタートアップに選ばれるAWS !   使ってみよう!のお悩み   1.サービスが多すぎて…   2.料料⾦金金がわからない…   3.どこから⼿手をつけていいのか…
  • 52. !   本資料料の最後に 操作⽅方法説明資料料へのリンクあります http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/
  • 53. !   体験ハンズオンも開催中です! http://aws.amazon.com/jp/event_̲schedule/
  • 54. 前半はここまでです。 後半は具体的な構成例例を ご紹介します
  • 55. メディア露露出時のピーク対策 !  AWSでWebアプリケーション つくるなら? •  AWSでのオススメ構成 •  アンチパターンも紹介 !  突発的なピーク対策 どうすればいいの? •  ピークはチャンス •  チャンスを逃さないための対策 60
  • 56. !  AWSでWebアプリケーションつくるなら? AWSでのオススメ構成 !   AWSでWebアプリケーションつくるなら? •  •  AWSでのオススメ構成 アンチパターンも紹介 !   突発的なピーク対策どうすればいいの? •  •  ピークはチャンス チャンスを逃さないための対策
  • 57. よく⾒見見かけるWebアプリの構成 Web + DB
  • 58. よく⾒見見かけるWebアプリの構成 Web Web + DB DB
  • 59. よく⾒見見かけるWebアプリの構成 LB Web Web + DB Web Web DB DB
  • 60. よく⾒見見かけるWebアプリの構成 LB Web ちなみにこちらの2つは やっちゃダメなパターン Web + (アンチパターン) Web Web DB DB DB
  • 61. よく⾒見見かけるWebアプリの構成 LB or Proxy  HA  Proxy,  LVS,  nginx Apache,  nginx Web Web + unicorn,  passenger,  fpm,  thin   + Ruby,  PHP,  Python DB MySQL,  PostgreSQL
  • 62. AWSでの基本的な構成 ELB Web Web EC2 EC2 RDS Availability   Zone RDS Availability   Zone AWS  Cloud
  • 63. 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を活⽤用する
  • 64. 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を活⽤用する
  • 65. とりあえず、おさえておきたいサービス お客様のアプリケーション ライブラリ  &  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
  • 66. いずれも既存の知識識で使えます! Amazon  EC2 1c ・必要なときに必要なだけ使えるLinux/Windowsサーバ ・プラスアルファで便便利利な機能 Amazon  S3 1 ・業界標準APIで操作するストレージ ・プラスアルファで便便利利な機能や⾼高い耐久性 Amazon  RDS 1 ・⼀一般的なMySQLまたはPostgreSQL ・プラスアルファで便便利利な機能 ELB(Elastic  Load  Balancing) 1 ・GUIで操作出来るL4のロードバランサ ・プラスアルファで便便利利な機能
  • 67. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒
  • 68. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒ ELB Web Web EC2 EC2 RDS Availability   Zone RDS Availability   Zone AWS  Cloud
  • 69. 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
  • 70. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒ トラフィックが増えた時に EC2の台数を増やして対応するのが簡単 1台(前提で動いているもの)を4台に するのは⾮非常に⼿手間ですが、 Web Web Web Web Web Web 2台(複数台前提で動いているもの)を EC2 EC2 EC2 EC2 EC2 EC2 4台にするのは簡単です! RDS Availability  Zone RDS Availability  Zone AWS  Cloud RDS Availability  Zone RDS Availability  Zone AWS  Cloud
  • 71. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒ EC2が1台死んでも サービスが落落ちない Web Web EC2 EC2 RDS RDS Availability  Zone Availability  Zone AWS  Cloud
  • 72. AWSでの基本的な構成 -‐‑‒EC2を複数台配置してELBで分散しておけば-‐‑‒ !  EC2の増減が簡単なのでトラフィックの 増減に対して、スピーディに、過剰投資 も機会損失もなく対応することができる !  EC2の単体障害が起きた時にもサービス が⽌止まらない
  • 73. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの?-‐‑‒
  • 74. 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のスペックを⼀一時的/恒久的に⾼高低させたり、 ストレージ容量量を簡単に追加できる
  • 75. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの?-‐‑‒ 複数のAZ間で冗⻑⾧長構成を簡単に取れる アベイラビリティゾーンB アベイラビリティゾーンA ⾃自動バッ スナップ クアップ ショット(⾃自 データ同期 ⾃自動フェイルオーバー 動/⼿手動) Binlog ⾮非同期レプリケーション Binlog Binlog (トランザクショ (トランザクショ ンログ) ンログ) (5分間隔) (5分間隔) S3 Availability  Zone  A Availability  Zone  B
  • 76. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの?-‐‑‒ バックアップの簡易易化/⾃自動化と簡単なレストア アベイラビリティゾーンB アベイラビリティゾーンA ⾃自動バッ スナップ クアップ ショット(⾃自 データ同期 ⾃自動フェイルオーバー 動/⼿手動) Binlog ⾮非同期レプリケーション Binlog Binlog (トランザクショ (トランザクショ ンログ) ンログ) (5分間隔) (5分間隔) S3 Availability  Zone  A Availability  Zone  B
  • 77. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの?-‐‑‒ アベイラビリティゾーンB アベイラビリティゾーンA ⾃自動バッ スナップ クアップ ショット(⾃自 データ同期 ⾃自動フェイルオーバー 動/⼿手動) Binlog ⾮非同期レプリケーション Binlog Binlog (トランザクショ (トランザクショ ンログ) ンログ) (5分間隔) (5分間隔) S3 Availability  Zone  A スレーブの構築と管理理も簡単 Availability  Zone   B (MySQLでのみ利利⽤用可能)
  • 78. AWSでの基本的な構成 -‐‑‒RDSを使うと何がうれしいの?-‐‑‒ !  冗⻑⾧長化やバックアップなど、DB運⽤用は 本来専任の運⽤用エンジニアが必要なほど ⼤大変な仕事。しかし、この⼤大部分を⾯面倒 ⾒見見てくれる !  スペックを上げたり、ストレージ追加し たりが簡単なので使い始めの検討に⼤大き な時間を割かなくてすむ(これはEC2に も⾔言える)
  • 79. AWSでの基本的な構成 -‐‑‒複数ゾーンでのサービス構築-‐‑‒
  • 80. AWSでの基本的な構成 -‐‑‒複数ゾーンでのサービス構築-‐‑‒ ゾーンがまるごと死んでも サービスは⽌止まらない Web Web EC2 EC2 RDS RDS Availability  Zone Availability  Zone AWS  Cloud それぞれのゾーンは地理理的に別の場所にあるので、 ⼤大きな災害やDC単位の障害にも強い
  • 81. AWSでの基本的な構成 -‐‑‒複数ゾーンでのサービス構築-‐‑‒ !  アベイラビリティゾーンは地理理的に離離れ た場所にあるので、DCレベルでのサー ビス冗⻑⾧長性を持つことができる !  通常、2箇所以上のDCにシステムを構築 するのは⾮非常に⼿手間と時間とお⾦金金がかか る
  • 82. AWSでの基本的な構成 -‐‑‒まとめ-‐‑‒
  • 83. AWSでの基本的な構成 -‐‑‒まずはこの構成に!-‐‑‒ ベストプラクティス! Web Web EC2 EC2 RDS RDS Availability  Zone Availability  Zone AWS  Cloud !   EC2単体はもちろん、データ センターレベルの障害があっ てもサービスが⽌止まらない耐 久性 !   必要なときにクイックにリ ソースを増減できる柔軟性 !   インフラ管理理の⼿手間は最⼩小化
  • 84. !  AWSでWebアプリケーションつくるなら? 3.どこから⼿手をつけていいのか… アンチパターンも紹介 !   AWSでWebアプリケーションつくるなら? •  •  AWSでのオススメ構成 アンチパターンも紹介 !   ピーク対策どうすればいいの? •  •  ピークはチャンス チャンスを逃さないための対策
  • 85. アンチパターンとは !  よくハマる、もしくは絶対にやってはい けない典型的な悪い例例のこと !  AWSをうまく使いこなす上でのアンチ パターンをいくつか紹介します
  • 86. アンチパターン1 !  アプリのセッションをEC2のローカル ファイルに保持する
  • 87. アンチパターン1 !  アプリのセッションをEC2のローカル ファイルに保持する EC2が2台以上になっても セッションの共有ができないので、 全くスケールできない!
  • 88. アンチパターン1 !  アプリのセッションをEC2のローカル ファイルに保持する EC2が2台以上になっても ELBの配下に複数台 のEC2をぶら下げて セッションの共有ができないので、 Webアプリケーショ 全くスケールできない! ンを動かすには必須 です。 Web Web
  • 89. アンチパターン1 !  アプリのセッションをEC2のローカル ファイルに保持する EC2が2台以上になっても ELBの配下に複数台 のEC2をぶら下げて セッションの共有ができないので、 Webアプリケーショ 全くスケールできない! ンを動かすには必須 です。 Web Web セッションは共有ストレージに!
  • 90. アンチパターン1 !  アプリのセッションをEC2のローカル ファイルに保持する EC2が2台以上になっても セッションの共有ができないので、 全くスケールできない! セッションはMySQLや memcached,  Redisなどに保持し ましょう
  • 91. アンチパターン2 !  1台のEC2にWebとDBとキャッシュ、 などの複数の役割を持たせる
  • 92. アンチパターン2 !  1台のEC2にWebとDBとキャッシュ、 などの複数の役割を持たせる WebはスカスカなのにDBがメモリを⾷食う のでEC2をスペックアップしなきゃいけ ない、とうようなムダがでる
  • 93. アンチパターン2 !  1台のEC2にWebとDBとキャッシュ、 などの複数の役割を持たせる DBが重くなっただけでApache まで増強することに WebはスカスカなのにDBがメモリを⾷食う ↓ のでEC2をスペックアップしなきゃいけ 無駄が出る ない、とうようなムダがでる EC2 ↓ できるだけ無駄をなくすために スケールの判断が慎重化 ↓ スピードダウン
  • 94. アンチパターン2 !  1台のEC2にWebとDBとキャッシュ、 などの複数の役割を持たせる DBが重くなっただけでApache まで増強することに WebはスカスカなのにDBがメモリを⾷食う ↓ のでEC2をスペックアップしなきゃいけ 無駄が出る ない、とうようなムダがでる EC2 ↓ できるだけ無駄をなくすために スケールの判断が慎重化 ↓ 詰め込んじゃダメ! スピードダウン
  • 95. アンチパターン2 !  1台のEC2にWebとDBとキャッシュ、 などの複数の役割を持たせる WebはスカスカなのにDBがメモリを⾷食う のでEC2をスペックアップしなきゃいけ ない、とうようなムダがでる コンポーネントは⼩小分けに!
  • 96. アンチパターン2 !  1台のEC2にWebとDBとキャッシュ、 などの複数の役割を持たせる WebはスカスカなのにDBがメモリを⾷食う のでEC2をスペックアップしなきゃいけ ない、とうようなムダがでる EC2やRDSなどのコンポーネントは 役割ごとに分けましょう!
  • 97. アンチパターン3 !  スモールスタートという名のもとにベス トプラクティスの構成でスタートしない
  • 98. アンチパターン3 !  スモールスタートという名のもとにベス トプラクティスの構成でスタートしない サービスがスタートしたら⽇日々の運⽤用や新 機能の開発などで⼿手が回らなくなります!
  • 99. アンチパターン3 !  スモールスタートという名のもとにベス トプラクティスの構成でスタートしない サービスがスタートしたら⽇日々の運⽤用や 新機能の開発などで⼿手が回らなくなりま ベストプラクティスの構成ではないと す! 個々の作業にかかるコストも上がってし まって、負のスパイラル。
  • 100. アンチパターン3 !  スモールスタートという名のもとにベス トプラクティスの構成でスタートしない サービスがスタートしたら⽇日々の運⽤用や新 機能の開発などで⼿手が回らなくなります! 最初に⼿手間をかけてベストプラク ティス構成を作ることが結局⼀一番⼿手 間を減らして、ビジネスのスピード があがります。
  • 101. !  AWSでWebアプリケーションつくるなら? 3.どこから⼿手をつけていいのか… まとめ !   AWSでWebアプリケーションつくるなら? •  •  AWSでのオススメ構成 アンチパターンも紹介 !   突発的なピーク対策どうすればいいの? •  •  ピークはチャンス チャンスを逃さないための対策
  • 102. !  AWSでWebアプリケーションつくるなら? 3.どこから⼿手をつけていいのか… まとめ !   ELB+EC2+RDSがWebア プリの基本構成 Web Web EC2 EC2 RDS Availability  Zone RDS Availability  Zone AWS  Cloud !   ⾼高い耐久性、拡張性、メン テナンス性がキーワード !   まず最初に⼿手間をかけてベ ストプラクティスの構成に。
  • 103. !  突発的なピーク対策どうすればいいの? 3.どこから⼿手をつけていいのか… ピークはチャンス !   AWSでWebアプリケーションつくるなら? •  •  AWSでのオススメ構成 アンチパターンも紹介 !   ピーク対策どうすればいいの? •  •  ピークはチャンス チャンスを逃さないための対策
  • 104. 突発的なピークはなぜ起こる? !  テレビやソーシャルでバズって突発的か つ⼀一時的にユーザーが集まる !  広告出稿の結果としてユーザーが急増す る !  イベントやキャンペーンで(ry
  • 105. よく聞く”もったいない”トラブル !  サービスがWBS(トレたま)に取り上げ られたが、急激な負荷で放送中にサーバ が落落ちてしまい、既存ユーザにも影響 が…orz !  YahooトップページやTechCrunchなど に取り上げられたが、アクセス集中によ るレスポンス低下で新規ユーザを逃して しまった…orz
  • 106. ピークトラフィックを扱う難しさ !  テレビなどで発⽣生する突発的なピークは 普段の50倍だったり100倍のトラフィッ クが発⽣生する! !  これを捌けるようなリソースを予め準備 しておくのは無駄!もしくは(予算的 に)無理理! !  なので既存のリソースで何とかしなきゃ いけない・・・
  • 107. 結果として、エンジニアから⾒見見ると・・・ !  急なメディア掲載とかやめてほしい !  「絶対に落落ちちゃダメなキャンペーン」 とか絶対やめてほしい !  「○○万⼈人が⼀一⻫斉にアクセスするイベン ト」とか(ry
  • 108. 結果として、エンジニアから⾒見見ると・・・ !  急なメディア掲載とかやめてほしい !  「絶対に落落ちちゃダメなキャンペーン」 とか絶対やめてほしい これって機会損失ですよね? !  「○○万⼈人が⼀一⻫斉にアクセスするイベン 突発的なピークをうまく捌いてチャンスを ト」とか(ry 積極的にものにしましょう。
  • 109. !  ピーク対策どうすればいいの? 3.どこから⼿手をつけていいのか… チャンスを逃さないための対策 !   AWSでWebアプリケーションつくるなら? •  •  AWSでのオススメ構成 アンチパターンも紹介 !   ピーク対策どうすればいいの? •  •  ピークはチャンス チャンスを逃さないための対策
  • 110. 対策1 -‐‑‒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
  • 111. 対策1 -‐‑‒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
  • 112. 対策1 -‐‑‒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
  • 113. 対策1 -‐‑‒EC2とRDSをスケールさせる-‐‑‒ 参考)ELBはトラフィックに 合わせて⾃自動的にスケールします 注意1 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
  • 114. 対策1 -‐‑‒EC2とRDSをスケールさせる-‐‑‒ 注意2 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
  • 115. 対策1 -‐‑‒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
  • 116. ピーク対応にいくらかかると思いますか? テレビ番組対策で2時間の間… EC2(medium)を20台増設、 RDSをスペックアップ(medium→xlarge) ・2時間後にピーク前の状態に戻す前提、ピークが来ない場合との⽐比較 ・m1.mediumのスペック:1コア・メモリ3.75GB ・m1.xlargeのスペック:4コア・メモリ15GB !  1:約1,000円 !  2:約10,000円 !  3:約100,000円
  • 117. アンチパターン4 !   テレビのトラフィックをなめてて、思い切切り の悪い対策でサービスダウンしてしまう 思い切切った増設をして「結局10%しか使 わなかったねw」は笑い話ですみますが、 サーバが落落ちたら残念念です…orz CEO・CTOの皆さん、費⽤用対効果 を考えて、思い切切った増設の判断 をお願いします!(1回⽬目は思い切切っ て、2回⽬目以降降で調節しましょう) 私たちからもお願いです…
  • 118. 対策2 -‐‑‒静的ファイルはS3から配信-‐‑‒ 動的コンテンツ Web Web EC2 EC2 RDS RDS 画像やJSなどの 静的コンテンツ Availability  Zone Availability  Zone AWS  Cloud Amazon S3 !   S3のWeb  Site   Hosting機能を使 うと、S3が静的な HTTPサーバーとし て動作する !   S3は⼤大規模なアク セスに耐えるよう に設計され、AWS 側で運⽤用されてい る
  • 119. 対策2 -‐‑‒静的ファイルはS3から配信-‐‑‒ 動的コンテンツ 画像やJSなどの 静的コンテンツ CloudFront Web Web EC2 EC2 RDS RDS Availability  Zone Availability  Zone AWS  Cloud Amazon S3 !   更更に、CDNサービ スである CloudFrontを組み 合わせるとレイテ ンシの向上も図れ る
  • 120. 対策2 -‐‑‒静的ファイルはS3から配信-‐‑‒ 画像やJSなどの 静的コンテンツ 動的コンテンツ !   更更にCloudFrontを 組み合わせるとレ ELB+EC2は動的コンテンツの配信だけ CloudFront イテンシの向上も に役割を絞り、静的コンテンツは Web Web 図れる S3(+CloudFront)に任せてしまう! EC2 Amazon EC2 RDS S3 Availability  Zone RDS Availability  Zone AWS  Cloud
  • 121. 対策2 -‐‑‒静的ファイルはS3から配信-‐‑‒ 画像やJSなどの 静的コンテンツ 動的コンテンツ 更更に・・・ !   更更にCloudFrontを トラフィック流流⼊入のランディングページ 組み合わせるとレ CloudFront を完全に静的なものにして イテンシの向上も Web Web S3(+CloudFront)でホスティングして 図れる EC2 しまえばEC2側へのトラフィックを⼤大幅 Amazon EC2 S3 に減らせます RDS Availability  Zone RDS Availability  Zone AWS  Cloud
  • 122. 対策2 -‐‑‒静的ファイルはS3から配信-‐‑‒ メディア紹介による流流⼊入 既存ユーザ 新規ユーザ サービスサイト トップページ service.hoge.com www.hoge.com 最⼩小限なコストで サーバ落落ち防⽌止 CloudFront Web Web
  • 123. !  突発的なピーク対策どうすればいいの? 3.どこから⼿手をつけていいのか… まとめ !   AWSでWebアプリケーションつくるなら? •  •  AWSでのオススメ構成 アンチパターンも紹介 !   突発的なピーク対策どうすればいいの? •  •  ピークはチャンス チャンスを逃さないための対策
  • 124. !  突発的なピーク対策どうすればいいの? 3.どこから⼿手をつけていいのか… まとめ !   ⼤大前提 •  システムが柔軟な拡張性を持っていることが必須な ので、ベストプラクティスに沿ったシステム構成で あること !   対策1 •  EC2とRDSは負荷を予測し、予めスケールさせておく •  終わったらもとに戻す !   対策2 •  S3(とCloudFront)を使って静的ファイルを配信する •  ELBとEC2は動的コンテンツの配信だけに役割を絞っ ておく
  • 125. メディア露露出時のピーク対策 今⽇日お話したこと !  AWSでWebアプリケーションつくるなら? •  AWSでのオススメ構成 •  アンチパターンも紹介 !  突発的なピーク対策どうすればいいの? •  ピークはチャンス •  チャンスを逃さないための対策 130
  • 126. !  質疑応答
  • 127. !  宿題
  • 128. [宿題]次回はどんな授業が聞きたいですか? !   次回はもうちょっとテクニカルな内容を予定して います。リクエストを参考にさせてください [1]AWSでのアプリケーションデプロイ [2]AWSを活⽤用したログ解析 [3]⽇日々の性能監視/障害監視 “NewRelic” いいですよ [4]スタートアップでも必要なセキュリティ対策 [5]その他(⾃自由記⼊入でお願いします)
  • 129. ありがとうございました!
  • 130. !  参考資料料
  • 131. AWSサポート !   ⽇日本語での技術サポートもご提供(オプション) ベーシック デベロッパー ビジネス エンタープライズ 利利⽤用可能 利利⽤用可能 利利⽤用可能 利利⽤用可能 サポートへの コンタクト EC2の 健全性エラーが発 ⽣生した場合 コンタクト フォーム 電話、チャット コンタクト フォーム 電話、チャット コンタクト フォーム 初回応答時間 不不可 12時間 (営業時間内) 1時間 15分 -‐‑‒ 1 5 無制限 24/365対応 なし なし あり あり Trusted   Advisor なし なし あり あり 専任スタッフ 特別サポート なし なし なし あり フォーラム 連絡先登録 料料⾦金金(⽉月額) 無料料 $49 AWS利利⽤用総額の $0~∼$10K:      10% $10K~∼$80K:  7% $80K~∼$250K:  5% $250K~∼:  3% (最低$100) AWS利利⽤用総額の10% (最低$15000) 〜~たとえばローンチ前後だけ「ビジネス」にすることも可能〜~
  • 132. リソース監視 !   AWSのリソース監視機能 CloudWatchでもOKですが、   サードパーティーのリソース   監視SaaSを利利⽤用する⽅方法も   あります !   たとえば”NewRelic”など     ・15⽇日以上の履履歴参照が出来る     ・メモリ使⽤用量量がわかる     ・下記リンクから申し込むと無料料利利⽤用枠あり(2013/7/1現在) http://newrelic.com/aws 137
  • 133. アカウント作成⽅方法 http://aws.amazon.com/jp/register-‐‑‒flow/ 138
  • 134. 基本的な操作⽅方法 !   AWS  Basic トレーニング資料料     →オフラインでのハンズオンも       定期的にやっています http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ !   ハンズオン情報     →いろいろなハンズオンイベントも       実施中です http://aws.amazon.com/jp/event_̲schedule/ 139
  • 135. 各サービスの説明 !   AWS  マイスターシリーズ   ・EC2&EBS編   ・RDS編   ・ELB編   ・CloudWatch/Auto  Scaling編   ・Cloudfront編    !   AWS上でのWeb アプリケーションデプロイ http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ 140
  • 136. コスト削減 !   AWS  マイスターシリーズ   ・リザーブドインスタンス&     スポットインスタンス編 http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/ 141
  • 137. !  ご利利⽤用料料⾦金金イメージ
  • 138. ご利利⽤用料料⾦金金イメージ ざっくりの⽬目安ですが… (動画や⾼高画質写真を扱わない⼀一般的な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⾒見見積もり例例
  • 139. さらに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⾒見見積もり例例
  • 140. 無料料使⽤用枠 !   アカウント作成から12か⽉月間の間は、 無料料でご利利⽤用いただける利利⽤用範囲があります ! http://aws.amazon.com/jp/free/ 145
  • 141. ⻑⾧長期ご利利⽤用の割引プランもあります !   オンデマンド・インスタンス •  時間単位でのインスタンス購⼊入 •  ⻑⾧長期のコミットメントなし L・M・Hの3種類 ⼀一時⾦金金と時間当たりのご利利⽤用料料⾦金金が異異なる !   リザーブド・インスタンス •  1年年間  or  3年年間での「インスタンス割引権利利」の購⼊入 •  ⼤大幅割引(3~∼5割引)が適⽤用 •  ⻑⾧長期間稼動が⾒見見込まれる処理理に最適 積算料料⾦金金 オンデマンド インスタンス リザーブド インスタンス ⼀一時⾦金金 期間 14 6 146