بنية SaaS متعددة المستأجرين: ما يحتاج CTOs إلى معرفته

أنت تقوم ببناء منتج SaaS. سوف يستخدمه العديد من العملاء. يتوقع كل عميل أن تظل بياناته خاصة، وأن تظل تكويناته منفصلة، ​​وأن تبدو تجربته وكأنها منصة خاصة به. السؤال ليس ما إذا كنت بحاجة إلى إيجارات متعددة. إنه النموذج الذي يجب اختياره.

يشكل هذا القرار مخطط قاعدة البيانات الخاصة بك، ومسار النشر، وقصة الامتثال، وبنية التكلفة الخاصة بك لسنوات. إذا أخطأت في ذلك، فسوف تقضي ستة أشهر في الانتقال إلى نموذج مختلف بينما تتوقف خريطة الطريق الخاصة بك.

هناك ثلاثة نماذج تستحق النظر فيها. ويتعامل كل منها مع التكلفة والعزلة والتعقيد التشغيلي بطرق مختلفة.

النماذج الثلاثة للهندسة المعمارية متعددة المستأجرين

1. قاعدة البيانات لكل مستأجر

يحصل كل مستأجر على قاعدة البيانات الخاصة به. The application layer routes queries to the correct database based on a tenant identifier, typically resolved from the subdomain, API key, or JWT claim.

هذا هو أقوى نموذج عزل. توجد بيانات المستأجر أ في قاعدة بيانات منفصلة عن بيانات المستأجر ب. لا توجد طريقة لخطأ استعلام لتسريب الصفوف عبر المستأجرين، لأن الصفوف موجودة في قواعد بيانات مختلفة على اتصالات مختلفة.

المزايا:

• صديقة للامتثال. يحب المدققون سماع عبارة "كل عميل لديه قاعدة بيانات خاصة به". تصبح متطلبات SOC 2 وHIPAA وموقع البيانات محادثات مباشرة.
• النسخ الاحتياطي والاستعادة لكل مستأجر. عندما يطلب منك المستأجر العودة إلى حالة الأمس، فإنك تقوم باستعادة قاعدة بيانات واحدة. لا يوجد استخراج جراحي من الجداول المشتركة.
• لا يوجد خطر صاخبة الجار. لا يمكن للمستأجر الذي يقوم بتشغيل استعلامات تحليلية باهظة الثمن أن يؤدي إلى انخفاض أداء المستأجرين الآخرين.
• التحجيم لكل مستأجر. يمكنك وضع المستأجرين ذوي القيمة العالية على مثيلات قاعدة بيانات أكبر.

العيوب:

• غالي. كل قاعدة بيانات لها تكلفة أساسية: الحوسبة والتخزين والنسخ الاحتياطي والمراقبة. عند وجود 10 مستأجرين، يمكن التحكم في ذلك. عند 500، هذا بند يجعل المدير المالي الخاص بك غير مريح.
• جحيم الهجرة يجب أن يتم تشغيل تغييرات المخطط عبر مئات قواعد البيانات. أنت بحاجة إلى أدوات لتنظيم عمليات الترحيل، وتتبع قواعد البيانات المحدثة، والتعامل مع حالات الفشل جزئيًا خلال عملية الطرح.
• يصبح تجميع الاتصال معقدًا. يحتاج خادم التطبيقات الخاص بك إلى مجموعات اتصال لمئات قواعد البيانات. تصبح حدود الاتصال قيدًا قبل أن تصبح وحدة المعالجة المركزية أو الذاكرة قيدًا.
• الاستفسارات بين المستأجرين مؤلمة. تتطلب التقارير المجمعة أو التحليلات على مستوى النظام الأساسي أو لوحات المعلومات الإدارية التي تعرض البيانات عبر المستأجرين استعلامات اتحادية أو مسار تحليلات منفصل.

