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


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


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


4 概要 AWSのサーバーレスアーキテクチャ のベストプラクティスに基づいて、 低コストで画像分析のサービス構築を行なった事例をご紹介し ます。 インフラリソースのコスト削減の手法や、 お客様の要望に合わせたデプロイサイクルと FBへのアプローチ についても併せてご紹介いたします。

5 よくあるお悩み

6 よくあるお悩み ● AIを含んだクラウドアーキテクチャとはどんなもの？ ● AIを含んだクラウドアーキテクチャをより安く作るには ● 開発と並⾏した良いFBを⽣み出すためには

最初にアプリケーションイメージ紹介 7

最初にアプリケーションイメージ紹介 ‧⼀例として、右の図のような物体検出AI ‧⼈、物などの範囲を異なる物体をAIで検出する ‧AWSではSage Maker Endpointというサービスが  画像を元に物体の範囲の矩形を推定する。 ‧AIの中⾝としてはYOLOというAIモデルが有名 8

9 AIサービスを含むサーバーレスアーキテクチャ🏗

10 AIサービスを含むサーバーレスアーキテクチャ🏗 ● データフロー解説

● AIアーキテクチャ図概要 AIサービスを含むサーバーレスアーキテクチャ🏗 11

低コストで画像分析のサービス構築💰 12

低コストで画像分析のサービス構築 ● コスト削減箇所⼀覧 ○ 画像データなど⼤きなデータはS3に ○ ⼀部の検索⽤データなど、サイズの⼩さなデータは DynamoDBへ ■ DynamoDBを採⽤し、DBのメンテナンスコストを低減 ○ ユーザー体験を損なわない部分ではLambdaを採⽤ ○ SPA（single page application）をS3配置し、 フロントのサーバーとメンテナンスを最低限に 13

低コストで画像分析のサービス構築 ● コスト削減箇所 ○ 画像データなど⼤きなデータはS3に 14

15 低コストで画像分析のサービス構築 ● コスト削減箇所 ○ ⼀部のサイズの⼩さな検索⽤データなどはDynamoへ ■ メンテナンスほぼ不要 ■ 単純なデータに向いている ■ S3も選択肢として有り

16 低コストで画像分析のサービス構築 ● コスト削減箇所 ○ ユーザー体験を損なわない部分でLambdaを採⽤ ○ フロントエンドのユーザー体験を重視するなら Lambdaは慎重に採⽤する感覚も必要

17 低コストで画像分析のサービス構築 ● コスト削減箇所 ○ ReactのSPA(single page application)をS3配置し、 フロントのサーバーとメンテナンスを最低限に

18 低コストで画像分析のサービス構築 ● コスト削減箇所：振り返り ○ 画像データなど⼤きなデータはS3に ○ ⼀部の検索⽤データなど、サイズの⼩さなデータは DynamoDBへ ■ DynamoDBを採⽤し、DBのメンテナンスコストを低減 ○ ユーザー体験を損なわない部分ではLambdaを採⽤ ○ SPA（single page application）をS3配置し、 フロントのサーバーとメンテナンスを最低限に

19 コストとパフォーマンスの綱引きを忘れない🍣

20 コストとパフォーマンスの綱引きを忘れない🍣 ● 綱引きのイメージ図 レスポンス メンテナンス性 コスト ユーザー体験

21 コストとパフォーマンスの綱引きを忘れない🍣 ● コストだけ⾒てしまうとユーザー体験を損なうので綱引きが⼤事 レスポンス メンテナンス性 コスト ユーザー体験

22 コストとパフォーマンスの綱引きを忘れない🍣 綱引き⼀覧 ● コストだけ⾒てしまうとユーザー体験を損なうので綱引きが⼤事 ● Lambdaは最低限の使⽤とし慎重に採⽤ ○ フロントでできる処理はフロントに ■ その分フロントのコードは設計思想をもつ ● AI のendpointは2種類のどちらかを検討しよう。 ○ サーバーレスエンドポイント ○ プロビジョンドエンドポイント それぞれ⼀⻑⼀短

コストとパフォーマンスの綱引きを忘れない🍣 ● Lambdaは不必要に使わないように採⽤ ○ フロントでできる処理はフロントに ■ その分フロントのコードは何らかの設計思想を持つ ● ”無秩序”にしない 良いところ ・サーバーレスだから、運用、メンテナンスがほぼ不要 ・サービス単位でプログラムを整理できる高いメンテナンス性 ・必要十分な時にリソースを起動できる高い経済性とコスパ 悪いところ ・サーバーレスだからこそ、都度立ち上げの時間（数秒）がかかる （常時起動の案もなしではないが、サーバーレスの意味が薄れる） 23

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 コストとパフォーマンスの綱引きを忘れない🍣 ● AI のendpointは2種類のどちらかを検討しよう。 ○ サーバーレスエンドポイント ■ サーバーレス：アクセスされるとサーバーが⽴ち上がり処理実⾏ ○ プロビジョンドエンドポイント ■ 常時起動型 ○ ⼀⻑⼀短

