Multi-tenant nüvə

Multi-tenant nüvə zəmanətli izolyasiya, idarə olunan limitlər və təhlükəsiz özelləşdirmə ilə ümumi resurslarda bir çox müstəqil müştərilərə (tenantlara) xidmət edən platformanın/məhsulun əsas qatıdır. Yaxşı dizayn edilmiş nüvə TCO-nu azaldır, bağlanmasını sürətləndirir, buraxılışları asanlaşdırır və hər bir kirayəçi üçün proqnozlaşdırıla bilən keyfiyyət təmin edir.

1) Kirayəçi modeli və izolyasiya sərhədləri

Təriflər

Tenant (Tenant/Org/Account): Öz istifadəçiləri, məlumatları, siyasətləri və limitləri olan məntiqi təşkilat.
İzolyasiya: bir icarədarın digərinin məlumatlarına, performansına və təhlükəsizliyinə təsirinin qarşısını almaq bacarığı.

İzolyasiya səviyyələri

1. Verilənlər: ayrı-ayrı DB/sxemlər/cədvəllər, «kirayəçi açarı» ilə şifrləmə, 'tenant _ id' filtrləri.
2. Hesablamalar: CPU/RAM/IO kvotaları, tenant üçün worker hovuzu və ya «balanslı» növbələr.
3. Şəbəkə: seqmentasiya, xüsusi endpoints/VPN, kirayəçilər üçün icazə siyahıları.
4. Əməliyyatlar: miqrasiya, backup, DR və «bir kirayəçi» təsir sərhədləri ilə insidentlər.

Multitenantlıq nümunələri

Silo (sərt izolyasiya): tenant üçün ayrı-ayrı klasterlər/BD. Maksimum təhlükəsizlik, yüksək qiymət.
Pool (ümumi resurslar): məntiqi izolyasiya ilə ümumi infrastruktur; daha yaxşı effektivlik, daha yüksək risk «noisy neighbor».
Bridge/Hybrid: hibrid - VIP/tənzimlənən müştərilər üçün ümumi idarəetmə müstəvisi + seçici «silo».

2) Kirayə sorğularının identifikasiyası və marşrutlaşdırılması

Kirayəçi icazəsi (Tenant Resolution)

Domen adı: 'https ://{ tenant} .example. com`

Yol boyu: '/t/{ tenant }/... '

Başlıq üzrə: 'X-Tenant-Id', 'X-Org' (imza yoxlaması)

Tokenlə: 'tenant _ id', 'org _ id', 'plan', 'scopes' damğaları

Marşrutlaşdırma

L7-şlyuz (API-şlyuz/Ingress) 'tenant _ id' çıxarır, konteksti zənginləşdirir ('plan', limitlər, region), treys/log qeydləri.
Funksional xidmətlər «yalnız oxumaq üçün» kontekstini qəbul edir; marşrut və limitlər üzrə qərarlar geytway/polis mühərriki tərəfindən qəbul edilir.

3) Məlumatlar və sxemlər: strategiyalar

Saxlama variantları

Şəred-sxema, row-level: bir sıra cədvəllər, 'tenant _ id' sahəsi, ciddi RLS (Row-Level Security).
Shared-DB, per-schema: bir DBB, tenant üçün ayrıca sxem; idarə və izolyasiya arasında balans.
Per-DB/cluster: tenant üçün ayrı DB/klaster; daha bahalı, suveren tələblər üçün daha asan.

Əsas təcrübələr

Hər yerdə açıq şəkildə 'tenant _ id' ötürmək və kompozit açarlar/indekslər daxil etmək.
RLS/DBMS səviyyəsində giriş siyasəti + «ikiqat kilidlə» xidmət təsdiqi.
Şifrələmə: açar iyerarxiyası (root KMS → tenant üçün key-envelope → obyekt üçün DEK).
Arxiv/retenshn və «unudulmaq hüququ» kirayəçi səviyyəsində siyasətçilər tərəfindən idarə olunur.

4) Parametrlər, cizgilər və versiyalar

Tenant konfiqurasiyaları