الأفضل لـ:التكنولوجيا المالية والرعاية الصحية والبرمجيات كخدمة للمؤسسات مع متطلبات صارمة لموقع البيانات. إذا كان عقدك ينص على "يجب أن تكون بيانات العميل موجودة في منطقة AWS محددة" أو "يجب أن تكون البيانات قابلة للحذف خلال 24 ساعة من إنهاء العقد"، فإن قاعدة البيانات لكل مستأجر تجعل كلا الأمرين قابلاً للتحقيق بشكل تافه.

2. قاعدة البيانات المشتركة، وفصل المخطط

قاعدة بيانات واحدة، ولكن يحصل كل مستأجر على المخطط الخاص به (مساحة الاسم). في PostgreSQL، يعني هذا أن كل مستأجر لديه مجموعة منفصلة من الجداول تحت اسم المخطط الخاص به: tenant_abc.users، tenant_xyz.users. يقوم التطبيق بتعيين search_path على كل اتصال لتوجيه الاستعلامات إلى المخطط الصحيح.

هذه هي الحل الوسط. يمكنك الحصول على عزل أفضل من الجداول المشتركة، وبتكلفة أقل من قواعد البيانات المنفصلة.

المزايا:

• أرخص من قاعدة البيانات لكل مستأجر. مثيل قاعدة بيانات واحد، تجمع اتصال واحد، مكدس مراقبة واحد.
• عزلة لائقة. توفر المخططات حدود مساحة الاسم. لا يمكن للاستعلام الذي تم تكوينه بشكل خاطئ في أحد المخططات الوصول إلى جداول مخطط آخر (على افتراض أنك قمت بتعيين search_path بشكل صحيح).
• النسخ الاحتياطي لكل مستأجر ممكن من خلال pg_dump --schema.
• تعد عمليات الترحيل أسهل من قاعدة البيانات لكل مستأجر. يمكنك تشغيل الترحيل مرة واحدة لكل مخطط، ولكن جميع المخططات موجودة في نفس قاعدة البيانات، لذلك تكون الأدوات أبسط.

العيوب:

• الانجراف المخطط. عندما تفشل عمليات الترحيل في بعض المخططات ولكنها تنجح في مخططات أخرى، فسينتهي بك الأمر مع مستأجرين يقومون بتشغيل إصدارات مختلفة من مخططك. تصحيح هذا أمر بائس.
• لا يتعامل PostgreSQL مع آلاف المخططات بشكل جيد. بعد تجاوز 5000 إلى 10000 مخطط، ستواجه تدهورًا في الأداء في عمليات البحث pg_catalog، وpg_dump مرات أبطأ، والتنافس على الفراغ التلقائي.
• نفس خطر الجار الصاخب كقاعدة بيانات مشتركة. لا يزال الاستعلام الباهظ الثمن لأحد المستأجرين يتنافس على نفس وحدة المعالجة المركزية والإدخال/الإخراج.
• دعم الأدوات غير متناسق. تتمتع ORMs وأطر الترحيل بمستويات مختلفة من الدعم لأنماط المخطط لكل مستأجر.

الأفضل لـ:SaaS في السوق المتوسطة مع ما بين 50 إلى 5000 مستأجر حيث تحتاج إلى عزل أفضل من الأمان على مستوى الصف ولكن لا يمكنك تبرير تكلفة قواعد البيانات المنفصلة.

3. مشاركة كل شيء بأمان على مستوى الصف

يتشارك جميع المستأجرين نفس الطاولات. يحدد عمود tenant_id في كل جدول المستأجر الذي يملك كل صف. تفرض سياسات الأمان على مستوى الصف (RLS) في PostgreSQL أن الاستعلامات يمكنها فقط رؤية الصفوف التي تنتمي إلى المستأجر الحالي.

هذا هو النموذج الأكثر شيوعًا لمنتجات B2B SaaS التي لا يتم بيعها للمؤسسات الخاضعة للتنظيم.

المزايا:

