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