26 コストとパフォーマンスの綱引きを忘れない🍣 様々なインスタンスタイプとサイズでの検証結果： serverless起動 4xlarge  約10秒（完全にcoldスタートの場合は20秒ほど） 常時起動 4xlarge  約2.5秒 常時起動 xlarge  約5秒 常時起動 large  約10秒

27 コストとパフォーマンスの綱引きを忘れない🍣 綱引き：振り返り ● コストだけ⾒てしまうとユーザー体験を損なうので綱引きが⼤事 ● Lambdaは最低限の使⽤とし慎重に採⽤ ○ フロントでできる処理はフロントに ■ その分フロントのコードは設計思想をもつ ● AI のendpointは2種類のどちらかを検討しよう。 ○ サーバーレスエンドポイント ○ プロビジョンドエンドポイント それぞれ⼀⻑⼀短

28 デプロイサイクル🚀

29 デプロイサイクル🚀 ● AWS CloudFormation ● AWS SAM ● 複数環境(dev、stg、prd) ● React(SPA) を使⽤。 週次、⽇次のデプロイ（環境への反映や機能追加）を可能に。

30 デプロイサイクル🚀 デプロイ作業が最低のコストで実行できるので デプロイの対応工数も最低限 💰 実質的にデプロイが多ければ多い プロジェクトほどお得 ● AWS CloudFormation ● AWS SAM ● 複数環境(dev、stg、prd) ● React(SPA) を使⽤。 週次、⽇次のデプロイ（環境への反映や機能追加）を可能に。

31 デプロイサイクル🚀 ● AWS CloudFormation（デプロイコマンド例） ○ AWSリソースのパラメータ管理と変更を容易にし、各種環境への デプロイを実現

32 デプロイサイクル🚀 ● AWS CloudFormation（ソース例）

33 デプロイサイクル🚀 ● AWS SAM（ソース例） ○ バックエンドアプリケーションのデプロイを半⾃動化

34 デプロイサイクル🚀 ● AWS SAM（デプロイコマンド例） ○ バックエンドアプリケーションのデプロイを半⾃動化

35 デプロイサイクル🚀 ● React(SPA) ○ フロントエンドサーバーを不要にし、 メンテナンス性を⾼めて、サーバーリソース費⽤の削減

36 デプロイサイクル🚀 ● React(SPA)

37 デプロイサイクル🚀 ● ここで疑問 CloudFormationもSAMも、 ポチポチ押せば作れる AWSサービスを作るために わざわざソースコードを書くのは むしろ手間が増えてない？

38 デプロイサイクル🚀 ● ここで疑問 ⭕YES CloudFormationもSAMも、 ポチポチ押せば作れる AWSサービスを作るために わざわざソースコードを書くのは むしろ手間が増えてない？

39 デプロイサイクル🚀 ● ここで疑問 それと引き換えに大きなメリット ・デプロイがコマンド一つで完了 なので検証環境など、複数環境への反映もワンコマンド ・ソースコード管理なのでおかしな作業ミスが発生しない なのでデプロイ事故も少なく、原因究明も迅速。 ・ソースコードがパラメータシートのような役割になる なので人依存ではなく透明性の高い運用になる（秘匿情報は除く） CloudFormationもSAMも、 ポチポチ押せば作れる AWSサービスを作るために わざわざソースコードを書くのは むしろ手間が増えてない？ ただし ⬇

40 これまでの⼯夫を⾏った上で、以下FBサイクルを回しています🔍 ● 週次でのデプロイ ↓ ● 簡易な開発者テスト ↓ ● ユーザーテスト ↓ ● FB受け取り or バグ対応 ↓ ● 急ぎ対応のものはデプロイ ↓ ● 上記ループ🔁

41 全体振り返り

全体振り返り コスト重視で AIアーキテクチャを組むポイント振り返り ● AIサービスを含むサーバーレスアーキテクチャ 🏗 ● 低コストで画像分析のサービス構築 💰 ● コストとパフォーマンスの綱引き 🍣 ● デプロイサイクル 🚀 ● ユーザーFBに対するサイクル 🔍 42

43 AWSとAIを用いて、 コストパフォーマンスの高い AIサービスを作りましょう！

44 最後に1分だけ弊社紹介

アイレットは画像解析や生成 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

47 ご清聴ありがとうございました。