AWSでDifyを構築する際の注意点と実践ノウハウ (Lightsail/EC2編)

Dify環境構築

AIチャットボット開発プラットフォーム「Dify」は、ローカル環境だけでなく、AWSのようなクラウド環境にもデプロイして利用できます。クラウドで運用することで、24時間アクセス可能な環境や、スケーラビリティといったメリットが得られます。

しかし、AWS環境へのデプロイには、ローカル環境とは異なる特有の注意点が存在します。この記事では、AWSの代表的なサービスである LightsailEC2 を利用してDifyコミュニティ版を構築する際に、特に気をつけるべきポイントに加え、安定運用やコスト最適化のための実践的なノウハウを解説します。

この記事の対象読者:

  • DifyをAWS上でセルフホストしたいと考えている方
  • LightsailやEC2でのDifyデプロイ手順は知っているが、より安定運用するための注意点やノウハウを知りたい方
  • AWSの基本的な知識(アカウント作成、インスタンス起動など)がある方

 

1. AWS環境の選択肢:Lightsail vs EC2 (メリット・デメリットと選択ノウハウ)

AWSでDifyを動かす主な選択肢として、LightsailとEC2があります。それぞれの特性を理解し、プロジェクトの規模や要件に合わせて選択することが重要です。

 

A. Amazon Lightsail

特徴:

    • 仮想サーバー、ストレージ、ネットワークなどがパッケージ化されており、初心者でも比較的簡単に始められる。
    • 月額固定料金でコスト予測がしやすい。
    • 3ヶ月間の無料利用枠があるプランも存在する(2024年10月時点)。

ノウハウ・Tips:

    • スモールスタートに最適: 個人利用や小規模なテスト導入には、手軽さとコスト predictability の観点からLightsailが適しています。
    • スペック選定: Difyの最小要件(CPU 2コア, メモリ 4GB)を満たすプランを選びましょう。無料枠の最安プラン (例: 512MBメモリ) では確実にスペック不足になります。4GBプラン以上が推奨されます。
    • ネットワーク: Lightsailのファイアウォール設定はシンプルですが、IPアドレス制限など基本的なセキュリティ設定は必ず行いましょう。
    • 限界: 大規模なナレッジベースを扱う、多数のユーザーアクセスが見込まれる、他のAWSサービスとの高度な連携が必要になる場合は、EC2への移行を検討する必要があります。

注意点:

    • インスタンス作成直後のSSH接続: インスタンス作成直後にブラウザSSHで接続しようとすると Unable to load key エラーが出ることがあります。少し待つか、一度画面を閉じて再接続すると解消されることが多いです。
    • HTTPアクセス推奨(初期設定時): デプロイスクリプトによっては初期状態がHTTPアクセス前提の場合があります。まずはHTTPで初期設定を完了させ、**本番運用では必ず別途SSL化(HTTPS)**を行いましょう。
    • 初期設定画面の表示遅延: Dockerコンテナ起動後、/install 画面が表示されるまで数分かかることがあります。焦らず待機しましょう。

Difyをデプロイするまでの流れ

LightsailでDifyをデプロイする手順は次のとおりです。

