ჩრდილებისა და ლიმიტების იზოლაცია

ჩრდილებისა და ლიმიტების იზოლაცია არის მრავალ-ტენანტური არქიტექტურის საფუძველი. მიზანი: ისე, რომ ერთი მოიჯარის ქმედებები არასოდეს იმოქმედოს სხვის მონაცემებზე, უსაფრთხოებაზე და SLO- ზე, ხოლო რესურსები განაწილებულია სამართლიანად და პროგნოზირებად. ქვემოთ მოცემულია გადაწყვეტილებების პრაქტიკული რუკა მონაცემთა დონიდან გამოთვლების დაგეგმვამდე და ინციდენტის მენეჯმენტამდე.

1) მუქარისა და მიზნის მოდელი

მუქარა

მონაცემთა გაჟონვა მოიჯარეებს შორის (ლოგიკური/ქეში/ლოგიკის საშუალებით).
„Noisy neighbor“: შესრულების დეგრადაცია ერთი კლიენტის ადიდების გამო.
პრივილეგიების ესკალაცია (შეცდომა დაშვების პოლიტიკაში).
ბილინგ დრიფტი (შეუსაბამობა გამოყენებისა და დარიცხვის შესახებ).
კასკადის წინააღმდეგი სცენარები (ინციდენტი ერთია, რაც იწვევს ბევრს დაშლას).

მიზნები

მონაცემთა და საიდუმლოების მკაცრი იზოლაცია.
პერ-ჩრდილოვანი ლიმიტები/კვოტები და სამართლიანი დაგეგმვა.
გამჭვირვალე აუდიტი, დაკვირვება და ბილინგი.
ინციდენტების ლოკალიზაცია და პერ ტენანტის სწრაფი აღდგენა.

2) იზოლაციის დონე (მოდელის გავლა)

1. მონაცემები

'tenant _ id' კლავიშებსა და ინდექსებში, Row-Level Security (RLS).
დაშიფვრა: KMS იერარქია - მოიჯარის გასაღები (KEK) - მონაცემთა გასაღებები (DEK).
ცალკეული სქემები/მაღალი მოთხოვნების მქონე BD (Silo), მთლიანი მტევანი c RLS ეფექტურობისთვის (აუზი).
პოლიტიკოსები ჭრიან და „დავიწყების უფლება“ per tenant, crypto-shredding გასაღებები.

2. გამოთვლები

კვოტები CPU/RAM/IO, მძღოლების პაკეტები ტენანტზე, „შეჩერებული“ ხაზები.
იზოლაცია GC/heap (კონტეინერები/პარამეტრები JVM/Runtime), parallelism ლიმიტები.
Per-tenant autoscaling + backpressure.

3. ქსელი

სეგმენტი: პირადი endpoints/VPC, ACL 'tenant _ id'.
საზღვარზე შეზღუდვა და წინსვლის კავშირი.
DDoS/ბოტებისგან დაცვა გეგმის/პრიორიტეტის გათვალისწინებით.

4. ოპერაციები და პროცესები

Parendator მიგრაცია, bacaps, DR, feature-flags.
ინციდენტები - „მიკრო ბლასტის სხივი“: ფუზინგი 'tenant _ id'.

3) გამქირავებლის წვდომისა და კონტექსტის კონტროლი

AuthN: OIDC/SAML; ნიშნები ატარებს 'tenant _ id', 'org _ id', 'plan', 'scopes'.
AuthZ: RBAC/ABAC (როლები + პროექტის, განყოფილების, რეგიონის ატრიბუტები).
კონტექსტი საზღვარზე: API კარიბჭე ამოიღებს და უხელმძღვანელებს ტენანტის კონტექსტს, ავსებს ლიმიტებს/კვოტებს, წერს ტრეისებში.
„ორმაგი საკეტის“ პრინციპი: შემოწმება სერვისში + RLS/BD პოლიტიკაში.

4) მონაცემები: სქემები, ქეში, ლოგოები

• Shared-schema (row-level): მაქსიმალური ეფექტურობა, მკაცრი RLS სავალდებულოა.
• Per-schema: იზოლაციის/ოპერაციების კომპრომისი.
• Per-DB/cluster (Silo): VIP/რეგულირებადი.

ქეში: გასაღების პრეფიქსი 'tenant: {id}:...', TTL გეგმების მიხედვით, დაცვა cache-stampede (lock/early refresh).

ლოგები/მეტამონაცემები: სრული ფსევდონიზაცია PII, ფილტრები 'tenant _ id', სხვადასხვა მოიჯარეების ლოგოების „წებოვანი“ აკრძალვა.

