Multi-tenancy w SaaS: silo, pool czy bridge — i droga pomiędzy nimi

Najdroższa decyzja przed pierwszym klientem

W platformie SaaS model tenancy to punkt, w którym krzyżują się ekonomia jednostkowa, poziom bezpieczeństwa i tempo prac inżynierskich. Decyduje o tym, ile kosztuje obsługa każdego klienta, jak daleko rozlewa się incydent, co można wiarygodnie obiecać audytorowi i jak bolesna będzie każda przyszła migracja. Zespoły spędzają tygodnie na wyborze frameworka frontendowego i jedno popołudnie na modelu tenancy. Proporcje powinny być odwrotne: framework można wymienić, model tenancy zastyga.

Przestrzeń rozwiązań pokrywają trzy kanoniczne modele — silo, pool i bridge — i żaden nie jest po prostu najlepszy. Każdy wymienia izolację na koszty operacyjne. Użyteczne pytanie nie brzmi, który model jest właściwy, lecz na jakie kompromisy mogą sobie Państwo dziś pozwolić — i ile będzie kosztować późniejsza zmiana zdania.

Silo, pool, bridge — rzeczywiste kompromisy

Modele różnią się tym, co współdzielą, a co dedykują; sposób, w jaki każdy z nich zawodzi, wynika wprost z tego wyboru.

• Silo — każdy tenant otrzymuje dedykowane zasoby, zwykle bazę danych, a często także compute. Najsilniejsza izolacja i najprostsza narracja compliance — ale twarde minimum kosztowe na tenanta i problem floty: dwustu tenantów oznacza dwieście baz danych do migrowania, backupowania, łatania i monitorowania.
• Pool — wszyscy tenanci współdzielą infrastrukturę, rozdzieleni kolumną tenant_id. Koszt krańcowy na tenanta zbliża się do zera, ale izolacja staje się zadaniem aplikacji, a jedno źle napisane zapytanie może zdegradować wszystkich naraz.
• Bridge — współdzielony compute nad rozdzielonymi danymi (schemat lub baza per tenant) albo flota warstwowa: infrastruktura pooled dla planu standardowego i dedykowane sila dla tenantów regulowanych lub enterprise.

Naszym domyślnym wyborem dla produktów B2B jest model pooled za rygorystyczną abstrakcją tenancy, z silo sprzedawanym jako płatny poziom premium — nigdy przyjmowanym odruchowo. Dedykowana infrastruktura, za którą nikt nie płaci, to nie architektura, lecz subsydium.

Izolacja to obrona warstwowa, nie klauzula WHERE

Kolumna tenant_id plus dyscyplina programistów to nie strategia izolacji; od zgłoszenia naruszenia danych dzieli ją jeden zapomniany filtr. Izolacja musi wytrzymać nawet wtedy, gdy programista popełni błąd — trzeba ją więc egzekwować na kilku niezależnych warstwach.

• Kontekst tenanta należy rozwiązać raz, na brzegu systemu — z subdomeny, tokenu lub nagłówka — i propagować przez każde żądanie, zadanie i zdarzenie; nic niżej nie wyprowadza go ponownie.
• Zapytania cross-tenant powinny być niemożliwe do napisania przez przypadek: repozytoria lub query buildery, które wymuszają zakres tenanta konstrukcyjnie, a nie konwencją.
• Row-level security w bazie danych warto włączyć jako zabezpieczenie ostatniej szansy: pominięty filtr powoduje błąd zapytania, zamiast ujawnić cały zbiór danych.
• Pola objęte regulacjami należy szyfrować kluczami per tenant — offboarding i żądania usunięcia danych stają się wtedy operacjami na kluczach, a nie skanowaniem tabel.
• Warto utrzymywać zautomatyzowany zestaw testów dostępu cross-tenant; każde niepowodzenie w nim to incydent bezpieczeństwa, a nie zwykłe zgłoszenie błędu.

Noisy neighbors: problem sprawiedliwości, nie pojemności

W modelu pooled pojemność jest współdzielona; bez jawnych reguł sprawiedliwości największy tenant dyktuje opóźnienia wszystkim pozostałym, a dodatkowy sprzęt jedynie podnosi sufit niesprawiedliwego planisty. Zużycie per tenant należy mierzyć od pierwszego dnia: garstka tenantów generuje większość obciążenia, a tym, czego się nie przypisuje, nie da się zarządzać.

• Limity zapytań i kwoty per tenant należy egzekwować w warstwie API i wliczyć w cenniki planów, aby limity były dźwignią handlową, a nie przeprosinami.
• Współbieżność per tenant w kolejkach zadań w tle trzeba ograniczyć — masowy import jednego tenanta nigdy nie może opóźniać webhooków innego.
• Warto ustawić limity czasu wykonywania zapytań i kierować zapytania analityczne na repliki; ścieżka transakcyjna nigdy nie jest miejscem na raportowanie.
• W skali floty architektura komórkowa (cell-based) i shuffle sharding ograniczają zasięg rażenia przeciążeń i wadliwych wdrożeń.

Observability, która zna słowo tenant

Pierwsze pytanie przy każdym incydencie SaaS brzmi: kogo to dotyczy? Jeśli Państwa telemetria nie odpowiada na nie w kilka sekund, mają Państwo dashboardy, a nie observability. Tożsamość tenanta powinna być pełnoprawnym wymiarem w logach, trace'ach i metrykach, z kardynalnością zarządzaną świadomie: pełna szczegółowość w logach i trace'ach, top-N plus agregaty w metrykach.

SLO per tenant warto zdefiniować przynajmniej dla najwyższego planu i stale mierzyć zużycie. Te same dane odpowiadają na pytania supportu w minuty, zasilają rozliczenia oparte na użyciu i ujawniają klientów, których po cichu obsługują Państwo ze stratą.

Migrację należy zaprojektować, zanim będzie potrzebna

Niezależnie od modelu startowego któryś tenant w końcu będzie musiał się przenieść: kontrakt enterprise zażąda silo albo flota silosów stanie się zbyt droga w utrzymaniu. Ścieżka migracji jest częścią architektury, a nie refleksją po fakcie.

• Kolumnę tenant_id warto zachować w każdym wierszu nawet w bazach silo — konsolidacja danych bez niej to archeologia.
• Schematy muszą pozostać identyczne we wszystkich silosach; dryf schematów po cichu zamienia migrację w przepisanie systemu.
• Tenantów należy kierować przez stabilną abstrakcję wiążącą każdego z lokalizacją jego danych, tak aby ta lokalizacja mogła się zmienić bez zmian w aplikacji.
• Przeprowadzkę trzeba przećwiczyć: eksport ograniczony do tenanta, przełączenie oparte na replikacji, krótkie okno dual write i zweryfikowany rollback.

Model, z którym Państwo startują, nie będzie modelem, z którym Państwo skończą. Zadaniem architektury jest uczynić z tej zmiany zaplanowany projekt, a nie ogólnofirmową sytuację awaryjną.