Мульти-тенантты ядро

Мульти-тенантты ядро - бұл кепілдендірілген оқшаулау, басқарылатын лимиттер және қауіпсіз кастомизация кезінде жалпы ресурстарда көптеген тәуелсіз клиенттерге (тенанттарға) қызмет көрсететін платформаның/өнімнің базалық қабаты. Жақсы жобаланған ядро TCO азайтады, онбордингті жылдамдатады, релиздерді жеңілдетеді және әрбір жалға алушы үшін болжамды сапаны қамтамасыз етеді.

1) Жалға алушының моделі және оқшаулау шекарасы

Анықтамалар

Тенант (Tenant/Org/Account): өз пайдаланушылары, деректері, саясаты және лимиттері бар логикалық ұйым.
Оқшаулау: бір жалға алушының екіншісінің деректеріне, өнімділігіне және қауіпсіздігіне әсерін болдырмау қабілеті.

Оқшаулау деңгейлері

1. Деректер: жеке ДБ/схемалар/кестелер, «жалға алушы кілтімен» шифрлау, 'tenant _ id' сүзгілері.
2. Есептеулер: CPU/RAM/IO квоталары, тенантқа арналған воркерлер пулы немесе «өлшенген» кезектер.
3. Желі: сегментация, жеке endpoints/VPN, жалға алушылар бойынша рұқсаттар тізімі.
4. Операциялар: көші-қон, бэкаптар, DR және «бір жалға алушыға» әсер ету шекаралары бар тосын оқиғалар.

Көп денелілік үлгілері

Silo (қатты оқшаулау): тенантқа жеке кластерлер/БД. Ең жоғары қауіпсіздік, жоғары баға.
Pool (жалпы ресурстар): логикалық оқшауланған жалпы инфрақұрылым; жақсы тиімділік, жоғары тәуекел «noisy neighbor».
Bridge/Hybrid: гибрид - VIP/реттелетін клиенттер үшін жалпы басқару жазықтығы + іріктеп «silo».

2) Жалға алу сұраныстарын сәйкестендіру және бағыттау

Жалға алушының рұқсаты (Tenant Resolution)

'https : //{ tenant} .example. com`

Жол бойынша: '/t/{ tenant }/... '

Тақырыбы бойынша: 'X-Tenant-Id', 'X-Org' (қолтаңбаны тексеру)

Токен бойынша: 'tenant _ id', 'org _ id', 'plan', 'scopes' таңбалары

Бағыттау

L7-шлюз (API-шлюз/Ingress) 'tenant _ id' шығарады, контексті байытады ('plan', лимиттер, өңір), трестерге/логтарға жазады.
Функционалдық сервистер «тек оқу үшін» контекстін қабылдайды; маршрут және лимиттер бойынша шешімдерді гейтвей/полис-қозғалтқыш қабылдайды.

3) Деректер мен схемалар: стратегиялар

Сақтау нұсқалары

Shared-schema, row-level: бір кесте жиынтығы, 'tenant _ id' өрісі, қатаң RLS (Row-Level Security).
Shared-DB, per-schema: бір ЖББЖ, тенантқа жеке схема; басқару мен оқшаулау арасындағы теңгерім.
Per-DB/cluster: тенантқа жеке БД/кластер; қымбат, егеменді талаптар үшін оңай.

Негізгі тәжірибелер

Барлық жерде 'tenant _ id' дегенді анық беру және оны құрамдас кілттерге/индекстерге қосу.
RLS/ДҚБЖ деңгейіндегі кіру саясаты + сервистік валидация «қос құлыппен».
Шифрлау: кілттердің иерархиясы (root KMS → key-envelope/тенант/объект/DEK).
Мұрағат/ретеншн және «ұмыту құқығы» жалға алушы деңгейіндегі саясаткерлермен басқарылады.

4) Параметрлер, фичтер және нұсқалар

Теңшелім баптаулары

'tenant _ config' кестесі/қоймасы (жоспар, квоталар, фича-жалаулар, локализация, SLA).
Конфигурацияның басымдықтары: дефолт → жоспар → тенант → қоршаған орта → пайдаланушы.
Қысқа TTL және оқиға бойынша мүгедектігі бар пішіндерді кешіктіру.