5) ტრეფიკისა და ოპერაციების შეზღუდვა

ძირითადი მექანიკა

Token Bucket: გაბრტყელებული აურზაური, პარამეტრიზაცია 'rate '/' burst'.
Leaky Bucket: throughput სტაბილიზაცია.
Fixed Window/Sliding Window: მარტივი/ზუსტი კვოტები დროის ფანჯრის გასწვრივ.
Concurrency limits: caps ერთდროული თხოვნებისთვის/ჯობებისთვის.

სად გამოვიყენოთ

საზღვარზე (L7/API კარიბჭე) არის მთავარი დაცვა და „სწრაფი უარი“.
ბირთვში (სერვისებში/რიგებში) - მეორე წრისთვის და „სამართლიანი პაკეტისთვის“.

პოლიტიკა

ტენანტის/გეგმის/ენდპოინტუს/ოპერაციის ტიპის მიხედვით (საზოგადოებრივი API, მძიმე ექსპორტები, ადმინისტრაციული მოქმედებები).
Priority: VIP იღებს უფრო დიდ 'burst- ს და წონას არბიტრაჟში.
Idempotence-keys უსაფრთხო ჭიდაობისთვის.

პროფილების მაგალითი (ცნებები)

Starter: 50 req/s, burst 100, 2 პარალელური ექსპორტი.
ბიზნესი: 200 req/s, burst 400, 5 ექსპორტი.
Enterprise/VIP: 1000 req/s, burst 2000, გამოყოფილი ვორკერები.

6) კვოტები და სამართლიანი დაგეგმვა

რესურსების კვოტები: საცავი, ობიექტები, შეტყობინებები/წუთები, დავალებები/საათი, რიგების ზომა.
შაბათ Fair Queuing/Deficit Round Robin: „შეჩერებული“ წვდომა საერთო მძღოლებზე.
Per-tenant worker pools: მკაცრი იზოლაცია ხმაურიანი/კრიტიკული მომხმარებლებისთვის.
ადმისიის კონტროლი: უკმარისობა/დეგრადაცია, სანამ კვოტები ამოწურულია.
Backoff + jitter: ექსპონენციალური შეფერხებები ისე, რომ არ მოხდეს ადიდების სინქრონიზაცია.

7) დაკვირვება და ბილინგი per tenant

სავალდებულო ჭდეები: 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: p95/p99 latency, error rate, availability, utilization, saturation.
Usage მეტრიკა: ოპერაციების მრიცხველები/ბაიტი/CPU წამები - აგრეგატორი - ინვოისი.
ბილინგის იდემპოტენტობა: საზღვარზე სნაიპშოტები, ორმაგი ჩამოწერისგან დაცვა/მოვლენების დაკარგვა.
დაშბორდები სეგმენტებით: VIP/რეგულირებული/ახალი მოიჯარეები.

8) ინციდენტები, დეგრადაცია და DR „მოიჯარეებისთვის“

'tenant _ id' ფუზინგი: კონკრეტული მოიჯარის გადაუდებელი გამორთვა/trotling დანარჩენზე გავლენის გარეშე.
Graceful Degradation: read-only რეჟიმი, რიგები „ქვიშის ყუთში“, გადავადებული დავალებები.
RTO/RPO per tenant: თითოეული გეგმისთვის აღდგენისა და ზარალის მიზნობრივი მნიშვნელობები.
სავარჯიშოები: რეგულარული „თამაშის დღეები“ ხმაურიანი მოიჯარის გამორთვით და DR- ის შემოწმებით.

9) მოთხოვნებთან შესაბამისობა (კონფიდენციალურობა, კონფიდენციალურობა)

რეგიონში ტენიანობის პინინგი; ჯვარედინი რეგიონალური ნაკადების მკაფიო წესები.
კლავიშებზე/მონაცემებზე წვდომის აუდიტი, ადმინისტრაციული ოპერაციების ჟურნალისტიკა.
Per tenant მონაცემთა მენეჯმენტი და ექსპორტია.

10) მინი რეფერენდუმი: როგორ შევიკრიბოთ ერთად

მოთხოვნის ნაკადი

