Multi-tenant SaaS ճարտարապետություն

01Tenancy-ի երեք մոդել

Պատկերացրեք գրասենյակային շենք։ Ընդհանուր սխեման open-space հարկ է. բոլոր tenant-ների տողերը նույն աղյուսակներում են՝ բաժանված tenant_id սյունակով։ Այն ամենաէժանն ու ամենապարզն է շահագործման համար՝ մեկ միգրացիա բոլորի համար և հեշտ cross-tenant անալիտիկա, բայց մեկուսացումն ամբողջությամբ կախված է նրանից, որ յուրաքանչյուր query ճիշտ scope ունենա։ Schema-per-tenant-ը առանձին սենյակներով հարկ է. յուրաքանչյուր tenant ստանում է իր աղյուսակների հավաքածուն նույն բազայում։ Մեկուսացումն ավելի ուժեղ է, և մեկ tenant-ի վերականգնումն ավելի հեշտ, բայց միգրացիաները պետք է անցնեն հարյուրավոր կամ հազարավոր սխեմաներով, իսկ connection pooling-ը բարդանում է։ Database-per-tenant-ը առանձին շենքեր են. ամենաուժեղ մեկուսացումը, ամեն tenant-ի համար առանձին performance tuning, տեղակայման վայր և գաղտնագրման բանալիներ, հեշտ ջնջում՝ ամենաբարձր շահագործման ծախսով։ Շատ պրոդուկտներ խառնում են դրանք. ընդհանուր սխեմա tenant-ների մեծ մասի համար և առանձին բազաներ խոշոր կամ կարգավորվող (regulated) հաճախորդների համար։

• Ընդհանուր սխեմա + tenant_id. ամենաէժանն է, մասշտաբավորվում է շատ փոքր tenant-ների համար, մեկուսացումը՝ կոդով և RLS-ով։
• Սխեմա յուրաքանչյուր tenant-ի համար. միջին տարբերակ. հիմնական ցավը միգրացիաների տարածումն է բոլոր սխեմաներով։
• Բազա յուրաքանչյուր tenant-ի համար. ամենաուժեղ մեկուսացումը և data residency. ամենաբարձր ծախսն ու ops բեռը։

02Մեկուսացման ապահովումը շերտերով

Մեկուսացումը երբեք չպետք է հենվի այն բանի վրա, որ ծրագրավորողը կհիշի WHERE պայմանը։ Tenant-ը որոշեք մեկ անգամ յուրաքանչյուր request-ի համար վստահելի աղբյուրից (authenticated token, API key կամ subdomain), երբեք body-ի դաշտից, որը կլիենտն է վերահսկում։ Պահեք այն request context-ում և ստիպեք տվյալների շերտին կիրառել այն. repository base class, ORM extension կամ global scope, որը ավելացնում է tenant ֆիլտրը և exception է նետում, եթե այն բացակայում է։ Ավելացրեք երկրորդ, անկախ շերտ բազայում՝ PostgreSQL row-level security-ով, որպեսզի նույնիսկ մոռացված ֆիլտրը ոչինչ չվերադարձնի։ Ուրիշ tenant-ի ID-ի համար լռելյայն պատասխանը թող լինի 404, ոչ թե 403, որպեսզի հարձակվողները չկարողանան պարզել, թե որ ID-ներն են գոյություն ունենում։ Հետո ապացուցեք դա թեստերով. յուրաքանչյուր մոդուլ ստանում է «սխալ tenant» թեստ, որը փորձում է կարդալ և փոփոխել ուրիշ tenant-ի գրառումները և սպասում է ձախողման։

1ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
2ALTER TABLE orders FORCE ROW LEVEL SECURITY;
3 
4CREATE POLICY tenant_isolation ON orders
5  USING (tenant_id = current_setting('app.tenant_id', true)::uuid)
6  WITH CHECK (tenant_id = current_setting('app.tenant_id', true)::uuid);
7 
8-- Per request, inside a transaction, using a non-owner app role:
9BEGIN;
10SET LOCAL app.tenant_id = '00000000-0000-0000-0000-000000000001';
11SELECT id, total FROM orders;  -- only this tenant's rows
12COMMIT;

03Պլաններ, սահմանաչափեր և feature flag-եր

