Қуатты жоспарлау және жүктеменің өсуі
Қысқаша түйіндеме
Қуат - бұл жүктеменің күтілетін өсуі мен істен шығуы кезінде мақсатты SLO төзу қабілеті. Негізі:1. Сұраныс болжамы (базалық тренд + маусымдық + ивенттер).
2. Жүктеме моделі (интернет үшін open-model).
3. Беріктік қоры (headroom) және қате бюджет.
4. Масштабтау (көкжиек/тік/авто) + шектегіштер (rate-limit/backpressure).
5. Қаржы: $/1000 RPS, $/ms p95, сценарийлер бойынша TCO.
Терминдер мен метриктер
Throughput: RPS/QPS/CPS - нақты өткізу қабілеті.
Latency p95/p99: теңшелетін жолдарға арналған мақсатты SLO.
Saturation: CPU/жад/IO/FD/қосылыстарды/кезектерді жүктеу.
Error rate: 5xx/timeout/429, кезең үшін қате бюджет.
Headroom: ең жоғары трафик кезінде бос қуат үлесі (30% ≥ ұсынылады).
Burst: қысқа мерзімді серпіліс (секунд/минут), Spike: күрт өсу × N.
Базалық модельдер мен формулалар
Little's Law (кезегі бар жүйелер үшін)
L = λ W
L - жүйедегі сұрау салулардың орташа саны, λ - кіру қарқындылығы (RPS), W - жүйедегі орташа уақыт. Кезектердің тереңдігін бағалау үшін пайдалы.
Жүктеу коэффициенті (ρ)
ρ = λ / μ
μ - сервистік жылдамдық (100% CPU кезінде RPS). ρ → 1 жасырындылық сызықтық емес өседі - жұмыс нүктесін ρ ≤ 0 ұстаңыз. 6–0. 75.
Safety factor/қор
Capacity_required = Peak_load (1 + Headroom) Degradation_factor
Мұнда Degradation_factor N істен шығуын, кэштің тозуын, бір РЖ/өңірдің жоғалуын ескереді (мысалы, 1. 2).
Сұраныс болжамы
1. Тарихы: күндізгі/апталық бейіндер, маусымдылық, оқиғалармен корреляция (матчтар/ағымдар/төлемдер).
2. Ивенттер: сценарийлік коэффициенттер (әдеттегі күн × 1, турнир × 2. 3, финал × 3. 5).
3. Флуктуация көздері: маркетингтік науқандар, релиздер, боттардың аномалиялары.
4. Болжам бірліктері: маршруттар бойынша RPS (login, lobby, catalog, payments), CPS TLS, QPS DB, IOPS диск, egress Гбит/с.
5. Сенім: екі сценарийді сақтаңыз - консервативті және агрессивті.
Жүктемені модельдеу
Open-model (Poisson-тәрізді кіріс): көпшілік API/веб үшін дұрыс - sizing үшін пайдаланыңыз.
Closed-model (VU + think-time): ішкі тізбектерге арналған; біріктіріңіз.
Маршруттар қоспалары: эндпойнттарға салмақтық үлестер; тек «ыстық» ғана емес, сонымен қатар «қымбат» (тіркеу, депозит) қосыңыз.
Естен шығармаңыз: ретраилер, кезектер, серіктестер лимиттері (PSP, бөгде API).
Беріктік қорын жобалау
Headroom мақсатты: ≥ 30% (интернет үшін); төлем өзегі және сындарлы жолдар үшін - 40-50%.
N + 1/N + 2: SLO бұзбай 1-2 инстанцияның/аймақтың істен шығуына төземіз.
Multi-region: әрбір өңір жиынтық шыңның 60% ≥ тартады (көршінің жоғалуына төзу үшін).
Degrade режимі: екінші дәрежелі функцияларды өшіріңіз, payload төмендетіңіз, кэш/стаб жауаптарды қосыңыз.
Sizing
Желі/Edge
CPS/RPS фронтта, TLS-handshake p95, resumption ≥ 70%, egress Гбит/с.
Anycast/Geo-routing, CDN/WAF лимиттері (алдын ала келісілсін).
Қор: линк/аплинк ≥ шыңы × 1. 3. H3 үшін UDP/443 қоры бар SYN backlog.
Теңгерімдегіштер/Прокси
Инстанцияға RPS, open connections, кезектер, CPU/IRQ.
Keepalive және connection pooling - бекендерге қосылыстарды азайтады.
Қор: ρ ≤ 0. 7, limiter по CPS/RPS per route.
Қолданбалар
Платодағы ядроға (RPS/core) мақсатты өнімділік.
Пулдар (thread/DB/HTTP) - лимиттерге сүйенбеңіз.
Қор: автоскейл CPU 60-70% және latency-trigger (p95) дейін.
Кэштер
Hit-ratio, көлемі hotset, eviction, реплика.
Қор: жады ≥ 1. 2 × hotset, желілік headroom ≥ 30%.
Дерекқорлар
QPS/TPM, p95 сұраулар, бұғаттау, буферлік кэш, WAL/replication lag.
IOPS және диск latency - p95 кілті.
Қор: жұмыс нүктесі CPU 50-65%, реплика <нысаналы; шардалау жоспары және read-replicas.
Дискілер/Сақтау орындары
IOPS (4k/64k), throughput, fsync cost.
Қор: IOPS ≥ шыңы × 1. 5, нысаналы терезеде latency p95; журнал/деректер үшін жеке пулдар.
GPU/ML (егер онлайн-инференс болса)
Samples/s, latency, VRAM headroom, batching.
Қор: «ара» жүктемесінің batch-параметрлері, warm-pool GPU.
Автоматты масштабтау
HPA/KEDA: CPU + кастомдық метриктер (p95 latency, RPS, кезек).
Warm pools: алдын ала қыздырылған инстанциялар.
Step-scaling: «кесу» үшін cooldown баспалдақтары.
Реакция уақыты: маңдайшеп қабаты үшін 1-2 минутқа T_scale ≤ көздейміз; ДБ үшін - алдын ала.
Шектегіштер мен backpressure
Rate-limit по IP/ASN/device/route; серіктестерге арналған квоталар.
TTL кезегі, «сыпайы» істен шығуы (429/грей-вол арқылы) таймауттарға қарағанда ерте.
Теңсіздік: төлемдердің кілттері; ретраи с budget + jitter.
Request collapsing/SWR: өрнек кезінде origin бағдарламасын оятпаңыз.
Жылдам есептеу мысалы
Берілген: API бойынша 35k RPS шыңының болжамы, p95 ≤ 250 мс, орташа service time 60% CPU кезінде инстанцияға 8 мс → μ ≈ 125 RPS/core, инстанцияға 8 ядро → ~ 1000 RPS/инстанс.
1 қадам (қорсыз): 35 инстанция.
2-қадам (headroom 30%): 35 × 1. 3 = 46.
3 қадам (бір AZ-дан бас тарту, + 20%): 46 × 1. 2 ≈ 55.
4 қадам (дөңгелектеу + ыстық резерв 10%): 61 инстанция.
Тексеру: ρ ≈ 35k/( 61k) ≈ 0. 57 - жасыл аймақта.
Қаржылық модель (FinOps)
$/1000 RPS қабаттар бойынша (edge, proxy, app, DB).
$/мс p95 (құйрықтың төмендеу құны).
TCO сценарийлері: on-demand vs reserved vs spot (үзілу қаупімен).
Қуаттар жоспары: аккаунттардың/кластерлердің тоқсандық лимиттері, бұлттардың квоталары, PSP/CDN лимиттері.
Істен шығуға дайындық және DR
Multi-AZ/region: әрбір иық жүктеменің 60% -ын ≈.
Failover-жоспар: withdraw Anycast, GSLB ауыстыру, TTL ≤ 60-120 с.
Сыни тәуелділік: PSP/банктердің лимиттері, қайталама провайдер.
Кезеңдік жаттығулар: PoP/BG/кэшті өшіру арқылы game day.
Бақылау және ерте қанығу сигналдары
Тұрақты кіру кезіндегі p95/p99 және кезектердің өсуі.
Кэштің hit-ratio құлауы, origin egress өсуі.
Retransmits/ECN CE ұлғаюы, TLS resumption құлдырауы.
Бойы 429/timeout және retry-rate.
ДБ үшін - қақтығыстардың өсуі, checkpoint time, WAL fsync.
Операциялық практикалар
Capacity review ай сайын: факт vs жоспар.
Құралдар үшін Change windows: freeze ядролар мен шектеулер.
Prewarm (CDN/DNS/TLS/пулдар) шыңға 10-30 минут қалғанда.
Лимиттерді нұсқалау: Git-те rate-limit/пулдар конфигін белгілеңіз.
iGaming/финтех ерекшелігі
Турнирлер/матчтар: spike + plateau профильдері, боттар үшін сұр маршруттар, тіркеу/депозиттердің жеке лимиттері.
Төлемдер/PSP: провайдер/әдіс бойынша квоталар, fallback-маршруттар, egress-IP пулдар, SLA Time-to-Wallet.
Контент-провайдерлер: студиялар бойынша тарату, ыстық кэштер, шард-пулдар.
Антифрод/AML: ережеге лимит/скоринг, шыңдау кезінде light-ережеге дейін деградация.
Енгізу чек-парағы
- Шыңдардың болжамы (база/маусым/іс-шаралар), екі сценарий.
- SLO/қате бюджет және мақсатты headroom ≥ 30%.
- Қабаттар бойынша Sizing (edge/proxy/app/cache/DB/IO/желі).
- Шектегіштер: rate-limit, кезектер, idempotency, retry-budget.
- HPA/KEDA + warm pools; ивент алдындағы айналдыру жоспары.
- Multi-AZ/region, failover-playbook, TTL және GSLB.
- Бұлт/PSP/CDN квоталары келісілген және құжатталған.
- Бақылау: capacity дашбордтары, қанығудың ерте сигналдары.
- DR-жаттығулар және тұрақты capacity-review.
Типтік қателер
Орташа RPS бойынша жоспар қалдықсыз/жарқылсыз.
ρ≈0. 9 «қағазда» - латенттілік сәл шу кезінде жарылады.
Сыртқы сервистер лимиттерінің игноры (PSP/CDN/ДҚ-кластер).
Degrade режимдері және backpressure - каскадтық фейл жоқ.
Алдын ала жылытусыз авто-масштаб - шыңнан кейін «үлгереді».
Барлық қабаттар үшін бірыңғай headroom - тар жер қоныс аударады.
Шағын ойнатқыштар
Ең жоғары оқиға алдында (T-30 мин)
1. minReplicas/target HPA үлкейту, warm pool қосу.
2. CDN/DNS/TLS/коннектілерді жылыту, кэштерді жылыту.
3. Уағдаластық бойынша пул лимиттерін және PSP квоталарын көтеру.
4. Сұр маршруттарды/бот-сүзгілерді қосу, ауыр эндпойнттарды тарылту.
Өңірдің ішінара жоғалуы
1. GSLB → көрші аймақ, TTL 60-120 с.
2. Degrade режимін қосу (кэш/жеңілдетілген беру).
3. PSP/egress-IP лимиттерін қайта бөлу.
4. Мәртебені коммуникациялау, р95/қателерді бақылау.
Ретрациялардың өрісі
1. retry-budget дегенді азайтып, backoff + jitter қосыңыз.
2. GET request-collapsing/SWR бағдарламасын қосу.
3. «Шулы» ASN үшін rate-limit уақытша қатайтылсын.
Жиынтық
Қуатты жоспарлау - бұл сұраныс болжамы + инженерлік модель + беріктік қоры + операциялық тетіктер. SLO мен headroom-ды рәсімдеңіз, сыртқы лимиттерді ескеріңіз, масштабтауды және деградацияны автоматтандырыңыз, «миллисекунд құнын» өлшеңіз және тұрақты capacity-review жүргізіңіз. Сонда жүктеменің өсуі тәуекелге емес, бизнестің басқарылатын өлшеміне айналады.