Rate limits және квоталар

Rate limits және квоталар - бұл жалпы ресурстарға сұранысты басқарудың іргелі механикасы: CPU, желі, БД, кезектер, сыртқы API. Мақсаты - әділеттілік (fairness), SLO болжамдылығы және жарылыстан, қиянаттан және «noisy neighbor» -дан қорғау.

1) Базалық ұғымдар

Rate limit - сұрау салулардың/операциялардың қарқындылығын шектеу (req/s, msg/min, байт/сек).
Burst - орташа rate үстінен рұқсат етілген қысқа мерзімді секіріс.
Quota - уақыт терезесі үшін көлем лимиті (құжаттар/тәулік, ГБ/ай).
Concurrency cap - бір мезгілде жасалатын операцияларды (бір мезгілде сұрау салуларды/джобтарды) шектеу.
Scope - қолдану саласы: per-tenant, per-user, per-token, per-endpoint, per-IP, per-region, per-feature.

2) Лимиттеу алгоритмдері

2. 1 Token Bucket (белгісі бар шелек)

Параметрлері: 'rate' (токендер/сек), 'burst' (шелектің өлшемі).
«Несие» ретінде жұмыс істейді: жинақталған токендер қысқа шыңдарға мүмкіндік береді.
Сыртқы API және пайдаланушы сұраулары үшін қолайлы.

2. 2 Leaky Bucket (аққан шелек)

Ағынды тұрақты жылдамдықпен тегіс «тегістейді».
Трафикті сезімтал backend 'лерге тегістеу үшін жақсы.

2. 3 Fixed/Sliding Window

Fixed window: қарапайым, бірақ «терезені ауыстыруға» осал.
Sliding window: нақтырақ, бірақ есептеу арқылы қымбат.

2. 4 GCRA (Generic Cell Rate Algorithm)

Виртуалды келу уақытындағы Token Bucket баламасы.
Бөлінген лимитерлер үшін дәл және тұрақты (аз жанжалды state).

2. 5 Concurrency Limits

Бір мезгілде орындалатын операцияларды шектеу.
Ағындар/қосылыстар пулының және «head-of-line blocking» тозуынан қорғайды.

3) Лимиттерді қайда қолдану керек

Шекарада (L7/API-шлюз): негізгі тосқауыл, жылдам істен шығу (429/503), арзан тексерулер.
Сервистер ішінде: ауыр операцияларға қосымша caps (экспорт, есептер, трансформациялар).
Сыртқы жүйелерге шығуда: үшінші жаққа арналған жеке лимиттер (anti-penalty).
Кезектерде/воркерлерде: fairness жалпы пулға.

4) Сатып алулар мен басымдықтар (multi-tenant)

Иерархия: Global → Region → Tenant/Plan → User/Token → Endpoint/Feature → IP/Device.
Priority-aware: VIP/Enterprise үлкен 'burst' және салмақ алады, бірақ ортақ SLO бұзбайды.
Лимиттер композициясы: қорытынды рұқсат = 'min (жаһандық, өңірлік, тенанттық, пайдаланушылық, эндпойнттық)'.

5) Көлемі бойынша квоталар

Тәуліктік/айлық квоталар: құжаттар/тәулік, ГБ/ай, хабарламалар/мин.
Жұмсақ/қатты табалдырықтар: ескерту (80/90%) және «қатты тоқта».
Roll-up: нысандар бойынша есеп (кестелер, файлдар, оқиғалар) және биллингке «алу».

6) Бөлінген лимитерлер

Талаптар: төмен кідіріс, келісімділік, істен шығуға төзімділік, көлденең масштабтау.

Local + probabilistic sync: жергілікті шард шелектер + мерзімді синхрондау.
Central store: Redis/KeyDB/Memcached с LUA/atomic ops (INCR/PEXPIRE).
Sharding: 'limit: {scope}: {id}: {window}' түрінің кілттері біркелкі.
Clock skew: «ақиқатты» клиенттерде емес, лимитердің серверінде сақтау.
Ұқсастық: «операциялардың» (Idempotency-Key) кілттері жалған есептен шығаруды азайтады.

7) Анти-абьюз және қорғау

Per-IP + device fingerprint көпшілік эндпойнттарға арналған.
Аномалиялар кезінде Proof-of-Work/CAPTCHA.
UX маңызды болғанда (іздеу кеңестері) толық істен шығудың орнына Slowdown (throttling).
Adaptive limits: инциденттер/қымбат тозулар кезінде шектердің динамикалық төмендеуі.

8) Клиенттің мінез-құлқы және хаттама

Кодтары: '429 Too Many Requests' (rate), '403' (квота/жоспар асып кетті), '503' (қорғаныштық тозу).

• 'Retry-After: ' - қашан қайталап көріңіз.

• `RateLimit-Limit: ;w=`
• `RateLimit-Remaining: `
• `RateLimit-Reset: `
• Backoff: экспоненциалды + джиттер (full jitter, equal jitter).
• Сәйкестік: 'Idempotency-Key' тақырыбы және қауіпсіз операциялардың қайталануы.
• Тайм-ауттар және алып тастау: лимиттерді «тартып алмау» үшін ілініп қалған сұрауларды дұрыс үзу.

9) Бақылау және тестілеу