• أرخص تكلفة البنية التحتية. قاعدة بيانات واحدة، مجموعة واحدة من الجداول، تجمع اتصال واحد. إن إضافة مستأجر لا يكلف أي بنية تحتية إضافية.
• أبسط الهجرات مخطط واحد، تشغيل ترحيل واحد. أنت لا تقوم بتنسيق أي شيء عبر قواعد بيانات أو مخططات متعددة.
• مسار قاعدة التعليمات البرمجية واحد. لا يوجد منطق شرطي لـ "ما هي قاعدة البيانات التي أتحدث إليها" أو "ما هو المخطط الذي يجب أن أستخدمه." يعد العمود tenant_id جزءًا من المخطط، ويتولى RLS الباقي.
• التحليلات عبر المستأجرين تافهة. تستعلم لوحات معلومات المسؤول والتقارير على مستوى النظام الأساسي عن نفس الجداول بأذونات مرتفعة.

العيوب:

• يمكن أن تتسبب أخطاء الاستعلام في تسرب البيانات. إذا كتب أحد المطورين استعلامًا يتجاوز RLS (باستخدام اتصال مستخدم متميز، أو نسيان تعيين متغير جلسة العمل)، فستتسرب بيانات المستأجر. هذه مخاطرة على مستوى التعليمات البرمجية، وليست ضمانًا على مستوى البنية التحتية.
• محادثات الامتثال أصعب. إن "جميع بيانات العملاء موجودة في نفس الجداول، مفصولة بعمود" يعد أمرًا أكثر صعوبة لفرق أمان المؤسسة من "أن يكون لكل عميل قاعدة بيانات خاصة به".
• خطر ضوضاء الجار هو الأعلى هنا. يقوم مستأجر واحد باستيراد 10 ملايين صف بتأمين الجداول التي تؤثر على جميع المستأجرين.
• يتطلب النسخ الاحتياطي والاستعادة لكل مستأجر استخراجًا جراحيًا. لا يمكنك استعادة مستأجر واحد دون كتابة أدوات مخصصة.

الأفضل لـ:B2B SaaS تحت مستوى المؤسسة. المنتجات التي تضم مئات أو آلاف المستأجرين حيث تكون تكلفة البنية التحتية أكثر أهمية من شهادات الامتثال.

جدول المقارنة

كيف قمنا ببناء DropTaxi على قاعدة بيانات مشتركة متعددة الإيجارات

عندما بنيناDropTaxi، وهي خدمة SaaS لحجز سيارات الأجرة متعددة المستأجرين للمشغلين الهنود، اخترنا نموذج قاعدة البيانات المشتركة مع أعمدة tenant_id.

وكان المنطق واضحا. مشغلي سيارات الأجرة هم شركات صغيرة. ليس لديهم متطلبات الامتثال التي تتطلب العزل على مستوى قاعدة البيانات. يلزم زيادة عدد المستأجرين من 5 إلى 500+ دون تكاليف البنية التحتية لكل مستأجر. ويجب أن يكون الإعداد فوريًا: قم بالتسجيل، وتهيئة العلامة التجارية، وتوجيه المجال، والبدء في البث المباشر. لا يوجد نشر، لا توفير، لا انتظار.

إليك ما تبدو عليه الهندسة المعمارية عمليًا:

تأهيل المستأجر بدون نشر.تعني إضافة مستأجر جديد إدراج صف في جدول tenants يتضمن اسم علامته التجارية، والألوان، وعنوان URL للشعار، والمجال، وأسعار الأجرة، ورمز Telegram bot المميز. لا يوجد خط أنابيب CI قيد التشغيل. لا يتم إعادة تشغيل أي حاوية. يؤدي الطلب التالي إلى هذا المجال إلى حل المستأجر الجديد وعرض الموقع الذي يحمل علامته التجارية.

النطاقات الفرعية ذات العلامات التجارية عبر البرامج الوسيطة.يصل كل طلب HTTP وارد إلى طبقة برمجية وسيطة من Hono تقرأ رأس Host. تستعلم البرامج الوسيطة عن قاعدة البيانات (عبر Drizzle ORM على Turso) للعثور على المستأجر المطابق لهذا النطاق. إذا وجد تطابقًا، فسيتم تحميل التكوين الكامل للمستأجر في سياق الطلب. إذا لم يكن الأمر كذلك، فسيحصل الطلب على 404. ثم تعرض طبقة Astro SSR الصفحات باستخدام العلامة التجارية للمستأجر، بحيث يرى الزائرون موقعًا مستقلاً لحجز سيارات الأجرة بدلاً من منصة عامة.

