أنماط معمارية SaaS متعدّدة المستأجرين: دليل عملي

يسجّل مطعمان في منصّتك للطلبات خلال الأسبوع نفسه. الأول مقهى واحد في جدّة، والثاني سلسلة من 40 فرعاً منتشرة في الإمارات. كلاهما يتوقّع أن يشعر بأن البرنامج صُمّم له وحده، بقائمته الخاصة وهويّته البصرية وحسابات موظّفيه وتقاريره. ولا ينبغي أن يرى أيٌّ منهما بيانات الآخر، ولو بالخطأ. طريقة إجابتك على هذا المطلب الواحد، "كيف نخدم عملاء كثيرين من منتج واحد"، هي جوهر معمارية SaaS متعدّدة المستأجرين (multi-tenant)، وهي تشكّل كل شيء من فاتورة الاستضافة إلى سرعة توقيع عميلك التالي.

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

ماذا يعني "multi-tenant" فعلاً

في منتج SaaS، المستأجر (tenant) هو مؤسّسة عميلة، وليس مستخدماً فردياً. قد يضمّ المستأجر الواحد مئات المستخدمين (مديرو الفروع والكاشيرات وموظّفو الإدارة في السلسلة)، لكنّهم جميعاً ينتمون إلى حساب واحد بإعدادات مشتركة وفوترة مشتركة.

تعدّد المستأجرين يعني أن تطبيقاً واحداً قيد التشغيل، وغالباً بنية تحتية واحدة مشتركة، يخدم كثيراً من هؤلاء المستأجرين في آنٍ معاً. البديل، أحادية المستأجر (single-tenant)، يمنح كل عميل نسخته المنفصلة من التطبيق وقاعدة البيانات. أحادية المستأجر أبسط في الفهم، وقد تكون مطلوبة أحياناً لمتطلّبات الامتثال للمؤسّسات الكبرى، لكنّها مكلفة في التشغيل وبطيئة في التحديث لأن كل عميل عبارة عن عملية نشر مستقلّة بذاتها.

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

أنماط عزل البيانات الثلاثة الأساسية

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

قاعدة بيانات مشتركة، مخطّط مشترك

تعيش بيانات كل المستأجرين في الجداول نفسها، مفصولةً بعمود tenant_id في كل صف. وأيّ استعلام لمستأجر يفلتر دائماً بهذا المعرّف.

• نقاط القوّة: أقلّ تكلفة، أسهل توسّعاً إلى آلاف المستأجرين، وأبسط في الصيانة والترحيل.
• نقاط الضعف: خطأ واحد في استعلام نسي فلتر tenant_id قد يسرّب بيانات عميل إلى آخر. العزل هنا يعتمد كلياً على انضباط الكود.

هذا أكثر الأنماط شيوعاً في SaaS عالي الحجم، ويعمل جيداً عند اقترانه بضمانات قوية (المزيد عنها أدناه).

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

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

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

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

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

• نقاط القوّة: نطاق ضرر نظيف، وسهولة في تلبية متطلّبات صارمة لإقامة البيانات (data residency) أو الامتثال، وتوسّع بسيط لكل مستأجر لعميل ثقيل.
• نقاط الضعف: أعلى تكلفة وتعقيد تشغيلي. إدارة الاتّصالات والترحيلات والمراقبة كلها تتضاعف مع كل قاعدة بيانات جديدة.

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

فرض العزل حتى لا تتسرّب البيانات أبداً

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

• ادفع تحديد نطاق المستأجر إلى ما دون كود التطبيق. ميزات قاعدة البيانات مثل أمان مستوى الصفّ (row-level security) في PostgreSQL يمكنها فرض أن الاتّصال لا يرى سوى صفوف مستأجره، حتى لو نسي الاستعلام الفلتر. هذا يحوّل كارثة محتملة إلى استعلام لا يعيد شيئاً ببساطة.
• حدّد المستأجر مرّة واحدة، مبكّراً، وثق به في كل مكان. تعرّف على المستأجر من الجلسة الموثّقة أو النطاق الفرعي عند حافة الطلب، أرفقه بسياق الطلب، ولا تدع أيّ استعلام يعيد اشتقاقه من مدخلات المستخدم.
• اجعل الأصل هو منع الوصول العابر للمستأجرين. اكتب طبقة بياناتك بحيث يؤدّي إغفال فلتر المستأجر إلى الفشل أو إعادة نتيجة فارغة، لا إلى إعادة كل شيء. الإعدادات الافتراضية الآمنة تتفوّق على المطوّرين الحذرين.
• اختبر التسرّب عمداً. أدرِج اختبارات آلية يحاول فيها المستأجر "أ" قراءة سجلّات المستأجر "ب"، ويجب أن تفشل. العزل الذي لا يُختبر هو عزل لا يمكنك الوثوق به.

التوسّع والتخصيص ومشكلة "الجار المزعج"

بمجرّد أن يصبح العزل متيناً، تصبح قابلية التوسّع هي الهمّ التالي. في نظام مشترك، قد يُضعف مستأجر ثقيل واحد الأداء للجميع، وهي مشكلة "الجار المزعج" (noisy neighbor) الكلاسيكية.

بعض الأنماط تبقي ذلك تحت السيطرة:

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

التخصيص هو المطلب المتكرّر الآخر. سيرغب المستأجرون في هويّتهم البصرية الخاصة، وأعلام الميزات (feature flags)، وأحياناً حقول مخصّصة. تعامل مع ذلك عبر الإعدادات ونموذج إعدادات مرن لكل مستأجر، لا عبر تفريع قاعدة الكود. ففي اللحظة التي يحصل فيها عميل واحد على فرع خاص من كودك، يبدأ امتيازك "منتج واحد، مستأجرون كثر" بالتآكل.

أهم النقاط

• المستأجر هو مؤسّسة عميلة؛ وتعدّد المستأجرين يعني تطبيقاً مشتركاً واحداً يخدم كثيرين منهم، وهو ما يجعل SaaS مجدياً اقتصادياً على نطاق واسع.
• عزل البيانات هو أهمّ قراراتك المعمارية، بثلاثة أنماط رئيسة: مخطّط مشترك (الأرخص)، ومخطّط لكل مستأجر (حلّ وسط)، وقاعدة بيانات لكل مستأجر (أقوى عزل).
• النموذج الهجين يتيح لك إبقاء المستأجرين الصغار على مخطّط مشترك مع منح العملاء المؤسّسيين الكبار قاعدة بيانات مخصّصة.
• افرض العزل تحت طبقة التطبيق (مثلاً عبر row-level security) واختبر التسرّب بين المستأجرين؛ ولا تعتمد على انضباط المطوّرين وحده.
• خطّط للجيران المزعجين عبر تحديد المعدّل لكل مستأجر، والعمل الخلفي غير المتزامن، والمراقبة لكل مستأجر، وعالج التخصيص عبر الإعدادات لا عبر تفريع الكود.

معمارية multi-tenant من تلك القرارات الرخيصة عند إتقانها في البداية، والمكلفة عند إصلاحها لاحقاً. إن كنت تبني منتج SaaS، أو توسّع منتجاً بدأ يئنّ تحت الضغط، يمكن لـ SummationWorks مساعدتك في اختيار نموذج العزل الصحيح وبنائه ليكبر معك. استكشف خدماتنا، واطّلع على أعمالنا، أو تواصل معنا لمناقشة معماريتك.