Cədvəl/saxlama 'tenant _ config' (plan, kvotalar, fiqa bayraqları, lokalizasiya, SLA).
Konfiqurasiya prioritetləri: defolt → plan → tenant → mühit → istifadəçi.
Qısa TTL və hadisə əlilliyi ilə konfiqurasiyaların önbelləklənməsi.

Ficha bayraqları və uyğunluq

Spot funksiyaların daxil edilməsi (per-tenant/per-cohort), kanarya yuvarlanması.
API versiyası: sabit müqavilə + sərhəddə adapterlər (back/forward-compatible formatları).

5) Limitlər, kvotalar və billinq

İstehlak siyasəti

Rate limiting: 'requests/sec' per tenant/route, planların prioritetləri ilə «token-baket».
Quotas: saxlama həcmi, obyektlərin sayı, mesajlar/dəq, jobs/saat.
Fairness: növbələrin «balanslı cədvəli» + VIP üçün oxucu izolyasiyası.

Billing

Sayğaclar 'tenant _ id' (usage-metriklər) → aqreqatorlar → invoys.
Sərhəddə snapshots usage (idempotentlik və hadisələrin itkisinə qarşı qorunma).
Modellər: sabit plan + keçid consumption, post-pay/pre-pay, endirimlər «tiered».

6) Təhlükəsizlik və giriş

Autentifikasiya/avtorizasiya

'tenant _ id', 'roles', 'scopes' damğaları ilə OIDC/SAML.
RBAC/ABAC: icarəçi səviyyəsində rollar (Owner/Admin/Reader), layihə/şöbənin atributları.
mTLS və məhdud tokenlərlə səlahiyyətli giriş (service-to-service).

Etimad sərhədləri

Sorğuların qəbulu siyasəti: başlıqların imzasının yoxlanılması, nonce/timestamp, mənbəyə bağlanması.
Sirləri və açarları: per-tenant rotasiyası, fərdi KMS kontekstləri, əsas əməliyyatların auditi.
Multi-region & data residency: bölgəyə tenanta pinning, nəzarət kros-regional axınlar.

7) «Kirayəçilər üzrə» müşahidə

İzləmə və metrika

Məcburi etiketlər: 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Daşbordlar və alertlər seqmentlər üzrə (VIP/tənzimlənən/yeni).

Qeydlər və audit

Dəyişməz saxlama və kirayəçi siyasəti ilə fəaliyyət jurnalları (kim/nə/nə/harada).
Ucuz saxlama üçün hadisələrin əvvəlcədən yığılması, «klik» detallarının bərpası.

8) Performans və «noisy neighbor»

Anti-səs tədbirləri

Növbə/worker səviyyəsi, CPU-shares və IO nisbətləri per tenant.
Cache ayrılması: 'tenant: {id}:...', TTL açar prefiksləri, «cache stampede» qorunması.
'tenant _ id' üzrə selektivlik nəzərə alınmaqla indekslər və sorğu planları.

Soyuq başlanğıc və «isti» hovuzlar

VIP/pik pəncərələr üçün ön-qızdırma.
Metrik siqnallar üzrə elastik hovuzlar (backpressure/avtoskeylinq).

9) Yeniləmələr və fasiləsiz miqrasiya

Strategiya

Backward uyğun miqrasiya (expand → migrate → contract).
«Kirayəçilər üçün» miqrasiya: tərəqqi nəzarəti ilə batches, konkret 'tenant _ id' üçün «pauza/geri dönüş».
Kirayəçilər toplusunda sempleme və «kanareya» miqrasiyası.

DR və hadisələr

RTO/RPO per tenant ilə DR planı; qlobal downtime olmadan qismən «read-only rejimi».
Hadisənin təcrid olunması: 'tenant _ id' tərəfindən fusinq, «isti» kirayəçinin söndürülməsi digərlərinə təsir etmir.

10) API və protokollar

REST/gRPC məcburi icarəçi kontekstində (damğalarda/başlıqlarda).
Hadisələr (event-driven): 'tenant. {id} .event' etiketli topiklər, filtrlər və abunə üçün ACL.
Qlobal giriş nöqtələri: L7-şluz konteksti təsdiqləyir, limitləri tətbiq edir, tenant siyasəti üzrə PII şifrələyir.

