Your SlideShare is downloading. ×
スタートアップならおさえておきたいAWS入門(スタートアップ向け構成例)@福岡市STARTUP CAFE
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

スタートアップならおさえておきたいAWS入門(スタートアップ向け構成例)@福岡市STARTUP CAFE

543
views

Published on

2015年4月13日実施の「スタートアップならおさえておきたいAWS入門@福岡市STARTUP CAFE」の資料(スタートアップ向け構成例)

2015年4月13日実施の「スタートアップならおさえておきたいAWS入門@福岡市STARTUP CAFE」の資料(スタートアップ向け構成例)

Published in: Technology

0 Comments
16 Likes
Statistics
Notes

  • Be the first to comment

Show More
No Downloads
Views
Total Views
543
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
23
Comments
0
Likes
16
Embeds 0
No embeds
Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Webサービス向けスケーラブルな構成例例 アマゾンデータサービスジャパン株式会社 テリトリーアカウントマネージャー  髙⼭山  博史 2015.04.13 -‐‑‒  継続的な成⻑⾧長やメディア紹介時のアクセス集中に備える  -‐‑‒  
  • 2.        スタートアップならおさえておきたいAWS⼊入⾨門  ①概要と基礎知識識編 http://www.slideshare.net/HiroshiTakayama/awsstartup-‐‑‒cafe ②スタートアップ向け構成例例[本資料料] http://www.slideshare.net/HiroshiTakayama/awsstartup-‐‑‒cafe-‐‑‒46844553 資料料の構成
  • 3. Agenda •  本資料料の対象 •  はじめに •  AWSを利利⽤用したスケーラブルな構成 •  その他、気をつけたいポイント •  まとめ
  • 4. Agenda •  本資料料の対象 •  はじめに •  AWSを利利⽤用したスケーラブルな構成 •  その他、気をつけたいポイント •  まとめ
  • 5. 本資料料の対象 •  現在、1〜～2台規模のEC2やVPSでサービスを 運⽤用しているWeb系エンジニアの⽅方 •  順調に動作してはいるけど「将来的なサービス成 ⻑⾧長やピークトラフィック」が⼼心配というエンジニ アの⽅方、CEOの⽅方
  • 6. Agenda •  本資料料の対象 •  はじめに •  AWSを利利⽤用したスケーラブルな構成 •  その他、気をつけたいポイント •  まとめ
  • 7. よく聞く”もったいない”トラブル •  提供サービスが、テレビ番組に取り上げられたが、 急激な負荷で放送中にサーバが落落ちてしまい、 数万⼈人の新規⾒見見込ユーザを逃してしまった… •  提供サービスが、有名ポータルサイトに掲載された/SNS でコンテンツがバズったが、アクセス集中によるレスポ ンス低下で、既存ユーザにも影響が… •  せっかくユーザが増えてきたのに、 DB移⾏行行時のトラブルで⼀一部データをロスト してしまった…
  • 8. CTO/エンジニアの⼼心配 •  急なメディア掲載とかやめて欲しい… •  アプリエンジニアなのに、 ITインフラの管理理とか無理理/⾯面倒… •  ピークに合わせて、サーバ増設したいけど、 どれくらい増やしていいかわからない…
  • 9. CEOの⼼心配 •  1年年後には、ユーザ数が今の数百倍になる予定な んだけど、実際に数百万ユーザになったときに、 今の構成で耐えられるの？その時のコストは？ •  メディア掲載等、新規ユーザ獲得のチャンスを逃 したくない！でもコスト増は最⼩小限に抑えたい！
  • 10. Agenda •  本資料料の対象 •  はじめに •  AWSを利利⽤用したスケーラブルな構成 •  その他、気をつけたいポイント •  まとめ
  • 11. よくある最⼩小構成 •  まずは最⼩小構成で… •  ユーザ増えてから対策予定… •  アプリに集中 •  VPS等ご利利⽤用の場合も同様 EC2 EC2 Web App DB (MySQL) AZ EC2 App DB AZ または
  • 12. この構成の弱点 •  急激なアクセス集中時にどうやって乗り切切る？ •  サービスが成⻑⾧長してユーザが増えた時に Webサーバ、DBはどうする？ •  データバックアップは？ •  そもそもサーバが落落ちたらどうする？…etc なるべく早めの対策で安⼼心！
  • 13. おさえておきたいAWSのサービス AWSグローバルインフラ Regions  /  Availability  Zones  /  Contents  Delivery  POPSAZRegion コンピュート処理理 ストレージ データベース EC2 Elastic Load  Balancing Auto  Scaling S3 Glacier EBS Storage  Gateway RDS DynamoDB ElastiCache Redshift データ分析 Kinesis EMR Data  Pipeline コンテンツ配信 CloudFront ネットワーク Virtual  Private  Cloud Direct  Connect Rout53 アプリケーションサービス WorkSpaces SQS SNS SES SWF Elastic  Transcoder CloudSearch Management  &  Administration CloudWatch CloudTrail IAM Management  Console SDK CLI ⾃自動化とデプロイメント CloudFormation BeanStalk OpsWorks EcosystemTechnology  Partner  /  Consulting  Partner  
  • 14. とりあえず、おさえておきたいサービス ・台数やスペックを柔軟に変更更可能な仮想サーバ  　(有償ライセンスのOS選択も可能) ・必要な時に、必要な台数を時間課⾦金金で利利⽤用可能 Amazon  EC2 ・従量量課⾦金金で使えるロードバランサー 　 ・GUIで各種操作可能、  　AZをまたいだバランシングも可能 ELB (Elastic  Load  Balancing) 既存の技術知識識で使えます
  • 15. とりあえず、おさえておきたいサービス ・マネージドデータベースサービス  　(代表的なDBエンジンに対応) ・冗⻑⾧長構成、マスタ/スレーブ構成や⾃自動バック  　アップなどご利利⽤用可能 Amazon  RDS 既存の技術知識識で使えます ・容量量無制限のオンラインストレージ ・⾃自動的に複数DCに保存し、  　⾮非常に⾼高い耐久性を実現C Amazon  S3
  • 16. しつこいですが… ・⼀一般的なLinux/Windowsサーバ ・プラスアルファで便便利利な機能 Amazon  EC2 ・⼀一般的なMySQLまたはPostgreSQL ・プラスアルファで便便利利な機能 Amazon  RDS ・業界標準APIで操作するストレージ ・プラスアルファで便便利利な機能や⾼高い耐久性 Amazon  S3
  • 17. 世界中のデータセンタ群(リージョン) どのリージョンでも同じ使い勝⼿手 同じやり⽅方で⽇日本から利利⽤用可能 11のリージョン 1. US  EAST  (Virginia) 2. US  WEST    (N.  California) 3. US  WEST  2  (Oregon) 4. EU  WEST  (Ireland) 5. JAPAN  (Tokyo) 6. South  America  (Sao  Paulo) 7. ASP  1  (Singapore) 8. ASP  2  (Sydney) 9. GovCloud   10. BJS  1  (Beijing  China)  limited  preview 11. EU  (Frankfurt) 28のアベイラビリティ・ゾーン(AZ) 50以上のエッジロケーション
  • 18. •  Tokyoリージョンは2つのデータセンタ(AZ)で構成 •  2つのAZを利利⽤用した冗⻑⾧長構成も簡単 リージョン＝データセンタ”群”？ EU (Ireland) Availability Zone A Availability Zone C Availability Zone B Asia Pacific (Tokyo) Availability Zone A Availability Zone B US West (Oregon) Availability Zone A Availability Zone B US West(Northern California) Availability Zone A Availability Zone B 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 US East (Northern Virginia) Availability Zone D Availability Zone C Availability Zone B Availability Zone E Availability Zone A Asia Pacific (Sydney) Availability Zone A Availability Zone B EU (Frankfurt) Availability Zone A Availability Zone B ＊AZ=Availability  Zoneの略略  　距離離の離離れたデータセンタ
  • 19. おすすめのスケーラブルな構成 EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS EC2 AZ① Web App 参考：元の構成
  • 20. ①Web/Appサーバを複数台に •  Web/Appサーバを複数台に →スケールアウトに対応できるよう 　  　にステートレスな実装が必要 •  振り分けのために ロードバランサ(ELB)も導⼊入 •  Web/Appサーバは、 それぞれ別Availability  Zone(AZ) に配置することを推奨 EC2 EC2 RDS ELB AZ① AZ② Web App Web App RDS
  • 21. ①「Web/Appサーバを複数台に」のメリット •  メディア掲載等、 ⼀一時的なアクセス集中時に増設 (スケールアウト)が可能 •  もちろん段階的なユーザ増に あわせてサーバ増設も可能 •  複数台使⽤用、複数AZ使⽤用で 可⽤用性・耐障害性もUP！ EC2 EC2 DB ELB AZ① AZ② Web App Web App EC2 Web App EC2 Web App RDS RDS
  • 22. 参考：AMIでEC2をコピー構築 •  AMI(Amazon  Machine  Image) –  簡単にマシンイメージを作成可能 –  作成したイメージからEC2を起動⇒コピー構築 Web AMI AMI作成 AMIからEC2起動 Web Web
  • 23. 参考：Auto  Scalingによる⾃自動拡⼤大/縮⼩小 •  Auto  Scaling –  EC2を負荷に応じて⾃自動的に拡⼤大/縮⼩小させる仕組み –  例例)  CPU使⽤用率率率が5分以上継続して70%以上だったら2台追加 Auto  Scaling  Group ELB CloudWatch 負荷状況を監視 EC2を追加構築 ELBの振り分けに追加 Web Web Web Web
  • 24. ②DBはRDS(Multi-‐‑‒AZ)に •  DBはAWSのマネージドRDB ”RDS”にする •  冗⻑⾧長化オプションの Multi-‐‑‒AZもON EC2 EC2 ELB AZ① AZ② Web App Web App RDS RDS
  • 25. ②「DBはRDS(Multi-‐‑‒AZ)に」のメリット •  AWSでチューニング済み •  ⼀一時的なアクセス集中時にスペックを 上げて(スケールアップ)対応可能 •  ユーザ増にもスペックUPと HD容量量増で容易易に対応可能 •  ⾃自動バックアップ&Point  In  Time   Recovery機能で、トラブル時も5分前 の状態まで戻せる •  同期の冗⻑⾧長化(MultiAZ)オプションで 万が⼀一に備える EC2 EC2 ELB AZ① AZ② Web App Web App
  • 26. 参考：Multi-‐‑‒AZで万が⼀一に備える AZ① AZ② アクティブ スタンバイ 通常時：同期レプリケーション トラブル時：⾃自動フェイルオーバー AZ① AZ② アクティブ スタンバイ AZ① AZ② スタンバイ アクティブ
  • 27. ②「DBはRDS(Multi-‐‑‒AZ)に」のメリット •  AWSでチューニング済み •  ⼀一時的なアクセス集中時にスペックを 上げて(スケールアップ)対応可能 •  ユーザ増にもスペックUPと HD容量量増で容易易に対応可能 •  ⾃自動バックアップ&Point  In  Time   Recovery機能で、トラブル時も5分前 の状態まで戻せる •  冗⻑⾧長化(MultiAZ)オプションも 簡単に導⼊入可能  and  more… EC2 EC2 ELB AZ① AZ② Web App Web App ⼤大変なDB運⽤用の負荷を⼤大幅に軽減 アプリケーションに集中できる
  • 28. おすすめ構成 ピーク・成⻑⾧長に 備えた構成 EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS
  • 29. ⼀一時的なアクセス集中時/サービス成⻑⾧長時 EC2 EC2 AZ① AZ② Web App Web App ELB EC2 EC2 ELB AZ① AZ② Web App Web App EC2 Web App EC2 Web App
  • 30. ⼀一時的なアクセス集中時/サービス成⻑⾧長時 EC2 EC2 AZ① AZ② Web App Web App ELB EC2 EC2 ELB AZ① AZ② Web App Web App EC2 Web App EC2 Web App メディア掲載前に対策、 翌⽇日などアクセスが元に戻ったら、 台数を元に戻せば、最⼩小限のコストで サーバ落落ち/レスポンス低下による 機会損失を防げる 何台まで増やすか？インスタンスタイプは？ まずは余裕を持ったインスタンス数やインスタンスタイプで乗り切切り、 その際のCPU利利⽤用率率率やメモリ使⽤用率率率を監視ツール/監視サービス等で確認して、 だんだん適切切なインスタンス数やタイプを⾒見見極めていくのがオススメです
  • 31. TVなど瞬間的にアクセスが急増する場合 AZ① AZ② Web App Web App Web App Web App … Web App Web App Web App Web App … ↑事前に スペック UP 事前に⼤大幅Webサーバ増
  • 32. TVなど瞬間的にアクセスが急増する場合 AZ① AZ② Web App Web App Web App Web App … Web App Web App Web App Web App … ↑事前に スペック UP 事前に⼤大幅Webサーバ増 ここで問題です
  • 33. 突発的なピーク対応にいくらかかると思いますか？ •  テレビ番組対策を想定 –  番組前から2時間増強して、2時間後に元に戻す前提 •  2時間の間サーバ/DBを増設 –  Appサーバ：通常m3.medium*2台を20台に変更更 –  DB：通常m3.medium(MultiAZ)を m3.xlargeに変更更(2段階スペックアップ)  　 　 　 　 　 　            1：約1,000円  　 　 　 　 　 　            2：約10,000円  　 　 　 　 　 　            3：約100,000円
  • 34. 突発的なピーク対応にいくらかかると思いますか？ •  テレビ番組対策を想定 –  番組前から2時間増強して、2時間後に元に戻す前提 •  2時間の間サーバ/DBを増設 –  Appサーバ：通常m3.medium*2台を20台に変更更 –  DB：通常m3.medium(MultiAZ)を m3.xlargeに変更更(2段階スペックアップ)  　 　 　 　 　 　            2：約10,000円  　 　 　 　 　 　            3：約100,000円  　 　 　 　 　 　            1：約1,000円
  • 35. アンチパターン •  TVのトラフィックを少なく⾒見見積もって、 “思い切切りの悪い対策”でサービスダウンしてしまう •  はじめてのTV放映時などは、かなり余裕⾒見見た思い切切りのい い増設をお願いします(取り上げられ⽅方にもよりますが…) •  たとえば”テレビ番組対策で2時間の間…EC2を20台増設、 RDSを2段階スペックアップ”でも＋1,000円程度度で対策が 可能です(EC2はm3.medium想定、RDSは m3.medium→m3.xlargeとした場合)
  • 36. アンチパターン •  TVのトラフィックを少なく⾒見見積もって、 “思い切切りの悪い対策”でサービスダウンしてしまう •  はじめてのTV放映時などは、かなり余裕⾒見見た思い切切りのい い増設をお願いします(取り上げられ⽅方にもよりますが…) •  たとえば”テレビ番組対策で2時間の間…EC2を20台増設、 RDSを2段階スペックアップ”でも＋1,000円程度度で対策が 可能です(EC2はm1.medium想定、RDSは m1.medium→m1.xlargeとした場合) 費⽤用対効果を考えて、思い切切った増設の判断をお願いします！ (1回⽬目は思い切切って、2回⽬目以降降で調節しましょう)
  • 37. もちろん継続的なサービス成⻑⾧長にも！ EC2 EC2 AZ① AZ② Web App Web App ELB EC2 EC2 ELB AZ① AZ② Web App Web App EC2 Web App EC2 Web App ⼀一度度この構成にすれば… ユーザが数百万⼈人になっても、 基本的にはWeb/Appサーバ増設、 RDSスペックアップを 繰り返せばOKなはず！ (それでも耐えられなくなったらご相談ください)
  • 38. あのゲームも基本的には同じような構成 Tokyo  Game  Show  2014の発表資料料より抜粋
  • 39. 成⻑⾧長に伴い… Tokyo  Game  Show  2014の発表資料料より抜粋
  • 40. サーバ増！ Tokyo  Game  Show  2014の発表資料料より抜粋
  • 41. まとめ：まずはこの構成にしておくのがオススメです EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS ピーク・成⻑⾧長に 備えた構成
  • 42. 参考：BASEのシステム構成 EC2 EC2 RDS (Active) DB ELB AZ① AZ② RDS (Standby) ElastiCache S3 S3：商品画像の 保存と配信 ＋αのポイント ElastiCache： セッション情報の保存
  • 43. 参考：画像保存と配信について補⾜足 EC2 EC2 RDS (Active) DB ELB AZ① AZ② RDS (Standby) ElastiCache S3 EC2やRDSの負荷軽減につながり 結果的にコスト削減が可能 S3のホスティング機能を 利利⽤用してS3から直接配信
  • 44. まとめ：まずはこの構成にしておくのがオススメです EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS ピーク・成⻑⾧長に 備えた構成 朗報：これから始める⽅方に！
  • 45. おすすめ構成の構築・デプロイの⾃自動化 EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS ElasticBeanstalk deploy! Java Python PHP .NET Ruby nodeJS Docker 各種⾔言語(コンテナ)もサポート！ http://www.slideshare.net/AmazonWebServicesJapan/aws-‐‑‒black-‐‑‒belt-‐‑‒tech-‐‑‒aws-‐‑‒elastic-‐‑‒beanstalk
  • 46. Rettyさん事例例
  • 47. Rettyさん事例例
  • 48. Rettyさん事例例 http://www.slideshare.net/shotaumeda1/ph-‐‑‒perawsdev-‐‑‒ops
  • 49. Rettyさん事例例 http://www.slideshare.net/shotaumeda1/ph-‐‑‒perawsdev-‐‑‒ops
  • 50. まとめ：まずはこの構成にしておくのがオススメです EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS ピーク・成⻑⾧長に 備えた構成
  • 51. まとめ：ElasticBeanstalkなら更更に簡単！ EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS ElasticBeanstalk deploy! Java Python PHP .NET Ruby nodeJS Docker 各種⾔言語(コンテナ)もサポート！
  • 52. Agenda •  本資料料の対象 •  はじめに •  AWSを利利⽤用したスケーラブルな構成 •  その他、気をつけたいポイント •  まとめ
  • 53. リソース監視 •  監視SaaSの利利⽤用(オススメ) –  NewRelic、Mackerelなど –  お⼿手軽で⾼高機能 •  CloudWatch  logs –  AWSとして提供している機能 –  2014/12に東京リージョンにも対応 •  監視ツールをEC2にインストール –  zabbix  munin  nagios等 –  ただしEC2を⽤用意する必要あり [Cloudwatch  logs]  http://www.slideshare.net/AmazonWebServicesJapan/aws-‐‑‒black-‐‑‒belt-‐‑‒tech-‐‑‒aws-‐‑‒cloudtrail-‐‑‒cloudwatch-‐‑‒logs
  • 54. 超基本的なセキュリティ対策① •  セキュリティグループの適切切な設定 –  各サーバ/DBへの適切切なセキュリティ設定 sg-‐‑‒1234 22:  0.0.0.0/0 80:  0.0.0.0/0 25:  sg-‐‑‒1234 sg-‐‑‒1234 sg-‐‑‒abcd 22:  0.0.0.0/0 3306:  sg-‐‑‒1234 Web App sg-‐‑‒1234 Web App sg-‐‑‒1234 sg-‐‑‒XYZ   Web App http://www.slideshare.net/AmazonWebServicesJapan/amazon-‐‑‒elastic-‐‑‒compute-‐‑‒cloud-‐‑‒amazon-‐‑‒ec2
  • 55. 超基本的なセキュリティ対策② •  IAMロールの活⽤用 –  コードに直接AWSの認証情報を埋め込まない！！ http://www.slideshare.net/AmazonWebServicesJapan/aws-‐‑‒black-‐‑‒belt-‐‑‒tech-‐‑‒aws-‐‑‒iam プログラム IAM  Role メタデータ
  • 56. Agenda •  本資料料の対象 •  はじめに •  AWSを利利⽤用したスケーラブルな構成 •  その他、気をつけたいポイント •  まとめ
  • 57. しつこいですがこの構成… EC2 EC2 RDS AZ① AZ② Web App Web App ELB RDS ピーク・成⻑⾧長に 備えた構成 ElasticBeanstalkも要検討
  • 58. まとめ •  なるべく早めに「スケーラブルな構成」にしておけば、 急にやってくるアクセス集中にも、必要最⼩小限のコスト で対応できる •  もちろん数⼗十万、数百万ユーザ獲得のサービス成⻑⾧長にも 柔軟に対応できる(⼤大規模サービスも基本はコレ) •  データバックアップやシステム冗⻑⾧長化も容易易なので、 サービスの信頼性向上により顧客満⾜足度度も向上 なるべく早めの対策で安⼼心！
  • 59. [導⼊入に関しての問い合わせ]   http://aws.amazon.com/jp/contact-‐‑‒us/aws-‐‑‒sales/ [課⾦金金・請求内容、またはアカウントに関するお問い合わせ] https://aws.amazon.com/jp/contact-‐‑‒us/ お問い合わせ窓⼝口
  • 60. 資料料たくさんあります！ •  AWS  クラウドサービス活⽤用資料料集 –  http://aws.amazon.com/jp/aws-‐‑‒jp-‐‑‒introduction/
  • 61. 少々散らかっているのでBlogにまとめました
  • 62. 2015.06.02-‐‑‒03  Save  the  Date
  • 63. AWS  Summit  Tokyo  2015  トラック紹介 •  nanapiさま：⽇日本最⼤大の即レスサービス「アンサー」を⽀支えるAmazon •  Gunosyさま：サーバにログインしない・させないサービス運⽤用 •  StudyPlusさま：Auto  Scaling  x  Spot  Instances  による  　 　 　 　 　 　 　    スケーラビリティとコストカット事例例(仮) •  スマートニュースさま：SmartNews  のデータサイエンティストの  　 　 　 　 　 　 　 　 　 　 　⾼高速イテレーションを⽀支える広告システム •  クックパッドさま：なぜクックパッドは開発しやすいのか http://www.awssummit.tokyo/?id=takayam ↓ここからお申込みおなしゃす
  • 64. 公式Twitter/Facebook AWSの最新情報をお届けします @awscloud_jp 検索索 最新技術情報、イベント情報、お役⽴立立ち情報、 お得なキャンペーン情報などを⽇日々更更新しています！ もしくは http://on.fb.me/1vR8yWm
  • 65. ありがとうございました。