معمارية SaaS متعدد المستأجرين: كيف تختار نموذج العزل قبل البناء

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

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

كل نموذج يجيب عن سؤال واحد: أين تنتهي بيانات المستأجر الأول وتبدأ بيانات الثاني؟ القرار يغيّر كل شيء بعده: النسخ الاحتياطي، والترقية، والتسعير، وحتى طريقة كتابة الاستعلامات.

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

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

إضافة tenant_id إلى كل جدول هي البداية، لا الحل. يجب أن يمر كل استعلام عبر سياق المستأجر، وأن يمنع مستوى الوصول الكتابة خارج هذا السياق. الخطأ الشائع أن يُنسى شرط المستأجر في استعلام واحد، فيرى عميل بيانات عميل آخر. هذا ليس خطأً بسيطاً. هو حادث أمني وإبلاغ محتمل بموجب نظام حماية البيانات.

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

العملاء المؤسسيون يطلبون تخصيصاً: حقول إضافية، وسير عمل مختلف، وتقارير خاصة. إذا لبّيت كل طلب بتفرّع في الكود، فبعد سنة ستدير خمس نسخ لا تستطيع ترقيتها. الحل هو التخصيص عبر الإعدادات والبيانات، لا عبر الشروط في الكود.

في المخطط المشترك، الترقية عملية واحدة. في المخطط لكل مستأجر، تحتاج سكربتاً يمر على كل مخطط ويسجّل النتيجة. في القاعدة لكل مستأجر، تحتاج تنسيقاً ومراقبة لكل قاعدة. كلما زاد العزل، زادت الحاجة إلى أتمتة. الترقية اليدوية لخمسين قاعدة ليست خطة، بل مخاطرة.

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

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

هل يمكن البدء بمخطط مشترك والانتقال لاحقاً؟ نعم، لكن الانتقال يؤثر على المفاتيح والعلاقات والنسخ. صمّم من البداية بحيث يكون المستأجر بُعداً أولياً.

هل tenant_id يكفي للعزل؟ لا. يحتاج سياق طلب وسياسة واختبارات. العمود وحده لا يمنع الخطأ.

ما أغلى جزء في التشغيل؟ المراقبة والنسخ الاحتياطي والترقيات، لا الخوادم.

هل العزل الكامل يرفع السعر؟ نعم، ويُباع للعملاء الذين يحتاجونه. لا تدفع ثمنه لعملاء لا يطلبونه.

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

• Microsoft Azure: نهج تعدد المستأجرين — مقارنة نماذج العزل.
• AWS SaaS — بنية وتشغيل منتجات SaaS.
• اللائحة التنفيذية لنظام حماية البيانات الشخصية — العزل والإفصاح والإبلاغ.
• منصات SaaS — كيف نبني ونشغّل.
• خطة SaaS في 12 أسبوعاً — أين يقع قرار المعمارية.