צינור אספקת דיירים אידמפוטנטי עבור SaaS

לקוח חדש בפלטפורמת SaaS אינו רק רשומה במסד נתונים. זהו Namespace ב-Kubernetes, סכמה ב-PostgreSQL, רשומת DNS, תפקיד IAM, דלי S3, רשומת חיוב ואימייל קבלת פנים. סקריפטים חצי-ידניים מובילים לשגיאות: דייר מקבל דלי S3 שגוי, DNS לא מוגדר, או סכמה נוצרת עם הרשאות שגויות. כל שדה חדש בטופס הרשמה דורש עריכות בארבעה מקומות. הניסיון שלנו מראה: אוטומציה היא הדרך היחידה להתרחב מבלי לאבד איכות. עם 50+ לקוחות, קליטת דיירים ידנית הופכת לצוואר בקבוק—זמן יצירת דייר גדל ל-2–3 שעות, ושיעור השגיאות עולה על 15%. העלות של אירוע כזה בודד יכולה להגיע ל-$5000.

מה קורה ללא אוטומציה

תרחיש טיפוסי: סקריפט קליטה בצורת קובץ bash שמהנדס מריץ ידנית לאחר קבלת טיקט. הסקריפט כולל psql -c "CREATE SCHEMA tenant_$1", aws s3 mb s3://company-tenant-$1, וכמה פקודות kubectl apply. הסקריפט אינו אידמפוטנטי, אינו מתעד, ואינו מבצע גלגול לאחור על כישלון באמצע. כאשר kubectl apply נכשל עקב מחסור בתת-רשת IP, הדייר נוצר חלקית. התמיכה מבלה שעה בגלגול ידני לאחור. זה לא תרחיש היפותטי—זה מה שאנו פוגשים ברוב הפרויקטים בשלב של "יש לנו 50+ לקוחות ואנחנו כבר לא עומדים בקצב." במקרה אחד, היעדר גלגול לאחור הביא לכך ששני דיירים חלקו דלי S3 משותף עם מפתחות חופפים—אירוע שעלה בכמה שעות של שחזור ונזק למוניטין.

איך לבנות צינור אספקה אידמפוטנטי?

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

גישה 1: Kubernetes Operator — לפלטפורמות על K8s

הדייר מתואר כ-CRD:

---
apiVersion: platform.company.io/v1alpha1
kind: Tenant
metadata:
  name: acme-corp
spec:
  plan: professional
  region: eu-west-1
  adminEmail: [email protected]
  quotas:
    cpu: "8"
    memory: 16Gi
    storage: 100Gi
---

ה-Operator (המבוסס על controller-runtime או Capsule) מיירט את יצירת האובייקט ומריץ לולאת תיאום: יוצר Namespace, ResourceQuota, NetworkPolicy, ServiceAccount, RoleBinding. על שגיאה, הסטטוס מתעדכן, והניסיון החוזר אוטומטי. המצב נשמר ב-etcd. זמן יצירת דייר הוא 30–50 אלפיות השנייה, מהיר פי 50 מגישת Terraform (עד 2–3 דקות).

גישה 2: Terraform + Temporal — לסביבות היברידיות

Terraform מבטיח תצורה הצהרתית ומצב; Temporal מספק תזמור עם מדיניות ניסיון חוזר ועסקאות פיצוי.

# modules/tenant/main.tf
resource "postgresql_schema" "tenant" {
  name = "tenant_${var.tenant_id}"
  database = var.database_name
  owner = postgresql_role.tenant.name
}

resource "aws_s3_bucket" "tenant_storage" {
  bucket = "${var.company_prefix}-${var.tenant_id}-storage"
  tags = {
    TenantID = var.tenant_id
    Plan = var.plan
  }
}

resource "aws_route53_record" "tenant_subdomain" {
  zone_id = data.aws_route53_zone.main.zone_id
  name = "${var.tenant_id}.${var.base_domain}"
  type = "CNAME"
  ttl = 300
  records = [var.alb_dns_name]
}

השוואת גישות:

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

למה אידמפוטנטיות קריטית לאספקה?

