Skip to main content

AgentBuilder 最佳實務

本指南提供在 Kubernetes 上的生產環境中部署 AgentBuilder 的最佳實務。

資源和擴展​

AgentBuilder 的最低資源需求因部署類型而異：

  • IDE（開發）：部署 AgentBuilder 視覺編輯器（前端）和 API（後端）。通常，這用於開發環境，開發人員在其中使用視覺編輯器建立和管理FLOW，然後打包並通過生產運行時部署提供服務。

    前端服務每個實例需要至少 512Mi RAM 和 0.3 CPU，1 個複本。

    後端服務每個實例需要至少 1Gi RAM 和 0.5 CPU，1 個複本。

  • 運行時（生產）：為生產FLOW部署 AgentBuilder 運行時，這是無頭（僅後端）服務，專注於提供 AgentBuilder API。這用於生產環境，其中FLOW以程式設計方式執行，而不需要視覺編輯器。

    最低需求包括每個實例 2Gi RAM 和 1000m（1 CPU），3 個複本。

更多關於 AgentBuilder 部署類型的資訊，請參閱 Kubernetes 上的 AgentBuilder 架構。

估計、測試和調整​

從最低推薦資源和複本開始，然後根據您的部署需求和效能測試監控和擴展。 在您的資源估計和效能測試中考慮以下因素：

  • FLOW複雜度。

  • 並發使用者和請求的數量。

    對於 IDE（開發）部署，請考慮前端活動也會 ping 後端服務，因此您通常需要一起擴展前端和後端。

  • 請求有效載荷內容和大小，特別是在生產部署中的檔案上傳。

  • 快取、檔案管理和 AgentBuilder 資料庫的儲存需求。

    生產部署推薦使用外部 PostgreSQL 資料庫。

  • 可能需要更多資源的基礎設施選項，例如多核心 CPU。

使用外部 PostgreSQL 資料庫​

外部 PostgreSQL 資料庫推薦用於生產部署，以改善可擴展性和可靠性，相較於預設的 SQLite 資料庫。

您的資源分配和複製策略必須能夠支援 PostgreSQL 服務和儲存。 例如，對於運行時（生產）部署，您可能為高可用性分配 4Gi RAM、2 CPU 和多個複本。 根據資源需求和使用指標，視需要調整 PostgreSQL 參數，例如 work_mem 和 shared_buffers。

推薦配置包括：

  • 持久性儲存以防止容器關閉時資料遺失
  • 高可用性 (HA) 或主動-主動以進行自動故障轉移、擴展和負載平衡
  • 多實例部署的共享資料庫
  • 多實例部署的共享儲存，例如 NFS 或雲端儲存，以存取儲存在磁碟上的大型檔案，例如 /opt/langflow/data/。

更多資訊請參閱配置外部 PostgreSQL 資料庫 和 企業 DBA 的 AgentBuilder 資料庫指南。

使用 HPA 進行動態擴展​

負載平衡和動態擴展推薦用於運行時（生產）部署。

例如，考慮在 Kubernetes 中使用 Horizontal Pod Autoscaler (HPA) 根據 CPU 或記憶體使用率動態擴展。 以下範例顯示具有基於 CPU 的擴展的 AgentBuilder HPA 配置：


_18
apiVersion: autoscaling/v2
_18
kind: HorizontalPodAutoscaler
_18
metadata:
_18
name: langflow-runtime-hpa
_18
spec:
_18
scaleTargetRef:
_18
apiVersion: apps/v1
_18
kind: Deployment
_18
name: langflow-runtime
_18
minReplicas: 1
_18
maxReplicas: 10
_18
metrics:
_18
- type: Resource
_18
resource:
_18
name: cpu
_18
target:
_18
type: Utilization
_18
averageUtilization: 80

故障點​

AgentBuilder 在生產中的可靠性取決於減輕關鍵故障點，特別是圍繞資料庫、檔案系統和實例可用性：

  • 資料庫故障：請參閱企業 DBA 的 AgentBuilder 資料庫指南。
  • 檔案系統故障：在多實例設定中檔案快取的並發問題，例如 /app/data/.cache，可能導致 IO 錯誤。 為避免此問題，請使用共享的 POSIX 相容檔案系統或雲端儲存。 使用持久性卷而不是在容器關閉時導致資料遺失的 ramdisk 解決方案。
  • 實例故障：部署多個複本以避免單一實例故障時的服務中斷。使用健康檢查來檢測和替換故障的 pod。
  • 網路和依賴故障：FLOW中使用的外部 API 或服務可能故障，導致FLOW錯誤。在FLOW或應用程式程式碼中實施重試邏輯和錯誤處理。監控網路延遲和依賴健康。

監控​

有效的監控確保 AgentBuilder 在不同負載下可靠運行並表現良好：

  • 資料庫監控：請參閱企業 DBA 的 AgentBuilder 資料庫指南。

  • 應用程式日誌：收集和分析錯誤、警告和FLOW執行問題的日誌。使用 ELK Stack 或 Fluentd 等工具集中日誌。您也可以檢查 AgentBuilder 日誌。

  • 資源使用率：追蹤 AgentBuilder 實例的 CPU、記憶體和磁碟使用率。在 Kubernetes 中使用 Prometheus 和 Grafana 進行即時指標收集和監控。

    要暴露您的 AgentBuilder 伺服器的 Prometheus 指標，請設定 LANGFLOW_PROMETHEUS_ENABLED=True（預設為 false）。 Prometheus 指標的預設端口是 9090。 要更改端口，請設定 LANGFLOW_PROMETHEUS_PORT。

  • API 效能：監控回應時間、錯誤率和請求吞吐量。為高延遲或錯誤峰值設定警報。

  • 可觀測性工具：與 LangWatch 或 Opik 整合以進行詳細的FLOW追蹤和指標。使用這些工具來除錯FLOW效能並優化執行。

安全性​

在生產中運行 AgentBuilder 需要強大的安全措施來保護應用程式、資料和使用者。 遵循行業最佳實務並使用安全的 AgentBuilder 配置，例如以下：

  • 容器安全性：為容器化應用程式應用安全最佳實務。例如，在運行時（生產）容器中設定 readOnlyRootFilesystem: true 以防止未經授權的修改。限制對包含敏感資料和不應暴露給未經授權使用者的配置檔案的檔案和程式碼庫的存取。
  • 秘密管理：將敏感資料（如 API 金鑰和 PostgreSQL 憑證）儲存在 Kubernetes 秘密或外部秘密管理器中，如 HashiCorp Vault。
  • 認證、授權和存取控制：如 API 金鑰和認證 中所述，使用啟用認證的 AgentBuilder 伺服器啟動。使用防火牆、網路政策、網路安全群組或 VPC 限制網路和資源存取。例如，將 PostgreSQL 資料庫存取限制為 AgentBuilder 實例。
  • 加密和隱私：遵循資料隱私和傳輸中及靜態資料加密的行業最佳實務和法律要求，包括 GDPR 要求、HTTPS、TLS 和 SSL。例如，使用有效 SSL 憑證配置 PostgreSQL，並將 ?sslmode=require 或 ?sslmode=verify-full 附加到連接字串以啟用資料庫連接的 SSL。
  • 安全性姿勢維護：進行定期安全稽核、保持軟體更新最新，並使用入侵檢測系統監控可疑活動。

另請參閱​

Search