Dify を PAI-EAS にデプロイすると、そのマネージドサービスと弾力的なスケーリング機能を利用できます。オンプレミスでのデプロイとは異なり、これによりチームは基盤となる環境の維持ではなく、アプリケーションロジックの開発に集中できます。その結果、プロトタイプから本番稼働までの反復プロセスを加速できます。
仕組み
このソリューションは、Dify アプリケーションを PAI-EAS 上でホストし、外部の依存関係を統合して完全なサービスを構築します。全体的なアーキテクチャは、PAI-EAS サービスインスタンスと外部のクラウドサービスで構成され、これらは Virtual Private Cloud (VPC) ネットワークを介して安全かつ効率的に通信します。
アーキテクチャのコアコンポーネントは次のとおりです。
PAI-EAS サービス: コアコンピューティングプラットフォームとして、EAS は Web インターフェイス、API バックエンド、非同期タスクワーカー、プラグインサンドボックスなど、Dify のすべてのサービスコンポーネントをマルチコンテナー環境で実行します。EAS は、サービスライフサイクル、リソーススケジューリング、およびネットワーク構成を管理します。
ApsaraDB RDS for PostgreSQL: ユーザー、会話、ナレッジベース、ワークフロー、プラグインの構成データを格納します。データベースをアプリケーションから分離することで、データの永続性と独立性が確保されます。
ApsaraDB for Redis: パフォーマンス専有型のキャッシングとメッセージキュー機能を提供します。ホットデータをキャッシュし、セッション状態を管理し、Celery Broker を介して Dify コンポーネント間で非同期タスクを分散します。
Elasticsearch: ベクトルデータベースおよびフルテキスト検索エンジンとして機能します。検索拡張生成 (RAG) シナリオでは、ナレッジベースからドキュメントを格納、インデックス付けし、効率的に取得します。
Object Storage Service (OSS): 永続ファイルストレージを提供します。Dify アプリケーションプラグイン、アップロードされたナレッジベースファイル、その他の永続データを格納し、サービスの更新や再起動後もデータが失われないようにします。
ワークフローは次のとおりです。
ユーザーは、EAS が提供する Web サービスアドレスを介して Dify インターフェイスにアクセスします。すべてのリクエストは、まず Nginx コンテナーによって Dify-Web または Dify-API コンテナーにルーティングされます。ビジネスロジックを処理する際、API サービスはバックエンドの PostgreSQL、Redis、および Elasticsearch と対話してデータ交換を行います。ドキュメントのインデックス作成などの非同期タスクは、Redis を介して実行のためにワーカーコンテナーにディスパッチされます。永続化が必要なすべてのファイルは、マウントされた OSS パスから読み書きされます。
1. 依存リソースの準備
Dify をデプロイする前に、必要な依存リソースを準備する必要があります。ネットワーク接続の問題を回避するために、これらのすべてのリソースが、デプロイする予定の PAI-EAS サービスと同じリージョンおよび VPC ネットワークにあることを確認してください。
ApsaraDB RDS for PostgreSQL および Elasticsearch インスタンスは、作成後に VPC を切り替えることをサポートしていません。作成時に PAI-EAS サービスと同じ VPC を選択する必要があります。
VPC を計画します。VPC がない場合は、VPC と vSwitch を作成します。
RDS PostgreSQL インスタンスを作成する: インスタンスが作成されたら、高権限アカウントを作成します。このアカウントを使用して、Dify のコアデータ用とプラグインデータ用の 2 つのデータベースを作成します。詳細については、「アカウントとデータベースの作成」をご参照ください。
Redis インスタンスの作成: EAS コンテナーからのアクセスを許可するには、PAI-EAS サービスの vSwitch の IP アドレス範囲を Redis インスタンスのホワイトリストに追加します。この情報は、VPC コンソールの vSwitch 詳細ページで確認できます。
Alibaba Cloud Elasticsearch インスタンスを作成する: このインスタンスは、ナレッジベースのベクトルストレージおよびフルテキスト検索エンジンとして機能します。EAS サービスと同じ VPC にあることを確認してください。
2. Dify サービスのデプロイ
PAI コンソールにログインします。ページの上部でリージョンを選択します。次に、目的のワークスペースを選択し、[Elastic Algorithm Service (EAS)] をクリックします。
[Inference Service] タブで、[Deploy Service] をクリックします。[Scenario-based Model Deployment] エリアで、[Dify LLM Application Platform] をクリックします。
デプロイページで、次の主要なパラメーターを構成します。
OSS: OSS バケットを選択し、ナレッジベースファイル、プラグインデータ、その他のファイルの永続ストレージ用のパスを指定します。このパス内に
difyとdify_pluginの 2 つのサブフォルダが自動的に作成されます。PostgreSQL 構成:
ホストアドレス: ApsaraDB RDS for PostgreSQL インスタンスの内部 IP アドレスを入力します。これは、ApsaraDB RDS for PostgreSQL コンソールの RDS PostgreSQL インスタンスの [データベース接続] ページで確認できます。
ポート: デフォルトは 5432 です。異なる場合は実際のポートを入力します。
データベース - コアデータ: アプリケーション、ユーザー、会話、ナレッジベース、ワークフロー、モデル構成など、コア機能に関連するすべてのデータを永続的に格納するために作成されたデータベースの名前を入力します。
データベースプラグイン: プラグインの実行ステータス、構成、メタデータに関連する情報を永続的に格納するために作成されたデータベースの名前を入力します。
アカウント、パスワード: データベース作成時に使用した高権限アカウントとパスワードを入力します。
Redis 構成:
ホストアドレス: Redis インスタンスの内部 IP アドレスを入力します。Redis コンソールに移動し、インスタンス詳細ページの接続情報セクションから取得します。
ポート: デフォルトは 6379 です。異なる場合は実際のポートを入力します。
アカウント、パスワード: Redis インスタンスのアカウントとパスワードを入力します。
Elasticsearch 構成:
ホストアドレス: Elasticsearch インスタンスの内部 IP アドレスを入力します。Alibaba Cloud Elasticsearch コンソールに移動し、インスタンス詳細ページに移動して、 [基本情報] セクションから取得します。
ポート: デフォルトは 9200 です。異なる場合は実際のポートを入力します。
アカウント、パスワード: Elasticsearch インスタンスのログイン名 (デフォルトは
elastic) とパスワードを入力します。パスワードを忘れた場合は、リセットできます。
リソース仕様: サービスをデプロイするための EAS インスタンス仕様を選択します。安定した運用のために、少なくとも 8 CPU と 16 GB のメモリを持つ仕様が推奨されます。
すべての構成が正しいことを確認したら、[デプロイ] をクリックします。サービスステータスが [実行中] に変わると、デプロイは成功です。
3. サービスステータスの確認とアクセス
サービスがデプロイされたら、そのステータスを確認し、機能を検証します。
サービスログの確認
サービスの起動に失敗した場合や異常に実行された場合は、サービス詳細ページの [インスタンスリスト] で対応するコンテナーコンポーネントを見つけることができます。その横にある [ログ] ボタンをクリックして、起動ログとランタイムログを確認し、エラーの原因を特定します。

