Multi-tenant SaaS arxitekturasi: har bir mijoz ma’lumotlarini qanday ajratish kerak

SaaS mahsuloti bitta tizimdan ko‘plab mijozlarga xizmat qiladi. Har bir mijoz, ya’ni ijarachi (tenant), faqat o‘z ma’lumotlarini ko‘rishni, boshqalar nima qilayotganidan qat’i nazar barqaror ishlashni va o‘z ma’lumotlari boshqalarga ta’sir qilmasdan tiklanishi yoki o‘chirilishini kutadi. Multi-tenant arxitektura shu va’dalarni haqiqatga aylantiradigan qarorlar majmui.

Bu qarorlarning aksariyati boshida arzon, keyinroq qimmat. Ushbu maqolada asosiy izolyatsiya modellari, ularni mustahkamlaydigan ma’lumotlar bazasi imkoniyatlari, shovqinli qo‘shnilar muammosi, tizimning ko‘pincha unutiladigan qismlari va mahsulot ishga tushgandan keyin yo‘nalishni qanday o‘zgartirish ko‘rib chiqiladi.

Multi-tenancy amalda nimani anglatadi

Ijarachi ma’lumotlarga egalik qiladigan va pul to‘laydigan birlik: odatda kompaniya, ba’zan jamoa yoki ish maydoni (workspace). Bitta ijarachida ko‘plab foydalanuvchilar bo‘ladi, bitta foydalanuvchi esa bir nechta ijarachiga tegishli bo‘lishi mumkin, masalan, bir necha mijozning ish maydonlarida ishlaydigan konsultant.

Izolyatsiyaning uch tomoni bor:

• Ma’lumotlar izolyatsiyasi. Hech bir so‘rov, hisobot, eksport yoki qidiruv boshqa ijarachining yozuvlarini qaytarmaydi.
• Unumdorlik izolyatsiyasi. Bir ijarachining og‘ir yuklamasi boshqalarni sekinlashtirmaydi.
• Operatsion izolyatsiya. Bitta ijarachini alohida zaxiralash, tiklash, migratsiya qilish, ko‘chirish yoki o‘chirish mumkin.

Quyidagi izolyatsiya modellari shu uchtasini xarajat va ekspluatatsiya mehnati bilan muvozanatlaydi.

Ijarachilar ma’lumotlarini ajratishning uch usuli

Ijarachi identifikatoriga ega umumiy sxema

Barcha ijarachilarning qatorlari bir xil jadvallarda saqlanadi va har bir qatorda tenant_id ustuni bo‘ladi. Har bir so‘rov shu ustun bo‘yicha filtrlanadi.

Bu yuritish eng arzon va ko‘plab kichik ijarachilarga masshtablash eng oson model. Bitta migratsiya hammani yangilaydi, barcha ijarachilar bo‘yicha umumiy hisobot tuzish oson. Xavf ham oddiy: bitta unutilgan filtr ma’lumotlarni sizdiradi. Izolyatsiya kod bazasidagi har bir so‘rov to‘g‘ri bo‘lishiga bog‘liq, shuning uchun u ehtiyotkorlik bilan emas, tuzilma bilan ta’minlanishi kerak.

Har bir ijarachi uchun alohida sxema

Har bir ijarachi bitta ma’lumotlar bazasi ichida o‘z sxemasini (jadvallar nomlar fazosini) oladi. So‘rovlar ijarachining sxemasida bajariladi, shuning uchun unutilgan filtr boshqa ijarachining jadvallariga yeta olmaydi.

Izolyatsiya kuchliroq, bitta ijarachini tiklash yoki eksport qilish osonroq. Xarajatlar ijarachilar soni bilan keladi. Migratsiyalar har bir sxema uchun alohida bajarilishi kerak va yarmida to‘xtab qolgan migratsiya ijarachilarni turli versiyalarda qoldiradi. Minglab sxemalar connection pool va ma’lumotlar bazasi katalogiga og‘ir yuk bo‘ladi. Bu model minglab kichik ijarachilarga emas, o‘nlab yoki yuzlab yirik ijarachilarga ega mahsulotlarga ko‘proq mos keladi.

Har bir ijarachi uchun alohida ma’lumotlar bazasi