نشر واحد لجميع المستأجرين.تقوم آلة Fly.io واحدة بتشغيل النظام الأساسي بأكمله. قاعدة بيانات واحدة. قاعدة بيانات واحدة. التكلفة الوحيدة لكل مستأجر هي تكوين DNS والصفوف الموجودة في قاعدة البيانات التي تخزن إعداداته.

يعمل هذا النموذج لأن المنتج لا يخدم الصناعات المنظمة، وحساسية البيانات منخفضة (تفاصيل الحجز، وليس السجلات المالية)، ومخاوف القياس الأساسية هي عدد المستأجرين بدلاً من حجم البيانات لكل مستأجر.

الأنماط العملية للأنظمة متعددة المستأجرين

بغض النظر عن النموذج الذي تختاره، تظهر هذه الأنماط في أنظمة الإنتاج متعددة المستأجرين.

الوسيطة لحل المستأجر

يجب أن يتم حل المستأجر مرة واحدة، على حافة مسار الطلب الخاص بك، ويجب أن ينتشر المستأجر الذي تم حله خلال دورة حياة الطلب بأكملها. استراتيجيات الحل المشتركة:

• النطاق الفرعي:acme.yourapp.com ينتقل إلى المستأجر acme. التحليل من رأس Host.
• المجال المخصص:يقوم app.acme.com بتعيين المستأجر عبر جدول بحث المجال.
• بادئة المسار:yourapp.com/acme/dashboard يستخرج المستأجر من عنوان URL. أقل شيوعًا في الإنتاج، ولكنه مفيد أثناء التطوير.
• مفتاح JWT/API:بالنسبة لمنتجات API-first، يوجد معرف المستأجر في رمز المصادقة المميز. تقوم البرامج الوسيطة بالتحقق من صحة الرمز المميز واستخراج مطالبة المستأجر.

قم بتخزين المستأجر الذي تم حله في سياق نطاق الطلب (c.set() الخاص بـ Hono، أو req.tenant الخاص بـ Express، أو متغير مؤشر الترابط المحلي في Go). لا ينبغي أن يحتاج أي رمز المتلقين للمعلومات إلى إعادة حل المستأجر.

تجمع الاتصال

في نموذج قاعدة البيانات لكل مستأجر، يصبح تجمع الاتصالات هو أول عنق الزجاجة الذي ستواجهه. تحتاج كل قاعدة بيانات مستأجرة إلى مجموعتها الخاصة، ويحتوي خادم التطبيق الخاص بك على عدد محدود من الاتصالات التي يمكنه الاحتفاظ بها مفتوحة.

الحلول التي تعمل في الإنتاج:

• PgBouncer لكل مثيل قاعدة البياناتمع التجميع على مستوى المعاملات. يؤدي هذا إلى تعدد إرسال العديد من اتصالات التطبيق عبر عدد أقل من اتصالات قاعدة البيانات.
• تهيئة التجمع البطيء.لا تقم بإنشاء تجمعات اتصال للمستأجرين الذين لم يتلقوا طلبًا في الساعة الماضية. قم بتدوير المجمعات حسب الطلب وطرد المجمعات الخاملة باستخدام TTL.
• خدمات التجميع المدارةمثل مجمع اتصال Supabase أو برنامج التشغيل بدون خادم الخاص بـ Neon، والذي يتعامل مع إدارة التجمع خارج عملية التطبيق الخاصة بك.

بالنسبة لنماذج قواعد البيانات المشتركة، يعمل تجمع اتصال واحد بشكل جيد. يتم تعيين سياق المستأجر على مستوى الجلسة (SET app.current_tenant لـ RLS، SET search_path لفصل المخطط) في كل عملية سحب اتصال.

التخزين المؤقت على نطاق المستأجر

