高可用デプロイアーキテクチャ: 本番運用のためのリファレンス設計

Dify が PoC から本番業務に移行する段階で、高可用性（HA）は選択肢ではなく必須要件となる。本稿では、アプリケーション層のマルチレプリカ構成、データベース HA、Redis Sentinel、オブジェクトストレージ、ベクトルDB クラスタ、監視体制、災害対策まで、エンタープライズ本番環境に求められる高可用デプロイアーキテクチャを体系的に解説する。

全体アーキテクチャの概観

graph TB
    subgraph LB["ロードバランサー層"]
        ALB["ALB / NLB / Nginx Ingress"]
        WAF["WAF"]
    end

    subgraph APP["アプリケーション層（Kubernetes）"]
        API1["API Server<br/>Replica x3"]
        WEB1["Web Server<br/>Replica x2"]
        WORKER1["Worker<br/>Replica x3"]
        SANDBOX1["Sandbox<br/>Replica x2"]
    end

    subgraph DATA["データ層"]
        subgraph PG["PostgreSQL HA"]
            PG_P["Primary"]
            PG_S1["Standby 1"]
            PG_S2["Standby 2"]
        end
        subgraph RD["Redis HA"]
            RD_M["Master"]
            RD_R1["Replica 1"]
            RD_R2["Replica 2"]
            RD_S["Sentinel x3"]
        end
        S3_["S3 / MinIO<br/>（オブジェクトストレージ）"]
        subgraph VDB["ベクトルDB HA"]
            VDB1["Node 1"]
            VDB2["Node 2"]
            VDB3["Node 3"]
        end
    end

    subgraph MON["監視・可観測性"]
        PROM["Prometheus"]
        GRAF["Grafana"]
        ALERT["AlertManager"]
        LOG["Loki / EFK"]
    end

    ALB --> API1
    ALB --> WEB1
    API1 --> PG_P
    API1 --> RD_M
    API1 --> S3_
    API1 --> VDB1
    WORKER1 --> PG_P
    WORKER1 --> RD_M
    WORKER1 --> S3_
    WORKER1 --> VDB1
    PROM --> APP
    PROM --> DATA

Dify のコンポーネント構成と HA 要件

各コンポーネントの役割と可用性要件

アプリケーション層の HA 設計

Kubernetes デプロイ構成

API Server Deployment の設計ポイント:

• replicas: 3 以上、RollingUpdate 戦略（maxUnavailable: 1, maxSurge: 1）
• podAntiAffinity: topology.kubernetes.io/zone をキーにした AZ 分散配置
• リソース: requests (CPU: 1, Memory: 2Gi) / limits (CPU: 2, Memory: 4Gi)
• ヘルスチェック: readinessProbe（30秒後開始、10秒間隔）、livenessProbe（60秒後開始、30秒間隔）で /health エンドポイントを監視

スケーリング戦略

Pod Disruption Budget

メンテナンス時やノード障害時でも最低限のレプリカを維持するため、PodDisruptionBudget で minAvailable: 2 を設定する。

データ層の HA 設計

PostgreSQL HA

PostgreSQL は Dify の全メタデータを格納する最重要コンポーネントである。

推奨構成（AWS の場合）:

graph LR
    subgraph AZ1["AZ-a"]
        PGP["PostgreSQL Primary<br/>db.r6g.xlarge"]
    end
    subgraph AZ2["AZ-c"]
        PGS["PostgreSQL Standby<br/>db.r6g.xlarge"]
    end
    
    PGP -->|"同期レプリケーション"| PGS
    PGP -->|"自動バックアップ"| S3B["S3<br/>バックアップ"]

設計ポイント:

• 自動フェイルオーバーの RTO: 60-120秒（RDS Multi-AZ の場合）
• バックアップ保持期間: 最低 7日、推奨 35日
• Point-in-Time Recovery: 5分間隔
• 接続プーリング: PgBouncer の導入を推奨（API Server のコネクション数管理）

Redis HA

Redis はセッション管理、キャッシュ、タスクキュー（Celery）に使用される。

Redis Sentinel 構成例:

graph TB
    subgraph Sentinels["Sentinel クラスタ"]
        S1["Sentinel 1"]
        S2["Sentinel 2"]
        S3["Sentinel 3"]
    end
    
    subgraph RedisNodes["Redis ノード"]
        RM["Master<br/>r6g.large"]
        RR1["Replica 1<br/>r6g.large"]
        RR2["Replica 2<br/>r6g.large"]
    end
    
    S1 ---|監視| RM
    S2 ---|監視| RM
    S3 ---|監視| RM
    RM -->|レプリケーション| RR1
    RM -->|レプリケーション| RR2

設計ポイント:

• Sentinel は最低3台（奇数台）で quorum を構成
• maxmemory-policy: allkeys-lru を推奨
• メモリサイジング: アクティブセッション数 x 平均セッションサイズ + キャッシュ + タスクキュー

オブジェクトストレージ

マネージドオブジェクトストレージは本質的に高可用であるため、アプリケーション側の接続設定（リトライ、タイムアウト）に注意すれば十分。

ベクトルDB HA

ネットワーク層の設計

Ingress / ロードバランサー構成

graph TB
    INTERNET["インターネット / 社内ネットワーク"] --> WAF2["WAF<br/>（AWS WAF / ModSecurity）"]
    WAF2 --> ALB2["Application Load Balancer<br/>（Multi-AZ）"]
    ALB2 --> ING["Kubernetes Ingress Controller<br/>（Nginx / ALB Ingress）"]
    
    ING --> SVC_API["Service: dify-api"]
    ING --> SVC_WEB["Service: dify-web"]
    
    SVC_API --> POD_API1["API Pod 1"]
    SVC_API --> POD_API2["API Pod 2"]
    SVC_API --> POD_API3["API Pod 3"]

設計ポイント:

• TLS 終端は ALB / Ingress Controller で実施
• WebSocket 対応（Streaming 応答のため）: Ingress Controller の timeout 設定を延長
• レート制限: WAF または Ingress レベルで設定
• IP ホワイトリスト: 社内ネットワークからのアクセスに限定（エンタープライズ標準）

サイジングガイドライン

規模別推奨構成

月額コスト概算（AWS, 東京リージョン）

※ LLM API 利用料は含まず。実際のコストは利用パターンにより大幅に変動する。

監視・可観測性

監視スタック構成

重要アラート設定

災害対策（DR）設計

RPO / RTO の設計指針と DR 構成パターン

業界ごとの RPO/RTO 要件に応じて DR 構成を選択する。金融業界では RPO < 1分 / RTO < 15分が求められ、ウォームスタンバイ以上が必要。製造業では RPO/RTO ともに1時間以内、小売・社内ツールでは4-24時間が一般的な目安となる。

バックアップ戦略

DR 訓練

災害対策は設計だけでは不十分であり、定期的な訓練が不可欠である。月次でバックアップリストアテストとカオスエンジニアリング（Pod/ノード障害シミュレーション）を実施し、四半期で DB/Redis フェイルオーバーテスト、半年で DR リージョン切替の end-to-end テストを行うことを推奨する。

デプロイパイプライン

GitOps（ArgoCD / Flux）ベースのデプロイフローを推奨する。Git Push → CI Pipeline（テスト + イメージビルド）→ Container Registry → ArgoCD 差分検知 → Staging 自動デプロイ → 承認 → Production ローリングアップデートの流れで、maxUnavailable: 1 / maxSurge: 1 の設定により、常に N-1 のレプリカがリクエストを処理し続ける。問題発生時は kubectl rollout undo で即座にロールバック可能。

まとめ

Dify の高可用デプロイアーキテクチャは、アプリケーション層のマルチレプリカ化だけでは完結しない。PostgreSQL、Redis、オブジェクトストレージ、ベクトルDB のデータ層 HA、ネットワーク層の冗長化、監視・アラート体制、そして災害対策まで、全レイヤーを体系的に設計する必要がある。

日本の金融機関や製造業では、既存の DR 基準や監査要件との整合性が求められるため、自社の非機能要件を明確にした上で、本稿のリファレンスアーキテクチャを自社環境に適合させることを推奨する。まずは中規模構成で本番運用を開始し、利用拡大に応じて段階的にスケールアウトするアプローチが、コストとリスクのバランスとして最も現実的である。

参考資料

• Dify Enterprise Resources Checklist: 公式ドキュメント
• Dify Kubernetes デプロイ: 公式ドキュメント
• ACK ベストプラクティス: Alibaba Cloud Blog