Viacnájomná architektúra bez žargónu: príručka pre zakladateľov

V určitom okamihu tvorby softvérového produktu vám vývojár povie slovo „multi-tenant“, pozrie sa na vašu tvár a predpokladá, že ste pochopili. Pravdepodobne ste prikývli. Väčšina zakladateľov to robí. No toto je jedno z tých skorých rozhodnutí, ktoré ticho stanovujú strop toho, ako rýchlo môžete rásť, ako lacno môžete prevádzkovať a ako zle sa veci môžu pokaziť, ak zákazník niekedy uvidí údaje, ktoré mu nepatria. Stojí to za desať minút vašej pozornosti teraz, pretože je veľmi nákladné vracať sa k tomu neskôr.

Sedel som oproti mnohým netechnickým zakladateľom — ľuďom s bystrým nápadom na SaaS produkt a bez osobitného záujmu o databázy. Dobrou správou je, že sa nemusíte učiť programovať, aby ste toto rozhodnutie urobili dobre. Potrebujete jasný myšlienkový model a krátky zoznam otázok. Presne tým je táto príručka. Žiadne módne slová, žiadne architektonické diagramy, na ktoré sa už nikdy nepozriete, len to, čo si váš vývojár želá, aby ste pochopili pred prvým riadkom kódu.

Ak si odnesiete jednu myšlienku, nech je to táto: multi-tenancy nie je funkcia, ktorú pridáte neskôr. Je to základ. Dom môžete prelakovať, ale nemôžete ľahko zmeniť to, na čom stojí, keď už stoja steny.

Čo „multi-tenant“ v skutočnosti znamená

Predstavte si bytový dom. Každý nájomník má vlastný byt — vlastný kľúč, vlastný nábytok, vlastné vchodové dvere. No všetci zdieľajú rovnakú konštrukciu: základy, rozvody, strechu, výťah. Majiteľ udržiava jednu budovu, nie päťdesiat samostatných domov, a práve to robí nájom dostupným. Multi-tenant softvér funguje presne takto. Jedna aplikácia obsluhuje mnoho zákazníkov — „nájomcov“ — a každý ju zažíva ako svoj vlastný súkromný priestor, hoci všetci bežia na rovnakom zdieľanom systéme pod tým.

Opačným prístupom je single-tenant: každý zákazník dostane vlastnú samostatnú kópiu softvéru, ako keby ste pre každého stavali úplne nový samostatný dom. Súkromnejšie, prispôsobiteľnejšie — a dramaticky drahšie na stavbu, prevádzku a aktualizáciu, pretože teraz udržiavate päťdesiat domov namiesto jednej budovy.

Takmer každý produkt, ktorý denne používate, je multi-tenant. Váš e-mail, váš účtovný nástroj, váš rezervačný systém, CRM, v ktorom žije váš obchodný tím. Vy a tisíc ďalších firiem zdieľate rovnaký základný softvér a nikto z vás nikdy nevidí toho druhého. Tá neviditeľnosť — to čisté oddelenie — je celé umenie multi-tenancy.

Prečo sa toto rozhodnutie dotýka celého vášho podnikania

Je lákavé zaradiť to pod „technický detail, ktorý rieši môj vývojár“. No model, ktorý si zvolíte, sa priamo premieta do častí podnikania, na ktorých vám záleží: do vášho mesačného účtu za hosting, do toho, ako rýchlo môžete dodať novú funkciu všetkým, čo môžete sľúbiť nervóznemu firemnému kupujúcemu a koľko škody môže napáchať jediná chyba.

Keď v dobre postavenom multi-tenant produkte opravíte chybu alebo vydáte funkciu, každý zákazník ju dostane naraz, z jednej aktualizácie. Vo svete single-tenant by ste túto zmenu zavádzali do päťdesiatich samostatných inštalácií, z ktorých každá môže byť dnes už mierne iná. Jedno je utorkové popoludnie. To druhé je projekt. Vynásobte to rokmi aktualizácií a uvidíte, prečo SaaS priemysel stojí na multi-tenancy.

Druhou stranou je, že zdieľanie infraštruktúry zvyšuje stávku na oddelení. V bytovom dome môže porucha rozvodov ovplyvniť viac ako jeden byt. V multi-tenant softvéri chyba v tom, ako udržiavate nájomcov oddelene, neobťažuje len jedného zákazníka — môže odhaliť údaje všetkých naraz. To nie je dôvod vyhýbať sa multi-tenancy. Je to dôvod postaviť ju poriadne, s niekým, kto to už robil.

Tri spôsoby, ako udržať nájomcov oddelene

