本番環境 vs 検証環境 – 構成差異・リソース設計・セキュリティ強化の実務ガイド

Dify Enterprise を検証環境で動かせたからといって、そのまま本番に持っていけるわけではない。検証環境と本番環境の違いは「ユーザー数が増える」程度の話ではなく、可用性・可観測性・復旧能力という根本的なリスクモデルが異なる。

Dify Enterprise の公式ドキュメント（Resources Checklist）では、testing deployment と production deployment の 2 種類の推奨スペックが明示されている。検証環境は worker node 1 台・4 CPU / 16 GB RAM 程度で済むが、本番環境は worker node 6 台・各 8 CPU / 32 GB RAM に加え、PostgreSQL・Redis・Qdrant もクラスタ構成での運用が前提となる。つまり公式が「検証」と「本番」を完全に別のリスクモデルとして定義している。

本記事では、日本企業のエンタープライズ IT チームが Dify Enterprise を本番展開する際に押さえるべき構成差異を、リソース・永続化・ログ・セキュリティ・バックアップの 5 軸で整理する。

1. リソースサイジングの違い

1.1 公式推奨スペック比較

1.2 Kubernetes リソース定義の考え方

検証環境では resources.requests / resources.limits を明示しなくても動作するが、本番では必ず定義する。以下は本番向けの参考値である。

# values.yaml -- 本番環境向け API サーバーのリソース例
api:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

worker:
  replicas: 3
  resources:
    requests:
      cpu: "2"
      memory: "4Gi"
    limits:
      cpu: "4"
      memory: "8Gi"

web:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "1Gi"
    limits:
      cpu: "1"
      memory: "2Gi"

sandbox:
  replicas: 2
  resources:
    requests:
      cpu: "500m"
      memory: "512Mi"
    limits:
      cpu: "1"
      memory: "1Gi"

1.3 レプリカ数の設計指針

ポイント: Alibaba Cloud ACK のベストプラクティス記事でも、本番環境では API / Worker / Web / Sandbox の多レプリカ配置が明示的に推奨されている。

2. 永続化（Persistence）の違い

2.1 検証環境

検証環境では emptyDir や Node ローカルストレージでも問題ない。目的は機能検証であり、データの耐久性は求めない。

# 検証環境 -- 永続化を最小限に
persistence:
  enabled: false

2.2 本番環境

本番では以下をすべて外部の永続化ストレージに接続する。

# 本番環境 -- 外部依存の明示
externalPostgres:
  enabled: true
  host: "dify-prod-pg.ap-northeast-1.rds.amazonaws.com"
  port: 5432
  username: "dify"
  database: "dify_production"
  existingSecret: "dify-pg-credentials"
  existingSecretPasswordKey: "password"

externalRedis:
  enabled: true
  host: "dify-prod-redis.xxxxx.apne1.cache.amazonaws.com"
  port: 6379
  existingSecret: "dify-redis-credentials"
  existingSecretPasswordKey: "password"

externalS3:
  enabled: true
  bucket: "dify-prod-storage"
  region: "ap-northeast-1"
  existingSecret: "dify-s3-credentials"

2.3 永続化チェックリスト

• PostgreSQL: RDS / Cloud SQL 等のマネージド DB を利用し、自動バックアップを有効化
• Redis: ElastiCache / Memorystore 等のマネージドサービスを利用
• Vector DB (Qdrant): 永続ボリューム (PVC) または外部クラスタを利用
• オブジェクトストレージ: S3 / GCS / Azure Blob のバージョニングを有効化
• values.yaml 自体を Git リポジトリで管理

3. ログレベルとオブザーバビリティ

3.1 検証環境のログ設定

検証環境では DEBUG レベルを有効にし、問題の早期発見と挙動確認を優先する。

# 検証環境
env:
  LOG_LEVEL: "DEBUG"

3.2 本番環境のログ設定

本番で DEBUG を常時有効にすると、ログ量が爆発してストレージコストとノイズが増大する。通常は WARNING 以上とし、必要に応じて一時的に INFO へ下げる運用とする。

# 本番環境
env:
  LOG_LEVEL: "WARNING"

3.3 本番で収集すべきログカテゴリ

3.4 オブザーバビリティスタックの推奨構成

graph LR
    A[Dify Pods] -->|stdout/stderr| B[Fluentd / Fluent Bit]
    B --> C[Elasticsearch / OpenSearch]
    C --> D[Kibana / Grafana]
    A -->|metrics| E[Prometheus]
    E --> D
    A -->|traces| F[Jaeger / Tempo]
    F --> D

