Izolarea și limitele chiriașilor

Izolarea chiriașilor și limitele sunt fundamentul arhitecturii multi-chiriași. Scop: Astfel încât acțiunile unui chiriaș să nu afecteze niciodată datele, securitatea și SLO ale altuia, iar resursele să fie distribuite în mod echitabil și previzibil. Mai jos este o hartă practică a soluțiilor de la nivelul datelor la planificarea computerizată și gestionarea incidentelor.

1) Modelul de amenințare și țintele

Amenințări

Scurgeri de date între chiriași (logic/prin cache/prin jurnale).
„Vecinul zgomotos”: degradarea performanței din cauza piroanelor într-un singur client.
Escaladarea privilegiilor (eroarea politicii de acces).
Derivă de facturare (neconcordanță de utilizare și taxe).
Scenarii Cascade fail-safe (incident de unul duce la downtime de mai multe).

Obiective

Izolarea strictă a datelor și secretelor.
Limite/cote marginale și planificare echitabilă.
Audit transparent, observabilitate și facturare.
Localizarea incidentelor și recuperarea rapidă pe chiriaș.

2) Niveluri de izolare (model end-to-end)

1. Date

'tenant _ id' in keys and indexes, Row-Level Security (RLS).
Criptare: KMS ierarhie → cheie chiriaș (KEK) → chei de date (DEK).
Scheme separate/DB cu cerințe ridicate (Silo), un cluster comun cu RLS pentru eficiență (Pool).
Politici de retenție și „dreptul de a uita” per chiriaș, chei de mărunțire a criptei.

2. Calcule

Cote CPU/RAM/IO, bazine de lucrători pe chiriaș, cozi ponderate.
Izolarea GC/heap (containere/setări JVM/Runtime), limitele paralelismului.
Autoscaling per chiriaș + backpressure.

3. Reţea

Segmentare: puncte finale private/VPC, ACL prin 'chiriaș _ id'.
Limitarea ratei și plafoanele de conectare per chiriaș la frontieră.
Protecție împotriva DDoS/boți, luând în considerare planul/prioritatea.

4. Operațiuni și procese

Migrații chiriași, copii de rezervă, DR, feature-steaguri.
Incidente - "micro-explozie-rază": fuzionarea cu "chiriaș _ id'.

3) Controlul accesului și contextul chiriașilor

AuthN: OIDC/SAML; tokens carry 'tenant _ id',' org _ id', 'plan', 'scopes'.
AuthZ: RBAC/ABAC (roluri + atribute ale proiectului, departament, regiune).
Context la frontieră: gateway-ul API extrage și validează contextul chiriașilor, completează cu limite/cote, scrie la trasee.
Principiul „blocare dublă”: verificarea în serviciul + RLS/politica de baze de date.

4) Date: scheme, memorie cache, busteni

• Schema partajată (nivel rând): este necesară eficiență maximă, RLS strict.
• Per-schema: izolare/operabilitate tradeoff.
• Per-DB/cluster (Silo): pentru VIP/reglementat.

Cache: chiriaș prefixe cheie: {id}:... ", TTL după planuri, protecție cache-busculadă (blocare/reîmprospătare timpurie).

Jurnale/metadate: pseudonimizarea completă a PII, filtre prin 'chiriaș _ id', interzicerea „lipirii” buștenilor diferiților chiriași.

5) Limitarea traficului și a operațiunilor

Mecanica de bază

Token Bucket: explozii netezite, parametrizare „rată ”/„ explozie”.
Găleată cu scurgeri: debit de stabilizare.
Fereastră fixă/fereastră glisantă: cote simple/exacte pe fereastra de timp.
Limite de concurență: capace pentru cereri simultane/jabs.

În cazul în care se aplică

La frontieră (poarta L7/API) - protecție de bază și „eșec rapid”.
În miez (în servicii/cozi) - pentru al doilea circuit și „cota echitabilă”.

Politici

Prin chiriaș/plan/punct final/tip de operațiune (API-uri publice, exporturi grele, acțiuni admin).
Prioritate: VIP devine mai „explozie” și greutate în arbitraj.
Cheile de la Idempotency pentru retrageri sigure.

Profile de probă (concepte)

Starter: 50 req/s, explozie 100, 2 exporturi paralele.
Afaceri: 200 req/s, izbucni 400, 5 exporturi.
Enterprise/VIP: 1000 req/s, explozie 2000, lucrători dedicați.

6) Cote și planificare echitabilă (corectitudine)

