ארכיטקטורת SaaS Multi-Tenant: הגישות והפשרות

SaaS ופיתוח מוצר, פיתוח תוכנה

שתף באמצעות:

הבחירה שתגדיר את כל שאר הארכיטקטורה

כשמפתחים מוצר SaaS, אחת ההחלטות הראשונות והכי קריטיות היא מודל ה-tenancy. זה לא ויכוח אקדמי. הבחירה בין shared database, database-per-tenant, או schema-per-tenant תשפיע על כל שורת קוד שתכתבו, על העלויות שלכם, ועל היכולת למכור ללקוחות enterprise.

ואין תשובה נכונה אחת. יש פשרות.

שלוש הגישות: מה באמת עומד על הפרק

גישה 1: Shared Database (בסיס נתונים משותף)

כל הלקוחות באותו database, באותם טבלאות. כל שורה מכילה tenant_id שמפריד בין הנתונים.

היתרונות:

הכי פשוט לפתח ולתחזק. קוד אחד, migration אחד, backup אחד.
הכי זול. DB אחד ב-$50/חודש יכול לשרת 1,000 tenants קטנים.
הכי קל לעשות onboarding – tenant חדש זה רק שורה בטבלת tenants.
Queries חוצי-tenants קלים – רוצים אנליטיקס על כל הלקוחות? פשוט.

החסרונות:

בעיית "noisy neighbor" – לקוח אחד שמריץ query כבד מאט את כולם.
סיכון אבטחה – באג אחד בפילטור tenant_id חושף נתוני לקוחות אחרים. וזה קורה. ראינו את זה יותר מדי פעמים.
קשה למכור ל-enterprise שדורשים isolation מלא של נתונים.
Scaling – בשלב מסוים ה-DB האחד לא מספיק.

מתאים ל: SaaS לעסקים קטנים ובינוניים, מוצרים עם נפח נתונים קטן-בינוני לכל tenant.

גישה 2: Schema-per-Tenant (סכמה לכל לקוח)

DB אחד, אבל כל tenant מקבל schema משלו. הטבלאות זהות במבנה אבל מופרדות לוגית.

היתרונות:

הפרדה לוגית טובה יותר – קשה יותר לגשת בטעות לנתוני tenant אחר.
קל יותר לעשות export/import של נתוני tenant בודד.
עדיין DB אחד, אז התפעול פשוט יחסית.
אפשר לתת ללקוח גדול schema משלו בלי להקים DB חדש.

החסרונות:

Migrations הם סיוט. צריך להריץ ALTER TABLE על כל schema. עם 500 tenants – זה 500 migrations.
Connection pooling מורכב יותר.
PostgreSQL מסתדר עם זה עד אלפי schemas. MySQL פחות.
Noisy neighbor עדיין בעיה – אותו DB פיזי.

מתאים ל: מוצרים שצריכים הפרדה טובה יותר בלי הוצאות של DB לכל לקוח. 100-5,000 tenants.

גישה 3: Database-per-Tenant (בסיס נתונים לכל לקוח)

כל tenant מקבל DB נפרד לחלוטין. הפרדה מלאה.

היתרונות:

אבטחה מקסימלית. אין סיכוי לזליגת נתונים בין tenants.
אין noisy neighbor – כל DB רץ עצמאית.
קל למכור ל-enterprise ולעבור SOC 2, ISO 27001, HIPAA.
Backup ו-restore ברמת tenant – פשוט.
אפשר לתת ללקוחות גדולים DB בגיאוגרפיה שלהם (GDPR).

החסרונות:

יקר. כל DB עולה כסף, גם כשהלקוח קטן. Cloud SQL instance קטן ב-GCP – $15/חודש. עם 1,000 לקוחות – $15,000/חודש רק על DB.
DevOps מורכב. צריך provisioning אוטומטי, monitoring לכל DB, migration לכולם.
Queries חוצי-tenants – כמעט בלתי אפשרי בלי ETL pipeline.
Onboarding איטי יותר – צריך להקים DB חדש.

