amptalkが月間10万件の商談解析SaaSを生み出すまでのアーキテクチャ変遷

AWS Startup Community Conference 2022 の登壇資料になります。

Transcript

1. amptalkが月間10万件の商談解析SaaSを 生み出すまでのアーキテクチャ変遷 AWS Startup Community Conference 2022 amptalk CTO 鈴木啓太 1
2. 自己紹介 2 鈴木 啓太 / Keita Suzuki amptalk 株式会社 - CTO @leonis_sk 好きな AWS サービス AWS CloudFormation アジャイル開発による内製開発の促進 オンラインストア開発 (Frontend/Backend/Cloud) → 現職
3. 3
 オンライン商談・電話 自動書き起こし解析ツール アンプトーク
4. サービス紹介 4 Slack Salesforce/ HubSpot Zoom Meetings Dialpad/ Zoom Phone 録画・録音データを 自動で転送 書き起こし・解析結果を SlackやSFAに出力
5. 商談解析機能 5 書き起こし機能 コメント機能 話者分離機能 トピック解析
6. 開発にとっても嬉しい機能 6 お客様からの FB や機能要望を 直接確認することができる 社内 LT 会のアーカイブ
7. 今日話したいこと 7 会社も資金も無い状態からプロダクト作りを開始 現在は月間 10 万件の商談を解析するまでに成長 アーキテクチャの変遷を振り返りながら、 各事業のフェーズでどのような課題が発生し、どのような設計判断をしてきたかご紹介 • これから事業作り・プロダクト作りを始めたい方 • 事業作り・プロダクト作りを始めたばかりの方 • その他 AWS でプロダクト作りをしている方 一例として参考になれば
8. 立ち上げ期 8
9. CEOとの出会い・プロトタイピング 9 ２人でプロトタイプ作りを開始 最初のプロダクトは実商談解析ではなく、営業のトレーニング（ロールプレイ）を支援するもの 1. 営業が課題に従って音声を録音 2. マネージャーが評価 3. 高評価順に録音を聞くことができる
10. アーキテクチャ 10
11. 設計判断 11 • デプロイ・テストの自動化 ◦ どうせ最初から最後まで必要なので 深く考えずに初めから自動化 事業仮説が正しいのかどうか、全く見えていない状態 • とにかく早く動くものを ◦ 「使い慣れていて早く作れる」ことを最優先に技術を選定 • 認証（Cognito）などマネージドサービスは使い倒す 資金（会社）なし • 様々な無料枠が用意されている AWS は強い味方 • 冗長化・スケーリングは度外視 時間リソースなし
12. 開発プロセス 12 プロダクトバックログ とにかく早く動くものを → 最小単位の１機能ができるごとに即リリース ログイン機能もなしで FB をもらいにいくことも • 未成熟すぎて実運用で使ってもらえない • Paying Customer でないと、口当たりの良いことを 言ってもらえるだけになってしまいがち • 誘導尋問になりがち • 現場にとっては工数が増えるだけで嬉しくない プロダクトだと分かった • ただのレコーダーとして利用している方も 仮説検証を細かく繰り返すことが大切とはいえ、 一番根本を間違えている状態で進み続けても未来がない
13. ピボット後（資金調達前） 13
14. ピボット 14 方向転換 • 現場の営業にとっては練習の工数が増える面倒なプロダクト ◦ オンライン商談を解析してフィードバックに繋げればよいのでは？ ◦ → それまでのプロダクトを捨てる決断 事業への自信 • プロダクトファーストなチーム • 前回の失敗 • 1,000 人のヒアリングに基づく仮説
15. アーキテクチャ 15
16. 設計判断 16 以前と比べ、事業拡大のビジョンが見えてきた状態 • 将来的なスケールを見据えつつ、初期費用を抑えるためのサーバレスな構成（Lambda / DynamoDB） • デプロイ・テストに加えて、アラート検知の仕組みも自動化 • 解析処理やジョブは SQS で疎結合に • インフラはすべて CloudFormation で作成 ◦ 手作業撲滅 ◦ 環境を一時的に増やしたい場合に非常に楽 • シングル AWS アカウントに、複数の環境を作成していた 商談の自動解析 • 書き起こしは Amazon Transcribe など既存サービスを検討 ◦ コスト・精度の面で断念 → 自前で作成
17. 資金調達後 17
18. 正式ローンチに向けて 18 • $100,000 のクレジット付与 ◦ コストを切り詰める必要がなくなった • サポートも手厚いので、やらない理由はない • 期限があるので、いつどれだけ申請するかは重要 AWS Activate 3rd party 連携 • Zoom / Salesforce などの外部連携
19. アーキテクチャ 19
20. 設計判断 20 セキュリティファースト • 連携先のセキュリティ審査、セキュリティチェックシート対応 ◦ 認証認可の仕組み改善、WAF・GuardDuty の導入などセキュリティ周りの徹底的な見直し ◦ ISMS の取得 • ユーザが増える前から継続して意識すべき RDS • RDS Proxy が GA ◦ 結合・検索・強い一貫性が必要なデータ → RDS ◦ それ以外（個人設定など）→ DynamoDB AWS Activate クレジット • うっかり高課金されたら...の恐怖が和らぎ、実験しやすくなる
21. 正式ローンチ 21
22. 正式ローンチ後 22 開発組織の拡大 • エンジニアの数が増え、権限の委譲・精緻化が必要に アクセス数の急激な増加 • リソースの使用状況やサービスクォータにより一層気を配ることが必要 クレジット • AWS Activate クレジットの終了後を見据えたコストの分析と最適化 → （元々課題ではあったが）AWS シングルアカウント運用が辛くなってくる
23. それまでのシングルアカウント運用 23 開発環境 レビュー環境 商用環境 開発環境 商用環境 メインプロダクト ウェブサイト 機械学習
24. シングルアカウント運用の辛さ 24 権限管理 • 管理アカウント保持者がボトルネックになっていく ◦ アカウント作成・権限付与 • IAM ポリシー設計が非常に複雑に ◦ 名前やタグでリソースの限定をしないといけない ◦ ちょっとした実験でも、IAM 設計が必要 ◦ 常に商用リソースへのアクセスを気にしなければいけない
25. シングルアカウント運用の辛さ 25 リソースの競合 • サービスクォータなどはアカウント内共通 ◦ 検証環境での実験が商用に影響を与えてしまう危険性 ◦ 商用デプロイ時にクォータ超過で失敗 コスト切り分け • タグ付けを適切に行わないと、細かいコスト分析ができない • 「EC2 - その他」などでまとめられると辛い
26. マルチアカウント構成 26
27. マルチアカウントへの移行 27 AWS Control Tower • まずはこれを利用することを考えるべき ◦ AWS SSO (AWS Identity Center) やセキュリティ・ガバナンスの下地をよしなに作成してくれる 商用稼働しているアカウントからの移行 • 最も大事な商用リソースのみを元のアカウントに残し、それ以外を剥がしていく ◦ 極力商用のデータ移行を発生させない ◦ 複数の商用ワークロードが発生する前にやる！ • CloudFormation を最大限に活用する
28. 移行後 28 シンプルな権限設計と権限委譲 • 開発環境の管理者権限を付与する、などシンプルな運用と権限委譲が可能 • 実験したければアカウントを作成・不要になったら削除 リソースの物理的分割 • 商用への影響を与えない安心感 わかりやすいコスト分析 • 一括請求 • マネジメントアカウントで、アカウント毎のコストが簡単に確認可能
29. これから 29
30. やっていきたいこと 30 さらなる組織拡大に向けて • より柔軟かつ堅牢な権限設計 • 学習用の AWS アカウントを安全に払い出す仕組み コスト最適化 • AWS Activate クレジット終了 ML Ops • SageMaker の活用を進めている
31. まとめ 31 事業仮説に自信が持てるまでは、とにかく早く動くものを 数多くのマネージドサービスが無料枠とともに用意されている AWS は強い味方 方向性が見えてきた時点でスケールを見据えた設計に セキュリティは早くから意識するに越したことはない マルチアカウント化は最初からやるべきだった テストやデプロイなどは永遠に必要な作業なので、はじめから自動化しておく We are hiring! （Frontend/Backend/AWS 全方面で採用中） 私たちと一緒に「人と人が向き合う時間が最大化される世界」を作りませんか？ Meety amptalk 採用ページ @leonis_sk