Multi-tenancy bez žargonu: průvodce pro zakladatele

V určitém bodě budování softwarového produktu vám vývojář řekne slovo „multi-tenant“, podívá se vám do tváře a předpokládá, že jste pochopili. Nejspíš jste přikývli. Většina zakladatelů to udělá. Jenže tohle je jedno z těch raných rozhodnutí, která tiše určují strop toho, jak rychle můžete růst, jak levně můžete provozovat a jak špatně se věci mohou zvrtnout, pokud zákazník někdy uvidí data, která mu nepatří. Stojí to teď za deset minut vaší pozornosti, protože vracet se k tomu později je velmi nákladné.

Seděl jsem naproti spoustě netechnických zakladatelů — lidem s bystrým nápadem na SaaS produkt a bez zvláštního zájmu o databáze. Dobrá zpráva je, že abyste se rozhodli dobře, nemusíte se učit programovat. Potřebujete jasný myšlenkový model a krátký seznam otázek. Přesně tím tento průvodce je. Žádná módní slova, žádné architektonické diagramy, na které se už nikdy nepodíváte, jen to, co by si váš vývojář přál, abyste pochopili před prvním řádkem kódu.

Pokud si odnesete jedinou myšlenku, ať je to tahle: multi-tenancy není funkce, kterou přidáte později. Je to základ. Dům můžete přemalovat, ale jakmile stojí zdi, nemůžete snadno změnit to, na čem stojí.

Co „multi-tenant“ doopravdy znamená

Představte si bytový dům. Každý nájemník má vlastní byt — vlastní klíč, vlastní nábytek, vlastní vstupní dveře. Ale všichni sdílejí stejnou konstrukci: základy, vodovod, střechu, výtah. Majitel udržuje jednu budovu, ne padesát samostatných domů, a právě to dělá nájem dostupným. Multi-tenant software funguje přesně takhle. Jedna aplikace obsluhuje mnoho zákazníků — „tenantů“ — a každý ji prožívá jako svůj vlastní soukromý prostor, přestože všichni běží na témže sdíleném systému pod povrchem.

Opačný přístup je single-tenant: každý zákazník dostane vlastní samostatnou kopii softwaru, jako byste pro každého stavěli zbrusu nový samostatný dům. Soukromější, lépe přizpůsobitelný — a dramaticky dražší na postavení, provoz a aktualizaci, protože teď udržujete padesát domů místo jedné budovy.

Téměř každý produkt, který denně používáte, je multi-tenant. Váš e-mail, váš účetní nástroj, váš rezervační systém, CRM, ve kterém žije váš obchodní tým. Vy a tisíc dalších firem sdílíte tentýž základní software a nikdo z vás toho druhého nikdy nevidí. Ta neviditelnost — to čisté oddělení — je celé umění multi-tenancy.

Proč se toto rozhodnutí dotýká celého vašeho podnikání

Je lákavé zařadit to pod „technický detail, který řeší můj vývojář“. Jenže model, který zvolíte, se přímo přelévá do těch částí podnikání, na kterých vám záleží: do měsíčního účtu za hosting, do toho, jak rychle dokážete vydat novou funkci všem, co můžete slíbit nervóznímu firemnímu kupci a kolik škody dokáže napáchat jediná chyba.

Když v dobře postaveném multi-tenant produktu opravíte chybu nebo vydáte funkci, každý zákazník ji dostane naráz, z jediné aktualizace. Ve světě single-tenant byste tu změnu rozváděli do padesáti samostatných instalací, z nichž každá už teď může být trochu jiná. Jedno je úterní odpoledne. To druhé je projekt. Vynásobte to roky aktualizací a uvidíte, proč SaaS průmysl stojí na multi-tenancy.

Druhá strana mince je, že sdílení infrastruktury zvyšuje sázku na oddělení. V bytovém domě může porucha vodovodu zasáhnout víc než jeden byt. V multi-tenant softwaru chyba v tom, jak držíte tenanty oddělené, nejen obtěžuje jednoho zákazníka — může naráz vystavit data všech. To není důvod se multi-tenancy vyhýbat. Je to důvod ji postavit pořádně, s někým, kdo to už dělal.

Tři způsoby, jak držet tenanty oddělené

