AIサービス立ち上げにAWS Amplifyを使ってわかったPros & Cons

シード期の人的・資金的リソースが少ない中で「AWS Amplify」を選定することの是非について纏めました。

結論、「Amplifyの採用はあり」という持論を持っています。

Transcript

1. A I サ ー ビ ス 立 ち 上 げ に AWS Am p lif y を 使 っ て わ か っ た Pros & Co ns 株 式 会 社 T e c h S w o r d 取 締 役 C T O 宮本 大輝
2. Contents ▪自己紹介 ▪サービス概要 ▪Amplifyとは ▪Pros & Cons & Tips ▪おわりに
3. Self Introduction 自己紹介
4. 自己紹介 宮本 大輝 みやもと たいき ▪ 株式会社TechSword 取締役CTO ▪ 岡山大学大学院自然科学研究科 ▪ 楕円曲線暗号に関する研究 ▪ ssh-keygen –t ed25519のやつ ▪ バックグラウンド ▪ アメリカでの研究インターンシップで機械学習に触れる ▪ IoTスタートアップ・ソラコムでのインターン
5. 好きなAWSサービス Amazon SageMaker AWS IoT Greengrass AWS Amplify
6. 本登壇の目的 ▪シード期スタートアップのプロダクト開発においてAmplifyを 選定することの利点＆欠点 結論 ▪スピード感を持って開発するならAmplifyは大いにあり
7. About Our Service サービス概要
8. 名称 株式会社TechSword 住所 〒700-8530 岡山県岡山市北区 津島中3丁目1番1号 会社概要 事業内容 ノーコードAIプラットフォームの開発・販売 設立 2021年5月19日 代表者 長島慶樹
9. ノーコードAIプラットフォーム TechSword Platform ▪ 知識0・スキル0でも画像認識AIを開発 ▪ 容易な実装が可能 ▪ 安価な導入コスト
11. アーキテクチャ
12. About AWS Amplify AWS Amplifyとは
13. AWS Amplifyとは？ （スケーラビリティとコストに配慮しつつ） サクッとアプリ開発ができるサービス
14. Amplifyの構成要素 https://speakerdeck.com/jaguar_imo/aws-amplify-overview-in-brief?slide=8
15. Amplifyがラップするサービス Cognito DynamoDB AppSync S3 Lambda API Gateway Kinesis Pinpoint Sumerian Elasticsearch Location Service Translate 認証・認可 DB GraphQL ストレージ 関数 REST API 分析 通知 AR/VR 全文検索 Geo 翻訳 etc･･･ 基本＆主要機能
16. Pros & Cons & Tips 利点と欠点とTips
17. 利点 ▪爆速開発 ▪開発環境の構築が容易 ▪サーバーレス構成となる ▪型安全な開発
18. 利点① 爆速開発 サービスに必要な 認証・ストレージ・データベースを AWSのベストプラクティスに則って CLIでコマンドを実行するだけで構築
19. Amplify CLI ▪CloudFormationテンプレートを生成 ▪ amplify push で反映 $ amplify add auth $ amplify add storage $ amplify add api
20. CI/CD ▪GitHub等との接続だけでCI/CD
21. PRごとにレビュー
22. enough? 🤔 AWSで同じことをやれるならそれがいいのでは？ ▪Activateを利用することでコスト0 ▪ただし、パフォーマンスの差は未検証
23. ローカルモック $ amplify mock ▪ローカルでAPI・ストレージ・認証を再現 ▪毎回 amplify push をする必要なし ▪ 1回のpushで大体2～5分は要する（そんなに待てない）
24. 開発環境の構築が容易 1. Dev containerをビルド 1. TypeScript-nodeイメージをpull 2. Javaをインストール（for Amplify mock） 3. pipenv/pyenvをインストール（for Python Lambda） 4. amplify cliをインストール 2. amplify pull --appid abcdxyz –envName dev 3. npm start
25. 総じて アプリケーションの機能開発以外のところに 脳みそも時間も使わなくていい CTO1人＋非フルコミットメンバー4人で 半年で正式版リリース
26. 利点② サーバーレス構成となる Pay-as-you-go (使った分だけ課金)
27. シード期のスタートアップ ▪AWSの利用料金はできるだけ減らしたい ▪ Activateのクレジットもできるだけ節約 ▪ユーザーが少ない段階で、EC2など立てるだけで課金される サービスは少し痛い ▪ もちろん、必要ならば使う サーバーレスで実現すれば安い （トラフィックが増えたとしても？🤔）
28. サーバーレス構成にすることで ▪スケーリングも（そんなに）気にしなくてもよい https://www.ragate.co.jp/blog/articles/5505
29. 利点③ 型安全な開発 GraphQLのクエリ変数やレスポンスの 型を自動生成
30. 開発の流れ 1. schema.graphqlにデータ構造を定義 ▪ nullable or non-nullable ▪ 他テーブルとのrelation 2. amplify mock ▪ 内部ではamplify codegenが実行 ▪ API.ts（型定義）とqueries.ts, mutation.ts, subscription.tsが生成 3. 型定義に沿ってquery/mutationを実行 type Project @model { id: ID! name: String team: Team @hasOne } type Team @model { id: ID! name: String! } const project = { name: “New project", team: “uuidv4" }; await API.graphql(graphqlOperation(createProject, {input: project}));
31. Amplify Graphqlの恩恵 ▪定義をもとに自動生成されることで、人為的ミスがなくなる ▪RDBMSと似たリレーション ▪ ただし、設計パターンは複数あり ▪ シングルテーブル ▪ マルチテーブル ▪ https://aws.amazon.com/jp/blogs/news/single-table-vs-multi-table- dynamodb-appsync/
32. 欠点 ▪GraphQL + AppSyncの取り扱い ▪Cognitoのエイリアス属性 ▪環境の共有が難しい ▪柔軟性の低さ ハマりポイント
33. ①GraphQL + AppSyncの取り扱い ▪list系query 良さげ？👀 allTodos取ってこれないことがある！😭 const allTodos = await( API.graphql({ query: queries.listTodos }) as Promise<ListTodoResult> );
34. なぜなら ▪list系queryは必ず全部取ってくることを保証しない ▪実績として、たった5個のitemsでもlistAllできないことがあった ▪ フロントから見ると「あれ、データ消えた！？」となってしまう 必ず全部取ってこないといけない場合は とする（たとえ5個、10個でも） do {listHoge} while(nextToken)
35. GraphQLのDepthにも注意 発生した問題 ▪ Amplify: Resolver invocation limit reached. 原因 ▪ 一部の深いネストのデータを取るためにAPIのdepthを7にしていた ▪ モデルの中に循環参照がある関係で、1回のQueryで取ってくるデータが とんでもないことに type Model @model @auth(rules: [{ allow: owner }]) { id: ID! name: String! status: ModelStatus! type: ModelType! images: [Image] @connection(keyName: "byModel", fields: ["id"]) ・ ・ } type Image @model @auth(rules: [{ allow: owner }]) @key(name: "byModel", fields: ["modelID"]) { id: ID! modelID: ID! model: Model @connection(fields: ["modelID"]) width: Int! height: Int! ext: String! objects: [Object] @connection(keyName: "byImage", fields: ["id"]) }
37. GraphQLのDepth ▪デフォルトの2に ▪深くまで取ってくる必要があるときは独自でQueryを書く
38. ②Cognitoのエイリアス属性 ▪エイリアス属性は 後から変更できない！ https://hiroga.hatenablog.com/?page=1569198704
39. 対処策 ▪まだアカウント数が片手で数えられるくらいだったので… ▪ Cognitoを完全に初期化して再セットアップ ▪Amplify上でのやり方 ▪ 通常通りamplify add authを実行 ▪ サインイン方法はUsernameを想定（←このUsernameは変更不可） ▪ (projectRoot)/amplify/backend/auth/testapp/cli-inputs.json の一部を次のように変更 ▪ "aliasAttributes": ["email", "preferred_username"], ▪ この変更はAmplify CLIを通してはできないので、jsonを書き換える他ない（もし くは後述のCDKか？）
40. ③環境の共有が難しい ▪toB向けアプリあるある 一般ユーザー 用 アプリ 管理者 用 アプリ
41. amplify import storage ▪いい感じに別プロジェクトのDynamoDBをインポートしてくれそ うな雰囲気があるが… ▪DynamoDBへのアクセス権をプロジェクトにインポートするのみ で、AppSync（GraphQL）が共有されるわけではない ▪ 結果的にExpress+Node.jsやFastAPI+PythonでREST APIサーバーを 構築する必要あり ▪ それなら最初からREST API組んだ方がいいかも…
42. ④柔軟性の低さ ▪Amplifyが対応していないものを別で作成しなければならない ▪ 例えば、S3/DynamoDB/Cognito以外のLambdaトリガーを設定したい とき ▪サブドメインによるマルチテナント運用は（たぶん）できない ▪ Slackでいうtechsword.slack.comなど ▪送信元IPに基づいたルーティングなど、インフラ寄りのことを 触るのは無理 ただし🖐️
43. 進むCDK対応 上手くやれるかも🦆
44. To the End おわりに
45. まとめ ▪スピード感が求められるスタートアップの初期フェーズ においてAmplifyは最適 ▪TypeScriptとの相性もGood👍 ▪GraphQL+AppSyncの仕様には注意 ▪柔軟性の観点からCDKの活用 or 脱Amplifyの時は来る かもしれない
46. エンジニア BizDev 絶賛募集中！
47. メディア出演 ▪NewsPicksのメイクマネーに出演 https://www.youtube.com/watch?v=MrBfP3I8hQ0
48. キーワード React TypeScript AI IoT ソラコム エッジ NVIDIA Jetson MLOps Python 物体検出 教師なし 異常検知
49. こんな人と働きたい！ ▪スーパーフレックスの会社で自発的に働きたい方 ▪エッジデバイスなど、ハードウェアも好きな方 ▪AIの民主化に興味がある方 ▪オーナーシップを持って開発をしたい方
50. How to contact me Feel free to reaching me out💬