معماری چندسازمانی (Multi-Tenant): کجا ارزش دارد و کجا گران تمام می‌شود

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

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

سه سطح جداسازی و معاملهٔ هرکدام

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

شمای مشترک با شناسهٔ مستأجر

همهٔ مستأجرها در یک پایگاه داده و یک مجموعه جدول، با یک ستون شناسهٔ مستأجر در هر ردیف.

ارزان‌ترین و ساده‌ترین گزینه برای عملیات است و بهترین بهره‌وری منابع را دارد. هزینه‌اش این است که جداسازی کاملاً به درستی کد وابسته می‌شود: یک پرس‌وجو که فیلتر مستأجر را جا بیندازد، دادهٔ یک مشتری را به مشتری دیگر نشان می‌دهد. این خطر را نباید با بازبینی کد مدیریت کرد؛ باید در لایهٔ دسترسی به داده اجباری شود، طوری که پرس‌وجوی بدون فیلتر اصلاً امکان‌پذیر نباشد.

بازیابی هم دشوار است: بازگرداندن دادهٔ یک مستأجر به دیروز بدون دست زدن به بقیه، کار ساده‌ای نیست و باید از ابتدا راهکار داشته باشد.

شما به‌ازای هر مستأجر

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

هزینهٔ اصلی در کوچ اسکیما ظاهر می‌شود. هر تغییر ساختار باید روی همهٔ شماها اجرا شود؛ یعنی ابزار کوچ باید از روز اول اجرای دسته‌ای، گزارش وضعیت به تفکیک مستأجر و ادامه از نقطهٔ شکست را پشتیبانی کند. با ده مستأجر این قابل مدیریت است؛ با چند صد مستأجر، خودش یک زیرسیستم می‌شود.

پایگاه داده به‌ازای هر مستأجر

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

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

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

قاتل واقعی: سفارشی‌سازی به‌ازای مشتری

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

هر کدام به‌تنهایی بی‌ضرر است. مجموعشان پس از دو سال، پایگاه کدی می‌سازد که هر تغییرش باید برای همهٔ مستأجرها آزمایش شود و هیچ‌کس دقیقاً نمی‌داند کدام شرط برای کدام مشتری نوشته شده.

مرز عملی را می‌شود از روز اول تعریف کرد:

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

اگر مشتری چیزی می‌خواهد که در دستهٔ اول و دوم نمی‌گنجد، پاسخ درست یا «نه» است یا «بله، به‌عنوان قابلیت محصول برای همه» — با زمان‌بندی محصول، نه با وعدهٔ فروش.

همسایهٔ پرسروصدا

در منابع مشترک، یک مستأجر می‌تواند تجربهٔ بقیه را خراب کند: گزارشی سنگین در ساعت اوج، ورود انبوه داده، یا حلقه‌ای که واسط برنامه‌نویسی را اشباع می‌کند.

چهار سازوکار معمولاً کافی است: سهمیهٔ نرخ درخواست به تفکیک مستأجر؛ صف جدا برای کارهای سنگین، خارج از مسیر تراکنش‌های تعاملی؛ مهلت و سقف هزینه برای پرس‌وجوها، چون یک پرس‌وجوی بدون سقف کافی است تا پایگاه داده را زمین بزند؛ و پایش مصرف به تفکیک مستأجر، تا منشأ کندی در چند دقیقه پیدا شود.

این سهمیه‌ها باید در سطح خدمت هم نوشته شوند؛ محدودیتی که مشتری از آن بی‌خبر است، در اولین برخورد به شکایت تبدیل می‌شود.

اقامت داده و حسابرسی به تفکیک مستأجر

برخی مشتریان — به‌ویژه در حوزه‌های تنظیم‌شده — الزاماتی دارند که با شمای مشترک قابل تأمین نیست: نگهداری داده در جغرافیای مشخص، کلید رمزنگاری اختصاصی، دورهٔ نگهداشت متفاوت، یا حق حسابرسی مستقل.

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

گزارش دسترسی هم باید به تفکیک مستأجر و فقط شامل دادهٔ همان مستأجر استخراج شود؛ گزارشی که فیلتر دستی لازم دارد، در حسابرسی جدی قابل ارائه نیست.

کِی تک‌مستأجری پاسخ درست است

• وقتی تعداد مشتریان کم و اندازه‌شان بزرگ است و هرکدام مذاکرهٔ جداگانه دارند.
• وقتی الزام حاکمیتی یا امنیتی، استقرار در محیط مشتری را اجباری می‌کند.
• وقتی چرخهٔ ارتقا باید در کنترل مشتری باشد، نه شما.
• وقتی تفاوت نیازها آن‌قدر زیاد است که محصول مشترک، عملاً چند محصول است.

در این حالت‌ها، تک‌مستأجری با استقرار خودکار و کد مشترک، هم صادقانه‌تر است و هم ارزان‌تر از چندسازمانی‌ای که زیر بار استثناها خم شده است.

سه قاعدهٔ عملی

1. سطح جداسازی را با سختگیرانه‌ترین مشتری بازار هدف انتخاب کنید، نه با اولین مشتری.
2. مرز پیکربندی و انشعاب را روز اول بنویسید و به تیم فروش هم بدهید. این مرز یک تصمیم تجاری است که به‌شکل فنی ظاهر می‌شود.
3. سهمیه و پایش به تفکیک مستأجر را پیش از مشتری دوم بسازید. بعد از مشتری دهم، این کار جراحی است.

چندسازمانی یک انتخاب فنی نیست؛ تعهدی است به اینکه همهٔ مشتریان یک محصول واحد را می‌گیرند. تا وقتی سازمان فروش هم این تعهد را پذیرفته باشد، معماری می‌ایستد. لحظه‌ای که استثنای اول فروخته شد، ساعت شمارش معکوس شروع شده است.