シード期のスタートアップに知ってほしい技術のこと

AWSのStartup CTO向けイベントにて登壇した資料です。

Transcript

1. © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. シード期のスタートアップ に知ってほしい技術のこと Kouki Kishida Startup Solutions Architect Amazon Web Services Japan G.K.
2. シード期が直⾯する技術課題
3. S-Curve で⾒るフェーズごとの技術課題、特性の⼀例 Stage Growth Seed Early Mid Later PMFにより成⻑
4. S-Curve で⾒るフェーズごとの技術課題、特性の⼀例 Stage Growth Seed Early Mid Later MVP/PSF PMF Growth 最⼩限のプロダクトで アイデアと実現⽅法を 素早く評価、検証する トライ＆エラーの連続 素早くデータドリブンな フィードバックサイクルを 構築し、ユーザーが⾃動的に 増え続ける状態を⽬指す 指数関数的を成⻑を⽀える スケーラビリティ・柔軟性・拡張性が 機能的にも組織的にも必要となる # MVP … Minimum Viable Product # PSF … Problem Solution Fit # PMF … Product Market Fit
5. 成⻑に応じて起こること • 「とにかく早く作りたい、お⾦もまだない」 − いかに早く MVP を作るか − いかに早くフィードバックループを回すか − 余計な⼯数はかけていられない − 余計なコストもかけていられない あくまでスピードとコスト効率を意識しつつ ⼿軽に対応できるならやらない⼿はない
6. 成⻑に応じて起こること • 「フィードバックサイクルを安定化したい」 − 常にカスタマーの想いをバックログに取り込む − ユーザーがファンになるためのアイデアを数多く検証する − フィードバックサイクルの⾃動化・最適化を⾏う ユーザーをファンにする施策とフィードバックを より効率よく回していかなければ⾏けない
7. 成⻑に応じて起こること • 「急激なビジネス成⻑に備えたい」 − ビジネス成⻑に応じてスケーラビリティを⾒据えたい − 今のシステムの状態を検知するしくみをつくりたい 急激なビジネス成⻑に備えて 技術がブロッカーにならないように考慮する
8. シード期のスタートアップに 伝えたいAmazonの考え⽅
9. スタートアップがビジネスにフォーカスし、 成功確率を⾼めるための考え⽅ • ⽬の前の判断が Two-way Door なもの ではないか⾒極める • Undifferentiated Heavy Lifting の排除
10. スタートアップがビジネスにフォーカスし、 成功確率を⾼めるための考え⽅ • ⽬の前の判断が Two-way Door なもの ではないか⾒極める • Undifferentiated Heavy Lifting の排除
11. Is it a one-way or a two-way door?
12. 技術選定や設計における One-way Door Decisions • 全体に⼤きな影響を与え、後から変更することが難しいもの。これらはちゃん と考えて決めるべし。 「本当にそれで⼤丈夫か︖」 − データの置き場 − データベース設計 − クラウドプラットフォーム − etc...
13. ⽬の前の判断が Two-way Door なものではないか考える • 「それ試しにやってから後で変えることもできるよね」という 要素（=Two-way Door）では時間を使いすぎずに意思決定する − 「試しにやる」ハードルを下げる • ⽬の前の決断が One-way door なのか Two-way door なのか⾒極める − Two-way door なのに無駄に時間をかけていないか︖ • 少しの⼯夫で Two-way door な状況に出来ないか︖ − 実は⾃分が知らないだけではないのか︖
14. スタートアップがビジネスにフォーカスし、 成功確率を⾼めるための考え⽅ • ⽬の前の判断が Two-way Door なもの ではないか⾒極める • Undifferentiated Heavy Lifting の排除
15. Undifferentiated heavy lifting（差別化に繋がらない重労働） アイデアの実現の過程には「差別化に繋がらない重労働」 が多く存在し、それらを減らすことができれば成功確率を 上げることが出来る（意訳） 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”」 とコメント
16. システム運⽤における Undifferentiated Heavy Lifting の例 • データベースの運⽤、バックアップ、レプリケーション設定 • 認証基盤の保守、管理、運⽤ • リアルタイム通信を⾏うサーバーの保守、管理、運⽤ • セキュリティパッチの管理、適⽤ • etc...
17. Undifferentiated heavy lifting 例︓Webアプリケーション向けのAPI Webサーバー Webサーバー 本当にやりたいのは、これらを⽤いた プロダクト開発 や 機能追加、あるいは それらを通した プロダクトの価値向上 のはず ロードバランサー コンテナレジストリ VPC ビルド＆デプロイ 他にも・・・ ・構成の検証テスト ・負荷のモニタリング など・・・ クライアント
18. Undifferentiated heavy lifting 例︓Webアプリケーション向けのAPI Webサーバー Webサーバー 本当にやりたいのは、これらを⽤いた プロダクト開発 や 機能追加、あるいは それらを通した プロダクトの価値向上 のはず ロードバランサー コンテナレジストリ VPC ビルド＆デプロイ 他にも・・・ ・構成の検証テスト ・負荷のモニタリング など・・・ クライアント AWS App Runner
19. では課題に対しておさえて おくべき思考とは
20. S-Curve で⾒るフェーズごとの技術課題、特性の⼀例 Stage Growth Seed Early Mid Later MVP/PSF PMF Growth 最⼩限のプロダクトで アイデアと実現⽅法を 素早く評価、検証する トライ＆エラーの連続 素早くデータドリブンな フィードバックサイクルを 構築し、ユーザーが⾃動的に 増え続ける状態を⽬指す 指数関数的を成⻑を⽀える スケーラビリティ・柔軟性・拡張性が 機能的にも組織的にも必要となる # MVP … Minimum Viable Product # PSF … Problem Solution Fit # PMF … Product Market Fit
21. データドリブンにプロダクトの意思決定を反映する • MVPをつくるにあたって、すすめるかピボットかの判断基準と指標（KPI）は 明確ですか︖ − プロダクトのベーシView数が◦件/⽉を超えたらビジネスとして成り⽴つ − 新規ユーザーの離脱率が◦%を超えたら、定着率が低く改善が必要 • その指標（KPI）を測定するために、データを集めて評価をしてますか︖ − データを集め、会社全員がKPIの進捗状況を確認できる • 評価後、機能追加や改善を素早く⾏える仕組みはととのっていますか︖
22. Amazon Redshift Serverlessで データドリブンな意思決定をはじめよう デベロッパー データアナリスト データサイエンティスト アプリケーションのビルドと データ分析 ビジネスリーダー ビジネス上の意思決定と成果 Redshift Serverless インフラを意識すること なくすぐにデータ分析 現場の運⽤負担、 導⼊コストとリー ドタイムを軽減 データの提供に集中 Amazon Redshift Serverless とは ⼿軽に始めることのできる、データウェアハウ スのマネージドサービス。 各データ分析者が、インフラに意識をむけるこ となく分析を⾏い、ビジネスの意思決定につな げることができる。 データエンジニア ビジネス上の意思決定と成果
23. Amazon Redshift Serverlessの特徴 DWHクラスターを管理することなくデータ分析 の実⾏やスケーリングが可能に シンプルで使いやすい ⼀貫した⾼速なパフォーマンスを提供するため に、DWHの処理能⼒を⾃動的にプロビジョニン グしスケーリングする インテリジェントに⾃動でスケール Amazon Redshiftの豊富なSQLの機能やデータレ イクとのシームレスな統合、 業界をリードする価 格パフォーマンスをそのまま利⽤できる ⾼度な機能・性能はそのまま コンピュート料⾦はワークロードの継続時間に 応じて秒単位でのお⽀払い、アイドル時間の料 ⾦はかからない 使った分だけの課⾦
24. AWS アカウントで、Amazon Redshift Serverless 使⽤開始画⾯へ 1 デフォルト設定を確認して保存 数分で利⽤可能に 2 お好みのツール、または Amazon Redshift Query Editor で接続 3 Amazon Redshift Serverlessは簡単に始められる
25. Amazon QuickSightでKPIにそった進捗を確認する Amazon QuickSightとは • インタラクティブなダッシュボードを提供 • Redshiftを始めとしたリソースに簡単にアクセス • KPIの可視化を実現する柔軟なビジュアルパーツ • きめ細かなアクセス制限
26. Redshift Serverless & QuickSightをもっと知りたい⽅へ • 公式ドキュメント − https://docs.aws.amazon.com/ja_jp/redshift/latest/mgmt/working-with-serverless.html • Redshift Serverlessで今から始めるサーバーレスデータ分析環境 − https://pages.awscloud.com/rs/112-TZM- 766/images/20220728_20th_ISV_DiveDeepSeminar_Redshift_Serverless.pdf • Amazon QuickSightでかっこいいBIダッシュボードを作る⽅法 − https://pages.awscloud.com/rs/112-TZM-766/images/20220728_20th_ISV_DiveDeepSeminar_QuickSight.pdf • Redshift Serverless & QuickSightのハンズオン − https://pages.awscloud.com/JAPAN-launch-GC-RedshiftServerless_Handson-2022-reg.html • Amazon Redshift 運⽤管理 − https://pages.awscloud.com/rs/112-TZM-766/images/AWS-Black-Belt_2023_Amazon-Redshift- Management_0331_v1.pdf
27. S-Curve で⾒るフェーズごとの技術課題、特性の⼀例 Stage Growth Seed Early Mid Later MVP/PSF PMF Growth 最⼩限のプロダクトで アイデアと実現⽅法を 素早く評価、検証する トライ＆エラーの連続 素早くデータドリブンな フィードバックサイクルを 構築し、ユーザーが⾃動的に 増え続ける状態を⽬指す 指数関数的を成⻑を⽀える スケーラビリティ・柔軟性・拡張性が 機能的にも組織的にも必要となる # MVP … Minimum Viable Product # PSF … Problem Solution Fit # PMF … Product Market Fit
28. 指数関数的を成⻑を⽀えるスケーラビリティ・柔軟性・拡張性を 実現する • 今のシステムの状況を監視できていますか︖ − DDoS攻撃などのセキュリティインシデントをすぐに検知できる − CPUやメモリ等のリソース不⾜が起きたときにアラートがおきる • システムの状況に応じてスケールする仕組みはととのっていますか︖ − データベースのWrite数が急激に増えても耐える構成 − フェイルオーバー対策・バックアップを⾏い修復可能なしくみをつくる
29. 指数関数的を成⻑を⽀えるスケーラビリティ・柔軟性・拡張性を 実現する • 今のシステムの状況を監視できていますか︖ − DDoS攻撃などのセキュリティインシデントをすぐに検知できる − CPUやメモリ等のリソース不⾜が起きたときにアラートがおきる • システムの状況に応じてスケールする仕組みはととのっていますか︖ − データベースのWrite数が急激に増えても耐える構成 − フェイルオーバー対策・バックアップを⾏い修復可能なしくみをつくる
30. GuardDuty はとりあえず有効化する • セキュリティの観点から 脅威を検知するサービス • 機械学習、異常検出、脅威インテリジェンスを使⽤ • 数クリックで有効化可能 • 従量課⾦モデルで⼩さくスタート • 30⽇間の無料トライアルで料⾦試算が可能 • 例えば重要度が ⾼ の検出を トリガーに通知するなど 偵察 インスタンス の侵害 アカウントの 侵害 通常と異なる API アクティビティ 悪意のある既知の IP 通常と異な るポート ポートスキャン 通常と異なる トラフィック量 通常と異なるインスタンスまた はインフラストラクチャの起動 匿名化プロキシ 窃取された 認証情報の悪⽤ ビットコイン アクティビティ DNSを⽤いた不正通信 CloudTrail の無効化 RDP/SSH ブルートフォース Amazon GuardDuty
31. 困った時の RDS Performance Insights • 運⽤でよく起こりがちな RDB ワーク ロードのパフォーマンス最適化を お助け • 数クリックで RDS のパフォーマンス 情報を可視化 • ダッシュボードからドリルダウンして いき、原因となったクエリなどを特定 • 無料枠からスモールにスタートできる • 7 ⽇間分のパフォーマンスデータ履歴 • 1 か⽉あたり 100 万件のリクエスト
32. 指数関数的を成⻑を⽀えるスケーラビリティ・柔軟性・拡張性を 実現する • 今のシステムの状況を監視できていますか︖ − DDoS攻撃などのセキュリティインシデントをすぐに検知できる − CPUやメモリ等のリソース不⾜が起きたときにアラートがおきる • システムの状況に応じてスケールする仕組みはととのっていますか︖ − データベースのWrite数が急激に増えても耐える構成 − フェイルオーバー対策・バックアップを⾏い修復可能なしくみをつくる
33. Amazon Aurora Serverless v2で柔軟なビジネスニーズに対応する アプリケーションのニーズに応じて⾃動的に容量を拡張 インスタンスタイプの⼀つとして簡単なセットアップ 秒単位のシンプルな従量課⾦ 瞬時に拡張し、要求の厳しいアプリケーションをサポート データベースのキャパシティ管理の⼼配からの解放 Amazon Aurora Serverless v2 とは
34. Amazon Aurora Serverless v2 Storage fleet Compute fleet ⾃動スケール ⾃動スケール • インプレーススケール︓CPUやメモリのリ ソースなどを動的に追加することで、1秒以 内にスケーリングが可能 • パフォーマンス影響なし︓数⼗万トランザク ションを実⾏中でも、スケーリングによる影 響はない https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is- generally-available-instant-scaling-for-demanding-workloads/
35. Aurora Serverless v2 のシームレスなスケーリング Aurora Serverless v2 のスケーリング例 (定期的に同時実⾏数を上げながら OLTP 処理を実施) 同時実⾏数 が増加 同時実⾏数 が増加 同時実⾏数 が増加 処理終了 同時実⾏数が増加して、必要なリソースが 増加した時点で、Aurora Serverless v2の キャパシティが増加(⻘線) また、スケール時にトランザクション (⾚線のCommitThroughput)を阻害しない 処理が終了して、リソースが不要 になると徐々にキャパシティが 減少(⻘線)
36. 監視やAurora Serverless v2についてもっと知りたい⽅ • 公式ドキュメント • https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless- v2.html • ブログ • https://aws.amazon.com/jp/blogs/news/amazon-aurora-serverless-v2-is-generally- available-instant-scaling-for-demanding-workloads/ • Deep Dive • https://www.youtube.com/watch?time_continue=350&v=b2Tl6SsWC-M&feature=emb_title • 〜スタートアップの⼈たちに捧ぐ〜 監視再⼊⾨ in AWS • https://speakerdeck.com/track3jyo/startup-monitoring-aws2022
37. 本⽇のまとめ • シード期のスタートアップにはTwo-way doorかどうかの⾒極めと 、ビジネス価値にリソースをさくべきである • PMFを迎えるにあたって備えるべきこと − プロダクトをデータドリブンに分析して改善するフィードバック サイクルを確⽴する − ビジネススケールに応じた柔軟性・スケーラビリティが必要にな る
38. Thank you © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.