Теги: `tenant_id`, `plan`, `user_id`, `endpoint`, `region`, `decision` (allow/deny), `reason` (quota/rate/concurrency).
Өлшемдер: өткізу қабілеті, 429/403/503 істен шығу үлесі, лимитердің кідіруі p95/p99, кілттер кэшінің hit ratio, жоспарлар бойынша бөлу.
Аудит логтары: блоктардың, топ «шулы» кілттердің себептері.
Тестілер: «ара/бурст/плато» жүктеме профильдері, хаос - Redis/shard істен шығуы, сағаттардың синхронизациясы.

10) Биллингпен интеграция

Usage-есептегіштер шекарада жиналады, батчалармен (әрбір N мин) біркелкілікпен біріктіріледі.
Жоспар бойынша мәлімет: артық шығын → оверчардж немесе жоспарды уақытша арттыру.
Айырмашылықтар: салыстыру usage vs invoice; дельтаға алерта.

11) Fairness ішінде (кезектер, воркерлер)

Weighted Fair Queuing/DRR: жоспардың салмағы бойынша жалға алушылар арасында слоттарды бөлу.
Per-tenant worker pools: қатаң оқшаулау VIP/шу.
Admission control: егер квоталар таусылса, орындалудан бас тарту; кезек көтерілмейді.
Caps concurrency: бір уақытта ауыр джобтарды шектеу.

12) Жоспарлардың үлгілік профильдері (мысал)

yaml plans:
starter:
rate: 50  # req/s burst: 100 concurrency: 20 quotas:
daily_requests: 100_000 monthly_gb_egress: 50 business:
rate: 200 burst: 400 concurrency: 100 quotas:
daily_requests: 1_000_000 monthly_gb_egress: 500 enterprise:
rate: 1000 burst: 2000 concurrency: 500 quotas:
daily_requests: 10_000_000 monthly_gb_egress: 5000

13) Сәулет эталоны (сөздік схема)

1. Edge/API-шлюз: TLS → контекстін алу (tenant/plan) → лимиттерді/квоталарды тексеру → RateLimit- → лог/трейс тақырыптарын орналастыру.
2. Policy Engine: басымдық ережелері (VIP), бейімделу шектері.
3. Limiter Store: Redis/KeyDB (atomic ops, LUA), кілттерді шардалау, репликалау.
4. Services: қайталама лимит және ауыр операцияларға арналған caps; іспеттілік; WFQ/DRR кезектері.
5. Usage/Billing: жинау, агрегаттау, инвойс, шектер бойынша алерталар.
6. Observability: метриктер/логи/тегі бар трейстер, дашбордтар per-tenant.

14) Азық-түлік алдындағы чек-парағы

• Лимит скоптары (tenant/user/token/endpoint/IP) және олардың иерархиясы анықталған.
• Алгоритм (Token Bucket/GCRA) және 'rate/burst' параметрлері таңдалды.
• concurrency caps және admission control ауыр операциялар үшін іске асырылды.
• 'RateLimit-' және 'Retry-After' тақырыптары қосылған; клиенттер backoff + jitter қызметін қолдайды.
• Лимитер бөлінген және істен шығуға төзімді (шардар, репликация, тозу).
• Usage-алым іспеттес; биллингпен байлам, артық шығынға арналған алерта.
• Бақылау қабілеті: метрлер/трестер/тегтері бар логи, топ «шулы» кілттер, alerter 'ы.
• Тесттер: бурсттар, «аралар», стораның істен шығуы, clock skew, салқын бастау.
• Клиенттерге арналған құжаттама: жоспарлар бойынша лимиттер, 429/Retry-After мысалдары, ретрациялардың best practices.
• Ерекшеліктер саясаты: лимиттерді уақытша қалай және қашан арттыру керек.

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

per-tenant/per-endpoint - «noisy neighbor» жоқ жаһандық лимит барлық SLO бұзады.
Жоқ 'burst': UX қысқа жарылыс кезінде зардап шегеді.
Тек бекітілген терезені пайдалану → «терезе шегінде екі рет соғу».
Демпотенттік пен ретраялар жоқ → қайталау дауылы.
Лимиттер тек шекарада, сервистерде/кезектерде caps жоқ → ішкі «тығындар».
Жауаптардағы лимиттерді көрсетпеу (жоқ 'Retry-After', 'RateLimit-') → клиенттер бейімделмейді.
OLTP → ДБ-да лимитердің жай-күйін сақтау жоғары жасырындылық және «ыстық» бұғаттау.

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

Шыңдары бар ашық API: Token Bucket + үлкен 'burst', RateLimit- тақырыптар, CDN/edge кэш.
Ішкі ауыр джобтар: concurrency caps + WFQ/DRR, admission control.
Үшінші тараптармен ықпалдасу: шығуға, буферлеуге/ретраға арналған жеке лимиттер.
SaaS мульти-тенанты: лимиттер иерархиясы (global → tenant → user → endpoint), VIP басымдылығы, айлар бойынша квоталар.

Қорытынды

Жақсы rate limits және квоталар - бұл платформа мен клиент арасындағы жүйелі келісім-шарт: ресурстардың адал үлесі, жарылысқа төзімділік, болжамды SLO және мөлдір биллинг. Алгоритмдерді (Token/GCRA + concurrency caps) біріктіріңіз, скоптар иерархиясын енгізіңіз, түсінікті тақырыптар мен метрикаларды беріңіз және нақты трафик профильдерінің астындағы схемаларды ұдайы тексеріңіз - осылайша платформа жүктеменің агрессивті өсуі кезінде де тұрақты болып қалады.