Upgrade to Pro — share decks privately, control downloads, hide ads and more …

シード期のスタートアップがクラウドネイティブにサービスを開発するために

 シード期のスタートアップがクラウドネイティブにサービスを開発するために

AWS Startup CTO Dojo
https://pages.awscloud.com/startup-cto-dojo-july_reg.html
2022年7月27日 (水)
「1. 創業期のスタートアップのための技術セッション(基礎編)」

はまーん

July 27, 2022
Tweet

More Decks by はまーん

Other Decks in Technology

Transcript

  1. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Shinichi Hama / track3jyo Startup Solutions Architect, West Japan Amazon Web Services Japan G.K. シード期のスタートアップが クラウドネイティブに サービスを開発するために for AWS Startup CTO Dojo
  2. Shinichi Hama / track3jyo Startup Solutions Architect Amazon Web Service

    Japan --- work: - ⻄⽇本のスタートアップ⽀援 - コンテナ技術のあれこれ 過去のスライド: https://speakerdeck.com/track3jyo 趣味︓家のアーキテクチャを考えること
  3. • 分かっているつもりで出来ていないスタートアップは多い • 本質的なところ以外 or その周辺でやるべきことが増える • セキュリティ / コンプライアンス対応

    • ログの収集、集約、⻑期保存 • バックオフィスの改善、効率化、インテグレーション • 組織の拡⼤によりオーバーヘッドも増える ビジネスにフォーカスする
  4. 幅広い機能︓200 以上のサービスを提供 ネットワーク アナリティクス コンピュート ストレージ & 配信 開発ツール 管理ツール

    セキュリティ アプリケーションインテグレーション モバイルサービス データベース IoT 機械学習 ゲーム Amazon EMR Amazon Kinesis Amazon Athena AWS Glue Amazon Elasticsearch Amazon Redshift Amazon QuickSight AWS Data Pipeline Amazon SNS Amazon SQS Amazon MQ AWS AppSync AWS Step Functions ELB AWS Elastic Beanstalk AWS Lambda Amazon EC2 Amazon ECS Amazon Aurora Amazon DynamoDB Amazon ElastiCache Amazon Redshift AWS DMS Amazon Neptune Amazon RDS AWS CodeBuild AWS CodeCommit AWS CodeDeploy AWS CodePipeline Amazon GameLift Amazon FreeRTOS AWS IoT Analytics AWS IoT Core AWS IoT Device Defender AWS IoT Greengrass Amazon Forecast Amazon Polly Amazon Rekognition Amazon SageMaker Amazon Translate Amazon CloudWatch AWS Auto Scaling AWS CloudFormation AWS CloudTrail AWS Config AWS Managed Services Amazon API Gateway AWS Amplify AWS AppSync AWS Device Farm Amazon Route 53 Amazon VPC AWS Direct Connect Amazon GuardDuty Amazon Inspector Amazon Cognito AWS Organizations AWS KMS AWS IAM Amazon EFS Amazon S3 AWS Snowball AWS Storage Gateway Amazon FSx Amazon EBS
  5. • 全⽂検索エンジン • リアルタイムコミュニケーション(WebRTC) • ライブ動画配信 • レコメンデーション • モバイル

    / Web アプリ ビジネス要件に対して、最適なサービスを選ぶことが出来る Amazon OpenSearch Service Amazon Chime SDK Amazon Interactive Video Service Amazon Personalize AWS Amplify 今必要な機能だけでなく、ピボットや将来の機能拡張にも対応することが出来る
  6. S-Curve で⾒るフェーズごとの技術課題、特性の⼀例 Stage Growth Seed Eealy Mid Later スピード コスト効率

    AI/ML (API) カスタマーサポート バックオフィス スケーラビリティ、安定性、可⽤性 ログ分析 AI/ML (Custom) セキュリティ コンプライアンス カスタマーエンゲージメント ※ 詳細な要素、タイミングは ケースバイケースで異なります
  7. S-Curve で⾒るフェーズごとの技術課題、特性の⼀例 Stage Growth Seed Eealy Mid Later スピード コスト効率

    AI/ML (API) カスタマーサポート バックオフィス スケーラビリティ、安定性、可⽤性 ログ分析 AI/ML (Custom) セキュリティ コンプライアンス カスタマーエンゲージメント ※ 詳細な要素、タイミングは ケースバイケースで異なります AWS Amplify, Amazon Lightsail, Serverless Services, AWS Fargate etc AWS Amplify, AWS Activate, AWS Savings Plan, Spot Instances etc Amazon Forecast etc Amazon SageMaker Amazon Pinpoint, Amazon Personalize etc Amazon Connect, Amazon Lex etc AWS Amplify, Serverless Services, Auto Scaling etc Amazon S3, AWS Glue, Amazon Athena etc Amazon WorkSpaces, AWS SSO etc AWS IAM, Amazon GuardDuty etc AWS CloudTrail etc
  8. 成⻑に応じて起こること – Seed(創業期) - • 「とにかく早く作りたい、お⾦もまだない」 • いかに早く MVP を作るか

    • いかに早くフィードバックループを回すか • 余計な⼯数はかけていられない • 余計なコストもかけていられない あくまでスピードとコスト効率を意識しつつ ⼿軽に対応できるならやらない⼿はない
  9. アイデアの実現の過程には 「差別化に繋がらない重労働」 が多く存在し、それらを減らすことができれ ば成功確率を上げることが出来る(意訳) • Web 2.0 Summit での Tim

    O’Reilly と Jeff Bezos との対談 https://www.flickr.com/photos/farber/292880154 Amazon CTO の Werner Vogels も メディア取材の際に 「Stop spending money on “undifferentiated heavy lifting”」 とコメント Undifferentiated heavy lifting
  10. システム運⽤における Undifferentiated Heavy Lifting の例 • データベースの運⽤、バックアップ、レプリケーション設定 • 認証基盤の保守、管理、運⽤ •

    リアルタイム通信を⾏うサーバーの保守、管理、運⽤ • セキュリティパッチの管理、適⽤ • etc...
  11. Undifferentiated heavy lifting Main 例︓データベース M S Replica レプリケーション Application

    Backup 定期取得 フェイルオーバー 上記以外 • ストレージ容量の確保 • パフォーマンスモニタリング • パッチ適⽤、監視設定 例︓ビデオ通話機能 配信サーバー 配信サーバー 接続先管理⽤ データベース • 配信サーバーのチューニング • 配信サーバーのスケーリング • 配信サーバーのパッチ適⽤ • 接続先の管理、ハンドリング 本当にやりたいのは、これらを⽤いた プロダクト開発 や 機能追加、あるいは それらを通した プロダクトの価値向上 のはず
  12. Undifferentiated heavy lifting Master 例︓データベース M S Slave レプリケーション Application

    Backup 定期取 得 フェイルオーバー 上記以外 • ストレージ容量の確保 • パフォーマンスモニタリング • パッチ適⽤、監視設定 例︓ビデオ通話機能 配信サーバー 配信サーバー 接続先管理⽤ データベース • 配信サーバーのチューニング • 配信サーバーのスケーリング • 配信サーバーのパッチ適⽤ • 接続先の管理、ハンドリング 本当にやりたいのは、これらを⽤いた プロダクト開発 や 機能追加、あるいは それらを通した プロダクトの価値向上 のはず Amazon Aurora Amazon Chime SDK
  13. ⽬の前の判断が Two-way Door なものではないか考える • 逆に、「それ試しにやってから後で変えることもできるよね」という 要素(=Two-way Door)では時間を使いすぎずに意思決定する − 「試しにやる」ハードルを下げる

    • ⽬の前の決断が One-way door なのか Two-way door なのか⾒極める − Two-way door なのに無駄に時間をかけていないか︖ • 少しの⼯夫で Two-way door な状況に出来ないか︖ • 実は⾃分が知らないだけではないのか︖
  14. connect DevAx © 2021, Amazon Web Services, Inc. or its

    affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Everything fails all the time Dr. Werner Vogels Chief Technology Officer of Amazon.com
  15. connect DevAx © 2021, Amazon Web Services, Inc. or its

    affiliates. All rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Design for Failure To Your Application
  16. 創業期スタートアップ向け「まずここから」Design for Failure • 想定上のアクセスが来てもダウンしない 冗⻑構成 (マルチAZ)/オートスケーリング • 問題のあるインフラがあっても置き換えてくれる オートヒーリング

    • データを誤って消しちゃった時にでも復旧できる バックアップ・リストア • (+α) アプリケーションがエラーになった際の リトライ処理やキューイング
  17. Design for Failure な設計になっていないとどうなるか︖ • 例1: ⼤事な時(e.g. VC へデモを⾒せる時等) にダウンし

    ていることによる機会損失 • 例2: メンバーも少ないため、その都度発⽣する障害対応 だけで1⽇が過ぎてしまう
  18. シード期において、Design for Failure を実現するために Q. 時間のないシード期のスタートアップにとって、Design for Failure を真⾯⽬に全て向き合うのは難しいのでは︖ •

    まずは、Design for Failure な設計が組み込まれたサービスを最初か ら選定できないか考える • スピードとコストとのトレードオフではない • むしろ対応に追われる⼯数がなくなりスピードアップ • 実装やアーキテクチャに依存するところはその先で考える • AWS の SA に相談も︕
  19. オーソドックスな技術スタック フロントエンド、 モバイルアプリ バックエンド Webサーバー バックエンド DBサーバー ⾔語・フレームワーク React, Vue,

    Swift, Kotlin, Java etc インフラ Web Hosting サービス、 BaaS etc ⾔語・フレームワーク Ruby on Rails, Laravel, Django, Express, Spring etc インフラ 仮想サーバー、コンテナ、 サーバーレス etc DB 種類 RDBMS, NoSQL, Fulltext Search, etc インフラ マネージドDBサービス, 仮想サーバー etc
  20. AWS Amplify の 4 つのコンポーネント Web やモバイルアプリ ケーションを⼀般的な ユースケースベースのガ イド付きワークフローで

    バックエンドを簡単に作 成、管理するツール Amplify CLI Web やモバイルアプリ ケーションと AWS を統 合するためのユースケー ス中⼼のライブラリ Amplify Libraries 継続的デプロイメントを 管理し、モダンな Web アプリケーションをビル ド、テスト、デプロイ、 そしてホスティングする ための AWS サービス Amplify Hosting AWS 上に最⼩限のコー ディングでフロントから バックまでのアプリケー ションを作成できるビ ジュアルな開発環境 Amplify Studio
  21. AWS Amplify の 4 つのコンポーネント Web やモバイルアプリ ケーションを⼀般的な ユースケースベースのガ イド付きワークフローで

    バックエンドを簡単に作 成、管理するツール Amplify CLI Web やモバイルアプリ ケーションと AWS を統 合するためのユースケー ス中⼼のライブラリ Amplify Libraries 継続的デプロイメントを 管理し、モダンな Web アプリケーションをビル ド、テスト、デプロイ、 そしてホスティングする ための AWS サービス Amplify Hosting AWS 上に最⼩限のコー ディングでフロントから バックまでのアプリケー ションを作成できるビ ジュアルな開発環境 Amplify Studio
  22. Amplify Hosting - Pull Request Previews https://docs.aws.amazon.com/amplify/latest/userguide/pr-previews.html Pull Request が作成されるたびに⼀時的

    なウェブサイトをホスト ホストした URL を Git Hub の Pull Request ページに載せる ⾮エンジニア職でも気軽に Pull Request レビューに参加することが可能に Pull Request が閉じたら⼀時的なウェブ サイトもクローズ
  23. もっと AWS Amplify を知りたい⽅へ 公式ドキュメント https://docs.amplify.aws AWS Summit 2021 「Web・モバイルアプリ開発を加速させる

    AWS Amplify」 https://d1.awsstatic.com/events/jp/2021/summit-online/AWS- 47_AWS_Summit_Online_2021_FWM01.pdf ワークショップ https://amplify-sns.workshop.aws/ja/ Amplify 学習リソース集 https://aws-amplify-jp.github.io/resources Amplify Japan User Group Slack https://github.com/aws-amplify-jp/awesome-aws-amplify-ja#slack
  24. AWS purpose-built database 従来のアプリ ケーション、ERP、 CRM、e コマース トラフィックの 多いウェブアプ リ、e

    コマースシ ステム、ゲーム アプリケーショ ン コンテンツ管理、 カタログ、ユー ザープロファイ ル キャッシュ、 セッション管理、 ゲームのリー ダーボード、地 理空間アプリ ケーション 不正検出、ソー シャルネット ワーク、レコメ ンデーションエ ンジン IoT アプリケー ション、DevOps、 産業テレメトリ 記録システム、 サプライチェー ン、銀⾏トラン ザクション 産業⽤機器のメ ンテナンス、取 引監視、フリー ト管理、ルート 最適化
  25. フルマネージド化による管理負荷の軽減 拡張性 ⾼可⽤性 DB バックアップ DB パッチ適⽤ DB インストール/構築 OS

    パッチ適⽤ OS インストール サーバーメンテナンス ハードウェア資産管理 電源/ネットワーク/空調 お客様 スキーマのデザイン クエリの作成 データベースの最適化 AWS 時間のかかる データベース管理タスクから解放され、 アプリケーションやビジネスに集中できる アプリケーション最適化
  26. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. データベース運⽤負荷の軽減 ストレージ⾃動拡張① 分散ストレージシステム SQL トランザクション キャッシュ ライターインスタンス SQL トランザクション キャッシュ リーダーインスタンス リーダーインスタンス SQL トランザクション キャッシュ データが 増えた︕
  27. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. データベース運⽤負荷の軽減 ストレージ⾃動拡張② 分散ストレージシステム SQL トランザクション キャッシュ ライターインスタンス SQL トランザクション キャッシュ リーダーインスタンス リーダーインスタンス SQL トランザクション キャッシュ 10GB単位で128TBまで⾃動的に拡張
  28. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. バックアップ⾃動化 分散ストレージシステム SQL トランザクション キャッシュ ライターインスタンス SQL トランザクション キャッシュ リーダーインスタンス リーダーインスタンス SQL トランザクション キャッシュ Amazon Simple Storage Service (Amazon S3) 継続的な増分バックアップ ・バックアップ保持期間は1〜35⽇ ・保持期間内の任意の時点に復元できる
  29. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. サーバレスデータベースとして ワークロードの拡⼤
  30. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Amazon Aurora Serverless v2 アプリケーションのニーズに応じて⾃動的に容量を拡張 インスタンスタイプの⼀つとして簡単なセットアップ 秒単位のシンプルな従量課⾦ 瞬時に拡張し、要求の厳しいアプリケーションをサポート データベースのキャパシティ管理の⼼配からの解放
  31. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 急激なアクセス増減対応の選択肢 Storage fleet ⾃動スケール Amazon Aurora Serverless v2
  32. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 急激なアクセス増減対応の選択肢 Storage fleet Compute fleet ⾃動スケール ⾃動スケール Amazon Aurora Serverless v2
  33. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 急激なアクセス増減対応の選択肢 Storage fleet Compute fleet ⾃動スケール ⾃動スケール Amazon Aurora Serverless v2 • インプレーススケール:CPUやメモリのリ ソースなどを動的に追加することで、1秒以 内にスケーリングが可能 • パフォーマンス影響なし:数十万トランザク ションを実行中でも、スケーリングによる影 響はない https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is- generally-available-instant-scaling-for-demanding-workloads/
  34. © 2022, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. Aurora Serverless v2 のシームレスなスケーリング Aurora Serverless v2 のスケーリング例 (定期的に同時実⾏数を上げながら OLTP 処理を実施) 同時実⾏数 が増加 同時実⾏数 が増加 同時実⾏数 が増加 処理終了 同時実⾏数が増加して、必要なリソースが 増加した時点で、Aurora Serverless v2の キャパシティが増加(⻘線) また、スケール時にトランザクション (⾚線のCommitThroughput)を阻害しない 処理が終了して、リソースが不要 になると徐々にキャパシティが 減少(⻘線)
  35. • スタートアップにとって⼤事なことはビジネスにフォーカ スできること • スタートアップが技術選定の際に考えるべきこと • Undifferentiated Heavy Lifting の排除

    • ⽬の前の判断が Two-way Door なものではないか⾒極める • まずは、Design for Failure な設計が組み込まれたサービ スを選定できないか考える さいごに – お伝えしたかったこと -
  36. Thank you © 2022, Amazon Web Services, Inc. or its

    affiliates. All rights reserved. Shinichi Hama track3jyo