Tenant-ները վճարում են տարբեր բաների համար, ուստի իրավունքները (entitlements) մոդելավորեք բացահայտ։ Պլանը սահմանում է հնարավորություններ (մոդուլներ, օրինակ՝ loyalty կամ խոհանոցի էկրաններ) և սահմանաչափեր (մասնաճյուղեր, օգտատերեր, պահոց, API կանչեր րոպեում)։ Հնարավորությունները ստուգեք մեկ տեղում՝ policy-ում կամ guard-ում, այլ ոչ թե «if plan === pro» ցրեք ամբողջ կոդով։ Կոշտ սահմանաչափերը կիրառեք գրելու պահին (տասնմեկերորդ մասնաճյուղի ստեղծումը ձախողվում է հստակ հաղորդագրությամբ), իսկ փափուկները՝ զգուշացումներով և օգտագործման dashboard-ներով։ Feature flag-երը առանձին գործիք են. դրանք ֆունկցիոնալը աստիճանաբար միացնում են beta tenant-ների համար, թույլ են տալիս kill switch-եր և tenant-ին հատուկ override-ներ, որոնց շուրջ պայմանավորվել են վաճառքի ժամանակ։ Երկուսն էլ պահեք audit անելու հնարավորությամբ, որովհետև «ինչու՞ է այս tenant-ը կարողանում դա անել» հարցը support-ում անպայման կլսեք։ Օգտագործման ճշգրիտ հաշվառումը օգնում է նաև billing-ին, ուստի գրանցեք այն որպես event-ներ, այլ ոչ թե վերահաշվեք կենդանի աղյուսակներից։

04Tenant-ը հաշվի առնող cache, հերթեր և realtime

Յուրաքանչյուր ընդհանուր կոմպոնենտ մի տեղ է, որտեղ tenant-ները կարող են «արտահոսել» միմյանց մեջ։ Cache key-երը պետք է պարունակեն tenant ID-ն (tenant:42:menu:v3), այլապես մի սրճարանը կտեսնի մյուսի մենյուն։ Background job-երը պետք է իրենց payload-ում կրեն tenant ID-ն, և worker-ը պետք է վերականգնի tenant context-ը նախքան տվյալներին դիպչելը՝ ճիշտ այնպես, ինչպես request-ը։ Realtime ալիքները նույն ուշադրությունն են պահանջում. կլիենտներին բաժանորդագրեք room-ների՝ ըստ tenant-ի և մասնաճյուղի, և յուրաքանչյուր բաժանորդագրություն թույլատրեք սերվերում։ Ֆայլերը պահվում են object storage-ում tenant-ի prefix-ով ճանապարհներով և մատուցվում են կարճատև signed URL-ներով։ Լոգերն ու trace-երը պետք է պարունակեն tenant ID-ն, որպեսզի support-ը կարողանա ուսումնասիրել մեկ հաճախորդի խնդիրը՝ առանց բոլորին զննելու։ Եվ վերջապես, rate limit-երն ու հերթերի concurrency-ն պետք է լինեն ըստ tenant-ի, որպեսզի մի tenant-ի import-ը չկարողանա «սովամահ անել» մյուսներին։

• Cache-ի, պահոցի և ալիքների անունները միշտ ներառում են tenant-ը։
• Job-երը վերականգնում են tenant context-ը մինչև աշխատելը։
• Ըստ tenant-ի rate limit-եր և արդար հերթագրում «աղմկոտ հարևանների» դեմ։

05«Աղմկոտ հարևաններ», տվյալների արտահանում և ջնջում

Ընդհանուր համակարգում մի tenant, որը հսկայական report կամ import է աշխատեցնում, կարող է դանդաղեցնել բոլորին։ Պաշտպանեք մյուսներին ըստ tenant-ի rate limit-երով և քվոտաներով, query-ների statement timeout-ներով, ծանր job-երի համար առանձին հերթերով կամ concurrency սահմանափակումներով, և ծանր աշխատանքը պլանավորեք պիկային ժամերից դուրս։ Հետևեք ռեսուրսների օգտագործմանը ըստ tenant-ի, որպեսզի նկատեք շեղվողին, և անհրաժեշտության դեպքում շատ մեծ tenant-ներին տեղափոխեք առանձին ռեսուրսների վրա. սա պատճառներից մեկն է, որ տվյալների շերտը պետք է կարողանա tenant-ին ուղղել այլ բազա։ Tenant-ներն են նաև իրենց տվյալների տերը։ Առաջարկեք ամբողջական արտահանում փաստաթղթավորված ֆորմատներով (CSV, JSON), իսկ ջնջումն իրականացրեք որպես իրական գործընթաց. soft-delete որոշակի grace period-ով, հետո hard-delete բազայից, ֆայլերից, cache-երից և search index-ներից, իսկ backup-ները ժամկետանց են դառնում հայտնի ժամանակացույցով։ Փաստաթղթավորեք սա GDPR-ի տիպի հարցումների համար։