Keď sa vývojári hádajú o multi-tenancy, zvyčajne sa hádajú o tom, ako oddelené majú byť údaje každého nájomcu. Existujú tri bežné prístupy a nachádzajú sa na posuvnej stupnici od „maximálne zdieľanie, najnižšie náklady“ po „maximálne oddelenie, najvyššie náklady“. Nemusíte si vybrať sami — ale mali by ste rozumieť kompromisu, ktorý váš vývojár robí vo vašom mene.

1. Zdieľaná databáza, zdieľané tabuľky

Údaje všetkých žijú v rovnakej databáze, v rovnakých tabuľkách, so skrytým štítkom — „tenant ID“ — ktorý označuje, ktoré riadky komu patria. Softvér je zodpovedný za to, aby vždy filtroval podľa tohto štítka, takže zákazník A vidí vždy len riadky zákazníka A. Toto je najlacnejší a najškálovateľnejší model, ten, ktorý používa väčšina skorých SaaS produktov. Háčik: oddelenie žije v kóde, takže jediný zabudnutý filter je spôsobom, ako údaje uniknú. Vyžaduje si dôsledné, disciplinované inžinierstvo.

2. Zdieľaná databáza, oddelené priehradky

Jedna databáza, ale každý nájomca dostane vlastnú ohradenú sekciu vo vnútri (vývojári ich nazývajú „schémy“). Silnejšie oddelenie ako prvý model, stále primerane efektívne, a ľahšie napríklad čisto exportovať alebo zmazať údaje jedného zákazníka. Kompromisom je viac pohyblivých častí na správu, keď narastiete do stoviek a tisícov nájomcov.

3. Samostatná databáza pre každého nájomcu

Každý zákazník dostane vlastnú vyhradenú databázu — to najbližšie k tomu, že mu dáte súkromný dom a pritom stále zdieľate aplikáciu. Toto je najsilnejšia izolácia a najľahší príbeh, ktorý možno povedať firemnému kupujúcemu citlivému na bezpečnosť. Je tiež najdrahšia na prevádzku a správu, takže býva vyhradená pre zákazníkov vysokej hodnoty, regulované odvetvia alebo produkty, kde by zámena údajov bola katastrofálna.

Časť, ktorú nesmiete pokaziť: izolácia

Ak existuje jedno miesto, na ktoré sa oplatí minúť vaše obavy, je to tu. Izolácia nájomcov je záruka, že zákazník A nikdy, za žiadnych okolností, nemôže vidieť, upraviť ani len vytušiť existenciu údajov zákazníka B. Znie to samozrejme. Je to však aj najčastejší zdroj vážnych chýb v multi-tenant produktoch, pretože zlyhanie je tiché — všetko vyzerá v poriadku až do dňa, keď niekto otvorí výkaz a uvidí v ňom zákazníkov cudzieho človeka.

Dôvod, prečo sa to deje, je štrukturálny. V najlacnejšom modeli si každá jednotlivá požiadavka na databázu musí pamätať filtrovať podľa nájomcu. Urobte to správne desaťtisíckrát a raz nesprávne, a máte únik. Preto sa skúsené tímy nespoliehajú na to, že si to vývojári zapamätajú — izoláciu zabudujú do základu, takže zabudnutie sa stáva nemožným, nielen len nepravdepodobným. Nemusíte rozumieť tomu, ako to robia. Musíte sa opýtať, či to robia.

Existuje aj tichší príbuzný tohto problému: „hlučný sused“. Keďže nájomcovia zdieľajú infraštruktúru, jeden zákazník robiaci niečo náročné — obrovský import, divoký výkaz — môže spomaliť systém pre všetkých ostatných, rovnako ako jeden byt s otvorenými všetkými kohútikmi môže zhodiť tlak vody v celej budove. Dobrý multi-tenant návrh s tým ráta limitmi a spravodlivým zdieľaním. Oplatí sa opýtať, najmä ak očakávate niekoľko veľmi veľkých zákazníkov.

Kedy je single-tenant naozaj správnou voľbou

Multi-tenancy je predvolenou voľbou pre SaaS, ale nie je to náboženstvo. Existujú čestné dôvody dať zákazníkovi vlastnú samostatnú kópiu a dobrý poradca vám povie, keď ste na taký narazili, namiesto toho, aby všetko nasilu tlačil do zdieľaného modelu.

• Zákazník v regulovanom odvetví — zdravotníctvo, financie, štátna správa — ktorého pravidlá súladu fakticky vyžadujú, aby jeho údaje žili niekde preukázateľne oddelene.
• Jeden veľký klient platiaci dosť na to, aby sa vyhradené nastavenie oplatilo, a ktorý chce hlboké prispôsobenie, ktoré nechcete, aby presakovalo do skúsenosti všetkých ostatných.
• Údaje natoľko citlivé, že náklady na únik medzi nájomcami by ukončili podnikanie, vďaka čomu sa maximálna izolácia oplatí napriek dodatočným nákladom.
• Požiadavka on-premise, kde softvér musí bežať vo vnútri múrov samotného zákazníka, nie vo vašom cloude.

