English {#english}
Intelligent Automation Implementation Plan
Purpose : Stepwise plan to implement end-to-end automation, monitoring, and AI server placement as defined in saas-unified-architecture-hetzner-cloudflare-zuplo-plan §9 and tenant-provisioning-flow §B.No code generation — implementation order, deliverables, and dependencies only.
1. Reference plans
saas-unified-architecture-hetzner-cloudflare-zuplo-plan.md §9: intelligent automation (full pipeline, monitoring, AI placement).tenant-provisioning-flow.md §A, §B: provisioning flow; Control Plane monitoring and AI placement.api-control-plane-implementation-plan.md §1–§21: unified Control Plane (phases, contract, queues, observability, security, runbook, backup, verification).
2. Implementation order and dependencies
Order : [1] Pulumi (skip if exists). [2] D1 schema (nodes, server_metrics, provision_jobs columns) → [3] Ansible playbook/roles + [4] zuplo_sync → [5] End-to-end workflow (Pulumi → Ansible → Zuplo → callback) → [6] Resource/usage monitoring collection → [7] AI placement engine (rules or model) → [8] Control Plane Webhook: call placement then trigger workflow/Worker with job_id, tenant_id, region, target_server_id/create_new_server.
Dependencies : [2] required for [5][6][7]. [3][4] required for [5]. [6] required for [7]. [8] after [5][7].
3–5. Deliverables, verification, references
§3.1 D1 : Migration 0007 — nodes (fqdn, max_tenants), server_metrics, provision_jobs (target_server_id, create_new_server).§3.2 Ansible + Zuplo Sync : prego-ansible playbook, roles (docker, frappe_site), artifacts/tenant_api_key.txt; zuplo_sync.ts; provision-tenant-pipeline runbook. Ansible scope: Vectorize/tenant DNS out of scope per pulumi-ansible-step1-step2 §3.§3.3 Workflow : provision-tenant-workflow-design (read first); .github/workflows/provision-tenant.yml or Provision Worker; runbook.§3.4 Monitoring : Hetzner/agent/Cron → Control Plane → D1 server_metrics/servers; tenant usage for placement; resource-optimization-safe-adoption-plan.§3.5 Placement : Rule engine (server_metrics, servers → target_server_id or create_new_server); optional ML; decidePlacement(); trace_events.§3.6 Webhook : Stripe Webhook → provision_jobs → decidePlacement() → workflow_dispatch or Provision Worker with placement result.§4 Verification : D1/Ansible/zuplo_sync/workflow/monitoring/placement/e2e checklist.§5 References : Links to saas-unified §9, tenant-provisioning-flow, IMPLEMENTATION_INDEX.
Full tables (§1, §3.1–§3.6) and exact wording are in the Korean section below.
한국어 {#korean}
지능형 자동화 구현 계획
목적 : 기획서 saas-unified-architecture-hetzner-cloudflare-zuplo-plan.md §9 , tenant-provisioning-flow.md §B 에 정의된 전 구간 자동화·모니터링·AI 서버 배치를 구현하기 위한 단계별 계획.코드 생성 없음 — 구현 순서·산출물·의존 관계만 정리.
1. 참조 기획
문서 섹션 내용 saas-unified-architecture-hetzner-cloudflare-zuplo-plan.md §9 지능형 자동화(전 구간 자동화, 모니터링, AI 배치) tenant-provisioning-flow.md §A, §B 프로비저닝 플로우, Control Plane 모니터링·AI 배치 api-control-plane-implementation-plan.md §1–§21 통합 Control Plane(5단계·Contract·Queues·보상·Observability·보안·Runbook·백업·구현 Phase·검증 조건)
2. 구현 순서 및 의존 관계
[2] D1 스키마 확장 (servers, server_metrics, provision_jobs 컬럼)
[3] Ansible playbook·롤 (Docker + Frappe + new-site + API Key)
[5] 전 구간 자동화 워크플로 (Pulumi → Ansible → Zuplo → 콜백)
[7] AI 배치 결정 엔진 (규칙 또는 모델)
[8] Control Plane Webhook에서 배치 호출 후 트리거 연동
[1] Pulumi : 이미 존재 시 스킵. 없으면 Hetzner·Cloudflare DNS/SSL·R2 연동 완료 후 진행.[2] D1 : servers, server_metrics, provision_jobs(target_server_id, create_new_server 등)가 있어야 [5][6][7] 연동 가능.[3][4] : [5] 워크플로가 Ansible·zuplo_sync를 호출하므로 선행 필요.[6] 모니터링 : [7] AI 배치가 server_metrics·servers를 읽으므로 선행.[8] : [5][7] 완료 후 Webhook에서 배치 결정 → workflow_dispatch(또는 Provision Worker) 호출 시 job_id, tenant_id, region, target_server_id/create_new_server 전달.
3. 단계별 산출물
3.1 D1 스키마 확장 (순서 2)
산출물 내용 마이그레이션 0007_intelligent_automation.sql 적용. 기존 nodes 테이블(0006)을 서버 레지스트리로 사용, fqdn, max_tenants 컬럼 추가.마이그레이션 server_metrics 테이블: node_id, cpu_pct, memory_pct, disk_pct, tenant_count, collected_at (node_id = nodes.node_id).마이그레이션 provision_jobs에 target_server_id (TEXT, node_id 참조), create_new_server (INTEGER 0/1) 컬럼 추가.문서 D1 테이블 정의서에 server_metrics·nodes 확장·provision_jobs 확장 명시. 적용 순서: migrations/APPLY.md 참조.
3.2 Ansible + Zuplo Sync (순서 3, 4)
산출물 내용 Ansible 구현됨. prego-ansible 레포: playbook.yml, inventory/, roles/docker, roles/frappe_site. 인벤토리(ansible_host), tenant_id → Docker + Frappe new-site + API Key. 결과를 artifacts/tenant_api_key.txt에 기록(워크플로 artifact → Zuplo Sync).Ansible roles: docker, frappe_site. Ref: config/README.md. 스크립트 구현됨. infra/zuplo_sync.ts: tenant_id, api_key(또는 --api-key-file <path>) → Zuplo Developer API 등록. CLI 및 syncTenantApiKey() export.Runbook docs/runbook/provision-tenant-pipeline.md: 수동 실행 순서 및 워크플로 입력 스펙.Ansible 범위 pulumi-ansible-step1-step2-plan.md §3 : Cloudflare Vectorize·테넌트 canonical DNS·테넌트 사용자 CNAME은 Ansible 비범위로 정리. Vectorize → Pulumi 또는 전용 스크립트, 테넌트 DNS → 현행 cloudflare-tenant-dns.ts + 워크플로 유지.Ansible 단계별 구현 ansible-implementation-plan.md : Frappe/bench 설치 role → 변수·시크릿 → 로컬 검증 → CI 연동 → 문서화 순서.
3.3 전 구간 자동화 워크플로 (순서 5)
산출물 내용 설계 기획서 provision-tenant-workflow-design.md : 워크플로 vs Provision Worker 비교, 입출력·단계별 설계·콜백 스펙·보안·멱등. 구현 전 필독. 워크플로 .github/workflows/provision-tenant.yml: inputs job_id, tenant_id, region, target_server_id(optional), create_new_server(optional). target_server_id 없고 create_new_server 시 Pulumi up → server_ip; 있으면 D1 nodes에서 host 조회. Ansible → api_key 수집 → zuplo_sync → Control Plane 콜백으로 provision_jobs=Completed, tenants_master=Active 갱신.또는 Provision Worker: D1 Pending job 폴링 또는 HTTP 트리거 → (Pulumi/Ansible은 외부 호출) → Zuplo → D1 직접 갱신. 문서 runbook: 워크플로 입력·Secrets·실패 시 재시도·콜백 URL 안내.
3.4 리소스·사용량 모니터링 (순서 6)
산출물 내용 수집 경로 Hetzner API 또는 노드 에이전트/Cron → Control Plane API 또는 Worker → D1 server_metrics·servers 갱신. 주기 1~5분. 서비스 사용량 기존 R2 Raw + D1 집계·Zuplo 메터링 활용. tenant_id별 부하 지표를 배치 시 참고할 수 있도록 스키마/쿼리 정리. 문서 모니터링 수집 주기·필수 메트릭·D1 쓰기 정책. Data Plane 리소스 절감 resource-optimization-safe-adoption-plan.md — Redis·Gunicorn·CDN·Docker 제한 등 기존 시스템 영향 없이 적용 순서.
3.5 AI 배치 결정 (순서 7)
산출물 내용 규칙 엔진 D1 server_metrics·servers 조회 → region·plan_tier·임계치(CPU/메모리/테넌트 수)·정책(서버당 최대 N) 적용 → target_server_id 또는 create_new_server 반환. (선택) 모델 ML/LLM 호출로 “최적 서버” 또는 create_new 추천. 입력: tenant_id, plan_tier, region, 현재 server_metrics 요약. API/함수 Control Plane 내부 또는 Worker: `decidePlacement(tenant_id, plan_tier, region) → { target_server_id? 감사 LogPath trace_events에 stage=PLACEMENT_DECIDED, payload에 target_server_id/create_new_server 기록.
3.6 Webhook·트리거 연동 (순서 8)
산출물 내용 Control Plane Stripe Webhook 처리 후 provision_jobs 삽입 → decidePlacement() 호출 → 결과를 workflow_dispatch(또는 Provision Worker) 입력으로 전달(job_id, tenant_id, region, target_server_id, create_new_server). 문서 Webhook → 배치 → 트리거 순서 및 입력 스펙.
4. 검증 체크리스트
5. 참조