تحتاج مفاتيح ذاكرة التخزين المؤقت الخاصة بك إلى بادئة المستأجر. إذا قمت بتخزين مفتاح "بيانات لوحة المعلومات" مؤقتًا دون تحديد نطاقه للمستأجر، فسوف تقدم بيانات لوحة معلومات المستأجر أ إلى المستأجر ب. يبدو هذا واضحًا، ولكنه أكثر الأخطاء شيوعًا في الإنتاج متعدد المستأجرين.

استخدم تنسيق مفتاح مثل tenant:{tenant_id}:resource:{resource_type}:{resource_id}. إذا كنت تستخدم Redis، ففكر في قواعد بيانات Redis منفصلة لكل مستأجر (تتوفر 0-15 بشكل افتراضي) لعمليات النشر الأصغر، أو بادئة المفاتيح لعمليات النشر الأكبر.

عزل الوظيفة في الخلفية

تحتاج وظائف الخلفية (إرسال البريد الإلكتروني، وإنشاء التقارير، واستيراد البيانات) إلى نشر سياق المستأجر من موقع قائمة الانتظار إلى العامل. عندما تقوم بإدراج مهمة، قم بتضمين tenant_id في حمولة المهمة. يجب على العامل إعداد نفس سياق المستأجر الذي توفره برامج HTTP الوسيطة قبل معالجة المهمة.

للحصول على حماية من الضوضاء المجاورة في قوائم انتظار المهام، استخدم قوائم انتظار منفصلة أو أولويات قائمة الانتظار لكل مستأجر. يجب ألا يقوم المستأجر الذي يقوم باستيراد 100000 سجل بحظر رسائل البريد الإلكتروني الترحيبية الخاصة بمستأجر آخر. تدعم كل من BullMQ وSidekiq وCelery قوائم الانتظار المسماة التي تتيح لك توجيه المستأجرين ذوي الحجم الكبير إلى العمال المتفانين.

بوابة متعددة كمتغير متعدد الإيجار

لا يعني الإيجار المتعدد فقط "نفس التطبيق، وعملاء مختلفين". يمكن أن يعني أيضًا "نفس النظام الأساسي، وأدوار مستخدم مختلفة مع بوابات منفصلة." عندما بنيناZestAMC، وهو نظام أساسي متعدد البوابات قائم على الأدوار، شاركت البنية نفس قاعدة البيانات وقاعدة التعليمات البرمجية، ولكنها كشفت عن واجهات مختلفة لأنواع مختلفة من المستخدمين: المسؤولين والمديرين والوكلاء الميدانيين. كان لكل بوابة توجيهها وأذوناتها وواجهة المستخدم الخاصة بها، ولكن جميعها مستمدة من نفس طبقة البيانات مع تحديد النطاق على مستوى الصف.

يعد هذا نمطًا مفيدًا عندما لا يكون "المستأجرون" لديك مؤسسات منفصلة ولكن أدوارًا منفصلة داخل مؤسسة واحدة. تظل الأوليات متعددة الإيجارات (الوصول إلى البيانات المحددة النطاق، والبرمجيات الوسيطة لكل دور، ونشر السياق) كما هي.

إطار القرار: كيفية اختيار النموذج الخاص بك

يعتمد النموذج الصحيح على ثلاثة متغيرات: متطلبات الامتثال، وعدد المستأجرين المتوقع، وميزانية البنية التحتية.

ابدأ بالامتثال.إذا كان عملاؤك يعملون في الصناعات الخاضعة للتنظيم (التمويل والرعاية الصحية والحكومة)، أو إذا كانت العقود الخاصة بك تتضمن شروط إقامة البيانات، فإن قاعدة البيانات لكل مستأجر هي الخيار الأكثر أمانًا. علاوة التكلفة هي بند في عقود المؤسسة التي يتوقع عملاؤك دفع ثمنها.

عامل في عدد المستأجرين.إذا كنت تتوقع أقل من 100 مستأجر ويحقق كل مستأجر إيرادات ذات معنى، فإن قاعدة البيانات لكل مستأجر تكون قابلة للتطبيق. بين 100 و5000، يعمل فصل المخطط إذا كنت تستخدم PostgreSQL ويمكنك الاستثمار في أدوات الترحيل. أكثر من 5000، الجداول المشتركة مع RLS هي الخيار العملي. وتنهار اقتصاديات البنية التحتية في النماذج الأخرى مع ارتفاع أعداد المستأجرين.