Dify Web インターフェイスへのアクセス
サービス詳細ページで、右上隅にある [Web アプリケーション] をクリックして Dify の初期化ページを開きます。管理者アカウントを作成すると、アプリケーションの使用を開始できます。
API の呼び出し
Dify API ページのベース URL は内部サービスアドレスです。
パブリックインターネットから Dify API を呼び出すには、http://******.console.cn-hangzhou.eas.pai-ml.comを PAI-EAS サービス呼び出し情報にあるパブリックエンドポイントに変更する必要があります。
次の図に示すように API キーを作成して、プログラムでアプリケーションと対話します。

以下は、チャットボットアプリケーションにメッセージを送信するパブリック API 呼び出しの例です。
curl -X POST 'http://xxxx.your_aliyun_account_id.cn-hangzhou.pai-eas.aliyuncs.com/v1/chat-messages' \ --header 'Authorization: Bearer app-xxxxxxxxxxxxx' \ --header 'Content-Type: application/json' \ --data-raw '{ "inputs": {}, "query": "Tell me about the main features of Dify", "response_mode": "blocking", "user": "test-user-001" }'
4. JSON 構成を使用した高度なデプロイの実行
自動化された、または高度にカスタマイズされたデプロイメントには、JSON 構成ファイルを使用できます。EAS サービスデプロイページで、[JSON デプロイ] に切り替えて、以下のテンプレートに入力します。このテンプレートは、Dify が必要とするすべてのコンテナー、環境変数、ストレージマウント、およびネットワーク構成を完全に定義します。
デプロイ時には、JSON テンプレート内のプレースホルダー ($ で始まる) を実際の値に置き換える必要があります。パラメーターの詳細については、「JSON デプロイメント」をご参照ください。
metadata セクションでは、Web アクセスポートを開くために
"enable_webservice": trueを設定する必要があります。storage セクションでは、
$oss_pathを実際の OSS パス (例:oss://your-bucket-name/dify-data/) に置き換えます。このパスは Dify API とプラグインによって使用され、このパス内にdifyとdify_pluginの 2 つのサブフォルダが自動的に作成されます。containers セクションで、置き換える必要がある環境変数を以下に説明します。詳細については、「Dify 環境変数」をご参照ください。
PostgreSQL データベース構成
db_host: PostgreSQL データベースインスタンスのアドレス。
db_port: デフォルトは 5432 です。
api_db: Dify コア機能データベース。アプリケーション、ユーザー、会話、ナレッジベース、ワークフロー、モデル構成など、コア機能に関連するすべてのデータを永続的に格納します。
plugin_daemon_db: Dify プラグインデータベース。プラグインの実行ステータス、構成、メタデータに関連する情報を永続的に格納します。
db_username、db_password: 両方のデータベースで 1 つのユーザー名とパスワードを共有します。
Redis 構成
Redis は、異なるサービスコンポーネント間のリアルタイムのメッセージパッシングと通信を可能にし、これはライブのユーザーと AI の会話にとって重要です。
redis_host: Redis インスタンスのエンドポイント。
redis_port: デフォルトは 6379 です。
redis_password: Redis インスタンスの作成時に設定したパスワード。
Elasticsearch 構成
ベクトルデータベースとフルテキスト検索エンジンを格納するために使用されます。
elasticsearch_host: Elasticsearch インスタンスのエンドポイント。
elasticsearch_port: デフォルトは 9200 です。
elasticsearch_username: デフォルトは elastic です。
elasticsearch_password: Elasticsearch インスタンスの作成時に構成したパスワード。パスワードを忘れた場合は、インスタンスのアクセスパスワードをリセットできます。
セキュリティキー
Dify は、安全な内部通信とデータを確保するためにキーを必要とします。
openssl rand -base64 42コマンドを使用してこれらのキーを生成できます。secret_key: セッションクッキーに安全に署名し、データベース内の機密情報を暗号化するために使用されるキー。
api_key: 不正な外部呼び出しを防ぐための内部 API アクセスに必要なキー。
plugin_daemon_key: 不正な外部呼び出しを防ぐために
plugin_daemonへの内部アクセスに必要なキー。
よくある質問
PAI-EAS と RDS for PostgreSQL 間の 'connection timed out' エラーを解決するにはどうすればよいですか?
[2025-09-13 00:46:28] [/bin/sh]: 2025/09/12 16:46:28 /app/internal/db/pg/pg.go:34
[2025-09-13 00:46:28] [/bin/sh]: [error] failed to initialize database, got error failed to connect to `host=pgm-xxxxxxxxxx.pg.rds.aliyuncs.com user=dify database=postgres`: dial error (timeout: dial tcp 10.0.0.230:5432: connect: connection timed out)
[2025-09-13 00:46:28] [/bin/sh]: 2025/09/12 16:46:28 init.go:95: [PANIC]failed to init dify plugin db: failed to connect to `host=pgm-xxxxxxxxxx.pg.rds.aliyuncs.com user=dify database=postgres`: dial error (timeout: dial tcp 10.0.0.230:5432: connect: connection timed out)
[2025-09-13 00:46:28] [/bin/sh]: panic: [PANIC]failed to init dify plugin db: failed to connect to `host=pgm-xxxxxxxxxx.pg.rds.aliyuncs.com user=dify database=postgres`: dial error (timeout: dial tcp 10.0.0.230:5432: connect: connection timed out)VPC の一貫性を確認する: RDS for PostgreSQL インスタンスと PAI-EAS サービスが同じ Virtual Private Cloud (VPC) にデプロイされていることを確認します。

必要に応じて再作成する: ApsaraDB RDS for PostgreSQL インスタンスは、作成後に VPC を切り替えることをサポートしていません。異なる VPC にある場合は、正しい VPC に新しい RDS インスタンスを作成し、Dify サービス構成を更新する必要があります。
PAI-EAS 上の Dify デプロイメントで 'redis.exceptions.TimeoutError' を修正するにはどうすればよいですか?
dify-api コンテナーのログに redis.exceptions.TimeoutError が表示される場合、アプリケーションが Redis サーバーに接続できないことを意味します。
[2025-09-13 00:28:21] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/redis/utils.py", line 188, in wrapper
[2025-09-13 00:28:21] [/bin/sh]: return func(*args, **kwargs)
[2025-09-13 00:28:21] [/bin/sh]: ^^^^^^^^^^^^^^^^^^^^^
[2025-09-13 00:28:21] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/redis/connection.py", line 1530, in get_connection
[2025-09-13 00:28:21] [/bin/sh]: connection.connect()
[2025-09-13 00:28:21] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/redis/connection.py", line 379, in connect
[2025-09-13 00:28:21] [/bin/sh]: self.connect_check_health(check_health=True)
[2025-09-13 00:28:21] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/redis/connection.py", line 389, in connect_check_health
[2025-09-13 00:28:21] [/bin/sh]: raise TimeoutError("Timeout connecting to server")
[2025-09-13 00:28:21] [/bin/sh]: redis.exceptions.TimeoutError: Timeout connecting to server
[2025-09-13 00:28:22] time="2025-09-12T16:28:22Z" level=info msg="program stopped with status:exit status 1" program=/bin/sh
このタイムアウトエラーは、通常、2 つのネットワーク構成の問題のいずれかが原因で発生します。
ネットワークアクセスを正しく構成する方法は次のとおりです。
VPC の一貫性を確認する: ApsaraDB for Redis インスタンスが PAI-EAS サービスと同じ VPC にあることを確認します。

ホワイトリスト構成の問題: Redis インスタンスにホワイトリストが構成されていることを確認します。EAS サービスが配置されている vSwitch の IP アドレスグループを追加する必要があります。IP アドレス範囲は vSwitch ページから取得できます。


PAI-EAS 上の Dify サービスが Alibaba Cloud Elasticsearch に接続できないのはなぜですか?
Dify サービスから Elasticsearch への接続の失敗は、ほとんどの場合、VPC の不一致が原因です。
これを解決するには、Alibaba Cloud Elasticsearch インスタンスが PAI-EAS サービスと同じ VPC にあることを確認します。

他のデータベースサービスと同様に、Elasticsearch インスタンスは作成後に別の VPC に移動することはできません。最初から正しい VPC にデプロイする必要があります。
Dify 起動時の 'FATAL: database "dify_core" does not exist' エラーを修正するにはどうすればよいですか?
このエラーは、Dify の起動プロセス中に dify-api サービスが必要なデータベースを見つけられない場合に発生します。
[2025-09-13 01:33:20] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/sqlalchemy/engine/default.py", line 625, in connect
[2025-09-13 01:33:20] [/bin/sh]: return self.loaded_dbapi.connect(*cargs, **cparams) # type: ignore[no-any-return] # NOQA: E501
[2025-09-13 01:33:20] [/bin/sh]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[2025-09-13 01:33:20] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/psycopg2/__init__.py", line 122, in connect
[2025-09-13 01:33:20] [/bin/sh]: conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
[2025-09-13 01:33:20] [/bin/sh]: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[2025-09-13 01:33:20] [/bin/sh]: File "/app/api/.venv/lib/python3.12/site-packages/psycogreen/gevent.py", line 32, in gevent_wait_callback
[2025-09-13 01:33:20] [/bin/sh]: state = conn.poll()
[2025-09-13 01:33:20] [/bin/sh]: ^^^^^^^^^^^
[2025-09-13 01:33:20] [/bin/sh]: sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) FATAL: database "dify_core" does not exist
[2025-09-13 01:33:20] [/bin/sh]:Dify のデプロイメントには、コアデータ用 (dify-api) とプラグインデータ用の 2 つのデータベースが必要です。このデプロイメントガイドで使用されている Dify Community Edition (1.7.1) のバージョンは、プラグインデータベースを自動的に作成しますが、コアデータデータベースは自動的に作成しません。
これを修正するには、Dify サービスをデプロイする前に、PostgreSQL インスタンスにコアデータベースを手動で作成する必要があります。
PAI-EAS 上の Dify コンテナーが marketplace.dify.ai に接続する際に 'timed out' エラーが発生するのはなぜですか?
サービスが marketplace.dify.ai からプラグインをダウンロードしようとするときにログにタイムアウトエラーが表示される場合、それはコンテナーがパブリックインターネットにアクセスできないためです。
[2025-09-13 00:00:00] [/bin/sh]: 2025-09-12 16:00:00,847.847 WARNING [Dummy-1] [ssrf_proxy.py:81] - Request to URL https://marketplace.dify.ai/api/v1/plugins/download?unique_identifier=langgenius/tongyi:0.0.46@8e73008929dbc3934936493d442fab4c34ef016ae817b144b45da278ba76580e failed on attempt 1: timed out
[2025-09-13 00:00:02] [/bin/sh]: 2025-09-12 16:00:02,046.046 WARNING [Dummy-2] [ssrf_proxy.py:81] - Request to URL https://marketplace.dify.ai/api/v1/plugins/download?unique_identifier=langgenius/tongyi:0.0.46@8e73008929dbc3934936493d442fab4c34ef016ae817b144b45da278ba76580e failed on attempt 1: timed out
[2025-09-13 00:00:06] [/bin/sh]: 2025-09-12 16:00:06,416.416 WARNING [Dummy-1] [ssrf_proxy.py:81] - Request to URL https://marketplace.dify.ai/api/v1/plugins/download?unique_identifier=langgenius/tongyi:0.0.46@8e73008929dbc3934936493d442fab4c34ef016ae817b144b45da278ba76580e failed on attempt 2: timed out
[2025-09-13 00:00:07] [/bin/sh]: 2025-09-12 16:00:07,614.614 WARNING [Dummy-2] [ssrf_proxy.py:81] - Request to URL https://marketplace.dify.ai/api/v1/plugins/download?unique_identifier=langgenius/tongyi:0.0.これは、PAI-EAS サービスコンテナーがデフォルトでパブリックインターネットアクセスを持たないために発生します。
アウトバウンドのインターネットアクセスを有効にするには、VPC を NAT Gateway または同様のソリューションで構成する必要があります。詳細な手順については、「VPC 構成」ガイドをご参照ください。