מתאים ל: Enterprise SaaS, מוצרים עם דרישות compliance גבוהות, tenants עם נפח נתונים גדול.

ה-Noisy Neighbor: הבעיה שמתעלמים ממנה

Noisy neighbor הוא מצב שבו tenant אחד צורך כל כך הרבה משאבים שהוא פוגע בביצועים של כולם. וזה קורה. לקוח אחד שמייבא CSV עם מיליון שורות. לקוח שמריץ ריפורט על 3 שנים של נתונים. לקוח שה-cron job שלו הולך פראי.

פתרונות:

Rate limiting ברמת tenant: כל tenant מוגבל ב-API calls, queries per second, storage. לא אופציונלי – חובה.
Resource quotas: הגבלת CPU ו-memory ברמת connection/session. PostgreSQL תומך ב-statement_timeout ו-work_mem per role.
Queue management: עבודות כבדות הולכות לתור (Redis Queue, BullMQ) במקום לרוץ sync.
Read replicas: ריפורטים ושאילתות כבדות רצים על replica, לא על ה-primary.
Tiered infrastructure: לקוחות גדולים מקבלים תשתית ייעודית. לקוחות קטנים על shared.

אבטחה: מה שלא מופיע ב-tutorial

ב-multi-tenant, באג אבטחה הוא פי 100 יותר חמור מב-single-tenant. במקום שלקוח רואה את הנתונים של עצמו – הוא רואה נתונים של כל הלקוחות.

דברים שחייבים:

Row-Level Security (RLS): אם אתם על PostgreSQL – השתמשו ב-RLS. זו שכבת הגנה ברמת ה-DB שמונעת גישה לנתונים של tenant אחר גם אם יש באג בקוד. אפשר להגדיר policy שאומר: "כל query חייב לכלול tenant_id שמתאים ל-current_setting('app.tenant_id')".
Middleware validation: כל request עובר middleware שמוודא שה-tenant_id ב-JWT מתאים למשאב שנגשים אליו. לא סומכים על הקוד בלבד.
Audit logging: כל גישה לנתונים של tenant מתועדת. מי ניגש, מתי, ולמה. חובה עבור SOC 2.
Penetration testing ספציפי: בודקים תרחישי cross-tenant access. לא רק SQL injection סטנדרטי – בודקים שמשתמש של tenant A לא יכול לגשת ל-API endpoints של tenant B על ידי שינוי ID ב-URL.
Encryption at rest per tenant: ל-enterprise – encryption key נפרד לכל tenant. Cloud KMS של GCP תומך בזה.

מודל עלויות: המספרים שצריך לדעת

הנה חישוב גס ל-500 tenants פעילים:

Shared Database:

Cloud SQL db-standard-2: $200/חודש
Storage 500GB: $60/חודש
Read replica: $200/חודש
סה"כ: ~$460/חודש = $0.92 לכל tenant

Schema-per-Tenant:

Cloud SQL db-standard-4 (צריך יותר RAM): $400/חודש
Storage 500GB: $60/חודש
Read replica: $400/חודש
Monitoring מורכב יותר: $50/חודש
סה"כ: ~$910/חודש = $1.82 לכל tenant

Database-per-Tenant:

500 x Cloud SQL db-f1-micro: $7,500/חודש
Storage 1GB x 500: $60/חודש
Automation/provisioning tools: $100/חודש
סה"כ: ~$7,660/חודש = $15.32 לכל tenant

ההפרש פי 16 בין shared ל-DB-per-tenant. בשוק ישראלי עם מחירי SaaS נמוכים יחסית – זה יכול להיות ההבדל בין רווחיות להפסד.

Customization ו-White Label

הרבה SaaS ישראלי נמכר כ-white-label – הלקוח רוצה את המוצר שלכם עם הלוגו שלו, הצבעים שלו, והדומיין שלו. זה מוסיף שכבה של מורכבות:

Theming: CSS variables לכל tenant. שמרו את ההגדרות ב-DB ותטענו אותן ב-runtime. לא build נפרד לכל לקוח – זה לא סקיילבילי.
Custom domains: Wildcard SSL + reverse proxy שמנתב לפי domain ל-tenant הנכון. Caddy או nginx עם dynamic upstreams עובדים טוב. Cloudflare for SaaS מפשט את זה מאוד.
Feature flags: לקוחות שונים רואים פיצ'רים שונים. LaunchDarkly, Unleash, או פתרון עצמי עם טבלת features פשוטה.
Email customization: כל tenant שולח מיילים מהדומיין שלו. צריך setup של SPF, DKIM, DMARC לכל דומיין. SendGrid ו-Postmark תומכים ב-sender authentication per tenant.

מיגרציה: מ-Single ל-Multi-Tenant

זה המצב הכי נפוץ שאנחנו רואים: חברה בנתה מוצר ללקוח אחד, הצליחה, ועכשיו רוצה למכור לעוד 50. המוצר לא נבנה ל-multi-tenant. מה עושים?

שלב 1: הוסיפו tenant_id לכל טבלה. כן, לכל טבלה. גם לטבלאות שנראות "גלובליות". migration אחד גדול.

שלב 2: עדכנו כל query. כל SELECT, UPDATE, DELETE צריך לכלול WHERE tenant_id = ?. אם אתם משתמשים ב-ORM – הגדירו default scope. ב-Prisma זה middleware, ב-Sequelize זה scopes.

שלב 3: Middleware לזיהוי tenant. לפי subdomain, לפי header, או לפי token. ה-tenant_id נקבע פעם אחת בתחילת ה-request ונגיש בכל הקוד.

שלב 4: בידוד storage. קבצים של לקוחות שונים ב-S3 prefixes שונים. אל תערבבו.

שלב 5: בדיקות. בדיקות ספציפיות ל-multi-tenant: צרו שני tenants, הכניסו נתונים, ווידאו ש-tenant A לא רואה נתונים של tenant B. אוטומטיות. בכל deploy.

המיגרציה הזו לוקחת בדרך כלל 4-8 שבועות לצוות מנוסה. לצוות שעושה את זה בפעם הראשונה – 3-4 חודשים.

SaaS ישראלי שמשרת שוק גלובלי

הרבה SaaS ישראלי מתחיל עם לקוחות ישראלים ומתרחב לחו"ל. זה מוסיף דרישות ארכיטקטוניות:

Data residency: לקוחות אירופאים דורשים שהנתונים ישארו ב-EU (GDPR). צריך region awareness – היכולת להריץ tenants ב-regions שונים.
Multi-currency: חיוב בשקלים, דולרים, ויורו. Stripe מטפל ברוב זה, אבל ה-DB שלכם צריך לתמוך במטבעות מרובים.
Timezone handling: כל tenant ב-timezone שלו. שמרו הכל ב-UTC וקנבטרו ב-presentation layer. נראה פשוט, בפועל זה מקור אינסופי לבאגים.
Compliance: SOC 2 Type II, GDPR, CCPA, HIPAA – כל אחד דורש דברים שונים מהארכיטקטורה. תתחילו עם SOC 2 כי הוא פותח את רוב הדלתות.

אז מה בוחרים?

הנה decision tree פשוט:

מוכרים ל-SMB, מחיר נמוך, הרבה tenants? → Shared DB
צריכים הפרדה בינונית, 100-5K tenants? → Schema-per-tenant
מוכרים ל-enterprise, compliance חשוב? → DB-per-tenant
לא בטוחים? → תתחילו ב-Shared DB עם RLS, ותעברו כשצריך.

הטעות הגדולה ביותר היא over-engineering מהיום הראשון. אם יש לכם 10 לקוחות – DB-per-tenant זה בזבוז כסף ומורכבות. אם יש 10,000 – shared DB בלי rate limiting זה כאב ראש.