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

下記、勉強会での資料です。
https://www.youtube.com/watch?v=m9xbpaJU6Dg

Transcript

1. 第155回 雲勉 サーバレスアーキテクチャを 
 用いたコスト重視AIサービス 
 

2. 講師自己紹介 2 ▪ 名前 玉衛　淳輝
 • (所属)アイレット株式会社 アジャイル事業部 • (経歴、アイレット歴)
 ◦ Webアプリケーション開発、
 ◦ スクラムマスター、機械学習エンジニア • ご質問は YouTubeのコメント欄で受け付けております。
 後日回答させていただきます！
 

3. アジェンダ 3 1. 概要
 2. お悩み
 3. AIを含んだサーバーレスアーキテクチャ 🏗
 4. 低コストで画像分析のサービス構築 💰
 5. コストとパフォーマンスの綱引き 🍣
 6. デプロイサイクル 🚀
 7. ユーザーFBに対するサイクル 🔍

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