הקמת תשתית רב-ענן: AWS, GCP, Azure

הקמת תשתית Multi-Cloud

Multi-cloud לא מתחיל עם דיאגרמת ארכיטקטורה יפה על לוח לבן. זה מתחיל עם מצב: הספק הראשי קרס לשלוש שעות והעסק הפסיד כסף. או: חוזה דורש אחסון נתונים באיחוד האירופי, אבל pipelines של ML זולים יותר להרצה על GCP. או פשוט: צוות אחד יושב היסטורית על Azure, אחר על AWS, ומיזוגם לחשבון אחד הוא בלתי אפשרי פוליטית. בכל שלושת המקרים, יש צורך בתשתית multi-cloud — אבל העיצוב שלה יהיה שונה מהותית. אנחנו מתכננים ופורסים פתרונות כאלה turnkey, תוך התמקדות בצרכים אמיתיים, לא בדיאגרמות מופשטות.

שני אתגרים שונים תחת שם אחד

יש Active/Active multi-cloud: האפליקציה בפועל רצה בשני עננים בו-זמנית, התעבורה מאוזנת ביניהם, ואם אחד נופל, השני לוקח על עצמו את הכל. זו ארכיטקטורה מורכבת ויקרה. סנכרון נתונים בין עננים, איזון עומסים גלובלי, גרסאות אפליקציה זהות בשני מיקומים — עומס תפעולי משמעותי.

יש Active/Passive: הספק הראשי מטפל בתעבורה, המשני מחומם ומוכן להשתלט תוך 15–30 דקות. הנתונים משוכפלים בצורה אסינכרונית. RPO — 15 דקות, RTO — 30 דקות. זו אפשרות ריאלית לרוב הפרויקטים.

ויש "multi-cloud לפי התמחות": Cloudflare Workers ללוגיקת קצה, AWS למחשוב ומסדי נתונים, GCS לאחסון קר זול, Vercel לפרונטאנד. כל ספק עושה את מה שהוא עושה הכי טוב והכי זול. קישוריות דרך API היא מינימלית.

לפני התכנון, חשוב להבין איזה משלושת האתגרים האלה אנחנו בעצם פותרים.

למה נתונים הם החלק הכי קשה ב-Multi-Cloud?

מחשוב ב-multi-cloud אינו קשה. Kubernetes עובד זהה ב-EKS, GKE ו-AKS. Terraform מנהל משאבים בכל שלושת הספקים. הבעיה היא נתונים. מסדי נתונים לא משתכפלים באופן טבעי בין עננים.

אפשרויות שכפול עבור PostgreSQL בין AWS RDS ו-GCP Cloud SQL:

• שכפול לוגי דרך pglogical — עובד אבל דורש הגדרה ידנית וניטור lag.
• Debezium CDC → Kafka (MSK או Confluent) → Consumer בענן היעד — אמין יותר אבל מורכב יותר.
• פתרונות מנוהלים: Google Database Migration Service, AWS DMS — מתאימים להגירה חד-פעמית, מוגבלים לשכפול שוטף.

Latency בין אזורים של ספקים שונים הוא 30–80 ms תלוי בגאוגרפיה. עבור בקשות סינכרוניות, זה קטלני. כל מה שעובר בין עננים חייב להיות אסינכרוני.

Terraform עבור Multi-Cloud

Workspace יחיד של Terraform, ספקים מרובים:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source = "hashicorp/google"
      version = "~> 5.0"
    }
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
  assume_role {
    role_arn = var.aws_role_arn
  }
}

provider "google" {
  project = var.gcp_project_id
  region = var.gcp_region
}

State מרוחק — ב-S3 עם נעילת DynamoDB, או ב-Terraform Cloud. ה-State חייב להיות יחיד — אחרת outputs מספק אחד לא יכולים להפוך ל-inputs עבור אחר.

מבנה הפרויקט מתחלק לפי ספק:

infrastructure/
  shared/ # общие переменные, data sources
  aws/
    networking/
    compute/
    databases/
  gcp/
    networking/
    storage/
  ml-platform/
  global/
    dns/ # Cloudflare или Route 53 как глобальный DNS
    monitoring/

רשת בין עננים: איך מתחברים?

חיבור ישיר בין AWS ו-GCP — דרך Dedicated Interconnect (GCP) + Direct Connect (AWS) עם נקודת החלפה משותפת ב-co-location ניטרלי (Equinix, Digital Realty). זה יקר (עולה בערך $2,000 לחודש לפורט) אבל מספק latency צפוי.

