スタートアップならおさえておきたい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. !  実は⽣生徒の皆さんもすでに(間接的に)ご利利⽤用かも？

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 ・台数やスペックを柔軟に変更更可能な仮想 1ｃ　サーバ(各種Linux/Windows) ・必要な時に、必要な台数を時間課⾦金金で　利利⽤用可能 Amazon RDS ・マネージドデータベースサービス 1 　(MySQL/PostgreSQLなどに対応) ・冗⻑⾧長構成、マスタ/スレーブ構成や　⾃自動バックアップなどご利利⽤用可能

43. とりあえず、おさえておきたいサービス4つ Amazon S3 ・容量量無制限のオンラインストレージ 1 ・⾃自動的に複数DCに保存し、　⾼高い耐久性を実現 ELB(Elastic Load Balancing) ・従量量課⾦金金で使えるロードバランサー　 1 ・GUIで各種操作可能・AZをまたいだロードバランシングも可能

44. いずれも既存の知識識で使えます！ Amazon EC2 1ｃ・必要なときに必要なだけ使える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 ちなみにこちらの２つはやっちゃダメなパターン 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 1ｃ・必要なときに必要なだけ使える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台（前提で動いているもの）を４台にするのは⾮非常に⼿手間ですが、 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

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. アンチパターン１ !  アプリのセッションをEC2のローカルファイルに保持する

87. アンチパターン１ !  アプリのセッションをEC2のローカルファイルに保持する EC2が２台以上になってもセッションの共有ができないので、全くスケールできない！

88. アンチパターン１ !  アプリのセッションをEC2のローカルファイルに保持する EC2が２台以上になっても ELBの配下に複数台のEC2をぶら下げてセッションの共有ができないので、 Webアプリケーショ全くスケールできない！ンを動かすには必須です。 Web Web

89. アンチパターン１ !  アプリのセッションをEC2のローカルファイルに保持する EC2が２台以上になっても ELBの配下に複数台のEC2をぶら下げてセッションの共有ができないので、 Webアプリケーショ全くスケールできない！ンを動かすには必須です。 Web Web セッションは共有ストレージに！

90. アンチパターン１ !  アプリのセッションをEC2のローカルファイルに保持する EC2が２台以上になってもセッションの共有ができないので、全くスケールできない！セッションはMySQLや memcached, Redisなどに保持しましょう

91. アンチパターン２ !  １台のEC2にWebとDBとキャッシュ、などの複数の役割を持たせる

92. アンチパターン２ !  １台のEC2にWebとDBとキャッシュ、などの複数の役割を持たせる WebはスカスカなのにDBがメモリを⾷食うのでEC2をスペックアップしなきゃいけない、とうようなムダがでる

93. アンチパターン２ !  １台のEC2にWebとDBとキャッシュ、などの複数の役割を持たせる DBが重くなっただけでApache まで増強することに WebはスカスカなのにDBがメモリを⾷食う ↓ のでEC2をスペックアップしなきゃいけ無駄が出るない、とうようなムダがでる EC2 ↓ できるだけ無駄をなくすためにスケールの判断が慎重化 ↓ スピードダウン

94. アンチパターン２ !  １台のEC2にWebとDBとキャッシュ、などの複数の役割を持たせる DBが重くなっただけでApache まで増強することに WebはスカスカなのにDBがメモリを⾷食う ↓ のでEC2をスペックアップしなきゃいけ無駄が出るない、とうようなムダがでる EC2 ↓ できるだけ無駄をなくすためにスケールの判断が慎重化 ↓ 詰め込んじゃダメ！スピードダウン

95. アンチパターン２ !  １台のEC2にWebとDBとキャッシュ、などの複数の役割を持たせる WebはスカスカなのにDBがメモリを⾷食うのでEC2をスペックアップしなきゃいけない、とうようなムダがでるコンポーネントは⼩小分けに！

96. アンチパターン２ !  １台のEC2にWebとDBとキャッシュ、などの複数の役割を持たせる WebはスカスカなのにDBがメモリを⾷食うのでEC2をスペックアップしなきゃいけない、とうようなムダがでる EC2やRDSなどのコンポーネントは役割ごとに分けましょう！

97. アンチパターン３ !  スモールスタートという名のもとにベストプラクティスの構成でスタートしない

98. アンチパターン３ !  スモールスタートという名のもとにベストプラクティスの構成でスタートしないサービスがスタートしたら⽇日々の運⽤用や新機能の開発などで⼿手が回らなくなります！

99. アンチパターン３ !  スモールスタートという名のもとにベストプラクティスの構成でスタートしないサービスがスタートしたら⽇日々の運⽤用や新機能の開発などで⼿手が回らなくなりまベストプラクティスの構成ではないとす！個々の作業にかかるコストも上がってしまって、負のスパイラル。