06Offline աշխատող կլիենտներ և սինխրոնացում

Վաճառքի կետի (POS) տերմինալները, դաշտային հավելվածներն ու kiosk-երը պետք է շարունակեն աշխատել, երբ ինտերնետն անջատվում է։ Պատտերնը հետևյալն է. կլիենտը կամ լոկալ hub-ը պահում է լոկալ բազա (հաճախ SQLite)՝ իրեն անհրաժեշտ տվյալներով, յուրաքանչյուր փոփոխություն գրանցում է որպես հրաման (command) եզակի ID-ով և կապը վերականգնվելիս այդ հրամաններն ուղարկում է սերվեր։ Սերվերը կիրառում է յուրաքանչյուր հրաման idempotent կերպով՝ կրկնօրինակները հեռացնելով ըստ command ID-ի և սարքի, ուստի անկայուն վերամիացումներից հետո կրկնակի փորձերը անվտանգ են։ Կոնֆլիկտների կանոնները որոշեք ըստ entity-ի. append-only գրառումները, օրինակ վաճառքները, հազվադեպ են կոնֆլիկտում. ընդհանուր գրառումները, օրինակ պաշարը կամ գները, պահանջում են հստակ տեր, «սերվերը հաղթում է» կանոններ կամ բացահայտ merge։ Լոկալ սխեման և միգրացիաները զգուշորեն version արեք, որովհետև սարքերը թարմացվում են տարբեր ժամանակներում։ Offline սարքին տվեք միայն այն իրավունքներն ու տվյալները, որոնք անհրաժեշտ են իր մասնաճյուղին, և օգտագործեք սարքին կապված token-ներ, որոնք կարելի է չեղարկել։

07Row-level security պրոդակշնում․ pooling, արտադրողականություն և դերեր

SET LOCAL-ը չի կարող ընդունել bind պարամետրեր, ուստի շատ հավելվածներ հրամանը կառուցում են որպես տող։ Ավելի անվտանգ տարբերակ է set_config('app.tenant_id', $1, true)-ը, որտեղ true-ն նշանակում է «լոկալ այս տրանզակցիայի համար»․ այն աշխատում է պարամետրերի և transaction-mode pooler-ների հետ։ Policy-ներում օգտագործիր current_setting-ի missing_ok տարբերակը, որպեսզի չսահմանված արժեքը տա NULL, որը ոչ մի տողի չի համապատասխանում, սխալի փոխարեն։ Արտադրողականություն․ policy-ները ամեն հարցմանը ավելացնում են պայման, ուստի tenant_id-ն դիր առաջինը կոմպոզիտ ինդեքսներում (tenant_id, created_at) և unique constraint-ներում (tenant_id, slug)։ Policy-ների ներսում կանչվող ֆունկցիաները պետք է լինեն պարզ և STABLE․ ամեն տողի համար բարդ subquery-ները դանդաղ են։ Օգտագործիր երեք դեր․ միգրացիաների դեր, որին պատկանում են աղյուսակները, հավելվածի դեր՝ առանց BYPASSRLS-ի, և առանձին, աուդիտվող սպասարկման դեր՝ իրական cross-tenant job-երի համար։

1-- Inside each request transaction (works with bind parameters and poolers)
2SELECT set_config('app.tenant_id', $1, true);
3 
4-- Indexes and constraints lead with the tenant
5CREATE INDEX orders_tenant_created_idx ON orders (tenant_id, created_at DESC);
6ALTER TABLE products ADD CONSTRAINT products_tenant_sku_key UNIQUE (tenant_id, sku);
7 
8-- App role cannot bypass policies
9CREATE ROLE app_rw LOGIN NOBYPASSRLS;
10GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_rw;

08Tenant-ների routing․ tenant directory, cell-եր և տեղաբաշխում

