معماری چندمستاجری در SaaS: جداسازی داده‌ی مشتری‌ها

وقتی محصولی به شکل SaaS عرضه می‌شود، ده‌ها یا صدها مشتری از یک سامانه استفاده می‌کنند. هر مشتری، که در این ادبیات «مستاجر» نامیده می‌شود، باید حس کند سامانه فقط مال خودش است: داده‌ی خودش، تنظیمات خودش، کاربران خودش.

چطور این جداسازی را بسازیم، یکی از اولین و ماندگارترین تصمیم‌های معماری یک محصول SaaS است.

سه الگوی اصلی

۱. پایگاه داده‌ی مشترک، جدول‌های مشترک

همه‌ی مشتری‌ها در یک پایگاه و یک مجموعه جدول. هر ردیف ستونی دارد که می‌گوید مال کدام مشتری است.

• مزیت: ساده‌ترین و ارزان‌ترین راه. اضافه کردن مشتری جدید، فقط یک ردیف است.
• هزینه: جداسازی کاملاً به دقت کد وابسته است. یک پرس‌وجوی بدون شرط مشتری، یعنی نشت داده.

۲. پایگاه مشترک، شِمای جدا

هر مشتری مجموعه جدول‌های خودش را در همان پایگاه دارد.

• مزیت: جداسازی قوی‌تر، پشتیبان‌گیری و بازیابی جداگانه ممکن می‌شود.
• هزینه: هر تغییر ساختار باید برای همه‌ی مشتری‌ها اجرا شود. با زیاد شدن تعداد، مدیریتش سخت می‌شود.

۳. پایگاه داده‌ی جدا برای هر مشتری

• مزیت: قوی‌ترین جداسازی. مناسب مشتری‌های بزرگ یا صنایع با الزام قانونی.
• هزینه: گران‌ترین در زیرساخت و نگهداری.

انتخاب بر اساس چه چیزی؟

• مشتری‌های شما چه کسانی‌اند؟ هزار فروشگاه کوچک با ده بانک فرق دارد.
• الزام قانونی دارید؟ بعضی صنایع جداسازی فیزیکی می‌خواهند.
• قیمت‌گذاری شما چیست؟ اگر مشتری ماهانه مبلغ کمی می‌دهد، پایگاه جدا برایش صرفه ندارد.

بسیاری از محصولات ترکیبی کار می‌کنند: الگوی مشترک برای عموم مشتری‌ها و پایگاه جدا برای مشتری‌های سازمانی. این ترکیب فقط وقتی ممکن است که از ابتدا در طراحی دیده شده باشد.

قاعده‌های امنیتی که نباید نادیده گرفته شوند

بیشتر نشت‌های داده در سامانه‌های چندمستاجری، از یک فراموشی ساده می‌آیند. این قاعده‌ها جلوی آن را می‌گیرند:

1. شناسه‌ی مشتری از نشست می‌آید، نه از درخواست. هرگز به شناسه‌ای که کاربر در نشانی یا بدنه‌ی درخواست فرستاده اعتماد نکنید.
2. فیلتر مشتری در یک لایه‌ی مرکزی اعمال شود. نباید هر برنامه‌نویس در هر پرس‌وجو یادش باشد آن را بنویسد.
3. پایگاه داده هم نگهبان باشد. قابلیت‌هایی مثل سیاست امنیتی سطح ردیف، حتی اگر کد اشتباه کند، جلوی دسترسی را می‌گیرند.
4. آزمون جداسازی بنویسید. تستی که صریحاً بررسی کند مشتری الف نمی‌تواند داده‌ی مشتری ب را ببیند.
5. فایل‌ها و کش را فراموش نکنید. نشت فقط از پایگاه داده نیست؛ فایل‌های آپلودی، کش و صف‌ها هم باید جدا باشند.

چیزهایی که کنار داده باید چندمستاجری شوند

• تنظیمات و برندسازی: هر مشتری لحن، رنگ و قواعد خودش را دارد.
• محدودیت مصرف: یک مشتری پرمصرف نباید سامانه را برای بقیه کند کند.
• صورت‌حساب و سهمیه: مصرف هر مشتری جدا شمرده شود.
• لاگ و ممیزی: بتوانید رویدادهای یک مشتری را جدا ببینید.

نمونه از کار واقعی

پاسخینو یک SaaS چندمستاجری است: هر فروشگاه دانش، کانال‌ها و لحن خودش را دارد و داده‌ی آن از بقیه جداست. در محصولی که دستیار هوش مصنوعی از دانش فروشگاه پاسخ می‌دهد، این جداسازی اهمیت دوچندان دارد: پاسخ یک فروشگاه هرگز نباید از اطلاعات فروشگاه دیگری ساخته شود. سازوکار آن را در دستیار هوش مصنوعی فروش چطور کار می‌کند توضیح داده‌ام.

جمع‌بندی

چندمستاجری تصمیمی است که عوض کردنش بعداً بسیار گران است. الگو را بر اساس نوع مشتری و الزام‌های واقعی انتخاب کنید، جداسازی را ساختاری بسازید و آن را آزمون کنید.

این از آن تصمیم‌هایی است که باید مکتوب شود. اگر در حال طراحی یک محصول SaaS هستید، معماری و برنامه‌ریزی فنی را ببینید.