Multitenancy në SaaS: silo, pool apo bridge — dhe rruga mes tyre

Vendimi më i shtrenjtë që merrni para klientit të parë

Në një platformë SaaS, modeli i tenancy është pika ku kryqëzohen ekonomia e njësisë, siguria dhe shpejtësia e inxhinierisë. Ai përcakton sa ju kushton çdo klient i ri, sa larg përhapet një incident, çfarë mund t'i premtoni me besueshmëri një auditori dhe sa i dhimbshëm do të jetë çdo migrim i ardhshëm. Ekipet shpenzojnë rëndom javë të tëra për të zgjedhur framework-un e frontend-it dhe një pasdite për modelin e tenancy. Raporti duhet përmbysur: framework-u zëvendësohet, modeli i tenancy ngurtësohet.

Hapësirën e mbulojnë tre modele kanonike — silo, pool dhe bridge — dhe asnjëri nuk është thjesht më i miri. Secili është një pikë në një spektër që e këmben izolimin me koston operacionale. Pyetja e dobishme nuk është cili model është i saktë, por cilat kompromise mund t'i përballojë biznesi juaj në fazën aktuale — dhe sa do të kushtojë ta ndryshoni mendjen më vonë.

Silo, pool, bridge — kompromiset reale

Dallimi mes tre modeleve qëndron te ajo që ndajnë dhe ajo që dedikojnë — dhe mënyra si dështon secili rrjedh drejtpërdrejt nga kjo zgjedhje.

• Silo — çdo qiramarrës (tenant) merr burime të dedikuara, zakonisht një bazë të dhënash dhe shpesh edhe compute. Izolimi më i fortë dhe rruga më e thjeshtë drejt përputhshmërisë, por me një dysheme fikse kostoje për qiramarrës dhe me një problem flote: dyqind qiramarrës do të thotë dyqind baza të dhënash për t'u migruar, ruajtur, përditësuar dhe monitoruar.
• Pool — të gjithë qiramarrësit ndajnë të njëjtën infrastrukturë, të ndarë me një tenant_id. Kostoja marxhinale për qiramarrës i afrohet zeros dhe operimi mbetet i njësuar, por izolimi bëhet përgjegjësi e aplikacionit dhe një query e keqe mund t'i degradojë të gjithë njëherësh.
• Bridge — compute i përbashkët mbi të dhëna të ndara (skemë ose bazë të dhënash për qiramarrës), ose një flotë me nivele: infrastrukturë pool për planin standard dhe silo të dedikuara për qiramarrësit enterprise ose ata të rregulluar.

Për produktet B2B, parazgjedhja jonë është modeli pool pas një abstraksioni strikt tenancy, me silo-n të ofruar si nivel premium me çmim — jo të adoptuar si refleks. Infrastruktura e dedikuar që nuk e paguan askush nuk është arkitekturë; është subvencion.

Izolimi është mbrojtje shumështresore, jo një klauzolë WHERE

Një kolonë tenant_id plus disiplina e zhvilluesve nuk përbën strategji izolimi; mjafton një filtër i vetëm i harruar që të përfundoni në një njoftim për shkelje të të dhënave. Izolimi duhet të qëndrojë edhe kur zhvilluesi gabon — pra duhet zbatuar në disa shtresa të pavarura.

• Zgjidheni kontekstin e qiramarrësit një herë të vetme në hyrje — nga subdomain-i, token-i ose header-i — dhe përcilleni nëpër çdo kërkesë, job dhe event; asgjë më poshtë nuk duhet ta rinxjerrë vetë.
• Bëjini query-t ndër-qiramarrës të pamundura për t'u shkruar aksidentalisht: repository ose query builder që e kërkojnë kontekstin e qiramarrësit që në ndërtim, jo me konventë.
• Aktivizoni row-level security në bazën e të dhënave si mburojë të fundit: një filtër i harruar e dështon query-n, nuk e rrjedh dataset-in.
• Enkriptoni fushat e rregulluara me çelësa për qiramarrës, që offboarding-u dhe kërkesat për fshirje të bëhen operacione çelësash, jo skanime tabelash.
• Mbani një suitë testesh të automatizuara për akses ndër-qiramarrës dhe çdo dështim aty trajtojeni si incident sigurie, jo si bug i radhës.

Noisy neighbor: problem drejtësie, jo kapaciteti

Në modelin pool kapaciteti është i përbashkët, dhe pa rregulla eksplicite drejtësie qiramarrësi më i madh ua cakton latencën gjithë të tjerëve. Të shtosh harduer vetëm sa e ngre tavanin e një planifikuesi të padrejtë. Fillimisht duhet atribuimi: mateni konsumin për qiramarrës që nga dita e parë, sepse një grusht qiramarrësish do të gjenerojë pjesën më të madhe të ngarkesës — dhe nuk mund të qeverisësh atë që nuk e atribuon.

• Vendosni rate limits dhe kuota për qiramarrës në shtresën API dhe përfshijini në çmimet e planeve, që kufijtë të jenë levë komerciale, jo justifikim.
• Kufizoni paralelizmin për qiramarrës në radhët e job-eve në sfond — importi masiv i njërit nuk duhet t'i vonojë kurrë webhook-ët e tjetrit.
• Caktoni statement timeouts dhe drejtojini query-t analitike te replikat; rruga transaksionale nuk është vend për raportim.
• Në shkallë flote, arkitektura me qeliza (cell-based) dhe shuffle sharding e kufizojnë rrezen e dëmit si nga mbingarkesa, ashtu edhe nga defektet e deployment-it.

Observability që e njeh qiramarrësin

Pyetja e parë në çdo incident SaaS është: kush po preket? Nëse telemetria juaj nuk përgjigjet dot brenda sekondash, keni dashboard-e, jo observability. Bëjeni identitetin e qiramarrësit dimension qendror në logje, trace dhe metrika — me kardinalitetin të trajtuar me vetëdije: besnikëri e plotë në logje e trace, top-N plus seri të agreguara në metrika.

Përcaktoni SLO për qiramarrës të paktën për nivelin tuaj më të lartë dhe mateni konsumin vazhdimisht. Të njëjtat të dhëna u përgjigjen pyetjeve të suportit brenda minutash, ushqejnë çmimet sipas përdorimit dhe nxjerrin në pah klientët të cilëve në heshtje po u shërbeni me humbje.

Projektojeni migrimin para se t'ju duhet

Me cilindo model që të nisni, një qiramarrës do të duhet të lëvizë një ditë: një kontratë enterprise do të kërkojë silo, ose një flotë silosh do të bëhet tepër e shtrenjtë për t'u operuar. Rruga e migrimit është pjesë e arkitekturës, jo mendim i mëvonshëm.

• Mbajeni tenant_id në çdo rresht edhe në bazat silo — konsolidimi i të dhënave pa të është arkeologji.
• Mbajini skemat identike ndër silo; devijimi i skemave e kthen migrimin në rishkrim pa e vënë re njeri.
• Kalojini qiramarrësit përmes një abstraksioni të qëndrueshëm që e lidh secilin me vendndodhjen e të dhënave të veta, në mënyrë që kjo vendndodhje të ndryshojë pa prekur aplikacionin.
• Provojeni lëvizjen paraprakisht: eksport vetëm i të dhënave të qiramarrësit, kalim me replikim, një dritare e shkurtër dual-write dhe rollback i verifikuar.

Modeli me të cilin nisni nuk do të jetë modeli me të cilin do të mbaroni. Detyra e arkitekturës është ta bëjë atë ndryshim projekt të planifikuar, jo emergjencë të gjithë kompanisë.