Izolacja najemcy i limity
Izolacja najemcy i granice są fundamentem architektury wielu najemców. Cel: Tak, że działania jednego najemcy nigdy nie wpływają na dane, bezpieczeństwo i SLO innego, a zasoby są rozprowadzane uczciwie i przewidywalnie. Poniżej znajduje się praktyczna mapa rozwiązań od poziomu danych do planowania obliczeń i zarządzania incydentami.
1) Model zagrożenia i cele
Zagrożenia
Wyciek danych między lokatorami (logiczny/cache/via logs).
„Hałaśliwy sąsiad”: degradacja wydajności ze względu na kolce u jednego klienta.
Eskalacja przywilejów (błąd w polityce dostępu).
Dryf rozliczeniowy (niedopasowanie użytkowania i opłat).
Kaskady bezpieczne scenariusze (incydent jednego prowadzi do przestojów wielu).
Cele
Ścisłe odizolowanie danych i tajemnic.
Marginalne limity/kwoty i sprawiedliwe planowanie.
Przejrzysty audyt, obserwowalność i rozliczenia.
Lokalizacja wypadków i szybkie odzyskiwanie na najemcę.
2) Poziomy izolacji (model końcowy)
1. Dane
'lokator _ id' in klucze i indeksy, Row-Level Security (RLS).
Szyfrowanie: hierarchia KMS → klucz najemcy (KEK) → klucze danych (DEK).
Oddzielne systemy/DB o wysokich wymaganiach (Silo), wspólny klaster z RLS dla wydajności (Pool).
Polityka retencji i „prawo do zapomnienia” na najemcę, klucze crypto-rozdrabniania.
2. Obliczenia
Kwoty CPU/RAM/IO, puli pracowników na najemcę, kolejki ważone.
Izolacja GC/hałdy (JVM/Kontenery/ustawienia runtime), ograniczenia paralelizmu.
Per-najemca autoskalowanie + backpressure.
3. Sieć
Segmentacja: prywatne punkty końcowe/VPC, ACL przez 'lokator _ id'.
Ograniczenie kursu i czapki połączeń na jednego najemcę na granicy.
Ochrona przed DDoS/botami, z uwzględnieniem planu/priorytetu.
4. Operacje i procesy
Wędrówki lokatorów, kopie zapasowe, DR, flagi funkcji.
Incydenty - „promień mikro-blast”: topienie przez 'lokator _ id'.
3) Kontrola dostępu i kontekst najemcy
AuthN: OIDC/SAML; tokeny przenoszą 'lokator _ id',' org _ id', 'plan', 'scopes'.
AuthZ: RBAC/ABAC (role + atrybuty projektu, departamentu, regionu).
Kontekst na granicy: brama API wyciąga i zatwierdza kontekst najemcy, uzupełnia limity/kwoty, pisze do szlaków.
Zasada „podwójnej blokady”: sprawdzanie w polityce + usługi RLS/bazy danych.
4) Dane: schematy, pamięć podręczna, kłody
Programy:- Wspólny schemat (poziom wiersza): wymagana jest maksymalna wydajność, ścisły RLS.
- Per-schemat: odizolowanie/operacyjność tradeoff.
- Per-DB/cluster (Silo): dla VIP/regulowanych.
Cache: lokator prefiksów kluczy: {id}:... ", TTL według planów, zabezpieczenie cache-stampede (zamek/wczesny odśwież).
Logi/metadane: pełne pseudonimizacja PII, filtry przez 'lokator _ id', zakaz „klejenia” kłód różnych najemców.
5) Ograniczenie ruchu i operacji
Podstawowa mechanika
Token Bucket: wygładzone wybuchy, parameteryzacja 'rate '/' burst'.
Leaky Bucket: Stabilizacja przepustowości.
Stałe okno/okno przesuwne: proste/dokładne kwoty w oknie czasowym.
Limity współistnienia: czapki dla jednoczesnych żądań/jabs.
Gdzie stosować
Na granicy (L7/API brama) - podstawowa ochrona i „szybka awaria”.
W rdzeniu (w usługach/kolejkach) - dla drugiego obiegu i „sprawiedliwego udziału”.
Zasady
Według najemcy/planu/punktu końcowego/rodzaju operacji (publicznych API, eksportu ciężkiego, działań administratora).
Świadomy priorytetu: VIP dostaje więcej „pęknięcia” i wagi w arbitrażu.
Idempotencja-klucze do bezpiecznych rekolekcji.
Profile próbki (koncepcje)
Rozrusznik: 50 req/s, wybuch 100, 2 równoległy eksport.
Biznes: 200 req/s, wybuch 400, 5 eksport.
Enterprise/VIP: 1000 req/s, burst 2000, dedykowani pracownicy.
6) Kwoty i sprawiedliwe planowanie (uczciwość)
Przydziały zasobów: przechowywanie, obiekty, wiadomości/min, zadania/godzina, rozmiar kolejki.
Ważone targi kolejkowania/rundy deficytu Robin: „Ważony” dostęp do wspólnych pracowników.
Baseny na najemcę: sztywna izolacja dla hałaśliwych/krytycznych klientów.
Kontrola wjazdu: awaria/degradacja przed wykonaniem, gdy kwoty są wyczerpane.
Backoff + jitter: wykładnicze opóźnienia, aby utrzymać wybuchy poza synchronizacją.
7) Obserwowalność i rozliczenie na najemcę
Wymagane znaczniki to 'lokator _ id',' plan ',' region ',' punkt końcowy ',' status '.
SLI/SLO na najemcę: p95/p99 opóźnienie, wskaźnik błędów, dostępność, wykorzystanie, nasycenie.
Metryka użytkowania: obsługa procesora/bajt/drugi licznik → agregator → faktury.
Billing idempotence: migawki na granicy, ochrona przed podwójnymi odpisami/utratą zdarzeń.
Deski rozdzielcze w segmentach: VIP/regulowane/nowi najemcy.
8) Incydenty, degradacja i DR „przez najemcę”
Topienie przez 'najemcę _ id': awaryjne wyłączenie/przepustowość określonego najemcy bez wpływu na resztę.
Graceful Degradation: tryb tylko do odczytu, kolejki piaskownic, zadania odroczone.
RTO/RPO na najemcę: cele odzyskiwania i strat dla każdego planu.
Wiertło: Regularne „dni gry” z hałaśliwym najemcą odcięty i DR sprawdzone
9) Zgodność (rezydencja, prywatność)
Lokator szpilkowy do regionu; jasne zasady przepływu międzyregionalnego.
Audyt dostępu do kluczy/danych, rejestrowanie administratorów.
Zarządzanie zatrzymywaniem i eksportem danych na najemcę.
10) Mini odniesienie: jak go połączyć
Przepływ żądania
1. Krawędź (brama API): TLS → wyciąg 'najemca _ id' → walidacja tokenu → zastosuj stawkę/kwoty → umieść szlaki.
2. Silnik polityczny: kontekst „najemca _ id/plan/funkcje” → decyzja o trasie i limitach.
3. Usługa: sprawdzanie praw + etykiety 'lokator _ id' → praca z bazą danych w RLS → cache z prefiksem.
4. Użycie-kolekcja: liczniki operacji/bajty → agregator → rozliczenie.
Dane
Schemat/DB według strategii (poziom wiersza/per-schema/per-DB).
KMS: klucze najemcy, obrót, crypto-rozdrabnianie przy usuwaniu.
Informatyka
Kolejki z wagami, puli pracowników na najemcę, czapki przez równoczesność.
Autoskalowanie przez metryki dla jednego najemcy.
11) Pseudo-polityka (dla orientacji)
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 kontrolna przedsprzedaży
- Pojedyncze źródło prawdy "najemca _ id'; wszędzie są wyrzucane i rejestrowane.
- Obsługa RLS/ACL włączona na poziomie DB + (podwójna blokada).
- Klucze szyfrowania na lokatora, crypto-rozdrabnianie udokumentowane.
- Limity/kwoty na granicy i wewnątrz; przetestowane wybuchy i „pęknięcie”.
- Fair-queuing i/lub dedykowanych pracowników VIP; czapki на równoczesność.
- SLO i wpisy dla jednego najemcy; deski rozdzielcze według segmentów.
- Zbieranie użytkowania jest idempotentne; zweryfikowany rollup rozliczeniowy.
- DR/incydenty są zlokalizowane dla najemcy; fusing przez 'tenant _ id' works.
- Środki pieniężne/dzienniki są podzielone przez najemcę; PII zamaskowany.
- Procedury migracji/tworzenia kopii zapasowych/wywozu są oparte na najemcy.
13) Typowe błędy
RLS wyłączony/ominięty przez użytkownika „usługi” - ryzyko wycieku.
Pojedynczy globalny ogranicznik → „hałaśliwy sąsiad” i naruszenie SLO.
Wspólne bufory/kolejki bez przedrostków → skrzyżowanie danych.
Rachunki liczą się według dzienników, które są tracone w szczytach.
Brak syntezy termojądrowej - upadki kaskadowe.
Migracje „w jednym padł swoop” bez możliwości zatrzymania problematycznego 'lokator _ id'.
14) Szybki wybór strategii
Regulowane/VIP: dane dotyczące silosu (w przeliczeniu na DB), pracowników dedykowanych, ścisłe kwoty i miejsce zamieszkania.
Masa SaaS: wspólny schemat + RLS, silne limity na granicy, uczciwe kolejki wewnątrz.
Ładowanie „hałaśliwe/pulsujące”: duże 'burst' + twarde czapki współzależności, ciśnienie wsteczne i priorytety zgodnie z planami.
Wnioski
Izolacja najemców i granice dotyczą granic i sprawiedliwości. Wyczyść "najemca _ id' poprzez stos, RLS i szyfrowanie danych, ograniczenie i kwoty na granicy i w rdzeniu, sprawiedliwy harmonogram, obserwowalność i lokalizacja incydentów - wszystko to daje bezpieczeństwo, przewidywalną jakość i przejrzyste rozliczenia dla każdego najemcy, nawet przy agresywnym wzroście platformy.