Všimnite si vzor: single-tenant je výnimka, po ktorej zámerne siahnete, zvyčajne pre konkrétneho zákazníka vysokej hodnoty, nie predvolená voľba, na ktorej staviate celé podnikanie. Ak vývojár navrhuje single-tenant pre váš štandardný produkt od prvého dňa, požiadajte ho, aby vám vysvetlil prečo — zvyčajne to znamená oveľa vyššie prevádzkové náklady a pomalšie aktualizácie, a vy chcete, aby to bola voľba, nie nehoda.

Otázky, ktoré si treba položiť skôr, než niekto napíše kód

Nemusíte navrhovať architektúru. Musíte sa uistiť, že osoba, ktorá ju navrhuje, premyslela tie správne veci. Tu je krátky zoznam, ktorý by som chcel, aby si netechnický zakladateľ priniesol na ten prvý rozhovor — vytlačte si ho, opýtajte sa, sledujte, ako sebavedome sa naň odpovedá.

1. 1
   Ako udržíte údaje nájomcov oddelene?

   Počúvate štrukturálnu odpoveď — systém to presadzuje — nie „budeme opatrní“. Toto je nediskutovateľná otázka.
2. 2
   Ktorý model používame a prečo?

   Zdieľané tabuľky, oddelené priehradky alebo databáza pre každého nájomcu. Niet zlej odpovede, ale mal by existovať dôvod, ktorý sedí vašim zákazníkom a rozpočtu.
3. 3
   Môžeme veľkému klientovi neskôr ponúknuť vyhradenú izoláciu?

   Aj keď začnete plne zdieľane, návrh by mal nechať priestor dať jednému veľkému alebo regulovanému zákazníkovi silnejšie oddelenie bez prestavby.
4. 4
   Čo sa stane, keď jeden zákazník narastie do obrovských rozmerov?

   Ako systém zabráni tomu, aby jeden náročný nájomca spomaľoval všetkých ostatných? Chcete počuť, že scenáre hlučného suseda boli zvážené.
5. 5
   Ako čisto exportujeme alebo zmažeme údaje jedného zákazníka?

   Zákazníci odchádzajú a zákon o ochrane súkromia vyžaduje, aby ste ich údaje na požiadanie odstránili. Malo by to byť jednoduchá, dobre zvládnutá operácia, nie panika.

Nehodnotíte technický detail odpovedí. Kontrolujete, či žiadna z týchto otázok nedopadne ako prekvapenie. Tím, ktorý už multi-tenant softvér staval, bude mať na všetkých päť ostré, takmer znudené odpovede. Zaváhanie pri prvej alebo tretej je signálom spomaliť a pohrabať sa hlbšie.

Krátky, životný príklad

Prišiel k nám zakladateľ s fungujúcim prototypom nástroja na objednávanie termínov určeného pre malé kliniky. Už mal troch platiacich zákazníkov — a tichý problém. Aby sa rýchlo dostal na trh, prvý vývojár dal každej klinike vlastnú samostatnú kópiu aplikácie. Traja zákazníci, tri inštalácie, tri mierne odlišné verzie, pretože každá si cestou vyžiadala malú úpravu.

Pri troch to fungovalo nádherne. Nočnou morou zakladateľa bola predstava tridsiatich. Každá oprava chyby znamenala prihlásenie sa na tri miesta. Každá nová funkcia znamenala tri nasadenia a tri veci na otestovanie. Nová klinika si vyžadovala takmer celý týždeň na ručné nastavenie. Model, ktorý ich dostal k spusteniu, bol teraz tým, čo obmedzovalo ich rast — presne ten problém základu, o ktorom je celý tento článok.

Nevytrhli sme všetko v dramatickom prepisovaní. Jadro sme prestavali na zdieľaný multi-tenant základ s izoláciou presadzovanou na úrovni systému, prispôsobenia jednotlivých kliník sme zachovali ako konfigurovateľné nastavenia namiesto samostatných kódových základní a tri existujúce kliniky sme presunuli jednu po druhej, súbežne, aby nikto nemal strašidelný deň prepnutia. Zavedenie novej kliniky prešlo z týždňa ručnej práce na samoobslužnú registráciu. Nové funkcie sa teraz dostávajú ku každému zákazníkovi z jediného vydania.

Čísla tu sú ilustratívne, nie sľub — každý produkt je iný — ale tvar je typický: prestavba stála skutočné peniaze a pár mesiacov, a vrátila sa už v rámci prvej hŕstky nových zákazníkov, ktorých zrazu mohli zaviesť bez toho, aby pohli prstom. Ponaučenie, ktoré si zakladateľ odniesol, bolo to lacnejšie: keby si na začiatku položili tých päť otázok, nebolo by čo prestavovať.

Časté otázky