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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

© 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

Slide 3

Slide 3 text

© 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で発表しました

Slide 4

Slide 4 text

© 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経由でコードを実⾏する。

Slide 5

Slide 5 text

© 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

Slide 6

Slide 6 text

© 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

Slide 7

Slide 7 text

© 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

Slide 8

Slide 8 text

© 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

Slide 9

Slide 9 text

Slide 10

Slide 10 text

© 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」を紹介

Slide 11

Slide 11 text

© 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使う⽅法もあり

Slide 12

Slide 12 text

© 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とは相性が悪かったというだけです

Slide 13

Slide 13 text

© 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

Slide 14

Slide 14 text

© 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

Slide 15

Slide 15 text

© 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 でウェブアプリを (ほぼ) そのままサーバーレス化する

Slide 16

Slide 16 text

© 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

Slide 17

Slide 17 text

Slide 18

Slide 18 text

© 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