①VMの作成
②SSHキーの作成
③SSHで①へアクセス
④スクリプトを貼り付けて実行(8分待つ)
⑤コンテナがスタートしたらサイトへアクセス(http://IP Address/install)
⑥アドミンアカウントの作成
⑦サイトへログイン

3 デプロイ用のスクリプト

上述した手順の中で、④に記載したスクリプトはこちらのコードを参考にしてください。

curl -fsSL https://gist.githubusercontent.com/gijigae/50f400a5f91a39fbf2f0d0a652a9c409/raw/install-dify.sh -o install-dify.sh

sudo sh install-dify.sh

install-dify.sh のファイルをLightsailのVMへダウンロードし、そのスクリプトを実行するためのコードです。

画像

ターミナルに「sudo sh install-dify.sh」が表示されましたら、Enterキーを押してください。Docker + Difyのインストールが始まります。デプロイが完了するまで、8分前後かかります。

 

B. Amazon EC2 + 関連サービス

特徴:

    • 柔軟性と拡張性: インスタンスタイプ、ストレージ(EBS/EFS/S3)、ネットワーク(VPC)などを細かくカスタマイズ可能
    • AWSエコシステム: 他のAWSサービス(S3, IAM, Bedrock, RDS, CloudWatchなど)とのシームレスな連携が可能。
    • スケーラビリティ: Auto Scalingなどを利用して負荷に応じた自動拡張が可能。

ノウハウ・Tips:

    • インスタンス選定: t3t4g (Graviton/ARM) などの汎用インスタンスがコストパフォーマンスに優れます。DifyはCPUとメモリをバランス良く消費するため、最初は medium サイズから始め、CloudWatchでリソース使用状況を監視しながら適切なサイズに調整(スケールアップ/ダウン)するのが効率的です。
    • コスト最適化: リザーブドインスタンス (RI) や Savings Plans を利用することで、大幅なコスト削減が可能です(1年または3年の長期利用が前提)。スポットインスタンスはコストを抑えられますが、中断の可能性があるためDifyのような常時稼働サービスには通常向きません。
    • インフラのコード化 (IaC): TerraformやAWS CloudFormationを使ってインフラ構成をコードで管理することで、再現性の確保、変更管理の容易化、人的ミスの削減につながります。

注意点:

    • EBSボリュームサイズ: OS領域とは別にデータ用EBSボリュームを用意しましょう。最初は50GB〜100GB程度から始め、必要に応じて拡張します(縮小は困難)。CloudWatchでディスク使用率アラームを設定しておくと安心です。
    • IAMロールの活用: EC2から他のAWSサービス(S3、Bedrockなど)を利用する場合は、必ずIAMロールを使用しましょう。アクセスキーをサーバー内に保存する必要がなくなり、セキュリティが格段に向上します。

 

2. ストレージ戦略:EBS vs S3 vs EFS (ユースケースとノウハウ)

Difyはナレッジベースのドキュメントや生成画像などを保存します。適切なストレージ選択は、コストとパフォーマンス、運用性に大きく影響します。

AWS上でのボリューム:本番環境のベストプラクティスとコスト

本番環境でデータを永続化する場合、専用のマネージドストレージサービスを利用するのがベストプラクティスです。それぞれのサービスには、パフォーマンスやコスト面で特徴があります。

サービス 特徴 コスト(東京リージョン)
Amazon EBS 単一インスタンスに紐づく高性能なブロックストレージ。Multi-Attach機能を持つ一部のボリュームタイプでは、限定的に複数インスタンスからアクセス可能。 EBS gp3: $0.096/GB/月 + IOPS/スループット料金
Amazon EFS 複数コンテナから同時にアクセスできる共有ファイルシステム。アクセス量に応じてIOPSとスループットがスケール。 EFS Standard: $0.30/GB/月
Amazon S3 静的ファイルやオブジェクトデータ用。直接的なファイルシステムアクセスには不向き。 S3 Standard: $0.025/GB/月

本番環境では、これらのマネージドストレージの権限設定にIAMポリシーを適用し、コンテナがアクセスできるリソースを厳密に管理することが不可欠です。

 

 

A. EBS (デフォルト)

  • 特徴: EC2インスタンスに直接アタッチされるブロックストレージ。高速アクセスが可能。
  • ノウハウ・Tips:
    • バックアップ: 定期的なEBSスナップショット取得を自動化しましょう(AWS Backupを利用すると便利)。
    • パフォーマンス: gp3タイプを選択し、必要に応じてIOPSやスループットを調整することで、コストを最適化しつつ性能を確保できます。
  • 注意点:
    • 容量拡張は比較的容易ですが、容量不足に陥るとDifyが停止するリスクがあります。CloudWatchでの監視が重要です。
    • 単一インスタンスに紐づくため、複数インスタンス構成(冗長化など)でのデータ共有には向きません。

 

B. Amazon S3連携 (推奨)

  • 特徴: 高い耐久性・可用性・スケーラビリティを持つオブジェクトストレージ。容量あたりのコストが非常に安い。
  • ノウハウ・Tips:
    • コスト削減: S3 Intelligent-Tiering を利用すると、アクセスパターンに応じて自動的にストレージクラスが最適化され、コストを削減できます。ライフサイクルポリシーを設定し、不要になった古いオブジェクト(ログなど)を自動削除または低コストなアーカイブストレージ(Glacier)に移動させることも有効です。
    • VPCエンドポイント: EC2インスタンスとS3間の通信をAWSネットワーク内で完結させる**VPCエンドポイント(Gateway型またはInterface型)**を利用することで、セキュリティが向上し、データ転送料金も節約できます。
    • アクセスキー管理: Dify標準機能ではIAMロールが使えないため、IAMユーザーのアクセスキーが必要です。AWS Secrets Managerにキーを保存し、アプリケーションから安全に取得する仕組みを導入することを強く推奨します。環境変数ファイルに直接書き込むのは避けましょう。アクセスキーは定期的にローテーションすることも重要です。
  • 設定手順概要: (詳細は別記事参照)
    1. Dify用S3バケット作成。
    2. IAMユーザー作成とアクセスキー取得(+適切なIAMポリシー設定)。
    3. EC2インスタンス上で環境変数設定(STORAGE_TYPE='s3' 他)。
    4. Difyコンテナ再起動。

 

C. Amazon EFS (選択肢の一つ)

  • 特徴: 複数インスタンスから同時にマウント可能な共有ファイルシステム (NFS)。
  • ノウハウ・Tips:
    • 複数インスタンス構成: Difyを複数のEC2インスタンスで冗長構成にする場合や、Auto Scalingでインスタンスが増減する場合のデータ共有に適しています。
    • コスト: S3より高価ですが、EBSより柔軟な共有が可能です。アクセス頻度が低い場合は**EFS IA (低頻度アクセス)**ストレージクラスを利用するとコストを抑えられます。
  • 注意点:
    • Difyの標準機能でEFSを直接ストレージバックエンドとして指定することはできません。EFSをEC2インスタンスにマウントし、そのマウントポイントをDockerのバインドマウントとしてコンテナに渡す形になります。設定がやや複雑になります。

 

3. LLM連携:Amazon Bedrock活用のノウハウ

AWS環境の大きな利点であるBedrock連携を最大限に活用しましょう。

  • IAMロールの活用: EC2インスタンスにBedrockへのアクセス権限を持つIAMロールをアタッチすれば、Dify設定画面でのクレデンシャル入力が一切不要になります。これが最も安全で推奨される方法です。
  • モデル選定: Bedrockでは多様なモデルが利用可能です。コスト(入力/出力トークン単価)、性能(精度、応答速度)、得意分野(テキスト生成、要約、コード生成など)を比較検討し、ユースケースに最適なモデルを選びましょう。まずは低コストなモデルで試し、必要に応じて高性能なモデルに切り替えるのが良いでしょう。
  • モデルアクセスの有効化: 利用したいモデルは、事前にAWSマネジメントコンソールのBedrock画面でアクセスを有効化しておく必要があります。忘れがちなポイントです。
  • リージョン: Bedrockが利用可能なリージョンと、DifyをデプロイするEC2インスタンスのリージョンを合わせるのが基本です。異なるリージョンのBedrockを利用することも可能ですが、レイテンシ(遅延)が大きくなる可能性があります。

IAMユーザ(アクセスキー)の作成

DifyからS3バケットにアクセスするためのIAMユーザを作成し、アクセスキーとシークレットアクセスキーを取得します。

IAMポリシーについては、今回は AmazonS3FullAccess をアタッチしました。
自環境のセキュリティ要件などに従って設定してください。
また、S3を作成する際にKMSの暗号化を有効化した場合、KMSキーの利用に必要な権限もあわせて付与します。
image.png

当初、IAMユーザ(アクセスキー)ではなくIAMロールで制御したいと思っていたんですが、現状のDifyの標準機能ではIAMロールは対応しておらず、アクセスキーの利用が必要となるようです。

# IAMロールでやろうとしたときに出たエラー
api-1 | botocore.exceptions.ClientError: An error occurred (AuthorizationHeaderMalformed) when calling the PutObject operation: The authorization header is malformed; a non-empty Access Key (AKID) mustbe provided in the credential.

Difyが稼働するサーバでの環境変数の設定

Difyが稼働するサーバに接続し、以下の環境変数を設定します。

環境変数名
STORAGE_TYPE s3
STORAGE_LOCAL_PATH storage
S3_ENDPOINT https://s3.(リージョン名).amazonaws.com
(例)https://s3.us-west-2.amazonaws.com 
S3_BUCKET_NAME 1. S3バケットの作成 で作成したバケットの名前
(例)dify-s3-bucket
S3_ACCESS_KEY 2. IAMユーザ(アクセスキー)の作成 で取得したアクセスキーの値
S3_SECRET_KEY 2. IAMユーザ(アクセスキー)の作成 で取得したシークレットアクセスキーの値
S3_REGION ※S3バケットを作成したリージョン
(例)us-west-2

各環境変数についての詳細は公式ドキュメント「環境変数の説明」をご確認ください。

Linux環境では、以下のコマンドで設定できます。
ついでに、/etc/profile にも書いておきましょう。

export STORAGE_TYPE='s3'
export STORAGE_LOCAL_PATH='storage'
export S3_ENDPOINT='https://s3.us-west-2.amazonaws.com'
export S3_BUCKET_NAME='dify-s3-bucket'
export S3_ACCESS_KEY='xxxxxxxxxxxxx'
export S3_SECRET_KEY='yyyyyyyyyyyyyyyyyyyyyyyyyyyy'
export S3_REGION='us-west-2'

ここまで来たら、サービスを再起動します。

cd dify/docker

#-d オプションをつけて、バックグラウンドで起動
docker compose up -d

dify/docker/docker-compose.yaml の中身を見てみると、以下のような記述があり、ホストの環境変数を利用しているのが分かります。

  S3_ENDPOINT: ${S3_ENDPOINT:-}
  S3_BUCKET_NAME: ${S3_BUCKET_NAME:-}
  S3_ACCESS_KEY: ${S3_ACCESS_KEY:-}
  S3_SECRET_KEY: ${S3_SECRET_KEY:-}
  S3_REGION: ${S3_REGION:-us-east-1}

LLM (Bedrock) 設定

※モデルへのアクセスは有効であること

※適当に 1 つモデル ID をコピーします

※IAM Role が割り当てられているため、アクセスキー設定は不要です

 

4. ネットワークとセキュリティ:実践的な設定ノウハウ

クラウド環境ではセキュリティ設定が非常に重要です。

  • VPCとサブネット: 可能であれば、パブリックサブネット(インターネットからのアクセスを受けるALBやNginxなど)とプライベートサブネット(Dify本体のEC2インスタンスやRDSなど)を分離する構成を検討しましょう。これにより、Difyインスタンスが直接インターネットに晒されるのを防ぎ、セキュリティが向上します。
  • セキュリティグループ: 最小権限の原則を徹底します。
    • SSH (22番): 自分のIPアドレス(または会社の固定IP)からのみ許可するように設定します。全開放 (0.0.0.0/0) は絶対に避けましょう。
    • HTTP/HTTPS (80/443): Difyへのアクセス元IPを特定できる場合は制限します。不特定多数からのアクセスを許可する場合は、AWS WAF (Web Application Firewall) の導入を検討し、不正アクセスをブロックします。
    • 内部通信: EC2インスタンスからRDSやElastiCacheなど他のAWSサービスへ接続する場合、セキュリティグループ間で必要なポートのみを許可するように設定します。
  • HTTPS化 (必須): 本番環境ではHTTPS化が必須です。AWS Certificate Manager (ACM) を利用すれば、無料でSSL/TLS証明書を発行・管理できます。Application Load Balancer (ALB) をEC2インスタンスの前に配置し、ALBでSSL終端を行う構成が一般的で、証明書の管理も容易になります。または、ホストOS上のNginxでLet’s Encryptを使う方法もあります。(参考: Nginxリバースプロキシガイド, Let’s Encryptガイド

 

5. 運用と監視:安定稼働のためのノウハウ

デプロイして終わりではなく、安定稼働のための運用体制を整えましょう。

  • 監視 (CloudWatch):
    • 基本的なメトリクス: EC2インスタンスのCPU使用率、メモリ使用率、ディスクI/O、ネットワークトラフィックなどをCloudWatch Metricsで監視します。
    • アラーム設定: CPU使用率が一定期間80%を超える、ディスク空き容量が10%未満になる、などの閾値を設定し、CloudWatch Alarmsで通知(メール、Slackなど)を受け取るように設定します。これにより、問題発生を早期に検知できます。
    • ログ: DockerコンテナのログをCloudWatch Logsに集約するように設定すると、ログの検索や分析、アラート設定が容易になります (Dockerのawslogsログドライバーを使用)。
  • コスト管理:
    • AWS Cost Explorer: 定期的にコストを確認し、想定外の費用が発生していないかチェックします。
    • 予算アラート: AWS Budgetsで予算を設定し、予算を超過しそうな場合にアラートを受け取るように設定します。
    • タグ付け: EC2インスタンスやEBSボリュームなどのリソースに適切なタグ(例: Project: Dify, Environment: Production)を付与することで、コストの内訳分析が容易になります。
  • バックアップ:
    • EBS: AWS Backupを利用して、EBSスナップショットの取得スケジュール(例: 毎日深夜)と保持期間(例: 7世代)を自動化します。
    • S3: バケットのバージョニングを有効にしておくと、誤ってファイルを削除・上書きした場合でも過去のバージョンを復元できます。クロスリージョンレプリケーションを設定すれば、災害対策にもなります。
  • アップデート: Dify本体やOS、Dockerなどのアップデート情報を定期的にチェックし、計画的に適用してセキュリティを維持します。アップデート前には必ずバックアップを取得しましょう。

 

まとめ

AWS環境でDifyを構築・運用する際は、ローカル環境にはない多くの選択肢と考慮事項があります。

  • 環境選択: Lightsailの手軽さか、EC2の柔軟性か。将来的な拡張性を見据えて選択しましょう。
  • ストレージ: S3連携はスケーラビリティとコスト面で大きなメリットがありますが、アクセスキーの安全な管理が重要です。
  • セキュリティ: IAMロール、セキュリティグループ、HTTPS化は必須と考え、最小権限の原則を徹底しましょう。
  • コスト: クラウドのメリットを活かすためにも、コスト監視と最適化を意識した運用が必要です。
  • 運用: 監視、バックアップ、アップデートの体制を整えることで、安定したサービス提供が可能になります。

これらの注意点とノウハウを踏まえ、ご自身の要件やスキルレベルに合った構成を選択し、安全で安定したDify環境をAWS上に構築・運用してください。

コメント

error: Content is protected !!