Ko’p tenant yadro

Ko’p tenant yadro - bu platforma/mahsulotning asosiy qatlami bo’lib, u kafolatlangan izolyatsiya, boshqariladigan limitlar va xavfsiz kastomizatsiya sharoitida umumiy resurslarda ko’plab mustaqil mijozlarga (tenantlarga) xizmat ko’rsatadi. Yaxshi loyihalashtirilgan yadro TCOni kamaytiradi, onbordingni tezlashtiradi, relizlarni soddalashtiradi va har bir ijarachi uchun bashorat qilinadigan sifatni taʼminlaydi.

1) Ijarachining modeli va izolyatsiya chegarasi

Aniqliklar

Tenant (Tenant/Org/Account): mantiqiy tashkilot o’z foydalanuvchilari, ma’lumotlari, siyosati va limitlari bilan.
Izolyatsiya: bir ijarachining ikkinchisining ma’lumotlariga, unumdorligi va xavfsizligiga ta’sirini oldini olish qobiliyati.

Izolyatsiya darajalari

1. Ma’lumotlar: alohida DB/sxemalar/jadvallar, «ijarachi kaliti» bilan shifrlash,’tenant _ id’filtrlari.
2. Hisoblab chiqishlar: CPU/RAM/IO kvotalari, tenant uchun vorkerlar puli yoki «tortilgan» navbatlar.
3. Tarmoq: segmentatsiya, xususiy endpoints/VPN, ijarachilar uchun ruxsatnomalar ro’yxati.
4. Operatsiyalar: migratsiyalar, bekaplar, DR va «bir ijarachiga» ta’sir chegaralari bilan bog’liq hodisalar.

Multitenantlik patternlari

Silo (qattiq izolyatsiya): tenantga alohida klasterlar/BD. Maksimal xavfsizlik, yuqori narx.
Pool (umumiy resurslar): mantiqiy izolyatsiyali umumiy infratuzilma; yaxshiroq samaradorlik, «noisy neighbor» xavfi yuqori.
Bridge/Hybrid: gibrid - boshqaruvning umumiy tekisligi + VIP/tartibga solinadigan mijozlar uchun tanlab «silo».

2) Ijarachi so’rovlarini identifikatsiyalash va yo’naltirish

Ijarachining ruxsatnomasi (Tenant Resolution)

’https : //{ tenant} .example. com`

’/t/{ tenant }/... ’

Sarlavha bo’yicha: ’X-Tenant-Id’,’X-Org’(imzoni tekshirish)

Token boʻyicha: ’tenant _ id’,’org _ id’,’plan’,’scopes’tamgʻalari

Marshrut

L7-shlyuz (API-shlyuz/Ingress)’tenant _ id’ni chiqaradi, kontekstni boyitadi (’plan’, limitlar, mintaqa), treys/loglarga yozadi.
Funksional servislar «faqat o’qish uchun» kontekstini qabul qiladi; yo’nalish va limitlar bo’yicha qarorlar geytvey/polis-dvigatel qabul qiladi.

3) Ma’lumotlar va sxemalar: strategiyalar

Saqlash variantlari

Shared-schema, row-level: bitta jadval to’plami,’tenant _ id’maydoni, qat’iy RLS (Row-Level Security).
Shared-DB, per-schema: bitta DBMS, tenantga alohida sxema; boshqarish va izolyatsiya o’rtasidagi balans.
Per-DB/cluster: tenantga alohida DB/klaster; suveren talablar uchun ancha qimmat, oson.

Asosiy amaliyotlar

Hamma joyda’tenant _ id’ni aniq uzatish va uni tarkibiy kalitlarga/indekslarga kiritish.
RLS/DBMS darajasidagi kirish siyosati + «ikki qulfli» servis validatsiyasi.
Shifrlash: kalitlar ierarxiyasi (root KMS → key-envelope/tenant → DEK/obyekt).
Arxiv/retenshn va «unutish huquqi» ijarachi darajasidagi siyosatchilar tomonidan boshqariladi.

4) Sozlamalar, chichlar va versiyalar

Tenant moslamalari