אידמפוטנטיות מבטיחה שהרצה חוזרת של הצינור לא יוצרת משאבים כפולים או שגיאות. ללא זה, הפעלה מחדש מקרית לאחר פסק זמן יכולה ליצור שני Namespace עם אותו שם (הראשון נכשל עם שגיאה, השני הוא כפילות). ב-Kubernetes operator, אידמפוטנטיות מובנית בארכיטקטורה: כל תיאום משווה את המצב הרצוי למצב הנוכחי. בשילוב Terraform + Temporal, היא מובטחת על ידי קובץ המצב: על apiVersion: platform.company.io/v1alpha1 kind: Tenant metadata: name: acme-corp spec: plan: professional region: eu-west-1 adminEmail: [email protected] quotas: cpu: "8" memory: 16Gi storage: 100Gi חוזר, Terraform רואה שהמשאבים כבר קיימים ומדלג על יצירה. Temporal שומר בנוסף את היסטוריית הצעדים, ומונע שימוש חוזר בפעילויות שכבר הושלמו.

חיסכון באוטומציה יכול להגיע ל-40% מעלויות הקליטה.

איך Temporal מבטיח אטומיות?

אם האספקה נכשלת בשלב 7 מתוך 10, יש צורך במנגנון גלגול לאחור. Temporal פותר זאת עם עסקאות פיצוי: לכל פעילות יש מקבילת פיצוי שפועלת על כישלון. לדוגמה, אם יצירת Kubernetes Namespace הצליחה אך הפעילות הבאה (יצירת מסד נתונים) נכשלה, Temporal קורא אוטומטית לפונקציה למחיקת ה-Namespace. היסטוריית זרימת העבודה נשמרת באשכול Temporal ונגישה דרך ה-UI—ניתן לראות את שלב הכישלון המדויק, להפעיל מחדש את זרימת העבודה מאותה נקודה, או להתאים ידנית את המצב.

// provisioning workflow
func ProvisionTenantWorkflow(ctx workflow.Context, req TenantRequest) error {
    if err := workflow.ExecuteActivity(ctx, CreateDatabase, req).Get(ctx, nil); err != nil {
        return err // Temporal handles retry based on policy
    }
    if err := workflow.ExecuteActivity(ctx, CreateKubernetesNamespace, req).Get(ctx, nil); err != nil {
        workflow.ExecuteActivity(ctx, DeleteDatabase, req) // compensate
        return err
    }
    // ...
}

הודות לגישה זו, ה-MTTR במהלך כישלונות אספקה יורד משעתיים ל-15 דקות. זה מאושר בפרויקטים עם 100+ דיירים.

אילו רמות בידוד אנו מגדירים?

ארכיטקטורת ריבוי דיירים דורשת מודל בידוד מפורש. אנו מגדירים:

• בידוד נתונים: סכמות PostgreSQL נפרדות עם אבטחה ברמת שורה או מסדי נתונים נפרדים בהתאם לדרישות רגולטוריות.
• בידוד רשת: NetworkPolicy ב-Kubernetes האוסר תעבורה בין Namespaces.
• בידוד IAM: תפקיד IAM נפרד לכל דייר עם הרשאות מינימליות באמצעות מדיניות מבוססת משאבים.
• הגבלת קצב: מכסה ברמת API Gateway (בקשות/דקה), ResourceQuota ברמת Kubernetes.

סודות נוצרים במהלך האספקה ונשמרים ב-Vault או ב-AWS Secrets Manager—בהתאם לתשתית.

שלבי העבודה

ציר זמן טיפוסי: מ-3 ימים לצינור Terraform פשוט ועד 5–7 ימים לזרימת עבודה מתוזמרת מלאה. העלות מחושבת באופן אישי לאחר ניתוח התשתית הקיימת.

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

העבודה כוללת מסירת קוד עובד (Operator, מודולי Terraform או זרימת עבודה של Temporal), תצורה ל-staging וייצור, תיעוד ו-runbook, הדרכת צוות (1–2 מפגשים), ותמיכה עם משוב למשך שבועיים לאחר המסירה.

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