Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

AWS Introduction for Startups

208 views

Published on

2016/08/31 TECH LAB PAAKでの勉強会資料です

Published in: Engineering
  • Be the first to comment

  • Be the first to like this

AWS Introduction for Startups

  1. 1. 事業の成功を⽀える AWSの使い⽅ 〜起業から宇宙まで〜 Akihiro Tsukada @akitsukada AWS Japan Solutions Architect
  2. 2. 2 AWSでの担当 スタートアップのお客様 モバイル系テクノロジー エンジニア的な属性 SI→Web→Startup(CTO) →AWS Ruby, iOS OOP, SOLID, KISS 好き ⼆郎(桜台ホーム) ジャッキーチェン 妻と娘 塚⽥ 朗弘 @akitsukada
  3. 3. 3 真に成⻑するシステムは 初期の設計が肝⼼ ↓ スタートアップのエンジニアとして それを実現しよう ↓ AWS SAとしてよりそれに特化して 数多くのシステムの成⻑を⽀えたい
  4. 4. TECHNICAL & BUSINESS SUPPORT Account Management Support Professional Services Solutions Architects Training & Certification Security & Pricing Reports Partner Ecosystem AWS MARKETPLACE Backup Big Data & HPC Business Apps Databases Development Industry Solutions Security APPLICATION SERVICES Queuing Notifications Search Orchestration Email ENTERPRISE APPS Virtual Desktops Storage Gateway Sharing & Collaboration Email & Calendaring Directories HYBRID CLOUD MANAGEMENT Backups Deployment Direct Connect Identity Federation Integrated Management SECURITY & MANAGEMENT Virtual Private Networks Identity & Access Encryption Keys Configuration Monitoring Dedicated INFRASTRUCTURE SERVICES Regions Availability Zones Compute Storage Databases SQL, NoSQL, Caching CDNNetworking PLATFORM SERVICES App Mobile & Web Front-end Functions Identity Data Store Real-time Development Containers Source Code Build Tools Deployment DevOps Mobile Sync Identity Push Notifications Mobile Analytics Mobile Backend Analytics Data Warehousing Hadoop Streaming Data Pipelines Machine Learning
  5. 5. TECHNICAL & BUSINESS SUPPORT Account Management Support Professional Services Solutions Architects Training & Certification Security & Pricing Reports Partner Ecosystem AWS MARKETPLACE Backup Big Data & HPC Business Apps Databases Development Industry Solutions Security APPLICATION SERVICES Queuing Notifications Search Orchestration Email ENTERPRISE APPS Virtual Desktops Storage Gateway Sharing & Collaboration Email & Calendaring Directories HYBRID CLOUD MANAGEMENT Backups Deployment Direct Connect Identity Federation Integrated Management SECURITY & MANAGEMENT Virtual Private Networks Identity & Access Encryption Keys Configuration Monitoring Dedicated INFRASTRUCTURE SERVICES Regions Availability Zones Compute Storage Databases SQL, NoSQL, Caching CDNNetworking PLATFORM SERVICES App Mobile & Web Front-end Functions Identity Data Store Real-time Development Containers Source Code Build Tools Deploymen t DevOps Mobile Sync Identity Push Notifications Mobile Analytics Mobile Backend Analytics Data Warehousing Hadoop Streaming Data Pipelines Machine Learning
  6. 6. Solutions Architects
  7. 7. Solutions Architects Solutions Architects!
  8. 8. 8 今、スタートアップが クラウドに求めるべきもの AWS スタートアップ アーキテクチャパターン マネージドサービスを使うべき理由 ケーススタディ Q&A / ディスカッション
  9. 9. 9 今、スタートアップが クラウドに求めるべきもの AWS スタートアップ アーキテクチャパターン マネージドサービスを使うべき理由 ケーススタディ Q&A / ディスカッション
  10. 10. 10 拡張性 -Scalability- 柔軟性 -Flexibility- 経済性 -Low Cost- 採⽤/育成 -Hiring/Training- 敏捷性 -Agility-
  11. 11. 11 今、スタートアップがクラウドに求めるべきもの ビジネスと開発にフォーカスさせてくれる 余計なことはクラウドのサービスに任せる ⼈間は⼈間にしかできない仕事を 開発サイクルと事業成⻑を加速してくれる クラウドを加速器として使い、⾜かせにしない リーンスタートアップなど、事業/開発のベストプラクティスとの好相性 ⾮常に柔軟に新規構築や構成の拡張/変更、サービスの停⽌が可能 後から作り直す暇はなく、唯⼀の正義は「⾃分で作らないこと」である 合理的なマネージドサービス群をいかに活⽤するか エンジニアのキャリアとして優れている 優秀なエンジニアは⾃分にふさわしい場所に⾏く エンジニア⼈材市場規模の⼤きさと質 採⽤はいつだって最⼤の悩み 低コスト
  12. 12. 12 初期のインフラ選定や設計の成否が及ぼすインパクト 年 MAU 0 1 2 3 4 10,000 50,000 100,000 1,000,000 年 リ リ ス / 年 0 1 2 3 4 50 100 200 1,000 事業本来のポテンシャル スタートダッシュに失敗 年 選 考 数 / ⽉ 0 1 2 3 4 3 20 30 100
  13. 13. 13 初期のインフラ選定や設計の成否が及ぼすインパクト 年 MAU 0 1 2 3 4 10,000 50,000 100,000 1,000,000 年 リ リ ス / 年 0 1 2 3 4 50 100 200 1,000 事業本来のポテンシャル スタートダッシュに失敗 年 選 考 数 / ⽉ 0 1 2 3 4 3 20 30 100 MAU スタートアップが⽬指す急成⻑を⽀えられるスケールや パフォーマンスが提供されているのか? 単なるユーザ数やDL数だけでなく、DAU/MAUが増えてくると システムへの負荷はごまかせなくなる リリース 多くリリースできるということはスピードを出しやすいということ ビジネスの本質に関係ない作業をいかに無くせるか DevOps的な各要件が⼗分にサポートされているか 選考数 就職/転職は「だれと」「なにを」「いくらで」やるかのバランス感 「だれと」と「なにを」の部分はAWSで促進
  14. 14. 14
  15. 15. 15 今、スタートアップが クラウドに求めるべきもの AWS スタートアップ アーキテクチャパターン マネージドサービスを使うべき理由 ケーススタディ Q&A / ディスカッション
  16. 16. 16 スタートアップにとって不可⽋なシステム設計ポイント 必要最⼩限でシンプルである Keep It Simple, Stupid! Small Startは正義 ⾃動的でスケーラブルである サービス急成⻑に耐えうるポテンシャル(=より適切な設計)が 必要 スケーラブルな設計とシンプルな設計は⽭盾しない 運⽤コストをかけている暇などなく、⾃動化は不可⽋ 機能の追加/変更/削除が容易であり、リカバリ可能である P/S Fit, P/M Fitの⼯程や、グロースを⽀える仮説検証サイクル を阻害してはならない コスト効率が⾼い ⼈的なコスト、⾦銭的なコスト、どちらもクラウド活⽤で 解決できる
  17. 17. 17 MVP -Minimum Viable Product- ならこれで⼗分 全てを1台の低ス ペックサーバで ホストする Web/App Server Database EC2 静的なファイルの み(HTML/JS/CSS)で よいなら S3 の 静的ウェブサイト ホスティング機能 で S3 ちょっとだけ動的 なことがやりたけ ればAPI GWと Lambdaを使って ⼿軽にAPIを API Gateway Lambda
  18. 18. 18 スケーラブルなアーキテクチャ ELB EC2 S3 RDS Standby EC2Auto Scaling CloudFront AZ-1 AZ-2 EC2でWebサーバを ⽴てる ELBを使って複数の AZに分散させる Auto Scalingも使⽤ RDSのMulti-AZで 可⽤性向上 静的コンテンツは S3から配信 CloudFrontで キャッシュ
  19. 19. 19 ELB S3 Auto Scaling CloudFront AZ-1 AZ-2 EC2でWebサーバ を⽴てる ELBを使って複数 のAZに分散させる Auto Scalingも使⽤ RDSのMulti-AZで 可⽤性向上 静的コンテンツは S3から配信 CloudFrontで キャッシュ EC2 RDS Standby EC2 スケーラブルなアーキテクチャ 最初にこの構成を作ってしまえば、 EC2とRDSのスケールアップ/アウト で超⼤規模でも捌いていける ただしアプリケーションがボトル ネックにならないような実装が必要 そこもある程度ご相談にのれます スケールアップ/アウトは容易に 設定可能
  20. 20. 20 ELB EC2 RDS Standby EC2Auto Scaling AZ-1 AZ-2 例えば… S3 CloudFront 必要に応じて構成要素を追加
  21. 21. 21 ELB EC2 RDS Standby EC2Auto Scaling AZ-1 AZ-2 SESを使って メール送信 SES S3 CloudFront 必要に応じて構成要素を追加 SNSを使って モバイルプッシュSNS RedshiftからBI Redshift 例えば…
  22. 22. 22 AZ-1 AZ-2 EB Env instances instances ELB Subnet Dev Subnet Auto Scaling group instances instances ELB Subnet Prod & Stage Subnet Auto Scaling group instances instances Auto Scaling group ELB EB Env EB Env Swap URL AZ-2 AZ-1
  23. 23. 23 Elastic BeanstalkによるBlue/Green Deployment URL: jackie.com env-prod1 ⽤途: Staging URL: chan.com env-prod2 ⽤途: Production Amazon Route 53 CNAME(ALIAS): example.com → chan.com URL: jackie.com env-prod1 ⽤途: Staging URL: chan.com env-prod2 ⽤途: Production URL: chan.com env-prod1 ⽤途: Production URL: jackie.com env-prod2 ⽤途: Staging Developer End Users example.com テスト実施中 End Users example.com Developer テスト完了、Swap URL !! End Users example.com Developer テスト実施中 ① ② ③
  24. 24. クラウドファーストから クラウドネイティブへ
  25. 25. 25 AWSアーキテクチャ分類 アーキテク チャ バックエンド アクセス 利⽤するSDK 主な登場サービス群 General Web JSON on HTTP(S) ⼀般的な ネットワーク アクセスライブラリ Elastic Load Balancing(ELB), Amazon Elastic Compute Cloud(EC2), Amazon Relational Database Service(RDS) Serverless API GW, Lambda, DynamoDB, … API GW Call API GW SDK 2-Tier※ AWS API Call AWS SDK Lambda, DynamoDB, … (横断的) AWS API Call AWS SDK Cognito, S3, SNS, Device Farm, Mobile Analytics, Amazon Kinesis, … ※2-Tier Architecture は Serverless の⼀形態ですが、ここでは分けて話をします。
  26. 26. 26 AWSアーキテクチャ分類 アーキテク チャ バックエンド アクセス 利⽤するSDK 主な登場サービス群 General Web JSON on HTTP(S) ⼀般的な ネットワーク アクセスライブラリ Elastic Load Balancing(ELB), Amazon Elastic Compute Cloud(EC2), Amazon Relational Database Service(RDS) Serverless API GW, Lambda, DynamoDB, … API GW Call API GW SDK 2-Tier AWS API Call AWS SDK Lambda, DynamoDB, … (横断的) AWS API Call AWS SDK Cognito, S3, SNS, Device Farm, Mobile Analytics, Amazon Kinesis, … ① ② ③
  27. 27. 27 ① General Web Architecture クライアントは HTTP(S)でWebサーバと 通信 サーバサイドは ELB + EC2 + RDS といった基本構成 Elastic Load Balancing (ELB) Amazon Elastic Compute Cloud (EC2) Amazon Relational Database Service (RDS)
  28. 28. 28 ① General Web Architecture ‣ メリット ‣ クライアント側は従来のノウハウをフ ルに活かせる ‣ 実績が多く枯れた構成である ‣ カスタマイズ性が⾼い ‣ デメリット ‣ サーバのスペック、台数などインフラ を意識して設計する必要がある ‣ サーバの運⽤は利⽤者に任されている
  29. 29. 29 ② Serverless Architecture Amazon API Gateway (API GW) AWS Lambda (Lambda) Amazon DynamoDB (DynamoDB) Amazon Cognito (Cognito) クライアントアプリは必要に応じて Cognitoから⼀時的なCredentialsを 得た後、JSONでWeb APIと通信 サーバサイドは API GW/Lambda/DynamoDB といったマネージドサービスを⽤い、 EC2やELBを利⽤しない
  30. 30. 30 ② Serverless Architecture ‣ メリット ‣ クライアント側の実装は従来のノウハウを 活かせる ‣ サーバの運⽤、スケールはAWSに⼀任で きる ‣ CognitoによるセキュアなAPIアクセス制 御が可能 ‣ 多くの場合コスト効率が⾼い ‣ デメリット ‣ 新規性が⾼く、まだ枯れていない ‣ 個々のサービスのマネージドな部分はカス タマイズしにくい
  31. 31. 31 ③ 2-Tier Architecture Amazon Mobile Analytics (MA) Lambda DynamoDB Cognito クライアントアプリはCognitoから Temporary Credentialsを得た後、 AWS SDKを通じて各AWSリソース のAPIを直接叩く サーバサイドは各AWSリソースを セッティングしておくのみ (左図は⼀部の例) Amazon Kinesis (Kinesis) ※Serverlessの⼀形態
  32. 32. 32 ③ 2-Tier Architecture ‣ メリット ‣ インフラの運⽤、スケールはAWSに⼀任できる ‣ 上限値の緩和申請は除く ‣ Cognitoによるセキュアなアクセス制御が可能 ‣ Web APIの設計が不要で⼿軽に使える ‣ 最⼩限のパーツを組み合わせて使うことができる ‣ 多くの場合コスト効率が⾼い ‣ デメリット ‣ 新規性が⾼く、まだ枯れていない ‣ クライアントサイドが各AWSリソースに依存する ‣ 個々のサービスのマネージドな部分はカスタマイ ズしにくい ※Serverlessの⼀形態
  33. 33. AWS Mobile Hub 所要時間数分で 2-Tierアーキテクチャを プロビジョニングし、 スターターアプリの ⾃動⽣成までするツール 2-Tier アーキテクチャ 管理コンソール AWS Mobile Hub Developer ③ 2-Tier Architecture ※Serverlessの⼀形態
  34. 34. どのアーキテクチャを採⽤すべきか?
  35. 35. どのアーキテクチャを採⽤すべきか? 三者択⼀でなく メリット/デメリットを ⾒て組み合わせを
  36. 36. 36 ?Mobile on AWS
  37. 37. Amazon Cognito (Cognito) Amazon DynamoDB (DynamoDB) Amazon Simple Storage Service (S3) Amazon SQS (SQS) Amazon SES (SES) モバイルに最適化 されたコネクタ モバイルに最適化 されたサービス AWS SDK for Android AWS Mobile SDK Amazon Mobile Analytics (Mobile Analytics) Amazon SNS Mobile Push (SNS) AWS SDK for iOS AWS SDK for Unity あなたの モバイルアプリ ゲーム ユーティリティ ファイナンス エンターテインメント AWS Lambda (Lambda) AWS Device Farm (Device Farm) Amazon API Gateway (API GW) AWS SDK for JavaScript ソーシャル AWSのモバイルサービス https://aws.amazon.com/jp/mobile/ Amazon CloudFront (CloudFront)
  38. 38. 38 ユーザ認証、アクセス認可 データの同期 ユーザ⾏動分析 メディアの管理 メディアの配信 プッシュ通知の送信 共有データの保存 モバイル アプリ Amazon Cognito (Identity, Userpools) Amazon Cognito (Sync) Amazon Mobile Analytics AWS Lambda Amazon CloudFront (Device Detection) Amazon DynamoDB Amazon SNS Mobile PushAWS Mobile SDK Amazon S3 Transfer Manager ビジネスロジックの実⾏ 実機テストの並列実⾏ AWS DeviceFarm AWSのモバイルサービス https://aws.amazon.com/jp/mobile/ Amazon API Gateway RESTful APIサーバ
  39. 39. 39 今、スタートアップが クラウドに求めるべきもの AWS スタートアップ アーキテクチャパターン マネージドサービスを使うべき理由 ケーススタディ Q&A / ディスカッション
  40. 40. 付加価値を⽣ まない重労働
  41. 41. どうやって差別化するか
  42. 42. 42 アプリ開発、とくに差別化のため の開発に集中したい
  43. 43. 43 「ビジネス価値に直結しない必須要件」はAWSに任せる ユーザー登録・ログイン機能 → Amazon Cognito モバイルプッシュ通知機能 → Amazon SNS モニタリング・アラート → Amazon CloudWatch & SNS ログ収集機能 → CloudWatch Logs & S3 RDBMS → Amazon RDS CDN → Amazon CloudFront Docker運⽤したい → Amazon ECS / Elastic Beanstalk マシンラーニング → Amazon Machine Learning リアルタイム分析したい → Spark on Amazon EMR etc…
  44. 44. 44 例えばRDS相当の機能、⾃分でやりますか? 5分前までのPITR ⽇次バックアップ & 設定保存期間 バックアップからの復元 ⾃アカウントのEC2からしかアクセスさせないFirewall 数分でSlave DBを5台増設 各種メトリクスを⾃動取得 アラートメール、AWS Lambdaへのフック 数分で別DCクラスタにHot Stand-by DBを構築 Master DBに障害が発⽣したときに1分でFail Over 数分でインスタンスをスペックアップ etc…
  45. 45. 45 全てを運⽤するには⼈⽣は短すぎる ⾃分で作らないことが唯⼀の正義 その分の労⼒はサービス開発に まわして事業の成⻑にあてる
  46. 46. 46 Focus your Business on AWS
  47. 47. 47 今、スタートアップが クラウドに求めるべきもの AWS スタートアップ アーキテクチャパターン マネージドサービスを使うべき理由 ケーススタディ Q&A / ディスカッション
  48. 48. 48 Gunosy ニュースパス
  49. 49. 49 Cognito Syncによるサーバレスなユーザー管理 Amazon CognitoMobile Client 設定値 Key1: value1 Key2: value2 … Push System CognitoSyncで LocalとAWS上 を同期 AWS Lambda Queue On SQS Amazon SNS その他要望に合わせて 配送先を追加 Syncイベントをフック Pushシステム側で Dequeue => DB登録 Amazon Elasticsearch Service
  50. 50. 50 Kinesisによるログ管理フロー Mobile Client Amazon Kinesis Client側でBuffering PutRecordsで まとめて送信 Log Log Log Log AWS Lambda ログ用S3 Amazon EMR Spark Streaming Amazon RDS Amazon EMR Hive / Presto リアルタイム集計 バッチ集計
  51. 51. 51 NASA/JPL キュリオシティ
  52. 52. 52 NASA/JPL はほんの数週間で、ウェブホス ティングおよびライブ動画ストリーミングソ リューションを設計、構築、テスト、デプロ イすることができました。 Adobe Flash Media Server、nginx キャッ シュ層を実⾏するAmazon EC2、ELB、 Amazon Route 53、Amazon CloudFront を組み合わせて開発 着陸の少し前に、NASA/JPL はそれぞれ 25 Gbps のトラフィックを処理できる AWS イ ンフラストラクチャのスタックを⽤意しまし た。 Amazon CloudWatch を使⽤して、トラ フィック量の急上昇を監視し、リージョンの 需要に基づいて追加の容量をプロビジョニン グしました。 着陸後、トラフィック量が通常の量に戻ると、 NASA/JPL は AWS CloudFormation を使 ⽤して、1 つのコマンドでリソースのプロビ ジョニングを解除しました。 https://aws.amazon.com/jp/solutions/case-studies/nasa-jpl-curiosity/
  53. 53. 53 https://mars.jpl.nasa.gov は、 Amazon EC2 上で実⾏するオープン ソースのコンテンツ管理システム Railoベース Amazon Relational Database Service(RDS)によって管理された 可⽤性の⾼い Multi-AZ MySQL デー タベース Amazon Route 53の重み付け分散で 多数の Elastic Load Balancing にト ラフィックの分散 Amazon CloudFront を使⽤して世 界中のアクセスポイントにトラ フィックを拡⼤
  54. 54. 54 https://aws.amazon.com/jp/swf/testimonials/swfnasa
  55. 55. 55 ⾼可⽤性: ミッションクリティカルな運⽤をサポートするため スケーラブル: Amazon EC2 インスタンスから発⽣する数百 の処理を同時に実⾏するため ⼀貫性: スケジュールされたタスクはきわめて⾼い確度で 1 回 実⾏されることが必要表現⼒: 開発を進めやすいように、複雑 なワークフローを簡潔に表現できること 柔軟性: Amazon EC2 以外のワークフローも実⾏可能で、タ スクのルーティングができること パフォーマンス: 最⼩限の遅延でタスクをスケジューリング https://aws.amazon.com/jp/swf/testimonials/swfnasa
  56. 56. 56 まとめ
  57. 57. 57 まとめ 0-1, 1-10, 10-100, 100-1000, 1000-*… AWSの技術は事業の全フェーズを無駄なくカバー可能 AWSは事業スピードを加速する装置。Focus Your Business on AWS ! 技術的にもコスト的にも、各フェーズに最適な選択肢があります マネージドサービスをうまく使って事業に集中 使い⽅に迷ったら ググる(情報鮮度に注意) コミュニティで解決する(JAWS-UG) ソリューションアーキテクト!
  58. 58. 58 今、スタートアップが クラウドに求めるべきもの AWS スタートアップ アーキテクチャパターン マネージドサービスを使うべき理由 ケーススタディ Q&A / ディスカッション
  59. 59. 59 Q&A ディスカッション
  60. 60. 60 お知らせ
  61. 61. 61 http://aws-startup-sec-talks-20160901.peatix.com/
  62. 62. 62 AWS Black Belt Online Seminarのご案内 AWSJ の Tech メンバーがAWSに関する様々な事を ⽇本語で紹介・解説する無料のオンラインセミナー AWSについてもっと勉強したい⽅にオススメ! AWS イベント 検索
  63. 63. Akihiro Tsukada @akitsukada AWS Japan Solutions Architect ご参加ありがとうございました 今後の勉強会テーマの ご要望やご意⾒ お待ちしております。 ▶ @akitsukada
  64. 64. 64 Appendix
  65. 65. 65 1. プッシュ通知 1. 株式会社みんなのウェディン グ様 2. サーバーレス編 1. VidRoll様 2. Cookpad株式会社様 3. リアルタイム/チャット編 1. ChatWork株式会社様 4. 構成管理編 1. 株式会社Retty様 5. IoT編 1. 株式会社あきんどスシロー様 6. モバイルサービス編 1. 株式会社トランスリミット様 2. 株式会社Timers様 3. 株式会社Gunosy様 7. コスト削減編 1. 株式会社ドリコム様 8. Q&A / Q&A / ディスカッ ション ケーススタディ補⾜
  66. 66. 66 ベストプラクティス実践編 株式会社みんなのウェディング様 ベストプラクティスに 則った基本構成 「成熟したノウハウが ⼊⼿しやすい」「当社 エンジニアの今後の キャリア形成にとって、 ⼤きくプラスになる」 MySQLをRDS for MySQLにしたことで運 ⽤コストを下げ、専任 DBA不在でも運⽤可能 に https://aws.amazon.com/jp/solutions/case-studies/minnano-wedding/
  67. 67. 67 サーバーレス編 VidRoll様 ⾮常に⾼度なパフォーマンスが 要求されるReal-time Biddingに API Gateway + Lambdaを活⽤ Lambdaは動画広告のリアルタイ ム変換処理にも EC2群の管理にElastic Beanstalkを利⽤ インフラ⾯を⼼配せず必要な コードだけを書けばよくなった コードの再利⽤性も上がり、通 常8-10⼈のエンジニアが必要 だった仕事を2-3⼈でこなせるよ うに https://aws.amazon.com/solutions/case-studies/vidroll/
  68. 68. 68 サーバーレス編 Cookpad株式会社様 料理動画の変換処理部分 に着⽬ S3への元ファイルアップ ロード→複数形指揮への 変換処理→配信 まで、 状態管理⽤のサーバはあ るものの基本的にはS3と Elastic Transcoder、 CloudFrontで実現 マネージドサービス利⽤ の好例 http://techlife.cookpad.com/entry/2014/06/17/160905 「料理動画を支える技術 - クックパッド開発者ブログ」
  69. 69. 69 リアルタイム/Chat編 ChatWork株式会社様 メッセージ検索部分に CloudSearchを活⽤、数億 を超えるメッセージを確実 に扱うためマネージドサー ビスを選択 チャット履歴は⼀旦 DynamoDBに⼊り、その 後SQSを経て並列処理によ り⾼速Indexing 「ビジネス」サポートを利 ⽤、「障害発⽣時のフォ ローだけでなく、アーキテ クチャー選定や具体的な実 装⽅法についても相談でき て助かる」 https://aws.amazon.com/jp/solutions/case-studies/chatwork/
  70. 70. 70 構成管理編 株式会社Retty様 10 Apps, 27 EnvsをEBで管理 (2015.08現在) Auto ScalingもEB で設定し、負荷対策 は完全に⾃動化 『OpsWorks, CloudFormation と ⽐較して EB の利点 は「プロビジョニン グ」と「デプロイ」 というアプリケー ションサーバーに必 須の機能が付いてい る事、代表的な実⾏ 環境が選択できる事、 導⼊が容易である 事』 https://aws.amazon.com/jp/solutions/case-studies/retty/
  71. 71. 71 IoT/Big Data編 株式会社あきんどスシロー様 Amazon Kinesis を使⽤した KineSushi という 仕組みを構築 各⽫センサーが検 知したデータをリ アルタイムで全店 舗からクラウドに アップロード Amazon Redshift で分析、Tableau 等で表⽰ https://aws.amazon.com/jp/solutions/case-studies/akindo-sushiro/
  72. 72. 72 モバイルサービス編 株式会社トランスリミット様 Mobileアプリの認 証にCognitoを利 ⽤ 可能な限りサーバ レス・マネージド な構成で低コスト に イベントなど、必 要なときだけサー バを⽴てて対応 http://www.slideshare.net/matsukaz/brain-dots-at-dots-brain-dots
  73. 73. 73 モバイルサービス編 株式会社Timers様 各デバイスから動画をアッ プロードするとき、サーバ を介さず直接S3に サーバの運⽤、負荷、 コストは⼼配無⽤に サーバがS3からアップロー ド通知(SNS)を受け取っ て、デバイスに通知 Multi-part Upload時は それぞれ通知がくるこ とに注意 http://www.slideshare.net/AhmadShiina1/s3sns
  74. 74. 74 モバイルサービス編 株式会社Gunosy様 「定時プッシュ」と 「速報プッシュ」の ⼆種類に関する設計 ノウハウ ⼤量のendpointを取 得する処理をSQL ベースからS3ベース に変えたことで10分 →15秒と⼤幅に⾼速 化 ハマったポイントと ベストプラクティス など、実際の運⽤経 験から会得された貴 重な知⾒ https://speakerdeck.com/toshimaru/900mo-daunrodoapuri-gunosy-wozhi-eruda-gui-mo-mobairuputusiyutong-zhi-ji-pan-1
  75. 75. 75 コスト削減編 株式会社ドリコム様 スポットインスタンスを⼤ 量に扱う際の知⾒を共有 オートスケーリング設定も 併せて参考に 関連: AutoScalingの閾値調 整についてはAWS Black Belt Tech Webinarの資料も ご⼀読を http://www.slideshare.net/Ama zonWebServicesJapan/aws- black-belt-tech-2015-amazon- ec2-auto-scaling http://www.slideshare.net/GedowFather/gedow-style-aws-spot-instance

×