يسجّل عميلك الأول فيعمل كل شيء. ويسأل عميلك الخمسون هل يمكن أن تظهر بياناته يوماً في لوحة عميل آخر. ويطلب عميلك المئتان قاعدة بيانات مخصصة لأن فريق الأمن لديه يشترط ذلك. ونموذج تعدد المستأجرين الذي اخترته في الأسبوع الأول هو ما يحدد مدى صعوبة كل محادثة من هذه المحادثات.
تعدد المستأجرين من القرارات القليلة في منتجات SaaS التي يكلّف التراجع عنها كثيراً. فتصميم البيانات والمصادقة والتخزين المؤقت والنسخ الاحتياطي وباقات التسعير كلها ترث منه. وكثير من الفرق تتعامل معه كإعداد في الإطار البرمجي، ثم تقضي ربعاً كاملاً في فك تشابكه عند وصول مشترين من المؤسسات الكبيرة.
في هذا الدليل ستتعرف على:
- نماذج العزل الأساسية الثلاثة ونقطة الضعف في كل منها
- كيف تطابق النموذج مع عملائك ومتطلبات الامتثال وميزانيتك
- التفاصيل التشغيلية التي تُبقي تعدد المستأجرين قابلاً للإدارة عند التوسع
لنبدأ بما يشمله هذا المصطلح فعلاً.
جدول المحتويات
1. ماذا يعني تعدد المستأجرين في الواقع
المستأجر (Tenant) هو مؤسسة عميلة لها مستخدموها وبياناتها وإعداداتها الخاصة. أما التطبيق متعدد المستأجرين (Multi-Tenant) فيخدم عدة مستأجرين من نسخة واحدة من الكود. ويقابله النموذج أحادي المستأجر، حيث يحصل كل عميل على نسخة مستقلة من التطبيق والبنية التحتية.
السؤال المفيد ليس "هل التطبيق متعدد المستأجرين أم لا؟" بل ما مدى قوة العزل بين المستأجرين؟ فالعزل طيف يشمل البيانات والموارد الحاسوبية والإعدادات وحتى توقيت الإصدارات. وكل نموذج في هذا الدليل يقع في نقطة ما على هذا الطيف، ويوازن بين قوة العزل والتكلفة والجهد التشغيلي.
نصيحة: اكتب في فقرة واحدة وعد العزل الذي ستقدمه لأكثر عملائك حساسية أمنياً. ثم اختر أرخص نموذج يستطيع الوفاء بهذا الوعد بصدق.
2. نماذج العزل الثلاثة الأساسية
تقريباً كل نظام متعدد المستأجرين هو صيغة من ثلاثة تصميمات للبيانات.
2.1 قاعدة بيانات مشتركة ومخطط مشترك
يحمل كل جدول يخص المستأجرين عمود tenant_id، وكل استعلام يقوم بالتصفية على هذا العمود. هذا هو النموذج الأرخص والأبسط، ويتوسع جيداً إلى آلاف المستأجرين الصغار.
الخطر واضح: استعلام واحد ينسى التصفية قد يسرّب بيانات بين العملاء. ويُعالج ذلك بفرض العزل في مكان واحد، مثل النطاق العام للاستعلامات (Global Scope) في الـ ORM أو أمان مستوى الصف (RLS) في PostgreSQL، بدلاً من الاعتماد على تذكّر كل مطور له.
2.2 قاعدة بيانات مشتركة ومخططات منفصلة
يحصل كل مستأجر على مخطط (Schema) خاص به في PostgreSQL أو على مجموعة جداول خاصة داخل قاعدة بيانات واحدة. العزل أقوى، ويصبح تصدير بيانات مستأجر واحد أو استعادتها أسهل بكثير.
تظهر التكلفة في التشغيل. فكل ترحيل (Migration) يُنفَّذ مرة لكل مستأجر، وبعد بضعة آلاف من المخططات يبدأ فهرس قاعدة البيانات نفسه في الإجهاد.
2.3 قاعدة بيانات لكل مستأجر
يحصل كل مستأجر على قاعدة بيانات مخصصة. يمنح ذلك أقوى عزل، ونسخاً احتياطياً واستعادة لكل مستأجر، وسهولة في الالتزام بمتطلبات موقع البيانات، وإمكانية وضع المستأجر الكبير على عتاد أقوى.
الثمن هو إدارة الاتصالات وتوزيع الترحيلات على القواعد وتكلفة أساسية أعلى لكل عميل جديد، حتى لو لم ينمُ هذا العميل أبداً.
| النموذج | العزل | التكلفة لكل مستأجر | جهد الترحيلات | الأنسب لـ |
|---|---|---|---|---|
| مخطط مشترك | منطقي (الكود وRLS) | الأقل | تنفيذ واحد | مستأجرون كثيرون وصغار بالاشتراك الذاتي |
| مخططات منفصلة | منطقي قوي | منخفضة إلى متوسطة | تنفيذ لكل مستأجر | منتجات الشركات المتوسطة بعشرات إلى مئات المستأجرين |
| قاعدة بيانات لكل مستأجر | فعلي | الأعلى | تنفيذ لكل مستأجر بتنسيق آلي | المؤسسات الكبيرة والعملاء المنظَّمون أو المقيّدون بموقع البيانات |
3. كيف تختار النموذج المناسب لمنتجك
خمسة أسئلة تحسم معظم القرار:
- كم مستأجراً تتوقع، وما حجم كل منهم؟ آلاف الحسابات الصغيرة تشير إلى المخطط المشترك. أما عشرات العملاء الكبار فقد يبررون عزلاً أقوى.
- ماذا تشترط فرق الأمن لدى مشتريك؟ الاستبيانات التي تسأل عن "الفصل المنطقي أو الفعلي" إشارة مهمة.
- هل يحتاج أي عميل إلى بقاء بياناته في منطقة جغرافية محددة؟ الأمر أسهل بكثير مع قواعد البيانات المنفصلة.
- ما مقدار التخصيص لكل مستأجر الذي تقدمه؟ الحقول وسير العمل المخصصة أسهل في الاحتواء حين لا يتشارك المستأجرون الجداول.
- ماذا يستطيع فريقك تشغيله؟ مئتا قاعدة بيانات تحتاجان أتمتة. والفريق الذي لا يملكها لا ينبغي أن يبدأ من هنا.
ولا يلزم اختيار نموذج واحد للجميع. النمط الشائع والصحي هو النموذج الهجين: مخطط مشترك افتراضياً، مع عرض قاعدة بيانات مخصصة للباقات الأعلى أو للعملاء المنظَّمين. ولا ينجح ذلك إلا إذا كان التطبيق يحدد الاتصال الصحيح لكل مستأجر منذ اليوم الأول.
نصيحة: سعّر العزل. إذا كانت قاعدة البيانات المخصصة تكلفك مبلغاً حقيقياً لكل مستأجر، فاجعلها ميزة في باقة أعلى بدلاً من تحمّل تكلفتها.
4. تحديد المستأجر وعزل البيانات
يجب أن يجيب كل طلب عن سؤال واحد قبل أن يلمس البيانات: أي مستأجر هذا؟ والإشارات الشائعة هي النطاق الفرعي (acme.yourapp.com) أو نطاق مخصص أو بادئة في المسار أو قيمة داخل رمز المصادقة.
حدّد المستأجر مرة واحدة وفي أبكر نقطة ممكنة، واحفظه في سياق الطلب. ولا تثق أبداً بمعرّف مستأجر يأتي في جسم الطلب أو في رابطه، لأن المستخدم يستطيع تغييره.
- 1وصول الطلبنطاق فرعي أو نطاق أو رمز
- 2تحديد المستأجرمرة واحدة عند الحافة
- 3ربط السياقاتصال أو نطاق عزل
- 4التحقق من الصلاحيةالمستخدم تابع للمستأجر
- 5الاستعلام والردمعزول افتراضياً
مثال توضيحي
ويجب أن يكون العزل بعد ذلك تلقائياً لا اختيارياً. استخدم نطاقاً عاماً أو سياسات RLS أو تبديل الاتصال، بحيث يكون الاستعلام غير المعزول مستحيلاً أو يفشل بوضوح.
التسريبات الخفية نادراً ما تكون في SQL. فهي تختبئ في مفاتيح الكاش والمهام في الطوابير ومسارات تخزين الملفات وفهارس البحث. أضف اسم المستأجر إلى كل منها، واجعل المهام الخلفية تحمل معرّف المستأجر صراحة، لأن العامل الخلفي لا يملك طلباً يقرأ منه.
5. الجار المزعج وعزل الأداء
في النظام المشترك قد يبطئ استيراد ضخم أو تقرير خارج عن السيطرة من مستأجر واحد بقية المستأجرين. هذه هي مشكلة الجار المزعج (Noisy Neighbor)، وتظهر عادة أول مرة ينضم فيها عميل كبير.
وسائل الدفاع العملية، بالترتيب الذي نضيفها به تقريباً:
- حدود معدل الطلبات لكل مستأجر على الـ API، حتى لا يستنزف تكامل واحد خوادم التطبيق.
- طوابير عادلة، تُقسَّم فيها الأعمال الخلفية أو تُوزن لكل مستأجر بدلاً من "الأسبق أولاً".
- مهلات للاستعلامات وحدود للتصفح حتى لا يحتجز استعلام مكلف واحد اتصالاً لدقائق.
- حصصاً للموارد في التخزين والمقاعد وحجم التصدير، مرتبطة بالباقة.
- النقل، بحيث ينتقل المستأجر الثقيل فعلاً إلى قاعدة بيانات أو مجموعة عمال مخصصة.
ولا يعمل شيء من هذا دون رؤية واضحة. أضف معرّف المستأجر إلى كل سطر سجل وكل مقياس وكل تتبع من البداية، لتتحول عبارة "التطبيق بطيء" إلى "المستأجر 412 ينفذ تصديراً من 3 ملايين صف".
6. الترحيلات والنسخ الاحتياطي وعمليات كل مستأجر
في العمليات اليومية يكسب نموذج العزل مكانته أو يخسرها.
الترحيلات. المخطط المشترك يُرحَّل مرة واحدة. أما المخططات أو القواعد المنفصلة فتحتاج أداة تمر على المستأجرين وتسجل التقدم وتستأنف بعد أي فشل. صمّم لفترة يعمل فيها المستأجرون بإصدارات مختلفة من المخطط، باستخدام تغييرات التوسيع ثم الانكماش (Expand and Contract) ليعمل الكود القديم والجديد معاً.
النسخ الاحتياطي والاستعادة. استعادة مستأجر واحد من نسخة احتياطية لقاعدة مشتركة أمر صعب، لأنك تحتاج إلى استخراج صفوفه دون المساس بصفوف الآخرين. وإذا كان أي عميل سيطلب يوماً "أعيدوا بياناتنا إلى يوم الثلاثاء"، فخطط لذلك قبل أن تحتاجه.
إنهاء الخدمة والحذف. تفرض قواعد الخصوصية والعقود حذف بيانات العميل المغادر بالكامل، بما في ذلك الملفات والكاش وفهارس البحث. وهذا استعلام لكل جدول في المخطط المشترك، وأمر حذف واحد في القاعدة المخصصة. وفي الحالتين ابنِه كمهمة مختبرة وقابلة للتكرار.
تصدير البيانات. يطلبه مشترو المؤسسات أثناء التعاقد. ويسهل بناء تصدير نظيف لكل مستأجر حين يكون العزل مركزياً بالفعل.
7. مسار عملي للمنتجات في مراحلها الأولى
لمعظم منتجات SaaS الجديدة نبدأ بـ مخطط مشترك، ولكن بانضباط:
- ضع
tenant_idعلى كل جدول يخص المستأجرين منذ أول ترحيل، حتى لو كان لديك عميل واحد. - افرض العزل مركزياً بنطاق عام أو RLS، وليس بالعرف والاتفاق.
- أبقِ تحديد المستأجر خلف واجهة واحدة، ليكون تبديل الاتصالات لاحقاً تغييراً محدود الأثر.
- اكتب اختبارات آلية تنشئ مستأجرين وتتأكد من أن أياً منهما لا يستطيع قراءة بيانات الآخر أو تعديلها. ونفّذها مع كل بناء.
- خزّن الملفات وعناصر الكاش وحمولات المهام بمفاتيح تراعي المستأجر.
والعائد هو المرونة. فبما أن كل صف يحمل tenant_id أصلاً، يصبح نقل عميل واحد إلى قاعدة بيانات مخصصة لاحقاً نسخاً مصفّى وتغييراً في الاتصال، لا إعادة كتابة. وتحتفظ بتكلفة المخطط المشترك المنخفضة إلى أن تبرر متطلبات عميل ما دفع ثمن عزل أقوى.
8. الأسئلة الشائعة
ما هي معمارية تعدد المستأجرين في منتجات SaaS؟
هي تصميم يخدم فيه تطبيق واحد منشور عدة مؤسسات عميلة (مستأجرين)، لكل منها مستخدموها وبياناتها المفصولة عن الآخرين. ويمكن أن يكون الفصل منطقياً باستخدام عمود tenant_id، أو فعلياً باستخدام مخططات أو قواعد بيانات منفصلة.
أي نموذج لتعدد المستأجرين هو الأرخص تشغيلاً؟
قاعدة البيانات المشتركة بمخطط مشترك هي الأقل تكلفة لكل مستأجر، لأن كل العملاء يستخدمون الجداول والبنية التحتية نفسها. والمقابل أنك تحتاج إلى فرض العزل بعناية شديدة لتجنب تسرب البيانات بين المستأجرين.
هل يمكن تغيير نموذج تعدد المستأجرين لاحقاً؟
نعم، لكن التكلفة تعتمد على طريقة البداية. فإذا كان كل جدول يحمل tenant_id أصلاً وكان تحديد المستأجر مركزياً، فإن نقل عميل إلى قاعدة بيانات مخصصة يكون في الغالب نسخاً مصفّى وتغييراً في الاتصال. وبدون هذه العادات قد يقترب الأمر من إعادة الكتابة.
هل يجعل تعدد المستأجرين التطبيق أقل أماناً؟
ليس بحد ذاته. فالأمان يعتمد على مدى اتساق فرض العزل. والعزل المركزي وأمان مستوى الصف ومفاتيح الكاش والملفات التي تراعي المستأجر والاختبارات الآلية بين المستأجرين تجعل النظام المشترك آمناً. ومع ذلك قد يشترط بعض العملاء المنظَّمين فصلاً فعلياً.
الخاتمة
تعدد المستأجرين ليس قراراً واحداً بل مجموعة مفاضلات بين العزل والتكلفة والجهد التشغيلي. المخطط المشترك رخيص وبسيط لكنه يتطلب عزلاً صارماً. والمخططات المنفصلة تضيف عزلاً على حساب ترحيلات أثقل. وقاعدة البيانات لكل مستأجر تمنح أقوى الضمانات بأعلى تكلفة تشغيل.
ونقطة البداية الأكثر أماناً لمعظم المنتجات هي مخطط مشترك منضبط يُبقي الباب مفتوحاً أمام قواعد بيانات مخصصة للعملاء الذين يحتاجونها. قرر بوعي، وافرض العزل في مكان واحد، واختبره مع كل بناء.
💬 على أي نموذج لتعدد المستأجرين يعمل منتجك اليوم، وهل كنت ستختاره مرة أخرى؟
التعليقات