چندمستأجری (Multi-tenancy) در پلتفرمهای سازمانی
اگر نرمافزاری میسازید که قرار است چند سازمان از آن استفاده کنند — یک سکوی فروش، یک سامانهٔ آموزشی، یک پنل مدیریت که به چند شرکت میفروشید — زود یا دیر به این سؤال میرسید:
یک نصب برای همه، یا یک نصب برای هر مشتری؟
جواب این سؤال، معماری، هزینهٔ زیرساخت، سرعت انتشار نسخهٔ جدید و حتی مدل قیمتگذاری شما را تعیین میکند. و برخلاف بیشتر تصمیمهای فنی، عوضکردنش بعد از مشتری دهم عملاً یعنی پروژهٔ مهاجرت داده.
مستأجر یعنی چه
«مستأجر» (tenant) یعنی یک مشتری سازمانی با دادههای خودش: شرکت الف، شرکت ب، مدرسهٔ ج. کاربران داخل هر مستأجر همدیگر را میبینند؛ بین مستأجرها هیچ دادهای مشترک نیست.
توجه کنید که این با «چند کاربر» فرق دارد. هر سامانهای چند کاربر دارد. چندمستأجری یعنی مرزی وجود دارد که عبور داده از آن یک حادثه است، نه یک ویژگی.
سه مدل، و آنچه واقعاً تفاوتشان است
یک: پایگاه دادهٔ مشترک با ستون مستأجر
همهٔ مستأجرها در یک پایگاه داده و یک مجموعه جدولاند و هر ردیف یک ستون
tenant_id دارد.
- ارزانترین. یک نصب، یک پشتیبانگیری، یک بهروزرسانی.
- سادهترین برای انتشار نسخه. یک بار مهاجرت اسکیما و همه بهروزند.
- خطرناکترین. یک کوئری که شرط
tenant_idرا جا بیندازد، دادههای شرکت الف را به شرکت ب نشان میدهد. این باگ در تست معمولاً دیده نمیشود چون در محیط توسعه یک مستأجر بیشتر نیست.
اگر این مدل را انتخاب میکنید — که برای اکثر سکوها انتخاب درستی است — شرط مستأجر نباید در دست برنامهنویس باشد. باید در لایهٔ دسترسی به داده اجباری شود، جوری که کوئری بدون آن اصلاً ساخته نشود.
دو: اسکیمای جدا برای هر مستأجر
یک پایگاه داده، اما هر مستأجر مجموعه جدولهای خودش را دارد.
- مرز روشنتر است و نشت تصادفی خیلی سختتر.
- خروجیگرفتن از دادههای یک مشتری و تحویلش هنگام قطع همکاری، ساده است.
- در عوض هر تغییر اسکیما باید روی همهٔ اسکیماها اجرا شود. با پنجاه مستأجر، مهاجرت به یک عملیات زماندار تبدیل میشود که ممکن است وسطش شکست بخورد و نیمی بهروز باشند و نیمی نه.
سه: نصب کاملاً جدا برای هر مستأجر
هر مشتری نسخهٔ خودش را دارد؛ پایگاه دادهٔ خودش، سرور خودش.
- بالاترین سطح جداسازی. برای مشتریهایی که الزام قانونی دارند یا دادهشان حساس است، گاهی تنها گزینه.
- امکان نسخههای متفاوت برای مشتریان متفاوت — که هم مزیت است و هم دام.
- گرانترین از هر جهت: زیرساخت، استقرار، پشتیبانی، و مهمتر از همه نگهداری بلندمدت.
آن دام را جدی بگیرید. اگر هر مشتری بتواند نسخهٔ خودش را داشته باشد، دو سال بعد هشت نسخهٔ متفاوت دارید و هیچ اصلاحی یک بار انجام نمیشود. این دیگر محصول نیست؛ هشت پروژهٔ سفارشی است که اسم مشترک دارند.
کدام را انتخاب کنیم
معیار ما در پروژهها معمولاً این چند سؤال است:
تعداد مستأجرها چند است؟ ده تای بزرگ با نصب جدا قابل اداره است. هزار تای کوچک، نه — هزینهٔ استقرار و پشتیبانی از درآمد هر مشتری بیشتر میشود.
اندازهشان چقدر تفاوت دارد؟ اگر یک مستأجر نود درصد بار را میسازد، در مدل مشترک بقیه را کند میکند. مدل ترکیبی — بزرگها جدا، بقیه مشترک — پاسخ رایجی است و هیچ ایرادی هم ندارد.
الزام قانونی و قراردادی دارید؟ در حوزهٔ سلامت و مالی، بعضی مشتریان صراحتاً میخواهند داده روی سرور خودشان بماند. این تصمیم را قرارداد میگیرد، نه معماری.
سرعت انتشار چقدر مهم است؟ اگر هفتهای یک بار نسخه میدهید، نصب جدا برای پنجاه مشتری یعنی پنجاه استقرار در هفته.
توصیهٔ پیشفرض ما برای سکوهای جدید: مدل مشترک با ستون مستأجر، بهعلاوهٔ امکان جداکردن یک مستأجر خاص وقتی لازم شد. یعنی از ابتدا فرض نکنید همه همیشه در یک پایگاه داده میمانند، اما برای همه هم از روز اول هزینهٔ جداسازی ندهید.
معماری آرا مارکت دقیقاً روی همین منطق بسته شده — چون در فروش سازمانی، همیشه یک مشتری هست که به دلایل خودش نصب اختصاصی میخواهد و همیشه بیست مشتری هستند که این هزینه را نمیدهند.
چیزهایی که تازهکارها جا میاندازند
دادههای مشترک. فهرست استانها، واحدهای اندازهگیری، نرخ ارز. اینها مال هیچ مستأجری نیستند. اگر برای هر مستأجر کپی شوند، بهروزرسانیشان کابوس است. از ابتدا جدایشان کنید.
سفارشیسازی هر مستأجر. یکی فیلد اضافه میخواهد، دیگری گردش تأیید متفاوت. اگر جواب شما «کد شرطی برای مشتری الف» باشد، سال بعد کدی دارید که هیچکس نمیتواند تغییرش دهد. راه درست، امکان پیکربندی است: فیلدهای قابل تعریف، قواعد قابل تنظیم. گرانتر است و همان چیزی است که تفاوت محصول با پروژه را میسازد.
کش. کلید کش باید شامل شناسهٔ مستأجر باشد، وگرنه شرکت الف نتیجهٔ کششدهٔ شرکت ب را میبیند. این باگ در محیط تست هرگز دیده نمیشود و در تولید فوری دیده میشود. در راهبرد کش بیشتر گفتهایم.
گزارشهای سراسری. شما بهعنوان صاحب سکو، آماری از همهٔ مستأجرها میخواهید. این تنها جایی است که عبور از مرز مجاز است و باید مسیر مشخص و محدودی داشته باشد، نه اینکه از دل همان کوئریهای عادی درآید.
پشتیبانگیری و بازگردانی یک مستأجر. مشتری میگوید «دیروز اشتباهی همهچیز را پاک کردیم». در مدل مشترک، بازگرداندن فقط دادهٔ او از پشتیبان کل، کار سادهای نیست. راهش را قبل از اینکه لازم شود مشخص کنید.
اثر تصمیم روی قیمتگذاری
نکتهای که معمولاً دیر فهمیده میشود: مدل چندمستأجری شما سقف مدل قیمتگذاریتان را تعیین میکند.
اگر هزینهٔ افزودن مستأجر جدید نزدیک صفر باشد، میتوانید نسخهٔ ارزان یا رایگان بدهید و از رشد مشتری درآمد بسازید. اگر هر مستأجر یک استقرار جداگانه لازم داشته باشد، کف قیمت شما همان هزینهٔ زیرساخت بهعلاوهٔ نگهداری است و بازار کوچکتری دارید.
هیچکدام غلط نیست. اما اگر معماریتان مدل سوم باشد و قیمتگذاریتان مدل اول، هر مشتری جدید شما را زیاندهتر میکند.
و یک هشدار
مهاجرت از تکمستأجری به چندمستأجری، تقریباً همیشه از آنچه برآورد میشود بزرگتر است، چون فقط افزودن یک ستون نیست: هر کوئری، هر کش، هر فایل آپلودشده، هر گزارش و هر کار پسزمینه باید مستأجر را بشناسد.
اگر احتمال میدهید محصولتان روزی چند مشتری داشته باشد، شناسهٔ مستأجر را از روز اول در مدل بگذارید — حتی اگر امروز مقدارش برای همه یکی باشد. هزینهاش امروز تقریباً هیچ است و فردا یک پروژه.