本記事はこちらのブログを参考にしています。
翻訳にはアリババクラウドのModelStudio(Qwen)を使用しております。

DifyをACK上でデプロイ・管理するための詳細解決策

著者: Qianlong Wang

人工知能技術の絶え間ない進歩に伴い、GPTシリーズのような大規模言語モデル(LLMs)は多くのAIアプリケーションの中心とされています。しかし、LLMsの開発、デプロイ、保守、最適化には複雑な一連の実践とプロセスが関与し、これをLLMOpsと呼ばれます。ユーザーが簡単にLLMアプリケーションを作成・管理できるよう、使いやすいLLMOpsプラットフォームであるDifyが登場しました。現在、DifyはDocker Composeとソースコードに基づくローカルデプロイを公式にサポートしていますが、これらの方法は高可用性と拡張性に欠け、本番環境には向いていません。一方、Kubernetes向けコンテナサービス（ACK）は、高性能なコンテナアプリケーション管理を提供し、企業向けKubernetesコンテナアプリケーションのライフサイクル管理をサポートし、標準的なサービス水準契約（SLA）に沿った補償条項付きで、安定性と安全性に対する高い要求を持つ大規模なビジネス環境に適しています。さらに、ACKは豊富なクラウド製品とシームレスに統合し、Difyの全体パフォーマンスを大幅に向上させます。ACKを使用することで、高可用性、拡張性、高SLAを持ったDifyサービスを簡単にデプロイし、本番環境の要件を満たすことができます。この記事では、ACKクラスター上での高可用性、拡張性、高SLAを持つDifyサービスのデプロイと管理に関する詳細な解決策を提供します。

Difyについて

LLMOpsは、大規模言語モデルの開発からデプロイ、保守、最適化までをカバーする一連の実践とプロセスの総称であり、その核心的な目標は大規模言語モデルの複雑さに対処することです。データ収集、アーキテクチャ設計、トレーニング、ファインチューニング、テスト、デプロイ、継続的なモニタリングなど、モデルの誕生から実際の応用までの全過程を含みます。LLMOpsの実践において、論理デザイン、コンテキスト強化、データ準備などの様々な課題に直面し、それらに対応するために多大な時間とエネルギーが必要となります。Difyはこれらの課題を簡単に取り組めるプラットフォームを提供し、一連の作業を容易にします。単一目的の細かな開発ツールではなく、大規模モデルアプリケーション開発のための総合プラットフォームとなっています。

Difyができること

ビジネスを立ち上げ、AIアプリケーションのアイデアを素早く現実に。成功も失敗も加速が必要です。実世界では、数十のチームがDifyを通じてMVP（Minimum Viable Product）を構築し、投資を確保したり、POC（Proof of Concept）を通じて顧客オーダーを獲得したりしています。
既存のサービスにLLMを統合し、LLMを導入して既存アプリケーションの機能を強化し、DifyのRESTful APIとの接続を通じてプロンプトとビジネスコードを分離します。
Difyの管理画面ではデータ、コスト、利用状況が追跡され、アプリケーション効果を継続的に改善します。
Difyは企業レベルのLLMインフラとして、一部の銀行や大手インターネット企業でLLMゲートウェイとして展開され、GenAI技術の普及を加速し、集中監視を実現しています。
LLMの能力を探究したい技術愛好家でも、Difyを通じてプロンプトエンジニアリングやエージェント技術を簡単に実践できます。GPTのリリース前に6万以上の開発者がDify上で初めてのアプリケーションを作成しました。

Dify on ACKアーキテクチャ

現在、DifyはDocker Composeとソースコードに基づくローカルデプロイの2つのデプロイ方法を公式にサポートしていますが、どちらも高可用性や拡張性に乏しく、開発やテスト環境での使用に適しています。これに対して、ACK上でDifyをデプロイすることで、高可用性と弾力性を得られる利点があります。Difyのコンポーネントがビジネス要件に応じて即座にスケールアウトできるため、ビジネス成長を効果的に促進します。また、クラウド製品とサービスを使用することでDifyの基本コンポーネントを置き換えることで、より高いパフォーマンスとSLAを実現できます。さらに、DifyがLLMアプリケーションをオーケストレートする際には、直接LLMサービスプロバイダーのOpenAPIを呼び出すか、ACKを使用して専用モデル推論サービスをデプロイすることができます。柔軟性とスケーラビリティによって多様な本番シーンのニーズに応えることができます。

ACK上でDifyをデプロイする

Difyアプリケーションのコンポーネントは、ビジネスコンポーネントと基本コンポーネントに分けられます。ビジネスコンポーネントにはAPI、worker、web、sandboxが含まれます。基本コンポーネントにはdb、verctor db、Redis、NGINX、ssrf_proxyが含まれます。現在、ACKコンソールのアプリケーションマーケットではack-difyアプリケーションのインストールが提供されています。デフォルトでは、基本コンポーネントにはオープンソースのRedis、postgres、Weaviateが使用されます。これら基本コンポーネントに対して高いパフォーマンス、機能、SLA要件がある場合、または基本コンポーネントの運用管理に負担を感じる場合は、以下のように私たちのクラウド製品を使用することができます：
• Tair（Redis® OSS互換）
• ApsaraDB RDS for PostgreSQL
• AnalyticDB for PostgreSQL

DifyはACKベースでクラウドサービスと統合された高可用性、弾力性のデプロイソリューションであり、安定かつ高性能なデプロイが可能です。