100. アンチパターン３ !  スモールスタートという名のもとにベストプラクティスの構成でスタートしないサービスがスタートしたら⽇日々の運⽤用や新機能の開発などで⼿手が回らなくなります！最初に⼿手間をかけてベストプラクティス構成を作ることが結局⼀一番⼿手間を減らして、ビジネスのスピードがあがります。

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. 突発的なピークはなぜ起こる？ !  テレビやソーシャルでバズって突発的かつ⼀一時的にユーザーが集まる !  広告出稿の結果としてユーザーが急増する !  イベントやキャンペーンで（ｒｙ

105. よく聞く”もったいない”トラブル !  サービスがWBS(トレたま)に取り上げられたが、急激な負荷で放送中にサーバが落落ちてしまい、既存ユーザにも影響が…orz !  YahooトップページやTechCrunchなどに取り上げられたが、アクセス集中によるレスポンス低下で新規ユーザを逃してしまった…orz

106. ピークトラフィックを扱う難しさ !  テレビなどで発⽣生する突発的なピークは普段の50倍だったり100倍のトラフィックが発⽣生する！ !  これを捌けるようなリソースを予め準備しておくのは無駄！もしくは（予算的に）無理理！ !  なので既存のリソースで何とかしなきゃいけない・・・

107. 結果として、エンジニアから⾒見見ると・・・ !  急なメディア掲載とかやめてほしい !  「絶対に落落ちちゃダメなキャンペーン」とか絶対やめてほしい !  「○○万⼈人が⼀一⻫斉にアクセスするイベント」とか（ｒｙ

108. 結果として、エンジニアから⾒見見ると・・・ !  急なメディア掲載とかやめてほしい !  「絶対に落落ちちゃダメなキャンペーン」とか絶対やめてほしいこれって機会損失ですよね？ !  「○○万⼈人が⼀一⻫斉にアクセスするイベン突発的なピークをうまく捌いてチャンスをト」とか（ｒｙ積極的にものにしましょう。

109. !  ピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… チャンスを逃さないための対策 !   AWSでWebアプリケーションつくるなら？ •  •  AWSでのオススメ構成アンチパターンも紹介 !   ピーク対策どうすればいいの？ •  •  ピークはチャンスチャンスを逃さないための対策

110. 対策１ -‐‑‒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. 対策１ -‐‑‒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. 対策１ -‐‑‒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. 対策１ -‐‑‒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

114. 対策１ -‐‑‒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

115. 対策１ -‐‑‒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. 対策２ -‐‑‒静的ファイルは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. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 動的コンテンツ画像やJSなどの静的コンテンツ CloudFront Web Web EC2 EC2 RDS RDS Availability Zone Availability Zone AWS Cloud Amazon S3 !   更更に、CDNサービスである CloudFrontを組み合わせるとレイテンシの向上も図れる

120. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 画像やJSなどの静的コンテンツ動的コンテンツ !   更更にCloudFrontを組み合わせるとレ ELB+EC2は動的コンテンツの配信だけ CloudFront イテンシの向上もに役割を絞り、静的コンテンツは Web Web 図れる S3(+CloudFront)に任せてしまう！ EC2 Amazon EC2 RDS S3 Availability Zone RDS Availability Zone AWS Cloud

121. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ 画像やJSなどの静的コンテンツ動的コンテンツ更更に・・・ !   更更にCloudFrontをトラフィック流流⼊入のランディングページ組み合わせるとレ CloudFront を完全に静的なものにしてイテンシの向上も Web Web S3(+CloudFront)でホスティングして図れる EC2 しまえばEC2側へのトラフィックを⼤大幅 Amazon EC2 S3 に減らせます RDS Availability Zone RDS Availability Zone AWS Cloud

122. 対策２ -‐‑‒静的ファイルはS3から配信-‐‑‒ メディア紹介による流流⼊入既存ユーザ新規ユーザサービスサイトトップページ service.hoge.com www.hoge.com 最⼩小限なコストでサーバ落落ち防⽌止 CloudFront Web Web

123. !  突発的なピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… まとめ !   AWSでWebアプリケーションつくるなら？ •  •  AWSでのオススメ構成アンチパターンも紹介 !   突発的なピーク対策どうすればいいの？ •  •  ピークはチャンスチャンスを逃さないための対策

124. !  突発的なピーク対策どうすればいいの？ 3.どこから⼿手をつけていいのか… まとめ !   ⼤大前提 •  システムが柔軟な拡張性を持っていることが必須なので、ベストプラクティスに沿ったシステム構成であること !   対策１ •  EC2とRDSは負荷を予測し、予めスケールさせておく •  終わったらもとに戻す !   対策２ •  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時間１５分 -‐‑‒ 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-‐‑‒ﬂow/ 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

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

Vous êtes en train de lire un aperçu.

Consultez-les par la suite

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

Plus De Contenu Connexe

Diaporamas pour vous (20)

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

Plus par schoowebcampus (20)

Plus récents (20)