本番環境では最低限 メトリクス (Prometheus) と ログ集約 (Fluentd + Elasticsearch) を導入する。Workflow の実行遅延やエラー率を可視化するダッシュボードを作成しておくと、障害の初動対応が大幅に改善される。

4. セキュリティ強化

4.1 シークレット管理

検証環境ではデフォルトの Secret 値をそのまま使いがちだが、本番では絶対に変更する。

# 本番環境 -- 必ず変更すべき Secret
api:
  secretKey: ""  # 外部 Secret Manager から注入
  innerApiKey: ""  # 同上

# Kubernetes Secret で管理する例
# kubectl create secret generic dify-secrets \
#   --from-literal=SECRET_KEY=$(openssl rand -hex 32) \
#   --from-literal=INNER_API_KEY=$(openssl rand -hex 32)

4.2 ネットワークポリシー

Sandbox コンテナはユーザーが投入するコードを実行するため、本番では NetworkPolicy で外部通信を厳密に制限する。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: sandbox-restrict
spec:
  podSelector:
    matchLabels:
      app: dify-sandbox
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: dify-api
      ports:
        - port: 5001
    # 外部インターネットへの通信はブロック

4.3 Ingress TLS

ingress:
  enabled: true
  className: "nginx"
  annotations:
    cert-manager.io/cluster-issuer: "letsencrypt-prod"
  tls:
    - secretName: dify-tls
      hosts:
        - console.dify.example.co.jp
        - api.dify.example.co.jp
  hosts:
    - host: console.dify.example.co.jp
      paths:
        - path: /
          pathType: Prefix

4.4 セキュリティチェックリスト

5. バックアップ戦略

5.1 検証環境

検証環境ではバックアップ頻度は低くてよい。環境の再構築が容易であることを重視する。

5.2 本番環境のバックアップ設計

5.3 復旧テストの実施

バックアップは取得するだけでは不十分である。四半期に 1 回以上、以下の復旧テストを実施することを推奨する。

1. PostgreSQL のスナップショットから新規インスタンスを復元し、Dify が正常起動するか確認
2. オブジェクトストレージの特定バージョンへのロールバックを検証
3. Velero によるクラスタ全体の復元手順を確認
4. 復旧時間（RTO）と復旧ポイント（RPO）が SLA 要件を満たしているか検証

6. 環境分離のベストプラクティス

6.1 推奨構成

graph TB
    subgraph "本番クラスタ"
        A[namespace: dify-production]
    end
    subgraph "ステージングクラスタ"
        B[namespace: dify-staging]
    end
    subgraph "検証クラスタ"
        C[namespace: dify-testing]
    end
    D[GitOps リポジトリ] --> A
    D --> B
    D --> C

6.2 values.yaml の環境別管理

helm-values/
  base/
    values.yaml          # 共通パラメータ
  overlays/
    testing/
      values.yaml        # 検証固有の上書き
    staging/
      values.yaml        # ステージング固有の上書き
    production/
      values.yaml        # 本番固有の上書き

各環境の values.yaml は Kustomize 風にベースを継承し、環境固有の差分のみを上書きする。これにより、検証と本番の構成ドリフトを防止できる。

6.3 環境ごとの License 管理

Dify Enterprise の License は Kubernetes namespace に紐づくため、環境ごとに個別の License が必要となる。License の台帳管理については「04-License-管理実務」の記事を参照のこと。

7. まとめ – 本番移行チェックリスト

本番移行前に以下を確認する。

• リソース定義（CPU / Memory の requests / limits）が全コンポーネントに設定済み
• レプリカ数が可用性要件を満たしている（API / Worker は 3 以上）
• PostgreSQL / Redis / オブジェクトストレージが外部マネージドサービスに接続済み
• Secret がすべてランダム生成値に置き換え済み
• TLS 終端が設定済み
• Sandbox の NetworkPolicy が適用済み
• ログレベルが WARNING 以上に設定済み
• ログ集約基盤（Fluentd + Elasticsearch 等）が稼働中
• バックアップが自動化され、復旧テスト済み
• values.yaml が Git 管理下にある
• License が本番 namespace で有効化済み
• ステージング環境で本番相当の負荷テストを実施済み

検証環境は「動くか確認する場所」、本番環境は「サービスを約束する場所」である。両者は同じデプロイ方法論を共有すべきだが、リスクの前提条件は根本的に異なる。この違いを構成として明示的に反映することが、安定した Dify Enterprise 運用の第一歩となる。