Jadval/ombor’tenant _ config’(reja, kvotalar, ficha-bayroqlar, mahalliylashtirish, SLA).
Konfiguratsiya ustuvorliklari: defolt → reja → tenant → muhit → foydalanuvchi.
Qisqa TTL va hodisa bo’yicha nogironligi bo’lgan konfiguratsiyalarni keshlash.

Ficha-bayroqlar va muvofiqlik

Nuqta (per-tenant/per-cohort) funksiyalarini yoqish.
API versiyalash: barqaror kontrakt + chegaradagi adapterlar (back/forward-compatible formatlar).

5) Limitlar, kvotalar va billing

Iste’mol siyosati

Rate limiting:’requests/sec’per tenant/route, reja ustuvorliklari bilan «token-baket».
Quotas: saqlash hajmi, obʼektlar soni, xabarlar/min, jobs/soat.
Fairness: navbatlarning «muvozanatli jadvali» + VIP uchun vorkerlarni izolyatsiya qilish.

Billing

Hisoblagichlar’tenant _ id’(usage-metriklar) → agregatorlar → invoys.
Chegaradagi snapshotlar usage (idempotentlik va hodisalarni yo’qotishdan himoya qilish).
Modellar: qat’iy reja + qayta konsumption, post-pay/pre-pay, chegirmalar «tiered».

6) Xavfsizlik va foydalanish

Autentifikatsiya/avtorizatsiya

OIDC/SAML’tenant _ id’,’roles’,’scopes’tamgʻalari bilan.
RBAC/ABAC: ijarachi darajasidagi rollar (Owner/Admin/Reader), loyiha/bo’lim atributlari.
mTLS va cheklangan tokenlar bilan ruxsat etilgan (service-to-service).

Ishonch chegaralari

Soʻrovni qabul qilish siyosati: sarlavha imzosini tekshirish, nonce/timestamp, manbaga bogʻlash.
Sirlar va kalitlar: per-tenant rotatsiyasi, alohida KMS kontekstlari, asosiy operatsiyalar auditi.
Multi-region & data residency: pinning tenanta mintaqaga, nazorat qilinadigan kross-mintaqaviy oqimlar.

7) «Ijarachilar bo’yicha» kuzatish

Trastirovka va metrika

Majburiy teglar:’tenant _ id’,’plan’,’region’,’endpoint’,’status’.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Segmentlar bo’yicha dashbordlar va alertlar (VIP/tartibga solinadigan/yangi).

Logi i audit

Ijaraga oluvchining siyosati bo’yicha o’zgarmas omborga va retenshnga ega bo’lgan harakatlar daftarlari (kim/nima/qachon/qaerda).
Arzon saqlash uchun voqealarni oldindan yig’ish, «bosish orqali» tafsilotlarni tiklash.

8) Unumdorlik va «noisy neighbor»

Shovqinga qarshi choralar

Navbatlar/vorkyerlar darajasiga limitlar, CPU-shares va IO-proporsiyalar per tenant.
Keshni ajratish:’tenant: {id}:’, reja boʻyicha TTL, «cache stampede» dan himoya qilish.
’tenant _ id’ bo’yicha selektivlikni hisobga olgan holda indekslar va so’rovlar rejalari.

Sovuq startlar va «issiq» pullar

VIP/pik oynalar uchun oldindan isitish.
Metrik signallar bo’yicha elastik vorker pullari (backpressure/avtoskeyling).

9) Yangilanishlar va to’xtovsiz migratsiya

Strategiya

Backward mos keladigan migratsiyalar (expand → migrate → contract).
Migratsiya «ijarachilar bo’yicha»: taraqqiyot nazorati bilan batchi, aniq’tenant _ id’uchun «pauza/orqaga qaytish».
Ijarachilar turkumida semplash va «kanareya» migratsiyasi.

DR va hodisalar

RTO/RPO per tenant bilan DR-reja; global tushishsiz qisman «read-only rejim».
Hodisani izolyatsiya qilish: fyuzing bo’yicha’tenant _ id’, «issiq» ijarachini o’chirish boshqalarga ta’sir qilmaydi.

10) API va protokollar

