サーバレスアーキテクチャを 用いたコスト重視AIサービス

Transcript

1. サーバレスアーキテクチャを ⽤いたコスト重視AIサービス
2. スライド概要 AWSのサーバーレスアーキテクチャのベストプラクティスに 基づいて、 低コストで画像分析のサービス構築を⾏なった事例をご紹介 します。 インフラリソースのコスト削減の⼿法や、 お客様の要望に合わせたデプロイサイクルとFBへのアプロー チについても併せて紹介します。
3. ⾃⼰紹介
4. ⼰⼰紹介 たまえ　じゅんき ⽟衛 淳輝 業務：Webアプリケーション開発 　　　スクラムマスター 　　　機械学習エンジニア …他 4 https://www.facebook.com/juk.tamm/

5. アジェンダ
6. アジェンダ • お悩み • AIを含んだサーバーレスアーキテクチャ🏗 • 低コストで画像分析のサービス構築💰 • コストとパフォーマンスの綱引き🍣 • デプロイサイクル🚀 • ユーザーFBに対するサイクル🔍
7. よくあるお悩み
8. 8 よくあるお悩み • AIを含んだクラウドアーキテクチャとはどんなもの？ • AIを含んだクラウドアーキテクチャをより安く作るには • 開発と並⾏した良いFBを⽣み出すためには
9. 最初にアプリケーションイメージ紹介
10. 最初にアプリケーションイメージ紹介 ‧⼀例として、右の図のような物体検出AI ‧⼈、物などの範囲を異なる物体をAIで検出する ‧AWSではSage Maker Endpointというサービスが  画像を元に物体の範囲の矩形を推定する。 ‧AIの中⾝としてはyoloというAIモデルが有名
11. AIサービスを含むサーバーレスアーキテクチャ🏗
12. 12 AIサービスを含むサーバーレスアーキテクチャ🏗 • データフロー解説
13. • AIアーキテクチャ図概要 AIサービスを含むサーバーレスアーキテクチャ🏗
14. 低コストで画像分析のサービス構築 💰
15. 低コストで画像分析のサービス構築 • コスト削減箇所⼀覧 ◦ 画像データなど⼤きなデータはS3に ◦ ⼀部の検索⽤データなど、サイズの⼩さなデータは DynamoDBへ ▪ DynamoDBを採⽤し、DBのメンテナンスコストを低減 ◦ ユーザー体験を損なわない部分ではラムダを採⽤ ◦ SPA（single page application）をS3配置し、 フロントのサーバーとメンテナンスを最低限に
16. 低コストで画像分析のサービス構築 • コスト削減箇所 ◦ 画像データなど⼤きなデータはS3に
17. 17 低コストで画像分析のサービス構築 • コスト削減箇所 ◦ ⼀部のサイズの⼩さな検索⽤データなどはDynamoへ ▪ メンテナンスほぼ不要 ▪ 単純なデータに向いている ▪ S3も選択肢として有り
18. 18 低コストで画像分析のサービス構築 • コスト削減箇所 ◦ ユーザー体験を損なわない部分でラムダを採⽤ ◦ フロントエンドのユーザー体験を重視するなら lambdaは慎重に採⽤する感覚も必要
19. 19 低コストで画像分析のサービス構築 • コスト削減箇所 ◦ ReactのSPA(single page application)をS3配置し、 フロントのサーバーとメンテナンスを最低限に
20. 20 低コストで画像分析のサービス構築 • コスト削減箇所：振り返り ◦ 画像データなど⼤きなデータはS3に ◦ ⼀部の検索⽤データなど、サイズの⼩さなデータは DynamoDBへ ▪ DynamoDBを採⽤し、DBのメンテナンスコストを低減 ◦ ユーザー体験を損なわない部分ではラムダを採⽤ ◦ SPA（single page application）をS3配置し、 フロントのサーバーとメンテナンスを最低限に
21. コストとパフォーマンスの綱引き 🍣
22. 22 コストとパフォーマンスの綱引きを忘れない🍣 • 綱引きのイメージ図 レスポンス メンテナンス性 コスト ユーザー体験
23. 23 コストとパフォーマンスの綱引きを忘れない🍣 • コストだけ⾒てしまうとユーザー体験を損なうので綱引きが⼤事 レスポンス メンテナンス性 コスト ユーザー体験
24. 24 コストとパフォーマンスの綱引きを忘れない🍣 綱引き⼀覧 • コストだけ⾒てしまうとユーザー体験を損なうので綱引きが⼤事 • lambdaは最低限の使⽤とし慎重に採⽤ ◦ フロントでできる処理はフロントに ▪ その分フロントのコードは設計思想をもつ • エンドポイントは2種類のどちらかを検討しよう。 ◦ サーバーレスエンドポイント ◦ プロビジョンドエンドポイント それぞれ⼀⻑⼀短
25. コストとパフォーマンスの綱引きを忘れない🍣 • lambdaは不必要に使わないように採⽤ ◦ フロントでできる処理はフロントに ▪ その分フロントのコードは何らかの設計思想を持つ • ”無秩序”にしない 良いところ ・サーバーレスだから、運用、メンテナンスがほぼ不要 ・サービス単位でプログラムを整理できる高いメンテナンス性 ・必要十分な時にリソースを起動できる高い経済性とコスパ 悪いところ ・サーバーレスだからこそ、都度立ち上げの時間（数秒）がかかる （常時起動の案もなしではないが、サーバーレスの意味が薄れる）
26. 26 コストとパフォーマンスの綱引きを忘れない🍣 /src | +-- app # ページ（現 `features/misc/routes`に相当） | | | +-- routes # ページに関連するコンポーネント | | | | | | +-- router.tsx # ルーティングの設定 | +-- config # 設定ファイル | +-- features # 機能ごとの構成物 | | | +-- sample | | | | | +-- assets # 機能1用のアセット | | | | | +-- components # 機能1用コンポーネント | | | | | +-- hooks # 機能1用フック | | | | | +-- types # 機能1用型定義 | | | | | +-- utils # 機能1用ユーティリティ | +-- assets # 共通のアセット | +-- components # 共通コンポーネント | +-- hooks # 共通フック | +-- stores # 共通の状態管理 | +-- types # 共通の型定義 | +-- utils # 共通ユーティリティ | +-- api # 共通のAPI • ラムダをあまりつかわなくても崩壊しないためのフロントエンド ディレクトリ構造⼀例 （react）
27. 27 コストとパフォーマンスの綱引きを忘れない🍣 • エンドポイントは2種類のどちらかを検討しよう。 ◦ サーバーレスエンドポイント ◦ プロビジョンドエンドポイント ◦ ⼀⻑⼀短
28. 28 コストとパフォーマンスの綱引きを忘れない🍣 様々なインスタンスタイプとサイズでの検証結果： serverless起動 4xlarge  約10秒（完全にcoldスタートの場合は20秒ほど） 常時起動 4xlarge  約2.5秒 常時起動 xlarge  約5秒 常時起動 large  約10秒
29. 29 コストとパフォーマンスの綱引きを忘れない🍣 綱引き：振り返り • コストだけ⾒てしまうとユーザー体験を損なうので綱引きが⼤事 • lambdaは最低限の使⽤とし慎重に採⽤ ◦ フロントでできる処理はフロントに ▪ その分フロントのコードは設計思想をもつ • エンドポイントは2種類のどちらかを検討しよう。 ◦ サーバーレスエンドポイント ◦ プロビジョンドエンドポイント それぞれ⼀⻑⼀短
30. デプロイサイクル🚀
31. 31 デプロイサイクル🚀 • AWS cloud formation • AWS SAM • 複数環境(dev、stg、prd) • React(SPA) を使⽤。 週次、⽇次のデプロイ（環境への反映や機能追加）を可能に。
32. 32 デプロイサイクル🚀 デプロイ作業が最低のコストで実行できるので デプロイの対応工数も最低限 💰 実質的にデプロイが多ければ多い プロジェクトほどお得 • AWS cloud formation • AWS SAM • 複数環境(dev、stg、prd) • React(SPA) を使⽤。 週次、⽇次のデプロイ（環境への反映や機能追加）を可能に。
33. 33 デプロイサイクル🚀 • AWS cloud formation（デプロイコマンド例） ◦ AWSリソースのパラメータ管理と変更を容易にし、各種環境への デプロイを実現
34. 34 デプロイサイクル🚀 • AWS cloud formation（ソース例）
35. 35 デプロイサイクル🚀 • AWS SAM（ソース例） ◦ バックエンドアプリケーションのデプロイを半⾃動化
36. 36 デプロイサイクル🚀 • AWS SAM（デプロイコマンド例） ◦ バックエンドアプリケーションのデプロイを半⾃動化
37. 37 デプロイサイクル🚀 • React(SPA) ◦ フロントエンドサーバーを不要にし、 メンテナンス性を⾼めて、サーバーリソース費⽤の削減
38. 38 デプロイサイクル🚀 • React(SPA)
39. 39 デプロイサイクル🚀 • ここで疑問 cloud formationもSAMも、 ポチポチ押せば作れる AWSサービスを作るために わざわざソースコードを書くのは むしろ手間が増えてない？
40. 40 デプロイサイクル🚀 • ここで疑問 ⭕YES cloud formationもSAMも、 ポチポチ押せば作れる AWSサービスを作るために わざわざソースコードを書くのは むしろ手間が増えてない？
41. 41 デプロイサイクル🚀 • ここで疑問 それと引き換えに大きなメリット ・デプロイがコマンド一つで完了 なので検証環境など、複数環境への反映もワンコマンド ・ソースコード管理なのでおかしな作業ミスが発生しない なのでデプロイ事故も少なく、原因究明も迅速。 ・ソースコードがパラメータシートのような役割になる なので人依存ではなく透明性の高い運用になる（秘匿情報は除く） cloud formationもSAMも、 ポチポチ押せば作れる AWSサービスを作るために わざわざソースコードを書くのは むしろ手間が増えてない？ ただし ⬇
42. 42 これまでの⼯夫を⾏った上で、以下FBサイクルを回しています🔍 • 週次でのデプロイ ↓ • 簡易な開発者テスト ↓ • ユーザーテスト ↓ • FB受け取り or バグ対応 ↓ • 急ぎ対応のものはデプロイ ↓ • 上記ループ🔁
43. 全体振り返り
44. 全体振り返り コスト重視で AIアーキテクチャを組むポイント振り返り • AIサービスを含むサーバーレスアーキテクチャ 🏗 • 低コストで画像分析のサービス構築 💰 • コストとパフォーマンスの綱引き 🍣 • デプロイサイクル 🚀 • ユーザーFBに対するサイクル 🔍
45. AWSとAIを用いて、 コストパフォーマンスの高い AIサービスを作りましょう！