Abstrakt Multi-tenancy je strategické rozhodnutí, které ovlivňuje ekonomiku, bezpečnost i provozní model SaaS produktu. Volba mezi sdílenou a izolovanou architekturou určuje, jakou cenovou hladinu lze nabídnout, jak rychle umí firma onboardovat zákazníky a jaké regulatorní požadavky dokáže splnit. Článek shrnuje hlavní architektonické vzory, techniky datové izolace, řízení tenant kontextu, dopady na výkon, provoz, bezpečnost a byznys model. Text je určen architektům, technickým ředitelům a produktovým manažerům SaaS produktů.
Proč multi-tenancy
Multi-tenancy přináší úspory z rozsahu: sdílením infrastruktury klesají jednotkové náklady na zákazníka, zjednodušuje se údržba a zrychluje onboarding. Z technického hlediska umožňuje centralizované upgrady, jednotný monitoring a snadnější škálování. Z byznys pohledu otevírá segment středních a malých firem, kde by dedikované nasazení nebylo ekonomicky únosné, a vytváří prostor pro síťové efekty a sdílenou analytiku.
Architektonické vzory
V praxi se používají tři základní modely, které se liší mírou sdílení zdrojů.
Pool model (sdílení všeho). Tenanti sdílejí jednu databázi i aplikační instance, izolaci zajišťuje aplikační vrstva nebo databázové mechanismy. Model umožňuje nejnižší náklady a efektivní využití zdrojů. Hodí se pro standardizovaný produkt s podobnými profily využití. Nevýhodou je problém hlučného souseda a omezená možnost zákaznických úprav.
Silo model (plná izolace). Každý tenant má vlastní databázi, často i samostatné aplikační instance a síťový segment. Model poskytuje maximální izolaci, předvídatelný výkon a snadné splnění regulatorních požadavků (zdravotnictví, finance, veřejná správa). Cenou je vyšší cena infrastruktury a složitější provoz.
Hybridní model. Kombinace předchozích modelů podle úrovně služby. Free a basic plány běží v poolu, profesionální tier sdílí databázi s dedikovanými aplikačními instancemi, enterprise tier dostává plnou izolaci. Architektura musí podporovat plynulou migraci mezi tiery.
Datová izolace
Izolace dat je nejcitlivější část multi-tenant architektury. Nejčastěji se kombinují tři techniky.
Row-Level Security (RLS) přesouvá ochranu z aplikace do databáze. V PostgreSQL se zakládá na bezpečnostních politikách vázaných na proměnnou s identifikátorem tenanta. Výhodou je vynucení izolace i v případě chyby aplikační vrstvy. Nutností je automatizovaný test, který opakovaně ověřuje, že každá tabulka má aktivní politiku.
Schema-per-tenant vytváří pro každého zákazníka samostatné databázové schéma. Hodí se pro stovky až nízké tisíce tenantů, kde je požadavek na snadný export a obnovu dat jednoho zákazníka. Vyžaduje vlastní nástroj pro běh migrací a opatrnou práci s connection poolem.
Partitioning rozděluje velké tabulky podle identifikátoru tenanta. Zlepšuje výkon (partition pruning), zjednodušuje mazání dat při odchodu zákazníka a omezuje rozsah údržby.
Řízení tenant kontextu
Identifikátor tenanta musí spolehlivě prostupovat celou aplikací. Kritická místa jsou HTTP middleware (extrakce z tokenu nebo hlavičky), asynchronní úlohy (serializace kontextu při odložení i obnově), databázové spojení (nastavení relační proměnné), cache (povinný prefix klíčů), strukturované logy a metriky. Chybějící kontext v jakékoli vrstvě představuje potenciální únik dat.
Pro cache se osvědčuje konvence pojmenování klíčů ve tvaru tenant:identifikátor:klíč, oddělené poolování pro různé úrovně služby a sledování zásahů cache podle tenanta. Pro největší zákazníky bývá vhodné vyčlenit dedikovanou cache instanci.
Výkon a škálování
Hlavním rizikem sdíleného modelu je problém hlučného souseda. Bránit se lze časovými limity dotazů, kvótami procesoru a paměti, omezováním rychlosti volání API, analýzou složitosti dotazů a možností automatického přesunu nadměrně náročného zákazníka do izolovaného režimu.
Indexy musí odrážet vzor přístupu k datům. Místo samostatných indexů pro identifikátor tenanta a další sloupce se osvědčuje složený index, který kombinuje tenanta s nejčastěji používaným filtrem. U masivních nasazení se volí horizontální dělení (sharding) podle tenanta, velikosti, regionu nebo jejich kombinace; pro transparentní sharding nad MySQL je zavedeným řešením Vitess.
Provoz a pozorovatelnost
Nasazení nových verzí v multi-tenant prostředí těží z kanárkových strategií, kdy se nová verze nasazuje nejprve na vybranou skupinu zákazníků. Tagy typu early_adopter, stable a conservative umožňují řízenou expozici rizika a automatický rollback při zhoršení byznys metrik.
Monitoring musí být tenant-aware. Štítky pro Prometheus, dashboardy s filtrem podle tenanta a alerty rozlišené podle úrovně služby jsou standardem. Vedle technických metrik je potřeba sledovat byznys ukazatele – počet požadavků, chybovost, využití funkcí a celkové skóre zdraví zákazníka.
Strategie zálohování závisí na modelu izolace: pool vyžaduje obnovu k bodu v čase s filtrem podle tenanta, schema model práci s jednotlivými schématy, silo model standardní per-database zálohy. Klíčové scénáře (poškození dat, omylové smazání, únik mezi tenanty, plné DR) je nutné testovat čtvrtletně.
Bezpečnost a soulad
Automatizované testy izolace patří mezi povinný standard – ověřují, že tenant nevidí cizí data ani po obejití aplikační vrstvy. Penetrační testování musí cílit na specifika multi-tenant prostředí: hranice mezi tenanty, únos relace, obejití RLS přes injection a otravu cache.
Z hlediska legislativy je třeba pokrýt přenositelnost dat (GDPR), právo na výmaz, geografická omezení a auditní záznamy přístupů. Pro regulovaná odvětví přibývají požadavky HIPAA (zdravotnictví), PCI DSS (platby) a FedRAMP (veřejná správa USA).
Byznys dopady
Architektura úzce souvisí s cenotvorbou. Pool model umožňuje nízké vstupní ceny, silo model vyžaduje prémiovou hladinu, hybridní model otevírá víceúrovňové ceníky. Životní cyklus zákazníka – onboarding, růst, případný odchod – musí být plně automatizován, včetně exportu dat, retence a možnosti reaktivace.
Závěr
Začněte jednoduše, ale myslete na budoucnost. Pool model s robustní RLS je vhodným startem pro většinu SaaS produktů. S růstem lze přidat hybridní úroveň a pro nejnáročnější zákazníky plnou izolaci. Klíčem k úspěchu je architektura, která tuto evoluci umožňuje bez kompletního přepsání, automatizace všech provozních úkonů a kontinuální testování izolace. Správně navržená multi-tenant architektura je trvalá konkurenční výhoda; špatně navržená vede k bezpečnostním incidentům a ztrátě důvěry zákazníků.
Zdroje:
- AWS SaaS Factory, Azure Multi-tenant Applications, Google Cloud Multi-tenancy
- PostgreSQL Row Level Security
- Martin Fowler – Multi-tenancy
- Vitess – Database Sharding
- AWS Well-Architected SaaS Lens