1. Edge (API კარიბჭე): TLS- ს შეუძლია ამოიღოს 'tenant _ id' - ნიშნის შესაბამისობა, რომ გამოიყენოს rate/üttas და დააყენოს მისაბმელები.
2. პოლისის ძრავა: კონტექსტი 'tenant _ id/plan/features' - გადაწყვეტილება მარშრუტისა და შეზღუდვების შესახებ.
3. მომსახურება: უფლებების შემოწმება + 'tenant _ id' - მუშაობა მონაცემთა ბაზასთან RLS- ით - ქეში პრეფიქსი.
4. Usage კოლექცია: ოპერაციების/ბაიტის მრიცხველები - აგრეგატორი - ბილინგი.

მონაცემები

სქემა/BD სტრატეგიის შესახებ (row-level/per-schema/per-DB).
KMS: ქირაობის გასაღებები, როტაცია, კრიპტო-ნაკადი მოხსნის დროს.

გამოთვლები

ხაზები სასწორით, per tenant warkers, caps concurrency.
Autoscaling per-tenant მეტრებში.

11) ფსევდო პოლიტიკა (ორიენტაციისთვის)

yaml limits:
starter:
req_per_sec: 50 burst: 100 concurrency: 20 exports_parallel: 2 business:
req_per_sec: 200 burst: 400 concurrency: 100 exports_parallel: 5 enterprise:
req_per_sec: 1000 burst: 2000 concurrency: 500 exports_parallel: 20

quotas:
objects_max: { starter: 1_000_000, business: 20_000_000, enterprise: 100_000_000 }
storage_gb: { starter: 100,   business: 1000,    enterprise: 10000 }

12) ჩეკის სია გაყიდვამდე

• ჭეშმარიტების ერთი წყარო „tenant _ id“; ყველგან იჭერს და იჭერს.
• RLS/ACL შედის BD + მომსახურების შემოწმების დონეზე (ორმაგი საკეტი).
• დაშიფვრის ღილაკები per tenant, დოკუმენტირებული როტაცია/მოცილება (crypto-shredding).
• ლიმიტები/კვოტები საზღვარზე და შიგნით; ტესტირება და „ბურსტი“.
• Fair-queuing და/ან გამოყოფილი ვორკერები VIP- სთვის; caps на concurrency.
• პერ-ჩრდილოვანი SLO და ალერტები; დაშბორდები სეგმენტებზე.
• მომხმარებელთა კოლექცია იდემპოტენტურია; შემოწმებულია ბილინგის შემცირება.
• DR/ინციდენტები ლოკალიზებულია მოიჯარეზე; 'tenant _ id' ფუზინგი მუშაობს.
• კეში/ლოგები იყოფა მოიჯარეებად; PII შენიღბულია.
• მიგრაციის/ხელყუმბარების/ექსპორტის პროცედურები - პრიორიტეტული.

13) ტიპიური შეცდომები

RLS გამორთულია/გვერდის ავლით „ოფიციალური“ მომხმარებლის მიერ - გაჟონვის რისკი.
ერთი გლობალური ლიმიტი არის „neisy neighbor“ და SLO დარღვევა.
ზოგადი ქეში/ხაზები პრეფიქსების გარეშე, მონაცემების გადაკვეთა.
ბილინგი თვლის ლოგებს, რომლებიც მწვერვალებზე კარგავენ.
Poarendator Fusing- ის არარსებობა კასკადის ვარდნაა.
მიგრაცია „ერთი ბეწვით“ პრობლემური 'tenant _ id' შეფერხების გარეშე.

14) სტრატეგიის სწრაფი შერჩევა

რეგულირებული/VIP: Silo მონაცემები (per-DB), გამოყოფილი ვორკერები, მკაცრი კვოტები და რეპრესიები.
მასობრივი SaaS: Shared-schema + RLS, ძლიერი საზღვრები საზღვარზე, შიგნით სამართლიანი.
დატვირთვა „ხმაურიანი/პულსირებადი“: დიდი 'burst' + მკაცრი currency-caps, backpressure და გეგმების პრიორიტეტები.

დასკვნა

ჩრდილებისა და ლიმიტების იზოლაცია საზღვრებსა და სამართლიანობას ეხება. მკაფიო 'tenant _ id' დასტის საშუალებით, RLS და მონაცემთა დაშიფვრა, საზღვარზე და კვოტებზე შეზღუდვა და კვოტები, სამართლიანი დამგეგმავი, დაკვირვება და ინციდენტების ლოკალიზაცია - ეს ყველაფერი ერთად იძლევა უსაფრთხოებას, პროგნოზირებულ ხარისხს და გამჭვირვალე ბილინგს თითოეული მოიჯარეისთვის, თუნდაც პლატფორმის აგრესიული ზრდით.