11) Kirayəçinin həyat dövrü

1. Provijininq: kirayəçi qeydinin yaradılması, açarların/konfiqurasiyaların yaradılması, bölgənin bağlanması.
2. Aktivləşdirmə: OIDC/SAML müştərisinin sərbəst buraxılması, rolların/siyasətlərin yaradılması, ilkin kvotalar.
3. Əməliyyat: monitorinq, billing, bayraq/planların yenilənməsi.
4. Suspend/Trottling: məlumat/ixrac saxlama ilə dondurma.
5. Çıxarılması/ixrac: retenshn, konservləşdirilmiş backup, kriptovalyutası (crypto-shredding).

12) Arxitekturanın mini-etalonu (şifahi sxem)

Edge (API-şlyuz): TLS/mTLS, çıxarış 'tenant _ id', limitlər, audit.
Control Plane: kirayəçilər kataloqu, konfiqlər, fiqa bayraqları, billing, siyasət.
Data Plane (xidmətlər): stateless-xidmətlər, növbələr, kvotalı olan vorkerlər; Tenant prefiksləri ilə Redis/kv.
Saxlama: RLS-DB/ayrı-ayrı sxemlər/DB; kirayəçi açarları ilə KMS; envelope-şifrələmə ilə obyekt saxlama.
Observability: treysinq/metrika/loqi ilə 'tenant _ id', alertlər per plan.
Admin: icarəçilər toplusunda təcrid olunmuş əməliyyatlar (miqrasiya/backaps).

13) Satış öncəsi nəzarət siyahısı

Sərhəddə və xidmətlərdə 'tenant _ id' -ni müəyyən etməyin vahid yolu.
RLS/ACL siyasətləri testlər və «mənfi ssenarilər» ilə yoxlanılır.
Kvotalar/limitlər/billing real yüklərdə təsdiqlənir; «billing drops» qorunması var.
Müşahidə və SLO per tenant; VIP/tənzimlənən üçün alert.
Miqrasiya uyğun, qismən geri və kirayə batches var.
RTO/RPO per tenant ilə DR ssenariləri və müntəzəm təlimlər.
Şifrələmə «kirayəçi açarı», rotasiya və açar auditi.
API müqavilələrinin/hadisələrin və versiyalaşdırma siyasətinin sənədləşdirilməsi.

14) Tipik səhvlər

Problemli bir icarədarda dayandırmaq imkanı olmadan qlobal miqrasiyalar.
Gizli asılılıq 'tenant _ id' cache/növbələrdə → məlumat sızması/növbələrin kəsişməsi.
Kontekstlərin qarışması (admin-əməliyyat təsadüfən 'tenant _ id' olmadan).
«Qoşa kilid» yoxdur: yalnız DB-də RLS olmadan xidmət yoxlaması.
Bütün klaster üçün vahid limiter → «noisy neighbor» və SLO pozulması.
İdempotentlik və audit-trail olmadan qeyri-şəffaf billing.

15) Sürətli strategiya seçimi

Ciddi izolyasiya/tənzimləmə: Silo (ayrı-ayrı DD/klaster), region-lok.
Balanslaşdırılmış effektivlik: Şəred-DB per schema + RLS, per tenant açarları.
Yüksək real-time trafik: VIP üçün «balanslı» kvotalar və xüsusi işçilər ilə ümumi növbələr.
Bir çox konfiqurasiya: Fich bayraqları + API adapterləri, prioritet konfiqurasiyaların saxlanması.

Nəticə

Çox tenant nüvəsi mühəndislik sərhədlərinin intizamıdır: 'tenant _ id' aydın tərifi, bütün təbəqələrdə ciddi izolyasiya, idarə olunan kvotalar və şəffaf billing, əlavə olaraq izlənmə və buraxılış uyğunluğu. Təsvir edilmiş nümunələri izləmək hər bir kirayəçi üçün təhlükəsizliyi, keyfiyyəti və dəyişmə sürətini qurban vermədən məhsulu genişləndirməyə imkan verir.