Cote de resurse: stocare, obiecte, mesaje/min, locuri de muncă/oră, dimensiunea cozii.
Ponderat echitabil coadă/deficit Round Robin: „ponderat” accesul la lucrătorii partajați.
Piscine de lucru per chiriaș: izolare rigidă pentru clienții zgomotoși/critici.
Controlul admiterii: eșec/degradare înainte de execuție atunci când cotele sunt epuizate.
Backoff + jitter: întârzieri exponențiale pentru a menține exploziile în afara sincronizării.

7) Observabilitate și facturare per chiriaș

Etichetele necesare sunt 'tenant _ id',' plan ',' regiune ',' endpoint ',' status '.
SLI/SLO per chiriaș: latență p95/p99, rată de eroare, disponibilitate, utilizare, saturație.
Măsurători de utilizare: CPU operare/octet/al doilea contoare → agregator → facturi.
Idempotența facturării: instantanee la frontieră, protecție împotriva dublelor scrieri/pierderi de evenimente.
Tablouri de bord în segmente: VIP/reglementate/chiriași noi.

8) Incidente, degradare și DR „de chiriaș”

Fuzionarea prin "chiriaș _ id': oprirea/împingerea de urgență a unui anumit chiriaș fără a afecta restul.
Degradare grațioasă: mod read-only, cozi de nisip, sarcini amânate.
RTO/RPO per chiriaș: obiective de recuperare și pierdere pentru fiecare plan.

Burghiu: regulat „zile de joc” cu chiriaș zgomotos tăiat și DR verificat

9) Conformitate (rezidență, confidențialitate)

Pinning chiriaș în regiune; reguli clare privind fluxul transregional.
Audit de acces la chei/date, logare admin.
Gestionați retenția și exportul de date per chiriaș.

10) Mini referință: cum să o puneți împreună

Fluxul de cerere

1. Edge (API gateway): TLS → extract 'tenant _ id' → validare token → aplică rata/cote → pune trasee.
2. Motor politic: context 'chiriaș _ id/plan/features' → decizia privind traseul și limitele.
3. Serviciu: drepturi de verificare + etichete 'chiriaș _ id' → lucrul cu baza de date în RLS → cache cu prefix.
4. Utilizare-colectare: contoare de operații/octeți → agregator → facturare.

Date

Schema/DB după strategie (rând-nivel/per-schemă/per-DB).
KMS: chei chiriaș, rotație, cripto-mărunțire pe ștergere.

Calcul

Cozi cu greutăți, piscine de lucrători pe chiriaș, plafoane de concurență.
Autoscaling prin măsurători per chiriaș.

11) Pseudo-politică (pentru orientare)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) Lista de verificare pre-vânzare

• Sursa unică a adevărului "chiriaș _ id'; peste tot este aruncat și logat.
• RLS/ACL activat la nivelul DB + verificarea serviciului (dublu blocare).
• Chei de criptare per chiriaș, cripto-mărunțire documentate.
• Limite/cote la frontieră și în interior; explozii testate și „izbucni”.
• Lucrători VIP echitabili și/sau dedicați; capace на concurență.
• SLO-uri și alerte per-chiriaș; tablouri de bord pe segmente.
• Colectarea utilizării este idempotentă; rollup de facturare verificat.
• DR/incidentele sunt localizate chiriașului; fuzionarea cu "chiriaș _ id' funcționează.
• Numerarul/jurnalele sunt împărțite pe chiriaș; PII mascat.
• Procedurile de migrare/backup/export sunt bazate pe chiriași.

13) Erori tipice

RLS dezactivat/ocolit de utilizator „serviciu” - risc de scurgere.
Limitatorul global unic → „vecinul zgomotos” și încălcarea SLO.
Cache-uri/cozi partajate fără prefixe → intersecția datelor.
Facturarea contează prin jurnalele care se pierd la vârfuri.
Lipsa de fuziune chiriaș - cascadă cade.
Migrațiile "într-o singură lovitură" fără capacitatea de a opri problematica "chiriaș _ id'.

14) Selectarea rapidă a strategiei

Reglementat/VIP: Date siloz (per-DB), lucrători dedicați, cote stricte și rezidență.
Mass SaaS: schemă comună + RLS, limite puternice la frontieră, coadă echitabilă în interior.
Încărcați "zgomotos/pulsant": mari "burst' + hard concurență-capace, backpressure și priorități în funcție de planuri.

Concluzie

Izolarea chiriașilor și limitele se referă la limite și justiție. Ștergeți 'chiriaș _ id' prin stiva, RLS și criptarea datelor, limitarea și cotele la frontieră și în miez, planificator echitabil, observabilitatea și localizarea incidentelor - toate acestea împreună oferă securitate, calitate previzibilă și facturare transparentă pentru fiecare chiriaș, chiar și cu o creștere agresivă a platformei.