לרוב הפרויקטים — רשת VPN mesh דרך WireGuard או Tailscale. Tailscale נוח במיוחד: סוכנים מותקנים על צמתים בשני העננים, יוצרים רשת mesh; כל הצמתים רואים זה את זה לפי IP. התצורה היא declarative דרך ספק ה-Tailscale של Terraform. הגדרת VPN של Tailscale מהירה פי 10 מיישום Direct Connect.

אם התעבורה בין עננים עוברת רק דרך API (HTTP/gRPC) — נקודות קצה ציבוריות עם mTLS מספיקות. Cert-manager מנפיק אישורים, SPIFFE/SPIRE מספק זהות לשירותים ללא קשר לענן.

Kubernetes ב-Multi-Cloud: GitOps וניהול

ניהול קלאסטרים מרובים — דרך ניהול fleet. ArgoCD עם ApplicationSet ו-cluster generators פורס את אותן אפליקציות ל-EKS ו-GKE ממאגר Git יחיד. הבדלים בין קלאסטרים נישאים ב-terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 5.0" } google = { source = "hashicorp/google" version = "~> 5.0" } azurerm = { source = "hashicorp/azurerm" version = "~> 3.0" } } } provider "aws" { region = var.aws_region assume_role { role_arn = var.aws_role_arn } } provider "google" { project = var.gcp_project_id region = var.gcp_region } ו-infrastructure/ shared/ # общие переменные, data sources aws/ networking/ compute/ databases/ gcp/ networking/ storage/ ml-platform/ global/ dns/ # Cloudflare или Route 53 как глобальный DNS monitoring/ .

תיעוד ArgoCD ApplicationSet מפרט את תכונת ה-cluster generator. דוגמה ל-ApplicationSet:

---
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: backend-service
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: '{{name}}-backend'
    spec:
      project: default
      source:
        repoURL: https://github.com/company/k8s-configs
        targetRevision: main
        path: apps/backend
        helm:
          valueFiles:
            - values.yaml
            - 'values-{{metadata.labels.cloud}}.yaml'
      destination:
        server: '{{server}}'
        namespace: backend

Velero לגיבויים בין עננים — snapshots של PVC מ-AWS EBS משוכפלים ל-GCS כשכבת DR נוספת.

ניטור ו-Observability: תצוגה אחת

מדדים ממספר עננים נאספים למערכת אחת. Prometheus federation או VictoriaMetrics עם remote_write מכל קלאסטר ל-Thanos מרכזי. Grafana עם datasources לשני העננים — דשבורדים מראים את מצב כל התשתית.

ל-distributed tracing — OpenTelemetry Collector בכל קלאסטר, ייצוא ל-Jaeger או Grafana Tempo. Traces עוברים דרך שירותים ב-AWS ו-GCP — כל השרשרת נראית.

טעויות אופייניות ואיך להימנע מהן

ניסיון להפוך את התשתית לזהה לחלוטין בשני העננים הוא מלכודת. ל-AWS ו-GCP יש פרימיטיבים שונים: Load Balancer Controller ב-EKS לעומת GKE Ingress, EBS לעומת Persistent Disk, Security Groups לעומת VPC Firewall Rules. ניסיון ליצור התאמה אחד-לאחד מבזבז זמן במלחמה בהבדלים, במקום לנצל את החוזקות של כל ספק.

אבסטרקציות כמו Crossplane עוזרות — אבל מוסיפות רמת מורכבות ועומס תפעולי משלהן.

שלב-אחר-שלב: הקמת Multi-Cloud Terraform

1. הגדרת ספקים ב-workspace יחיד עם aliases נפרדים.
2. יצירת backend משותף ל-remote state (לדוגמה, S3 + DynamoDB).
3. מבנה קוד למודולים לפי ספק תחת ספריית values-aws.yaml מאוחדת.
4. שימוש ב-outputs מספק אחד כ-inputs לאחר.
5. יישום שינויים בשלבים: קודם רשת, אחר כך מחשוב, ואז נתונים.

מה כלול בעבודה

לוחות זמנים משוערים

אנחנו מתחילים בסדנת ארכיטקטורה — מזהים את המשימה האמיתית ובוחרים את הארכיטקטורה הפחות מורכבת שפותרת אותה. נעריך את הפרויקט שלכם תוך יומיים — פשוט צרו קשר.