スタートアップならおさえておきたいAWS入門@TECH LAB PAAK 20160307
•
11 gefällt mir•2,155 views
http://peatix.com/event/152608/ での登壇資料です。スタートアップでシステム作ろうとされている方はぜひ。
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von akitsukada
Mehr von akitsukada (20)
スタートアップならおさえておきたいAWS入門@TECH LAB PAAK 20160307
- 1. スタートアップなら おさえておきたいAWS⼊入⾨門 Akihiro Tsukada @akitsukada AWS Japan Solutions Architect
- 2. 2 AWSでの担当 スタートアップのお客様 モバイル系ソリューション サーバレスアーキテクチャ 低コストアーキテクチャ エンジニア的な属性 SI→Web→Startup(CTO)→AWS Ruby, iOS OOP, SOLID, KISS 好き ⼆二郎郎（桜台ホーム） ジャッキーチェン 妻と娘 塚⽥田 朗弘 @akitsukada
- 8. 8 初期のインフラ選定や設計の成否が及ぼすインパクト 年年 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
- 9. 9 初期のインフラ選定や設計の成否が及ぼすインパクト 年年 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で促進
- 10. 10
- 12. 12 スタートアップにとって不不可⽋欠なシステム設計ポイント 必要最⼩小限でシンプルである Keep It Simple, Stupid! Small Startは正義 ⾃自動的でスケーラブルである サービス急成⻑⾧長に耐えうるポテンシャル（=より適切切な設計）が必要 スケーラブルな設計とシンプルな設計は⽭矛盾しない 運⽤用コストをかけている暇などなく、⾃自動化は不不可⽋欠 機能の追加/変更更/削除が容易易であり、リカバリ可能である P/S Fit, P/M Fitの⼯工程や、グロースを⽀支える仮説検証サイクルを阻害して はならない コスト効率率率が⾼高い ⼈人的なコスト、⾦金金銭的なコスト、どちらもクラウド活⽤用で解決できる もちろん時には資⾦金金で時間を買うこともあるが、それすらもAWSであれば 容易易 例例：アプリケーションのパフォーマンスをチューニングするのではなく、 サーバーをよりよいものにスペックアップして負荷に対応する
- 13. 13 MVP -‐‑‒Minimum Viable Product-‐‑‒ ならこれでも⼗十分 全てを1台の低ス ペックサーバで ホストする Web/App Server Database EC2 静的なファイルの み（HTML/JS/CSS）で よいなら S3 の 静的ウェブサイト ホスティング機能 で S3 ちょっとだけ動的 なことがやりたけ ればAPI GWと Lambdaを使って ⼿手軽にAPIを API Gateway Lambda
- 14. 14 スケール可能で⼀一般的なアーキテクチャ例例 ELB EC2 S3 RDS Standby EC2Auto Scaling CloudFront AZ-‐‑‒1 AZ-‐‑‒2 EC2でWebサーバを ⽴立立てる ELBを使って複数の AZに分散させる Auto Scalingも使⽤用 RDSのMulti-‐‑‒AZで 可⽤用性向上 静的コンテンツは S3から配信 CloudFrontで キャッシュ
- 15. 15 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のスケールアップ/アウト で超⼤大規模でも捌いていける ただしアプリケーションがボトル ネックにならないような実装が必要 そこもある程度度ご相談にのれます スケールアップ/アウトは容易易に 設定可能
- 16. 16 ELB EC2 RDS Standby EC2Auto Scaling AZ-‐‑‒1 AZ-‐‑‒2 例例えば… S3 CloudFront ⼀一般的なアーキテクチャに必要要素を追加
- 17. 17 ELB EC2 RDS Standby EC2Auto Scaling AZ-‐‑‒1 AZ-‐‑‒2 SESを使って メール送信 SES S3 CloudFront ⼀一般的なアーキテクチャに必要要素を追加 SNSを使って モバイルプッシュSNS RedshiftからBI Redshift 例例えば…
- 18. 18 AZ-‐‑‒1 AZ-‐‑‒2 EB Env instances instances ELB Subnet Dev Subnet Auto Scaling group AZ-‐‑‒2 AZ-‐‑‒1 instances instances ELB Subnet Prod & Stage Subnet Auto Scaling group instances instances Auto Scaling group ELB EB Env EB Env Swap URL
- 19. 19 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 テスト実施中 ① ② ③
- 23. 23 Other Services API GatewayLambda S3 Cognito CloudFront アプリはS3から配信 されるHTML/JS、ま たはネイティブ実装 ELB/EC2を使わず API Gatewayと Lambdaで応答 スケーリング、 サーバ運⽤用は AWSに⼀一任 運⽤用/構築/開発から の解放 サーバーレスアーキテクチャ
- 24. 24 2-‐‑‒Tier ・認証API ・データ保存API Amazon Cognito （認証/認可） Amazon DynamoDB （データ保存） Web DB バッチ プッシュ通知 Amazon SNS Mpbile Push （プッシュ通知） プッシュ通知 AWS Lambda （イベント処理理） LB 従来 AWS Lambda （ロジック） Amazon RDS （DB） 2-‐‑‒Tier Architecture
- 25. 25 Followers 4. メタデータをDynamoDBに登録 -‐‑‒ タイトル、コメント等 1. 認証・認可 -‐‑‒ FBアプリと連携 6. Push通知 -‐‑‒ フレンドやフォロワーに通知 Cognito Mobile Analytics DynamoDB S3 SNS 7. 画像をポストしたことを Analyticsに登録 2. S3への画像アップロード 5. 結果をSNSへ通知 App with AWS Mobile SDK 3. 画像のリサイズ、 サムネイル⽣生成 アプリ から 写真閲覧 サーバーレス（2-‐‑‒Tier）な実装の例例: 写真共有アプリ
- 27. 27 メジャーな技術である 情報が多い 使える⼈人が多い 即戦⼒力力な⼈人をより採⽤用しやすい 事例例・実績が多く安定している アップデートは今なお多い！ カスタマイズしやすい よくも悪くも細かい制御ができる 場合によってはよりスケーラ ブルになりうる 超⼤大規模な場合、マネージドサービ スよりスピーディにスケールできる 可能性がある General Architecture Serverless Architecture 新規性、注⽬目度度が⾼高い 事例例として⾼高価値で露露出機会が多い Tech Companyとしてのプレゼン ス向上、ブランディングになる ベストプラクティスやエコシステム が成熟していない 運⽤用管理理/開発⼯工数が激減 性能⾒見見積もりや監視、低レイヤーの 実装から解放される よりビジネスにフォーカスできる 多くの場合コスト減になる コスト効率率率が⾮非常に⾼高い どちらを使えば？ 適材適所で 組み合わせを
- 29. 29 ユーザ認証 アクセスの認可 データの同期 ユーザ⾏行行動分析 メディアの管理理 メディアの配信 プッシュ通知の送信 モバイル アプリ 共有データの保存 AWS solutions for Mobile App Issues Amazon Cognito (Identity) AWS Identity and Access Management Amazon Cognito (Sync) Amazon Mobile Analytics AWS Lambda Amazon CloudFront (Device Detection) Amazon DynamoDB (Object Mapper) Amazon Kinesis (Recorder) Amazon SNS Mobile Push AWS Mobile SDK Amazon S3 Transfer Manager ストリームリアルタイムデータビジネスロジックの実⾏行行
- 32. 32 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 / ディスカッション ケーススタディ
- 34. 34 サーバーレス編 VidRoll様 ⾮非常に⾼高度度なパフォーマンスが 要求されるReal-‐‑‒time Biddingに API Gateway + Lambdaを活⽤用 Lambdaは動画広告のリアルタイ ム変換処理理にも EC2群の管理理にElastic Beanstalkを利利⽤用 インフラ⾯面を⼼心配せず必要な コードだけを書けばよくなった コードの再利利⽤用性も上がり、通 常8-‐‑‒10⼈人のエンジニアが必要 だった仕事を2-‐‑‒3⼈人でこなせるよ うに https://aws.amazon.com/solutions/case-studies/vidroll/
- 37. 37 構成管理理編 株式会社Retty様 10 Apps, 27 EnvsをEBで管理理 (2015.08現在) Auto ScalingもEB で設定し、負荷対策 は完全に⾃自動化 『OpsWorks, CloudFormation と ⽐比較して EB の利利点 は「プロビジョニン グ」と「デプロイ」 というアプリケー ションサーバーに必 須の機能が付いてい る事、代表的な実⾏行行 環境が選択できる事、 導⼊入が容易易である 事』 https://aws.amazon.com/jp/solutions/case-studies/retty/
- 38. 38 IoT/Big Data編 株式会社あきんどスシロー様 Amazon Kinesis を使⽤用した KineSushi という 仕組みを構築 各⽫皿センサーが検 知したデータをリ アルタイムで全店 舗からクラウドに アップロード Amazon Redshift で分析、Tableau 等で表⽰示 https://aws.amazon.com/jp/solutions/case-studies/akindo-sushiro/
- 42. 42 コスト削減編 株式会社ドリコム様 スポットインスタンスを⼤大 量量に扱う際の知⾒見見を共有 オートスケーリング設定も 併せて参考に 関連: 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
- 44. 44 Q&A ディスカッション
- 45. 45 Q: t2.nanoをMVP⽤用途で使うとして、どの程度度の規模までいける？ス ケールする場合はスケールアウトすればいい？ A: アプリケーション次第としか⾔言えないが、あくまでもMVPとして 仲間内とかごく限られた⼈人たち向けに公開する⽤用途と考えたほうがよ い。スケールする場合は、まずはスケールアップしたほうがよい。 Q: AWS Certificate ManagerをTokyoで使いたい。 A: CloudFrontを利利⽤用すればTokyoでも可能。 Q&A
- 46. スタートアップなら おさえておきたいAWS⼊入⾨門 Akihiro Tsukada @akitsukada AWS Japan Solutions Architect ご参加ありがとうございました 今後の勉強会テーマの ご要望やご意⾒見見 お待ちしております。 ▶ @akitsukada