Պահիր tenant directory՝ փոքր, բարձր հասանելիությամբ աղյուսակ կամ ծառայություն, որը յուրաքանչյուր tenant քարտեզագրում է այնտեղ, որտեղ ապրում են նրա տվյալները․ ընդհանուր A կլաստեր, առանձին B տվյալների բազա, EU տարածաշրջան։ Ամեն հարցում որոշում է tenant-ին, հետո նրա տեղաբաշխումը և միանում ճիշտ pool-ին։ Այս մեկ միջնորդ շերտը հետագա տեղափոխումները դարձնում է հնարավոր․ մեծ tenant-ին միգրացիա արա իր սեփական տվյալների բազա՝ տվյալները պատճենելով, փոփոխությունները վերարտադրելով, գրառումները կարճ ժամանակով սառեցնելով և directory-ի գրառումը փոխելով։ Ավելի առաջ գնալով՝ cell-based ճարտարապետությունը գործարկում է մի քանի նույնական stack (հավելված, տվյալների բազա, քեշ, հերթեր), որոնցից յուրաքանչյուրը սպասարկում է tenant-ների ենթաբազմություն։ Այդ դեպքում վատ դեպլոյը կամ գերբեռնվածությունը ազդում է մեկ cell-ի, ոչ թե բոլոր հաճախորդների վրա, և փոփոխությունները թողարկում ես cell առ cell։ Գինը ավելի շատ ինֆրաստրուկտուրան և գործիքներն են cross-cell գործողությունների համար, օրինակ՝ գլոբալ ադմին որոնում և billing, ուստի պրոդուկտների մեծ մասը սկսում է մեկ cell-ով և directory-ով, որը պատրաստ է ավելիին։

09Միգրացիաներ և սխեմայի փոփոխություններ շատ tenant-ների համար

Ընդհանուր սխեմայում մեկ միգրացիան միանգամից դիպչում է բոլոր tenant-ների տվյալներին, ուստի այն պետք է լինի online․ սյունակներն ավելացրու nullable կամ հաստատուն default-ներով, ինդեքսները ստեղծիր CONCURRENTLY, backfill արա փոքր batch-երով, հետո constraint-ներն ավելացրու NOT VALID և վալիդացրու առանձին։ Երբեք րոպեներով lock մի արա զբաղված աղյուսակը։ Schema-per-tenant կամ database-per-tenant մոդելների դեպքում խնդիրը դառնում է fan-out․ հազարավոր միգրացիաներ, որոնք կարող են մասնակի ձախողվել։ Գործարկիր դրանք job runner-ով՝ յուրաքանչյուր tenant-ի կարգավիճակով, retry-ներով և զուգահեռության սահմաններով, թողարկման ընթացքում հավելվածը պահիր համատեղելի և՛ հին, և՛ նոր սխեմայի հետ (expand, migrate, contract), և դարձրու այնպես, որ կեսից կանգնեցնելն անվտանգ լինի։ Հետևիր սխեմայի տարբերակին յուրաքանչյուր tenant-ի համար և հրաժարվիր սպասարկել այն tenant-ին, որի տարբերակը գործող կոդը չի աջակցում։

• Նախ expand, դեպլոյ արա կոդ, որն աշխատում է երկուսի հետ էլ, contract՝ հետո։
• CREATE INDEX CONCURRENTLY և batch-երով backfill մեծ աղյուսակների համար։
• Միգրացիայի կարգավիճակ ըստ tenant-ի schema- կամ database-per-tenant կարգավորումներում։

10Offline sync-ի ներքին մեխանիզմները․ հերթականություն, ժամացույցներ և կոնֆլիկտներ

Սարքերի ժամացույցները շեղվում են, ուստի միայն wall-clock timestamp-ները չեն կարող դասավորել մի քանի սարքից եկող փոփոխությունները։ Տարածված մոտեցումներ․ թող սերվերը նշանակի մոնոտոն աճող հաջորդականության համար, երբ ընդունում է հրամանը, իսկ կլիենտները քաշեն «ամեն ինչ N համարից հետո», կամ օգտագործիր hybrid logical clock-եր, որոնք ֆիզիկական ժամանակը համադրում են counter-ի հետ՝ մնալով իրական ժամանակին մոտ և պահպանելով պատճառականությունը։ Կոնֆլիկտների համար յուրաքանչյուր դաշտի համար ընտրիր կանոն․ միայն ավելացվող իրադարձությունները երբեք չեն բախվում, last-writer-wins-ը պարզ է, բայց լուռ կորցնում է խմբագրումները, դաշտի մակարդակի merge-ը պահում է չհամընկնող փոփոխությունները, իսկ CRDT-ները ավտոմատ merge են անում counter-ների, բազմությունների և տեքստի համար՝ բարդության գնով։ Հրամանները պահիր փոքր և մտադրության վրա հիմնված («ավելացրու 2 միավոր 15 պատվերին»)՝ ամբողջ վիճակը վերագրելու փոխարեն, քանի որ դրանք շատ ավելի լավ են merge լինում։ Սահմանափակիր, թե սարքը որքան կարող է offline մնալ, մինչև պարտադիր ամբողջական resync։