Dify（ディファイ）をGoogle Cloudにデプロイしてみた

こんにちは。調和技研研究開発部の高松です。

プログラミングなしで生成AIアプリケーションを開発できるとあって話題になっている「Dify（ディファイ）」。今回は、社内でフローなどを共有しながら検証するために、クラウド上に検証環境を作ってみました。

Difyとは？

Difyは、LangGenius, Inc.が提供するオープンソースのLLMアプリ開発プラットフォームです。LLMに特化したノーコードツールということで、現在、非常に盛り上がっているLLM関連OSSの１つです。

また、開発元がSaaSとしても提供[1]しています。フリー版もありますのでこちらでお試しするのがもっとも簡単です。

上記のようなかたちで、LLMアプリケーションをノードとフローで記述します。

個人的にGoogle Cloudを勉強しておく用事もあったのでGoogle Cloud上に構築してみましたが、バグを踏んでしまい、中々大変でした。（バグについては後述します）

構成

構成図は以下で、VM上でdocker-composeを使い、データベースとストレージにGoogleのマネージドサービスを使っています。

ちなみにこちらの図はEraser AI[2]を使って書きました。言葉で指示をだして図を書かせることができます。

図でWeb Applicationと省略しているコンテナ部分ですが、VM上で動かしているコンテナは以下の７つです。

api
worker
web
redis
sandbox
ssrf_proxy
nginx

Difyのコンテナ構成はこちらで、本家のリポジトリ[3] にあります。

Cloud Runを使って構成することもできるそうですが、状態を持つredisはCloud Runには載せられません。これもマネージドサービスを使うとちょっと試すにしてはお高くなっていくのでやめました。お試し用途では、全部VMでも、もちろん問題ないと思います。

Google SQL (PostgreSQL)はベクトル検索の拡張機能もサポートしていますので、デフォルトのweaviateの替わりになります。psqlなどで入って以下のようなSQLで機能を有効化します。

CREATE EXTENSION IF NOT EXISTS vector;

あとは、SSL用の証明書を作ってnginxに設定したら完成です。

…というほどすんなりとはいかず、２つほどトラブルが起きました。

お試し中に起きた2つのトラブル

１）workerが動かない

結論から言うとDBのパスワードに記号が入っていると、celeryに与えるDBのアクセス情報をceleryがパース出来ずworkerが起動しません。「今時、こんな仕様があるのか」と驚いたのですが、界隈では常識でしょうか。

うっかりパスワード管理ツールなどで記号入りのパスワードを作ると、はまってしまうのでした。

２）Google Storageが使えない

こちらも結論から言うと、Dify側のバグでした。

Google Storageを使う際に特定のサービスアカウントを使う構成をとった場合、環境変数で与えたキー情報の読み込みに失敗するバグと、ファイルのアップロード時にもバグがあり、ソースコードを修正する必要がありました。

コンテナをビルドしコンテナレジストリをGCPに建て、そちらにpushしたコンテナを使って、ようやく期待の動作ができました。

提出したPull Request[4]は、最新のv0.6.11 にマージされています。

Difyを上手に活用していく

Difyを使いこなすまでの紆余曲折を書きましたが、Dify自体はLLMを始めるツールとして、とても優れたツールです。当社でも技術検証などで活用していく予定です。

【参考文献】

[1]https://dify.ai/

[2]https://app.eraser.io/

[3]https://github.com/langgenius/dify/blob/main/docker/docker-compose.png

[4]https://github.com/langgenius/dify/pull/5054

記事を書いた人

高松一樹

研究開発部部長。言語系AIとプロダクトを管轄。2001年に当社の母体である北海道大学調和系研究室を卒業（修士）。B2Bミドルウェアの開発、通信関連の研究開発を経て、AI研究が再度の盛り上がりを見せてきた2019年1月、調和技研に参加。大きなうねりの中にあるAI業界に身を置くことができて、毎日スリリングです。