Když se vývojáři přou o multi-tenancy, obvykle se přou o to, jak oddělená mají být data každého tenanta. Existují tři běžné přístupy a leží na posuvné stupnici od „maximální sdílení, nejnižší náklady“ po „maximální oddělení, nejvyšší náklady“. Nemusíte si jeden vybírat sami — ale měli byste rozumět kompromisu, který za vás vývojář dělá.

1. Sdílená databáze, sdílené tabulky

Data všech žijí v téže databázi, v týchž tabulkách, se skrytým štítkem — „tenant ID“ — který značí, které řádky komu patří. Software je zodpovědný za to, že podle toho štítku vždy filtruje, takže zákazník A vidí jen řádky zákazníka A. To je nejlevnější a nejlépe škálovatelný model, ten, který používá většina raných SaaS produktů. Háček: oddělení žije v kódu, takže jediný vynechaný filtr je způsob, jak data unikají. Vyžaduje pečlivé, disciplinované inženýrství.

2. Sdílená databáze, oddělené přihrádky

Jedna databáze, ale každý tenant dostane uvnitř ní vlastní oddělenou sekci (vývojáři jim říkají „schémata“). Silnější oddělení než první model, stále rozumně efektivní a usnadňuje například čistý export nebo smazání dat jednoho zákazníka. Kompromis: víc pohyblivých částí na správu, jak rostete do stovek a tisíců tenantů.

3. Samostatná databáze pro každého tenanta

Každý zákazník dostane vlastní vyhrazenou databázi — to nejbližší tomu dát mu soukromý dům a přitom stále sdílet aplikaci. To je nejsilnější izolace a nejsnáze vyprávitelný příběh pro firemního kupce, kterému záleží na bezpečnosti. Je to také nejdražší na provoz a obsluhu, takže to bývá vyhrazené pro vysoce hodnotné zákazníky, regulovaná odvětví nebo produkty, kde by záměna dat byla katastrofální.

Část, kterou nesmíte pokazit: izolace

Pokud je jedno místo, kde investovat své obavy, je to tady. Izolace tenanta je záruka, že zákazník A nemůže za žádných okolností vidět, upravit ani jen tušit existenci dat zákazníka B. Zní to samozřejmě. A přitom je to jediný nejčastější zdroj vážných chyb v multi-tenant produktech, protože selhání je tiché — všechno vypadá v pořádku až do dne, kdy někdo otevře report a uvidí v něm cizí zákazníky.

Důvod, proč se to stává, je strukturální. V nejlevnějším modelu si každý jednotlivý databázový dotaz musí pamatovat filtrovat podle tenanta. Udělejte to desettisíckrát správně a jednou špatně a máte únik. Proto se zkušené týmy nespoléhají na to, že si vývojáři vzpomenou — zabudují izolaci do základu, takže zapomenout se stane nemožným, ne jen nepravděpodobným. Nemusíte rozumět tomu, jak to dělají. Musíte se ptát, jestli to dělají.

Existuje i tišší příbuzný tohoto problému: „hlučný soused“. Protože tenanti sdílejí infrastrukturu, jeden zákazník dělající něco náročného — obří import, utržený report — může zpomalit systém všem ostatním, stejně jako jeden byt s puštěnými všemi kohoutky může srazit tlak vody v celé budově. Dobrý multi-tenant návrh s tím počítá pomocí limitů a férového sdílení. Stojí za to se na to zeptat, zvlášť pokud čekáte pár velmi velkých zákazníků.

Kdy je single-tenant skutečně správná volba

Multi-tenancy je pro SaaS výchozí, ale není to náboženství. Existují poctivé důvody dát zákazníkovi vlastní samostatnou kopii a dobrý poradce vám řekne, kdy jste na jeden narazili, místo aby cpal všechno do sdíleného modelu.

• Zákazník v regulovaném odvětví — zdravotnictví, finance, státní správa — jehož pravidla shody fakticky vyžadují, aby jeho data ležela někde prokazatelně odděleně.
• Jediný velký klient platící dost na to, aby se vyhrazené nasazení vyplatilo, a který chce hluboké přizpůsobení, jež nechcete nechat prosáknout do prožitku všech ostatních.
• Data tak citlivá, že náklady na únik napříč tenanty by ukončily byznys, což činí maximální izolaci hodnou té vyšší ceny.
• Požadavek on-premise, kdy software musí běžet uvnitř zdí samotného zákazníka, ne ve vašem cloudu.

