SaaS متعدد المستأجرين serverless على AWS: معمارية بتتوسع لكل tenant

السؤال اللي بيحدد معماريتك

خليني أحكي معك مباشرة: القرار الواحد اللي بيرسم شكل أي SaaS متعدد المستأجرين هو كيف بتعزل الـ tenants. اعمله صح وبتتوسع لآلاف العملاء على بنية تحتية مشتركة مع نموذج تكاليف نظيف. اعمله غلط وإما بتسرّب بيانات عميل لعميل تاني، وهاد الشي بينهي الشركة، أو بتبني بنية تحتية مخصصة لكل tenant، وهاد الشي بيفلّسها.

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

عزل الـ multi-tenant مش ميزة بتضيفها. هو خاصية بتفرضها على كل طبقة: قاعدة البيانات، فهرس البحث، الـ API، الوكلاء، والداشبورد. طبقة وحدة ما بتكفي.

نحنا مشغّلين هالمعمارية في الإنتاج بمنصتنا Exfinity، وهي SaaS متعدد المستأجرين على AWS بتخدم tenants معزولين من بنية تحتية مشتركة بمنطقة أوروبية. هاد الدليل هو التصميم الحقيقي. لبديل تنسيق الحاويات، شوف دليلنا عن Kubernetes لمنصات SaaS، وهاد شغل سحابة من صلب عملنا.

مين بيهمه شو

Serverless أو الحاويات: اختار لكل خدمة

الـ serverless مش كل شي أو ولا شي. المعمارية الصح بتستخدم الاتنين، مختارين حسب نوع الشغل.

الـ functions-as-a-service بتناسب الشغل المتقطع، المدفوع بالأحداث، وقصير العمر: endpoint للـ API، مستهلك طابور، مهمة مجدولة. بتدفع لكل استدعاء وبتنزل للصفر. الخدمات طويلة العمر أو اللي بتحمل حالة، متل API بحث ماسك فهارس دافئة، أو runtime للـ AI بيدير حالة الوكلاء، بتناسب الحاويات على حوسبة مُدارة، وين بتخلي العمليات دافئة وبتتحكم بالـ runtime.

Exfinity بيشغّل الـ API وتدفقات الدفع كدوال، والبحث وruntime الـ AI والاستيعاب والداشبورد كحاويات على حوسبة مُدارة، وكل واحد بيتوسع لحاله. الدرس: لا تفرض نموذج واحد على كل شي. دليلنا عن platform engineering بيغطي هالمقايضة بعمق.

طبقات عزل الـ tenants الست

هاد قلب الدليل كله. العزل مفروض على كل طبقة بيلمسها الطلب.

Request with tenant identity
   │
   ▼
[1] API middleware   ── tenant id from the token, never the query string
[2] Database         ── tenant id as partition key on every query
[3] Search index     ── tenant filter on every search
[4] Agents / AI       ── conversation and memory scoped per tenant
[5] Tool layer       ── every tool checks scope before it runs
[6] Dashboard        ── cross-tenant access returns not-found, not forbidden

الـ API middleware. هوية الـ tenant بتجي من الـ claims المتحقق منها بالـ token، مش من باراميتر بالـ query أي مستدعي بيقدر يزوّره. أي tenant id بالـ URL من مستخدم مش admin بينهمل بصمت. هاي أول بوابة، وهي اللي أكتر الناس بتغلط فيها.

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

فهرس البحث. كل بحث بيحمل فلتر tenant، فاستعلام tenant ما بيقدر أبداً يرجّع مستندات tenant تاني، حتى لو كانوا متشاركين بنفس الفهرس.

الوكلاء والذاكرة. كل محادثة محصورة بـ tenant واحد، واسترجاع ذاكرة الوكلاء بيفرض هالنطاق، فوكيل بيخدم الـ tenant A ما بيقدر يسترجع خيوط الـ tenant B. بنغطي هاد في دليلنا عن ذاكرة الوكلاء.

طبقة الأدوات. كل أداة بيقدر الوكيل يستدعيها بتتحقق من نطاق الـ tenant قبل التنفيذ، وبتحمل الـ tenant والقناة والموارد المسموحة في سياق تشغيلها.

الداشبورد. الوصول عبر الـ tenants بيرجّع not-found بدل forbidden، بحيث الرد ما بيأكد حتى إن مورد الـ tenant التاني موجود.

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

لبنات البناء على AWS

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

النمط اللي لازم تلاحظه: مخازن البيانات قاعدة بشبكات فرعية خاصة بدون أي وصول عام، الحوسبة بتوصلها عبر الـ VPC، وبس الـ load balancer والـ CDN بيواجهوا الإنترنت. إغناء الـ tokens عند طبقة المصادقة هو المكان اللي بتنختم فيه هوية الـ tenant بكل طلب، بحيث الخدمات اللي بعدها تقدر تثق فيها. دليلنا عن البنية التحتية ككود بيغطي كيف تجهّز كل هاد بشكل قابل للتكرار.

حدود لكل tenant: كيف تمنع tenant واحد يغرّق السفينة

البنية التحتية المشتركة معناها إن الحمل الجامح لـ tenant واحد أو مفتاحه المسرّب بيصير مشكلة الكل، إلا إذا حددته. في كنترولين مهمين.

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

بدون هدول، أهمل عميل عندك هو اللي بيحدد أرضية الموثوقية للكل. دليلنا عن تصميم الأنظمة للفشل بيغطي هالوضعية الدفاعية.

العمود الفقري للأحداث: فك ارتباط المنصة

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

