LLMアプリ開発プラットフォームDifyをAWSで可能な限りマネージド化したかった

OSSのLLMアプリ開発プラットフォームであるDifyを極限までAWSでマネージド化したい！先月そんな思いで検討・実装を始めました。もちろんAWS CDKを使っています。本セッションでは、マネージドなアーキテクチャの変遷、各アーキテクチャのよしあし、開発の過程で得られた知見などをまとめて紹介します。生成AIアプリ開発に役立つアーキテクチャやCDKの知識がここにある、はず！

Transcript

1. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 友岡 雅志 Sr. Prototyping Engineer LLMアプリ開発プラットフォームDifyを AWSで可能な限りマネージド化したかった 1 2024/08/07 JAWS-UG CDK⽀部#15
2. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. 友岡 雅志 Sr. Prototyping Engineer @AWS Japan CDK経験 前職でオンプレ→AWS移⾏の際に採⽤ (2019/12 - 2020/10) AWS社内サービスの運⽤開発 (2021/7 - 2022/3) 様々なプロトタイプ開発に利⽤ (2020/11 – 現在) 好きな⽣成AIの使い⽅ 妻とのけんかの仲裁・仲直り⽅法の壁打ち…笑 2 ⾃⼰紹介 𝕏: @tmokmss ブログ: tmokmss.hatenablog.com
3. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Dify (dɪfὰɪ) とは • LLMアプリ開発プラットフォーム • 主要な機能 • ワークフロー: ノーコードで処理を組める • 多様なモデルやツールのサポート • LLMOps: 利⽤・稼働状況のモニタリング • BaaS: Difyの各機能やワークフローは ウェブAPIで他のサービスと統合可能 • SaaS版はすぐに試せる https://cloud.dify.ai/ 追加の参考情報 話題のローコードツール「Dify」で⽣成AIアプリを作ってみよう︕ Difyの全社活⽤について、Dify Meetup Tokyo #1で発表しました
4. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Difyをマネージド化したい (CDKで) きっかけ (sonodarさん): 上記はTerraformによる偉業 AWS CDKで書き換えてみるかと思ったのが 今回の話のきっかけです 4 https://www.m3tech.blog/entry/dify-aws DifyのOverview (インフラ視点) api Fast API web Next.js sandbox worker Celery users Object storage Vector storage Redis Postgres ※ sandboxはLLMが⽣成したコードを安全に実⾏するための、Dify 独⾃のサンドボックス環境。HTTP経由でコードを実⾏する。
5. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. アーキテクチャの変遷 1. ALB + ECSで元ネタを踏襲 2. ALBのコスト節約したい… ALBをAPI Gateway HTTP APIで置き換え 3. API GatewayはDifyと相性悪かった… CloudFront + Lambdaで置き換え 4. 結局ALB + ECSがDifyには向いてるわ 5 本⽇はこれらの検討・実装の過程で 得られた学びや知⾒を共有します︕ GitHub: tmokmss/dify-on-aws-cdk
6. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v1: ALB + ECS • オブジェクトストレージ:S3 • Vectorストレージ: Aurora Postgres • Redis: ElastiCache Redis • コンピュート: ECS Fargate 単純にTerrafrom→CDKで書き換えたかたち 6
7. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Terraformと⽐較して… • CDKの良さ • 条件分岐しやすい • 引数によってVPCをインポートしたりしなかったり • ALBにTLSの設定をするかしないか選ぶようにしたり • コンテナイメージを扱いやすい • ecs.ContainerImage.fromAssetを使えば、コンテナのビルドやデプロイ・ECSタスク定義での イメージタグ参照など、⾯倒な部分がすべて隠蔽される • Docker Hubのイメージを少しカスタマイズしてからデプロイしたいようなときにも活躍 • Lambdaによるカスタムリソースでデプロイ時処理の柔軟性が⾼い • DBの初期化もIaCのレベルで可能 (デプロイの 再現性⾼めるのには有⽤) 7
8. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. カスタムリソースでPostgres DBの初期化 • Aurora Serverless v2 (Postgres) ならData APIでSQLクエリ実⾏可能 • AwsCustomResourceを使えばデプロイ時クエリ実⾏は容易 • ちなみに: DB Cluster作成直後はData APIが利⽤不可 • リソース作成間に待機時間を追加するコンストラクトの使い所 cdk-time-sleep • 使⽤例: DBCluster作成完了 → 1分間待つ → SQLクエリ実⾏ 8
9. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v1: ALB + ECS デメリット • ALBのコスト • ALBのTLS化にはひと⼿間必要 • ドメインの購⼊など 9 画像↑の情報は2024年8⽉現在
10. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v2: API Gateway + ECS メリット • ALB分のコストを削減 • API Gatewayはリクエスト量に応じた課⾦ なので、⼩規模ではより安価に • セキュリティグループの代わりに Lambda AuthorizerでIPアドレス制限 [1] 10 ちなみに: このLambdaランタイムにLLRT [2]を使っている (コールドスタート時間が100msほど減少) cdk-lambda-llrt ライブラリで簡単に利⽤できる コード: tmokmss/dify-on-aws-cdk@dda7305 [1] API Gateway(HTTP API) で IP アドレス制限する [2] AWS Lambda特化のJavaScriptランタイム「LLRT」を紹介
11. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. API GatewayからECSサービスに直通する • ECSサービスの公開にALBを使わなくても良くなる⽅法 [1] • CFnが暗黙にECS Service ConnectのCloudMapを作成するので、カスタムリソー スでARNを取得する (CDK基本︖所作のひとつ😎) 11 [1] API Gateway load balanced Fargate service with Cloud Map using CDK construct ※ Service Connectの代わりにService Discovery使う⽅法もあり
12. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v2: API Gateway + ECS デメリット • API Gatewayの制約 • response streaming不可 • バックエンドが全レスポンスを返した段階 で、まとめてクライアントに応答される • チャットなどのUX悪化 • 29秒タイムアウト • Difyのワークフロー実⾏など、 30秒を超える⽤途はあり得る • 最近は緩和できるようになったものの、 デフォルトのまま使えないのは減点対象 12 ※ 今のDifyとは相性が悪かったというだけです
13. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v3: CloudFront + Lambda メリット • API Gatewayがなくなった • 先述の制約から解放 • CloudFront + Lambda関数URLで代替 • タイムアウトは15分まで伸びる • response streamingも対応 • IPアドレス制限はWAFで実現可能 • Lambda Web Adapter (LWA)を使えば Lambda上でそのままDifyを動かせる • Lambdaの部分はオートスケールが容易 13 コード: tmokmss/dify-on-aws-cdk@60a29c4
14. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Lambda関数URL + LWA + CloudFrontの魅⼒ • 特に⽣成AIアプリではかなり良さげな構成︕ • Response streaming: LWAがLambdaランタイムへの依存[1]を吸収するため、アプリ側は通常の Server-sent events (SSE)などの実装をすればOK。このため、ローカルでの動作検証も容易 • セキュリティ: 関数URLをIAM認証で保護 + CloudFront OACの利⽤で、クライアントからは透過 的に関数URLを保護 (POST/PUTはpayloadの署名が必要なため、L@Eを利⽤)。CloudFrontなら TLS化・WAF・カスタムドメインの利⽤も簡単に︕ デメリット • レスポンスストリームはI/O boundに なりがちのため、 Lambdaでの コスト効率は低いこともある • アクセス量が⼤きいほどI/O多重化 ができるECSなどの⽅がコスト⾯は有利 14 [1] AWS Lambda response streaming 実装前にしりたいやつ [2] Restrict access to an AWS Lambda function URL origin
15. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. おまけ: その他Lambda Web Adapterの魅⼒ • 基礎知識: LWA[1]は⼀般のウェブアプリをLambda上で動かすための拡張機能[2] • モノリシックなウェブアプリをそのまま動かすために役⽴つ機能も多い • AWS_LWA_ASYNC_INIT: true • Lambdaはコールドスタートが10秒を超えると初期化処理を中断・再実⾏するが、このフラグ を有効化するとLWAが初期化フェーズを管理し、10秒超えても1回の初期化で済む • AWS_LWA_AUTHORIZATION_SOURCE • Lambda関数URLのIAM認証はAuthorizationヘッダーを使う。この機能を使えば、LWAがIAM 認証で使われたAuthorizationヘッダーを別のヘッダーの値で上書きする • AWS_LWA_INVOKE_MODE: response_stream • Lambdaのresponse streamingを、アプリからは透過的に扱うことができる (ただTransfer-Encoding: chunkedのレスポンスを返せば良し) 15 [1] GitHub: awslabs/aws-lambda-web-adapter [2] Lambda Web Adapter でウェブアプリを (ほぼ) そのままサーバーレス化する
16. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v3: CloudFront + Lambda デメリット • Lambdaのコールドスタート • DifyAPIは頑張って40秒→18秒 [1] • ⼤きなHTTPペイロードを受けられない • L@Eでハッシュ計算する構成 [2]は1MBが上限 • Difyではファイルアップロードに⽀障あり • Sandbox/Workerは結局ECSが必要 • Worker: Redisをキューとするため常駐の必要あり • Sandbox: Lambdaで使えないシステムコールが必要 [3] • → コンピュートの総コストはあまり減らない 16 [1] Python Lambdaのコールドスタートが遅いときの対処法 [2] CloudFront + Lambda 関数 URL 構成でPOST/PUT リクエストを⾏うため Lambda@Edge で… [3] Introduction to DifySandbox
17. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. v4: v1に回帰 物事に向き・不向きはある…🥹 現⾏のmainはこれで決着 早速同僚が拡張してくれました 17 https://qiita.com/mabuchs/items/50523146a322d9f6cb3e
18. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. まとめ あえてまとめるなら… • OSSアプリのIaCを書くのは、各技術に慣れるための良い練習になりオススメ • 実⽤的な規模・複雑度のアプリなら、リアルな課題が⽣じてくれる • 特に枯れてない技術だとOSS貢献も捗る (今回はIssue4つ, PR6つが⽣み出された) • OSSベース vs AWSベース • マネージドサービスへの最適化具合は (当たり前だが) OSSベースだと低下しがち • Redis (as a キュー) vs SQS、アプリとLambdaとの相性など • AWSネイティブなLLMアプリプラットフォームの例 • Bedrock Claude Chat https://github.com/aws-samples/bedrock-claude-chat • Generative AI Use Cases JP (略称:GenU) https://github.com/aws-samples/generative-ai-use-cases-jp 18
19. © 2024, Amazon Web Services, Inc. or its affiliates. All rights reserved. Thank you! Masashi Tomooka mtomooka@amazon.co.jp 𝕏: @tmokmss 19