Тенанттарды оқшаулау және лимиттер
Тенанттар мен лимиттерді оқшаулау - бұл мульти-тенанттық архитектураның іргетасы. Мақсаты: бір жалға алушының әрекеттері деректерге, қауіпсіздікке және SLO-ға ешқашан әсер етпеуі, ал ресурстар әділ және болжамды түрде бөлінуі. Төменде - деректер деңгейінен есептеулер мен инцидент-менеджментті жоспарлауға дейінгі шешімдердің практикалық картасы.
1) Қатерлер мен мақсаттар моделі
Қатерлер
Жалға алушылар арасында деректердің жылыстауы (логикалық/кэш бойынша/логтер арқылы).
«Noisy neighbor»: Бір клиенттің өнімділігінің бұзылуы.
Артықшылықтардың күшеюі (қол жеткізу саясатындағы қате).
Биллинг-дрифт (пайдалану мен есептеулердің сәйкессіздігі).
Каскадтық істен шығуға төзімді сценарийлер (біреудің инциденті көпшіліктің даунтаймына әкеледі).
Мақсаттар
Деректер мен құпияларды қатаң оқшаулау.
Пер-тенанттық лимиттер/квоталар және әділ жоспарлау.
Айқын аудит, бақылау және биллинг.
Инциденттерді оқшаулау және per tenant жылдам қалпына келтіру.
2) Оқшаулау деңгейлері (өтпелі модель)
1. Деректер
«tenant _ id» кілттер мен индекстерде, Row-Level Security (RLS).
Шифрлау: KMS иерархиясы → жалға алушы кілті (KEK) → деректер кілті (DEK).
Жоғары талаптар кезіндегі бөлек схемалар/БД (Silo), тиімділік үшін RLS-мен ортақ кластер (Pool).
Ретеншн саясаты және «ұмыту құқығы» per tenant, crypto-shredding кілттер.
2. Есептеу
CPU/RAM/IO квоталары, тенантқа воркер пулдары, «өлшенген» кезектер.
GC/heap оқшаулау (контейнерлер/JVM/Runtime баптаулары), parallelism лимиттері.
Per-tenant autoscaling + backpressure.
3. Желі
Сегментация: private endpoints/VPC, ACL бойынша 'tenant _ id'.
Шекарада rate limiting және per-tenant connection caps.
Жоспарды/басымдықты ескере отырып, DDoS/боттардан қорғау.
4. Операциялар мен процестер
Жалға алу бойынша көші-қон, бэкаптар, DR, feature-flags.
Инциденттер - «микро-бласт-радиус»: 'tenant _ id' бойынша фьюзинг.
3) Жалға алушының қолжетімділігі мен контекстін бақылау
AuthN: OIDC/SAML; 'tenant _ id', 'org _ id', 'plan', 'scopes' деп белгіленеді.
AuthZ: RBAC/ABAC (рөлдер + жобаның, бөлімнің, өңірдің атрибуттары).
Шекарадағы контекст: API-шлюз тенант контексін алады және валидациялайды, лимиттермен/квоталармен толықтырады, деп жазады трейстерге.
«Қос құлыптау» қағидаты: + RLS/БД саясатын тексеру.
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-шлюз) - негізгі қорғау және «тез істен шығу».
Өзекте (сервистерде/кезектерде) - екінші контур және «fair share» үшін.
Саясат
Операция теңге/жоспар/эндпойнт/түрі бойынша (жария API, ауыр экспорт, әкімшілік әрекеттер).
Priority-aware: VIP төрелік кезінде үлкен 'burst' және салмақ алады.
Қауіпсіз ретрациялар үшін idempotency-keys.
Бейіндер үлгісі (ұғымдар)
Starter: 50 req/s, burst 100, 2 параллель экспорт.
Business: 200 req/s, burst 400, 5 экспорт.
Enterprise/VIP: 1000 req/s, burst 2000, бөлінген воркерлер.
6) Квоталар және әділ жоспарлау (fairness)
Ресурстар бойынша квоталар: сақтау орны, объектілер, хабарламалар/мин, тапсырмалар/сағат, кезектердің мөлшері.
Weighted Fair Queuing/Deficit Round Robin: ортақ воркерлерге «салмақты» қатынау.
Per-tenant worker pools: шулы/сындарлы клиенттер үшін қатты оқшаулау.
Admission control: квоталар аяқталғанға дейін істен шығу/тозу.
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': авариялық өшіру/троттлинг нақты жалға алушының басқаларына әсер етпей.
Graceful Degradation: read-only режимі, «құмсалғыштағы» кезектер, кейінге қалдырылған тапсырмалар.
RTO/RPO per tenant: әрбір жоспар үшін қалпына келтіру мен шығындардың мақсатты мәндері.
Жаттығулар: тұрақты «game days» шулы жалға алушыны ажырату және DR тексерумен.
9) Талаптарға сәйкестігі (residency, жекешелендіру)
Пиннинг тенанта аймаққа; кросс-өңірлік ағындардың нақты ережелері.
Кілттерге/деректерге қол жеткізу аудиті, әкімшілік операцияларды журналдау.
per tenant деректерінің ретеншін және экспортын басқару.
10) Шағын референс: бірге қалай жинау керек
Сұрау ағыны
1. Edge (API-шлюз): TLS → алу 'tenant _ id' → токен валидациясы → қолдану rate/quotas → трейдер қою.
2. Қозғалтқыш полисі: 'tenant _ id/plan/features' контексті → бағыт және лимиттер туралы шешім.
3. Қызмет: құқықтарды тексеру + 'tenant _ id' → префиксі бар кэшпен жұмыс істеу.
4. Usage-жинау: операциялар/байт есептеуіштер → агрегатор → биллинг.
Деректер
Схема/Стратегия бойынша ДҚ (row-level/per-schema/per-DB).
KMS: жалға алушыға кілттер, ротация, жою кезінде crypto-shredding.
Есептеулер
Таразылары бар кезектер, concurrency бойынша per tenant, caps воркерлерінің пулдары.
Пертенантты метриктер бойынша Autoscaling.
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 қосылған.
- per tenant шифрлау кілттері, ротация/жою құжатталған (crypto-shredding).
- Шекарадағы және ішкі лимиттер/квоталар; жарылыстар мен «burst» сынақтан өткізілді.
- Fair-queuing және/немесе VIP үшін бөлінген воркерлер; caps на concurrency.
- Пер-тенантты SLO және алерталар; сегменттер бойынша дашбордтар.
- Usage-алым іспеттес; биллингпен мәліметтер тексерілді.
- DR/инциденттер жалға алушыға дейін оқшауланады; 'tenant _ id' бойынша фьюзинг пысықтайды.
- Кэш/логтар жалға алушылар бойынша бөлінген; PII бүркемеленген.
- Көші-қон/бэкап/экспорт рәсімдері - жалға алу бойынша.
13) Типтік қателер
RLS «қызметтік» пайдаланушымен ажыратылған/қоршалған - ағып кету қаупі.
Бірыңғай жаһандық лимитер → «noisy neighbor» және SLO бұзылуы.
Префикссіз жалпы кэштер/кезектер → деректерді қиып өту.
Биллинг шыңдалған кезде жоғалатын логтар бойынша есептейді.
Жалдау бойынша фьюзингтің болмауы - каскадтық құлдырау.
Проблемалық 'tenant _ id' тұрағының мүмкіндігінсіз «бір қалтамен» көші-қон.
14) Стратегияны жылдам таңдау
Реттелетін/VIP: Silo-деректер (per-DB), бөлінген воркерлер, қатаң квоталар және residency.
Жаппай SaaS: Shared-schema + RLS, шекарадағы күшті лимиттер, ішіндегі fair-queuing.
«Шу/пульс» жүктемесі: үлкен 'burst' + қатты concurrency-caps, backpressure және жоспарлар бойынша басымдықтар.
Қорытынды
Тенанттар мен лимиттерді оқшаулау - бұл шекара мен әділдік туралы. Нақты «tenant _ id» стек арқылы, RLS және деректерді шифрлау, шекарада және өзекте лимиттеу және квоталар, әділ жоспарлаушы, тосын оқиғаларды бақылау және оқшаулау - осының бәрі бірге, тіпті платформаның агрессивті өсуі кезінде де, әрбір жалға алушы үшін қауіпсіздікті, болжамды сапаны және мөлдір биллингті береді.