Har bir ijarachi o‘z ma’lumotlar bazasini, ba’zan o‘z serverini oladi. Bu uchala tomonda eng kuchli izolyatsiyani beradi: alohida unumdorlik, alohida zaxira nusxalar, ijarachi ma’lumotlarini muayyan mintaqada joylashtirish imkoni va mijozning xavfsizlik tekshiruviga aniq javob.

Shu bilan birga, uni yuritish eng qimmat. Har bir bazani yaratish, kuzatish, zaxiralash va migratsiya qilish kerak, shuning uchun bu model faqat puxta avtomatlashtirish bilan ishlaydi. U kam sonli yirik yoki tartibga solinadigan mijozlarga mos keladi va ko‘p mahsulotlar uni umumiy infratuzilma ustidan premium tarif sifatida taklif qiladi.

Xavfsizlik to‘ri sifatida qator darajasidagi xavfsizlik

Umumiy sxema modelida ijarachi filtrini ma’lumotlar bazasining o‘zi majburiy qilishi mumkin. PostgreSQLdagi qator darajasidagi xavfsizlik (row-level security) jadvalga siyosat biriktirish imkonini beradi, shunda sessiya faqat joriy ijarachisiga mos qatorlarni ko‘radi. Joriy ijarachi odatda ilova har bir so‘rov boshida o‘rnatadigan sessiya sozlamasidan o‘qiladi.

Bu unutilgan WHERE shartini ma’lumotlar sizib chiqishidan bo‘sh natijaga aylantiradi. Himoya ishlashi uchun bir necha qoida bor:

• Ilova siyosatlarni chetlab o‘ta olmaydigan rol bilan ulanadi. Jadval egalari va superfoydalanuvchilar sukut bo‘yicha ularni chetlab o‘tadi.
• Ijarachi sozlamasi har bir tranzaksiya uchun o‘rnatiladi va keyin tozalanadi, shunda pooldan olingan ulanish bir ijarachi kontekstini keyingi so‘rovga olib o‘tmaydi.
• Siyosatlar ijarachiga tegishli har bir jadvalni qamraydi va sinov bunday jadvallarning birortasi siyosatsiz qolmaganini tekshiradi.

Qator darajasidagi xavfsizlik yagona emas, ikkinchi himoya chizig‘i. Ma’lumotlarga kirish qatlami baribir har bir so‘rovni ijarachi bo‘yicha cheklashi kerak, shunda biror narsa sizib chiqishi uchun ikkalasi ham ishdan chiqishi kerak bo‘ladi.

Shovqinli qo‘shnilar

Har qanday umumiy modelda ijarachilar bir xil protsessor, xotira, ulanishlar va disk uchun raqobatlashadi. Katta import yoki qimmat hisobotni ishga tushirgan bitta ijarachi mahsulotni hamma uchun sekinlashtirishi mumkin.

Himoya bir necha qatlamdan iborat:

• Har bir ijarachi uchun so‘rovlar chegarasi va kvotalar API chaqiruvlari, fon vazifalari va saqlash hajmi uchun, uning tarifiga bog‘langan holda.
• Adolatli navbatlar fon ishlari uchun, shunda bir ijarachining to‘planib qolgan vazifalari qolganlarni navbatda kutib qoldirmaydi.
• So‘rovlar byudjeti: taymautlar, sahifalash chegaralari va ijarachi identifikatoridan boshlanadigan indekslar.
• Har bir ijarachi bo‘yicha metrikalar, shunda faqat tizim sekinlashganini emas, kim nimadan foydalanayotganini ko‘rasiz.
• Chiqish yo‘li: og‘ir ijarachini kodni o‘zgartirmasdan alohida bazaga yoki alohida resurslar guruhiga ko‘chirish imkoni.

Ma’lumotlar bazasidan tashqarida ajratish

Izolyatsiya ko‘pincha ma’lumotlar bazasi uchun loyihalanadi va boshqa hamma joyda unutiladi. Quyidagilarning har birida ijarachi hisobga olinishi kerak:

• Autentifikatsiya va avtorizatsiya. Ijarachi mijoz o‘zgartira oladigan so‘rov parametridan emas, tasdiqlangan sessiya yoki tokendan olinishi kerak. Rollar har bir ijarachi uchun alohida saqlanadi, chunki bir odam bir ish maydonida administrator, boshqasida esa faqat ko‘ruvchi bo‘lishi mumkin.
• Keshlash. Har bir kesh kaliti ijarachi identifikatorini o‘z ichiga oladi. Ijarachilar o‘rtasida umumiy bo‘lib qolgan keshlangan sahifa yoki so‘rov natijasi amaliyotda eng ko‘p uchraydigan sizib chiqishlardan biri.
• Fon vazifalari. Har bir vazifa o‘z ijarachisini olib yuradi va ma’lumotlarga tegishdan oldin, xuddi veb-so‘rov kabi, ijarachi kontekstini o‘rnatadi.
• Fayllar va qidiruv. Obyekt xotirasidagi yo‘llar va qidiruv indekslari ijarachilar bo‘yicha bo‘linadi, imzolangan yuklab olish havolalari esa so‘rov yuborgan ijarachiga nisbatan tekshiriladi.
• Loglar va analitika. Loglardagi ijarachi identifikatorlari qo‘llab-quvvatlash va nosozliklar bilan ishlashni mumkin qiladi; loglardagi shaxsiy ma’lumotlar bazadagi kabi ehtiyotkorlikni talab qiladi.
• Zaxira nusxalar va o‘chirish. Bitta ijarachini ma’lum vaqt nuqtasiga tiklash va shartnomasi tugaganda uni to‘liq o‘chirish imkoniyati bo‘lishi kerak. Umumiy sxemada buning uchun maxsus vositalar kerak va ularni birinchi mijoz so‘rashidan oldin yaratish o‘zini oqlaydi.

Modelni tanlash va keyinroq o‘tish

Yangi B2B SaaS mahsuloti uchun oqilona standart tanlov: har bir jadvalda ijarachi identifikatori bo‘lgan umumiy sxema, uni ma’lumotlarga kirish qatlami va qator darajasidagi xavfsizlik ta’minlaydi, birinchi kundan ijarachini hisobga oladigan keshlash va fon vazifalari bilan. Bu arzon, ko‘plab ijarachilarga masshtablanadi va boshqa yo‘llarni yopib qo‘ymaydi.

Bu yo‘llarni ataylab ochiq qoldiring:

• Hamma ijarachilar hali bir joyga ishora qilayotgan bo‘lsa ham, har bir ijarachining bazaga ulanishini ijarachilar reyestri orqali aniqlang.
• Barcha ijarachilar bo‘yicha noyob identifikatorlardan foydalaning, shunda ijarachining qatorlarini to‘qnashuvlarsiz boshqa joyga ko‘chirish mumkin bo‘ladi.
• Ijarachilarga tegishli ma’lumotlarni tariflar va ma’lumotnoma jadvallari kabi global ma’lumotlardan aniq ajratib saqlang.

Bular joyida bo‘lsa, yirik yoki tartibga solinadigan mijozni alohida bazaga ko‘chirish qayta yozish emas, ma’lumotlar migratsiyasi va reyestrdagi o‘zgarishga aylanadi. Teskari yo‘nalishda, ko‘p bazadan bittasiga o‘tish ancha qiyin va bu umumiy modeldan boshlash uchun yana bir sabab.

Har bir ijarachi uchun alohida bazani boshidanoq faqat bozor buni talab qilganda tanlang: jismoniy ajratishni talab qiladigan shartnomalar, har bir mijoz ma’lumotlarini muayyan mamlakatda saqlash talabi yoki yuklamasi umumiy infratuzilmada ustunlik qiladigan bir nechta juda yirik mijozlar.

Qisqacha

• Ijarachilarni ajratish birinchi jadvaldan oldin hal qilinadi va har bir qatlamga yetadi: autentifikatsiya, kesh, fon vazifalari, fayllar, loglar va zaxira nusxalar.
• Odatiy standart tanlov umumiy sxema; ijarachi uchun alohida sxema va alohida baza kuchliroq izolyatsiyani yuqoriroq ekspluatatsiya xarajati evaziga beradi.
• Izolyatsiyani ikki marta, kodda va bazada ta’minlang va u ishlashini sinab ko‘ring.
• Shovqinli qo‘shnilarga kvotalar, adolatli navbatlar va har bir ijarachi bo‘yicha metrikalar bilan tayyorlaning.
• Ulanishlarni ijarachilar reyestri orqali yo‘naltiring, shunda istalgan ijarachini keyinchalik qayta yozishsiz ko‘chirish mumkin bo‘ladi.