تحقق من ميزانيتك.إذا كنت في مرحلة ما قبل الإيرادات أو مرحلة التأسيس، فإن الجداول المشتركة مع RLS تتيح لك الشحن بشكل أسرع وإنفاق أقل. يمكنك الانتقال إلى نموذج عزل أقوى لاحقًا عندما يكون لديك عملاء من المؤسسات يطلبون ذلك (ويدفعون مقابله). لا تحتاج معظم منتجات SaaS أبدًا إلى إجراء هذا الترحيل، لأن معظم منتجات SaaS تُباع للشركات الصغيرة والمتوسطة التي تهتم بالميزات، وليس بنماذج عزل قاعدة البيانات.

النظر في النهج الهجين.تقوم بعض المنتجات بتشغيل جداول مشتركة للطبقة القياسية وقاعدة البيانات لكل مستأجر لعملاء المؤسسات. يعد هذا الأمر أكثر تعقيدًا من الناحية التشغيلية، ولكنه يتيح لك خدمة كلا السوقين دون فرض نموذج واحد. يستخدم كل من Stripe و Notion أشكالًا مختلفة من هذا النمط.

أخطاء شائعة يجب تجنبها

• اختيار قاعدة بيانات لكل مستأجر لمنتج سيضم آلاف المستأجرين.التكلفة التشغيلية لإدارة الآلاف من قواعد البيانات تفوق فوائد العزل. إذا كان المستأجرون لديك من الشركات الصغيرة والمتوسطة التي تدفع 50 دولارًا شهريًا، فلن تتمكن من تحمل تكلفة البنية التحتية المخصصة لكل مستأجر.
• نسيان نطاق مجموعة الاختبار الخاصة بك.يجب أن يتم تشغيل اختبارات التكامل الخاصة بك مع سياق المستأجر. إذا نجحت اختباراتك دون تعيين مستأجر، فهي تختبر مسار التعليمات البرمجية الذي لن يصل إليه مستخدمو الإنتاج لديك.
• عدم اختبار سياسات RLS مع الاستعلامات العدائية.اكتب الاختبارات التي تحاول الوصول إلى بيانات Tenant B أثناء مصادقتها على أنها Tenant A. وقم بتشغيلها في CI. مجموعة اختبارات النجاح دون اختبارات الوصول عبر المستأجرين تعطي ثقة زائفة.
• بناء إدارة المستأجرين كفكرة لاحقة.يعد توفير المستأجر وتكوينه وإلغاء توفيره من ميزات المنتج من الدرجة الأولى. أنشئ أدوات الإدارة جنبًا إلى جنب مع المنتج، وليس بعد الإطلاق.
• تخطي التسجيل مع علم المستأجر.يجب أن يتضمن كل سطر سجل معرف المستأجر. عندما تقوم بتصحيح مشكلة إنتاج في الساعة 2 صباحًا، فإن عبارة "حدث خلل ما" تكون عديمة الفائدة. "لقد وصل المستأجر acme_corp إلى قيد المفتاح الخارجي في جدول الطلبات" وهو أمر قابل للتنفيذ.

النسخة القصيرة

اختر قاعدة بيانات لكل مستأجر إذا كان الامتثال هو المحرك لبنيتك. اختر فصل المخطط إذا كنت بحاجة إلى عزل معتدل على نطاق معتدل. اختر الجداول المشتركة مع RLS إذا كنت تعمل على تحسين السرعة والتكلفة. قم ببناء برمجيات وسيطة لحل المستأجر في اليوم الأول. قم بتوسيع نطاق ذاكرات التخزين المؤقت وسجلاتك ووظائف الخلفية واختباراتك لسياق المستأجر. ولا تبالغ في هندسة نموذج العزل لمرحلتك الحالية؛ يمكنك تشديد العزلة عندما يطلبها عملاؤك وتدعمها إيراداتك.

الأسئلة المتداولة