آليتين بيحملوا هاد الشي. الطوابير المرتبة بتتعامل مع الشغل اللي لازم يصير مرة وحدة بالضبط وبالترتيب، متل حجز بيتحول لحجز عند المورّد، مع dead-letter queue بتلقط أي شي بيفشل بحيث ما في شي بيضيع بصمت. وخدمة جدولة بتطلق المهام المتكررة، فحوصات الحداثة، التنظيف، الأرشفة، بدون سيرفر cron لازم حدا يجالسه.

User action ──▶ fast response
     │
     └──▶ ordered queue ──▶ worker ──(fail)──▶ dead-letter queue
                                                      │
                                            alert, inspect, replay

Exfinity بيمرر الحجوزات وتوليد المستندات عبر طوابير مرتبة مع dead-letter queues، وبيدير جداول الزحف والصيانة من ناقل أحداث. المنصة الصحية بتخلي هالـ dead-letter queues فاضية، فأي وحدة مش فاضية هي إنذار. هاي نفس انضباط الموثوقية متل دليلنا عن تكامل الشركات، مطبّق داخل منصة وحدة، والنمط العام موجود في دليلنا عن المعمارية المدفوعة بالأحداث.

إقامة البيانات: وين بتعيش فيزيائياً

للعملاء الأوروبيين، هاد مش تفضيل، هاد شرط. إذا عقدك أو الـ GDPR بيقول إن البيانات بتضل بالاتحاد الأوروبي، معماريتك لازم تفرض هالشي، مش بس تدّعيه.

هاد معناه تختار منطقة عن قصد وتخلي التخزين والمعالجة جواتها. Exfinity شغال بمنطقة أوروبية، مع كل البيانات التشغيلية والبحث والكاش داخل المنطقة، وقائمة موثّقة بالمعالجين الفرعيين وشو بيلمس كل واحد فيهم. مزودو النماذج خارج الاتحاد الأوروبي بينعاملوا كمعالجين فرعيين مع شروط معالجة بيانات، والبيانات الشخصية ممكن تنحجب عنهم بالكامل بالترميز، متل ما غطينا في دليلنا عن RAG الآمن للـ PII. دليلنا عن الـ GDPR والـ AI وصفحة الثقة بيغطوا إطار الامتثال.

البنية التحتية ككود: قابلة للتكرار أو ولا شي

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

الانضباط اللي بيفرق: state منفصل لكل بيئة، أدوار بأقل صلاحية للـ pipeline نفسها، وصفر تغييرات يدوية بالكونسول بتنحرف عن الكود. Exfinity بيجهّز الـ stack تبعه بـ Terraform مع wrapper لإعدادات كل خدمة والـ state البعيد، وبيرقّي عبر التطوير والـ staging والإنتاج مع موافقة يدوية على الإنتاج. دليلنا عن البنية التحتية ككود بيغطي الممارسات اللي بتخلي هاد الشي قابل للصيانة.

كيف تبلش

1. قرر العزل أولاً. افرض نطاق الـ tenant على كل طبقة قبل ما تبني الميزات.
2. قسّم الحوسبة حسب نوع الشغل. دوال للمتقطع والمدفوع بالأحداث، حاويات للدافئ واللي بيحمل حالة.
3. اختم هوية الـ tenant عند المصادقة. حطها بـ claims متحقق منها بالـ token، وما تثق أبداً بالعميل.
4. ضيف حدود لكل tenant بكير. حدود معدل وسقوف تكلفة قبل ما تستقبل حمل حقيقي.
5. حوّل كل شي لكود. بنية تحتية ككود من أول يوم، مش ترقيع لاحق.

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

الطرق الشائعة اللي بيروح فيها هاد الشي بالغلط

1. العزل بطبقة وحدة. فحص واحد ضايع بيسرّب بيانات. افرض نطاق الـ tenant بكل مكان.
2. الثقة بالعميل بهوية الـ tenant. أي tenant id بالـ URL قابل للتزوير. استخدم claims متحقق منها بالـ token.
3. ما في حدود لكل tenant. حمل tenant واحد أو مفتاحه المسرّب بيغرّق الكل. حدّده.
4. مخازن بيانات عامة. قواعد البيانات والبحث لازم يعيشوا بشبكات فرعية خاصة، والوصول إلهن بس عبر الـ VPC.
5. بنية تحتية يدوية. تغييرات الكونسول بتنحرف وما بتنعاد. حوّل كل شي لكود.
6. تجاهل الإقامة لحد ما عقد يسأل عنها. ترقيع قيود المنطقة لاحقاً مؤلم. اختار عن قصد من البداية.

مين بيبني هاد الشي

Oronts شركة برمجيات بقيادة مؤسسها في ميونخ. Refaat Al Ktifan، مؤسسنا ومهندس الحلول، بيقود فريق senior عبر الـ backend والسحابة والمنصات. المعمارية بهاد الدليل هي التصميم الحقيقي ورا Exfinity، وهو SaaS متعدد المستأجرين منشغّله على AWS بمنطقة أوروبية. منصمم نموذج العزل، منبني طبقات الـ serverless والحاويات، منحوّل البنية التحتية لكود، ومنسلّمك منصة بتقدر تشغّلها وتوسّعها. شوف صفحات الخدمات والحلول عنا.

الخلاصات

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

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

عم تبني أو توسّع منصة متعددة المستأجرين على AWS؟ خبرنا عن احتياجات العزل والإقامة عندك. ابلش من التواصل أو خد عرض سعر محدد النطاق.