Фича-жалаулар және үйлесімділік

Нүктелі (per-tenant/per-cohort), канареялық домалақтау функцияларын қосу.
API нұсқалау: тұрақты келісімшарт + шекарадағы адаптерлер (back/forward-compatible форматтары).

5) Лимиттер, квоталар және биллинг

Тұтыну саясаты

Rate limiting: 'requests/sec' per tenant/route, жоспарлардың басымдықтарымен «токен-бакет».
Quotas: сақтау көлемі, нысандар саны, хабарламалар/мин, jobs/сағ.
Fairness: кезектердің «өлшенген кестесі» + VIP үшін воркерлерді оқшаулау.

Биллинг

«tenant _ id» (usage-метриктер) бойынша есептеуіштер → агрегаторлар → инвойс.
Шекарадағы usage снапшоттары (теңсіздік және оқиғаларды жоғалтудан қорғау).
Модельдері: бекітілген жоспар + қайта consumption, пост-пей/пре-пей, «tiered» жеңілдіктері.

6) Қауіпсіздік және қол жетімділік

Аутентификация/авторизация

OIDC/SAML 'tenant _ id', 'roles', 'scopes' таңбаларымен.
RBAC/ABAC: жалға алушы деңгейіндегі рөлдер (Owner/Admin/Reader), жобаның/бөлімнің атрибуттары.
mTLS және шектеулі токендері бар (service-to-service) жіберілген кіру.

Сенім шегі

Сұрауды қабылдау саясаты: тақырып қолтаңбасын, nonce/timestamp, көзді байланыстыруды тексеру.
Құпиялар мен кілттер: per-tenant ротациясы, жекелеген KMS-контекстер, негізгі операциялардың аудиті.
Multi-region & data residency: пиннинг тенанта к региону, бақыланатын кросс-өңірлік ағындар.

7) «жалға алушылар бойынша» байқау

Трассалау және метрика

Міндетті тегтер: 'tenant _ id', 'plan', 'region', 'endpoint', 'status'.
SLI/SLO per tenant: `availability`, `p95 latency`, `error budget`.
Сегменттер бойынша дашбордтар мен алерттар (VIP/реттелетін/жаңа).

Логи және аудит

Өзгермейтін сақтау орны және жалға алушының саясаты бойынша ретеншімен іс-қимыл журналы (кім/не/қашан/қайда).
Оқиғаларды арзан сақтау үшін алдын ала біріктіру, «басу бойынша» егжей-тегжейін қалпына келтіру.

8) Өнімділік және «noisy neighbor»

Шуға қарсы шаралар

Кезектер/воркерлер деңгейіне арналған лимиттер, CPU-shares және IO-пропорциясы per tenant.
Кэштерді бөлу: 'tenant: {id}:', жоспар бойынша TTL, 'cache stampede' дегеннен қорғау.
'tenant _ id' бойынша селективтілікті ескере отырып, сұрау индекстері мен жоспарлары.

Суық старттар және «жылы» пулдар

VIP/ең жоғары терезелер үшін алдын ала жылыту.
Метрика сигналдары бойынша воркерлердің икемді пулдары (backpressure/автоскейлинг).

9) Тоқтаусыз жаңарту және көші-қон

Стратегия

Backward-үйлесімді көші-қон (expand → migrate → contract).
«Жалдаушылар бойынша» көші-қон: прогресті бақылайтын батчи, нақты 'tenant _ id' үшін «үзіліс/кері қайту».
Жалға алушылар тобында тұқымдастыру және «канареялық» көші-қон.

DR және оқыс оқиғалар

RTO/RPO per tenant бар DR-жоспар; ішінара «read-only режимі» жаһандық даунтайсыз.
Инцидентті оқшаулау: 'tenant _ id' бойынша фьюзинг, «ыстық» жалға алушыны сөндіру басқаларға әсер етпейді.

10) API және хаттамалар

REST/gRPC жалға алушының міндетті контексімен (таңбаларда/тақырыптарда).
Оқиғалар (event-driven): 'tenant. {id} .event' неймингі бар топиктер, сүзгілер және жазылым ACL.
Жаһандық кіру нүктелері: L7-шлюз контексті валидациялайды, лимиттерді қолданады, тенант саясаты бойынша PII шифрлайды.