上記デプロイの実装方法

上記のデプロイを実現するためには、ACKのack-difyパラメータ設定インターフェイスで以下の主要な設定を行います：

クラウド製品の設定
高可用性・拡張性設定
サービスアクセス設定

1. クラウド製品の設定

このチュートリアルでは、Tair（Redis® OSS互換）、ApsaraDB RDS for PostgreSQL、AnalyticDB for PostgreSQLを使用します。以下のチュートリアルに従って事前に必要なリソースを用意することができます。
• Tair（Redis® OSS互換）
• ApsaraDB RDS for PostgreSQL
• AnalyticDB for PostgreSQL

2. 高可用性・拡張性設定

ACK上でアプリケーションをデプロイする際、多くのユーザーは障害復旧とピーク負荷への対応を強化するために高可用性と自動スケーリングを求める傾向があります。ACKでは、アプリケーションに対して以下の簡単な設定を行うことで、これらの効果を達成できます
以下は、複数のレプリカを実現するために設定できるパラメータです。

api.replicas: 2
worker.replicas: 2
web.replicas: 2
sandbox.replicas: 2

レプリカ分散: 単一ノードまたはゾーン障害による全体サービスの可用性喪失を防ぐため、通常はレプリカを分散させる必要があります。例では、ポッド間のアフィニティを構成して、同じコンポーネントのポッドを可能な限り異なるノードに配置しています。yaml
api.affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
  podAffinityTerm:
  labelSelector:
  matchExpressions:
  - key: component
  operator: In
  values:
  - api
  topologyKey: kubernetes.io/hostname

worker.affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: component
operator: In
values:
- worker
topologyKey: kubernetes.io/hostname

web.affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: component
operator: In
values:
- web
topologyKey: kubernetes.io/hostname

sandbox.affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: component
operator: In
values:
- sandbox
topologyKey: kubernetes.io/hostname

拡張性の設定: 島波負荷に対応するために、通常、リソース消費が多いコンポーネントには自動スケーリングの設定を追加します。たとえば、worker コンポーネントが大量のドキュメント知識ベースを処理するとCPU/メモリーの増加が起こりやすいため、次のような設定でworkerの自動スケーリングを実現できます。yaml
worker:
autoscaling:
enabled: true
minReplicas: 1
maxReplicas: 5
metrics:
- type: Resource
  resource:
  name: memory
  target:
  averageUtilization: 80
  type: Utilization

設定後、同じDifyコンポーネントの複数レプリカは異なるノードに分散され、workerはメモリー使用量に基づいて自動的にスケールされます。デプロイの効果は以下の通りです：shell
➜ ~ kubectl get po -n dify-system -o wide
(省略: 各ポッドの状態表示)

また、workerの自動スケーリング状況は以下のコマンドで確認できます。shell
➜ ~ kubectl get hpa -n dify-system
(省略: HPAの状態表示)

サービスアクセス設定
ACKでは、DifyサービスへのアクセスにはIngressを使用することをお勧めします。詳細については、Ingress管理をご覧ください。現在、NGINX IngressとALB Ingressの両方を設定できますが、この例ではNGINX Ingressを使用しています。セキュリティ上の理由から、tls設定を有効化することを強くお勧めします。yaml
ingress:
enabled: false
className:
annotations: {}
hosts:
- host: dify-example.local
  paths:
  - path: /
    pathType: Prefix
    backend:
    service:
    name: ack-dify
    port: 80
    tls:
- secretName: chart-example-tls
  hosts:
  - dify-example.local

成功した設定により、Difyサービスに安全かつ簡単にアクセスし、LLMアプリケーションをオーケストレーションし、既存のビジネスに統合できます。具体的な例については、Difyを使用したAI搭載Q&Aアシスタントの作成をご覧ください。

まとめ
Dify On ACKアーキテクチャは高可用性と拡張性をサポートし、ビジネス要件に基づいて迅速にスケールアウトすることができます。このデプロイ方法はクラウドサービスを統合し、より高いパフォーマンスとサービス水準契約(SLA)を提供し、Difyの安定性と可用性を大幅に向上させます。ACKを使用することで、Tair（Redis® OSS互換）、ApsaraDB for PostgreSQL、AnalyticDB for MySQLなどのApsaraDBデータベースをデフォルトのオープンソースコンポーネントに置き換え、さらに機能とパフォーマンスを向上させることができます。さらに、ACKの拡張性設定により、企業はピーク負荷に対応し、自動スケーリングを実装し、システムのディザスターリカバリ能力を向上させることができます。これにより、Difyはイノベーションプロジェクトを迅速に立ち上げるだけでなく、企業向けのエンタープライズ級LLMインフラとして活用され、GenAI技術の企業内での普及を加速することができます。まとめると、ACK上でDifyをデプロイすることで可用性とパフォーマンスが大幅に改善され、管理・操作が簡素化され、企業にとって強固なAIアプリケーション開発環境を提供します。DifyとそのACKへのデプロイメントにより、ユーザーは迅速にAIアプリケーションを実装し、効果を継続的に最適化することができます。
*RedisはRedis Ltdの登録商標です。そのすべての権利はRedis Ltdに帰属しており、アリババクラウドによるいかなる使用も参照目的のみであり、Redisとアリババクラウドとの之間のスポンサー関係、支持、または関連付けを示唆するものではありません。