Všimněte si vzoru: single-tenant je výjimka, po které sáhnete záměrně, obvykle pro konkrétního vysoce hodnotného zákazníka, ne výchozí stav, na kterém stavíte celý byznys. Pokud vývojář navrhuje single-tenant pro váš standardní produkt už od prvního dne, požádejte ho, ať vám vysvětlí proč — obvykle to znamená mnohem vyšší provozní náklady a pomalejší aktualizace, a vy chcete, aby to byla volba, ne nehoda.

Otázky, které položit, než kdokoli napíše kód

Nemusíte navrhovat architekturu. Musíte se ujistit, že ten, kdo ji navrhuje, promyslel ty správné věci. Tady je krátký seznam, který bych chtěl, aby si netechnický zakladatel přinesl na onu první schůzku — vytiskněte si ho, ptejte se a sledujte, s jakou jistotou se na ně odpovídá.

1. 1
   Jak budete držet data tenantů oddělená?

   Posloucháte strukturální odpověď — systém to vynucuje — ne „budeme opatrní“. Tahle je ta nediskutovatelná.
2. 2
   Který model používáme a proč?

   Sdílené tabulky, oddělené přihrádky nebo databáze na tenanta. Není špatná odpověď, ale měl by existovat důvod, který sedí na vaše zákazníky a rozpočet.
3. 3
   Můžeme později nabídnout vyhrazenou izolaci velkému klientovi?

   I když začnete plně sdíleně, návrh by měl nechat prostor dát jednomu velkému nebo regulovanému zákazníkovi silnější oddělení bez přestavby.
4. 4
   Co se stane, když jeden zákazník zmohutní?

   Jak systém zabrání, aby jeden náročný tenant zpomalil všechny ostatní? Chcete slyšet, že se počítalo se scénáři hlučného souseda.
5. 5
   Jak čistě exportujeme nebo smažeme data jednoho zákazníka?

   Zákazníci odcházejí a zákon o ochraně soukromí vyžaduje na požádání jejich data odstranit. Mělo by to být jednoduchá, dobře pochopená operace, ne panika.

Neznámkujete technický detail odpovědí. Kontrolujete, že žádná z těchto otázek nedopadne jako překvapení. Tým, který už multi-tenant software stavěl, bude mít na všech pět svižné, skoro znuděné odpovědi. Zaváhání u první nebo třetí je signál zpomalit a zavrtat se hloub.

Krátký příklad z reálné praxe

Přišel za námi zakladatel s funkčním prototypem objednávacího nástroje mířeného na malé kliniky. Měl už tři platící zákazníky — a tichý problém. Aby se rychle dostal na trh, dal první vývojář každé klinice vlastní samostatnou kopii aplikace. Tři zákazníci, tři instalace, tři mírně odlišné verze, protože každý si cestou vyžádal malou úpravu.

Při třech to fungovalo krásně. Zakladatelovou noční můrou byla představa třiceti. Každá oprava chyby znamenala přihlásit se na tři místa. Každá nová funkce znamenala tři nasazení a tři věci k otestování. Nová klinika zabrala skoro týden ručního nastavení. Model, který je dostal ke spuštění, byl teď tím, co stropovalo jejich růst — přesně ten problém základu, o kterém je celý tento článek.

Nevytrhli jsme všechno v dramatickém přepsání. Přestavěli jsme jádro na sdílený multi-tenant základ s izolací vynucenou na úrovni systému, ponechali jsme přizpůsobení jednotlivých klinik jako konfigurovatelná nastavení místo samostatných kódových základen a migrovali jsme tři stávající kliniky jednu po druhé, souběžně, aby nikdo neměl děsivý den přepnutí. Zavedení nové kliniky se z týdne ruční práce změnilo na samoobslužnou registraci. Nové funkce teď doputují ke každému zákazníkovi z jediného vydání.

Čísla zde jsou ilustrativní, ne příslib — každý produkt je jiný — ale tvar je typický: přestavba stála reálné peníze a pár měsíců a zaplatila se během prvních pár nových zákazníků, které najednou mohli zavést, aniž by hnuli prstem. Ponaučení, které si zakladatel odnesl, bylo to levnější: kdyby těch pět otázek položili na začátku, nebylo by co přestavovat.

Časté otázky