11) Жалға алушының өмірлік циклі

1. Провижининг: жалға алушының жазбасын жасау, кілттерді/конфигурацияларды генерациялау, өңірді байланыстыру.
2. Белсендіру: OIDC/SAML клиенттерін шығару, рөлдерді/саясатты, бастапқы квоталарды құру.
3. Пайдалану: мониторинг, биллинг, жалауларды/жоспарларды жаңарту.
4. Суспенд/троттлинг: деректерді/экспортты сақтай отырып мұздату.
5. Жою/экспорттау: ретеншн, сақталған бэкаптар, кілттерді крипто-өшіру (crypto-shredding).

12) Архитектураның шағын эталоны (сөздік сызба)

Edge (API-шлюз): TLS/mTLS, 'tenant _ id' алу, лимиттер, аудит.
Control Plane: жалға алушылар каталогы, конфига, фича-жалаулар, биллинг, саясат.
Data Plane (сервистер): stateless-сервистер, кезектер, квоталары бар воркерлер; Redis/kv тенант бойынша префиксі бар.
Storage: RLS-БД/жеке схемалар/БД; жалға алушыға кілттері бар KMS; envelope-шифрлауы бар объектілік сақтау орны.
Observability: трейсинг/метрика/логи с тегом 'tenant _ id', алерты per plan.
Admin: жалдаушылар тобындағы оқшауланған операциялар (көші-қон/бэкаптар).

13) Азық-түлік алдындағы бақылау тізімі

• Шекарада және сервистерде 'tenant _ id' анықтаудың бірыңғай тәсілі.
• RLS/ACL саясаты тесттермен және «теріс сценарийлермен» тексерілген.
• Квоталар/лимиттер/биллинг нақты жүктемелерде валидацияланады; биллинг-дроптардан қорғау бар.
• Бақылау және SLO per tenant; VIP/реттелетін үшін алерттар.
• Көші-қон үйлесімді, ішінара қайтару және жалға алу батчі бар.
• RTO/RPO per tenant бар DR-сценарийлер және тұрақты жаттығулар.
• «Жалға алушы кілтімен» шифрлау, кілттерді ротациялау және аудит.
• API/оқиғалар келісімшарттарының құжаттамасы және нұсқалау саясаты.

14) Типтік қателер

Жаһандық көші-қонды проблемалы жалға алушыда тоқтату мүмкіндігінсіз «бір мезетте».
Кэштегі/кезектердегі 'tenant _ id' дегенге жасырын тәуелділік → деректердің жылыстауы/кезектердің қиылысуы.
Мәтінмәндерді араластыру ('tenant _ id' жоқ кездейсоқ admin-операциялар).
«Қос құлыптың» болмауы: ДБ-да RLS-сіз тек сервистік тексеру.
Бүкіл кластерге арналған бірыңғай лимитер → «noisy neighbor» және SLO бұзылуы.
Идемпотенттіліксіз мөлдір емес биллинг және аудит-трейл.

15) Стратегияны жылдам таңдау

Қатаң оқшаулау/реттеу: Silo (жеке ДБ/кластер), аймақ-лок.
Теңгерімді тиімділік: Shared-DB per schema + RLS, per tenant кілттері.
Жоғары real-time трафик: VIP үшін «өлшенген» квоталармен және бөлінген воркерлермен жалпы кезектер.
Көптеген кастомизациялар: фича-жалаулар + API адаптерлері, басымдықтар бойынша конфигурацияларды сақтау.

Қорытынды

Мульти-тенанттық ядро - бұл инженерлік шекараның пәні: «tenant _ id» айқын анықтамасы, барлық қабаттарда қатаң оқшаулау, басқарылатын квоталар мен мөлдір биллинг, плюс бақылануы мен релиздердің үйлесімділігі. Сипатталған үлгілерді орындау әрбір жалға алушы үшін қауіпсіздікті, сапаны және өзгерістер жылдамдығын құрбандық етпей, өнімді кеңейтуге мүмкіндік береді.