REST/gRPC majburiy ijara kontekstida (tamg’alar/sarlavhalarda).
Hodisalar (event-driven):’tenant. {id} .event’nomli topiklar, filtrlar va obuna uchun ACL.
Global kirish nuqtalari: L7-shlyuz kontekstni tasdiqlaydi, limitlarni qo’llaydi, tenant siyosati bo’yicha PIIni shifrlaydi.

11) Ijarachining hayot sikli

1. Provijining: ijarachining yozuvini yaratish, kalitlarni/konfiguratsiyalarni yaratish, mintaqani bog’lash.
2. Faollashtirish: OIDC/SAML mijozini chiqarish, rol/siyosat yaratish, birlamchi kvotalar.
3. Ekspluatatsiya: monitoring, billing, bayroq/rejalarni yangilash.
4. Suspend/trottling: ma’lumotlarni/eksportni saqlash bilan muzlatish.
5. Olib tashlash/eksport qilish: retenshn, konservatsiya qilingan bekaplar, kalitlarni kripto-o’chirish (crypto-shredding).

12) Arxitekturaning mini-etaloni (so’z sxemasi)

Edge (API-shlyuz): TLS/mTLS,’tenant _ id’, limitlar, audit.
Control Plane: ijarachilar katalogi, konfiga, ficha bayroqlari, billing, siyosat.
Data Plane (servislar): stateless-servislar, navbatlar, kvotali vorkerlar; Tenant bo’yicha prekfikli Redis/kv.
Storage: RLS-DB/alohida sxemalar/DB; ijarachiga kalitli KMS; envelope-shifrlangan obyekt ombori.
Observability: treysing/metrika/logi bilan’tenant _ id’, alertlar per plan.
Admin: ijarachilar turkumida izolyatsiya qilingan operatsiyalar (migratsiyalar/bekaplar).

13) Sotishdan oldingi nazorat ro’yxati

• Chegara va xizmatlarda’tenant _ id’ni aniqlashning yagona usuli.
• RLS/ACL siyosati testlar va «salbiy stsenariylar» tomonidan tekshirilgan.
• Kvotalar/limitlar/billing real yuklamalarda validatsiya qilinadi; «billing-droplardan» himoya qilish mavjud.
• Kuzatish va SLO per tenant; VIP/tartibga solinadigan alertlar.
• Migratsiyalar mos keladi, qisman qaytarish va ijarachi batchlar mavjud.
• RTO/RPO per tenant bilan DR-stsenariylari va muntazam mashqlar.
• «Ijarachi kaliti» bilan shifrlash, rotatsiya va kalitlarni tekshirish.
• API shartnomalari/voqealar va versiyalash siyosati hujjatlari.

14) Tipik xatolar

Muammoli ijarachida global migratsiyani to’xtatish imkoniyati yo’q.
Kesh/navbatlardagi’tenant _ id’ga yashirin bog’liqlik → ma’lumotlarning chiqib ketishi/navbatlarning kesishishi.
Kontekstlarni aralashtirish (admin-operatsiya tasodifan’tenant _ id’emas).
«Ikki qulf» yo’qligi: faqat DBda RLSsiz servis tekshiruvi.
Butun klaster uchun yagona limiter → «noisy neighbor» va SLO buzilishi.
Idempotentlik va audit-trailsiz noaniq billing.

15) Strategiyani tez tanlash

Qattiq izolyatsiya/tartibga solish: Silo (alohida DB/klaster), mintaqa-lok.
Muvozanatli samaradorlik: Shared-DB per schema + RLS, per tenant kalitlari.
Yuqori real-time trafigi: VIP uchun «muvozanatli» kvotalar va ajratilgan vorkerlar bilan umumiy navbatlar.
Ko’plab kastomizatsiyalar: fich-bayroqlar + API adapterlari, ustuvorlik bo’yicha konfiguratsiyalarni saqlash.

Xulosa

Ko’p tenant yadro - muhandislik chegaralari intizomi: «tenant _ id» aniq ta’rifi, barcha qatlamlarda qat’iy izolyatsiya, boshqariladigan kvotalar va shaffof billing, shuningdek, relizlarning kuzatilishi va mosligi. Tavsiflangan patternlarga amal qilish har bir ijarachi uchun o’zgarishlar xavfsizligi, sifati va tezligini qurbon qilmasdan mahsulotni ko’paytirish imkonini beradi.