ენერგიის დაგეგმვა და ტვირთის ზრდა

მოკლე რეზიუმე

1. მოთხოვნის პროგნოზი (ძირითადი ტენდენცია + სეზონური + ტირაჟი).

2. დატვირთვის მოდელი (ღია მოდელი ინტერნეტისთვის).

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.

ძირითადი მოდელები და ფორმულები

პატარა კანონი (რიგის სისტემებისთვის)

L = λ W

L არის სისტემის მოთხოვნების საშუალო რაოდენობა, C- საშუალო შეყვანის ინტენსივობა (RPS), W არის საშუალო დრო სისტემაში. სასარგებლოა რიგების სიღრმის შესაფასებლად.

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

ρ = λ / μ

მომსახურების სიჩქარე (RPS 100% CPU). S-1- ით, ლატენტობა არაწრფივი იზრდება - შეინარჩუნეთ სამუშაო წერტილი 0. 6–0. 75.

უსაფრთხოების ფაქტორი/რეზერვი

Capacity_required = Peak_load (1 + Headroom) Degradation_factor

სადაც Degradation _ factor ითვალისწინებს N უარის თქმას, ქეშის დეგრადაციას, ერთი RoP/რეგიონის დაკარგვას (მაგალითად, 1. 2).

მოთხოვნის პროგნოზი

1. ისტორია: დღის/ყოველკვირეული პროფილები, სეზონური, კორელაცია მოვლენებთან (მატჩები/ნაკადები/გადახდები).
2. ტირიფები: სცენარის კოეფიციენტები (ჩვეულებრივი დღე × 1, ტურნირი × 2. 3, ფინალი × 3. 5).
3. რყევების წყაროები: მარკეტინგული კამპანიები, გამოშვებები, ბოტების ანომალიები.
4. პროგნოზის ერთეულები: RPS მარშრუტებზე (login, lobby, catalog, payments), CPS TLS, QPS DB, IOPS დისკი, egress Gbit/s.
5. ნდობა: შეინახეთ ორი სცენარი - კონსერვატიული და აგრესიული.

დატვირთვის მოდელირება

ღია მოდელი (Poisson მსგავსი მრევლი): შესაფერისია საზოგადოებრივი API/ვებისთვის - გამოიყენეთ sizing.
Closed-model (VU + think-time): შესაფერისია შიდა რიგითებისთვის; შერწყმა.
მარშრუტების ნაზავი: წონის წილი ენდპოინტებზე; ჩართეთ არა მხოლოდ „ცხელი“, არამედ „ძვირფასო“ (რეგისტრაცია, ანაბარი).
არ უნდა დაგვავიწყდეს: რეტრაები, რიგები, პარტნიორების ლიმიტები (PSP, მესამე მხარის API).

უსაფრთხოების ზღვრის დიზაინი

Headroom სამიზნე: მწვერვალის 30% -ზე მეტი (ინტერნეტისთვის); გადახდის ბირთვის და კრიტიკული გზებისთვის - 40-50%.
N + 1/N + 2: გაუძლო 1-2 ინსტანციის/ზონის უკმარისობას SLO დარღვევის გარეშე.
Multi-region: თითოეული რეგიონი მოიცავს მთლიანი მწვერვალის 60% -ს (მეზობლის დაკარგვის გადასარჩენად).
Degrade რეჟიმი: გამორთეთ მეორეხარისხოვანი ფუნქციები, შეამცირეთ payload, ჩართეთ ქეში/პასუხები.

Sizing ფენებში

ქსელი/Edge

CPS/RPS ფრონტზე, TLS-handshake p95, resumption-70%, egress Gbit/S

Anycast/Geo-routing, CDN/WAF ლიმიტები (წინასწარ კოორდინაცია).
რეზერვი: link/applink - მწვერვალი × 1. 3, SYN backlog მარაგი, UDP/443 H3- ისთვის.

დაბალანსება/მარაგი

RPS ინსტანციებზე, ღია კავშირებზე, რიგებზე, CPU/IRQ.
Keepalive და დაკავშირება pooling - ამცირებს კავშირებს ზურგჩანთებზე.
რეზერვი - 0. 7, limiter по CPS/RPS per route.

პროგრამები

სამიზნე პროდუქტიულობა ბირთვზე (RPS/core) პლატოზე.
პულები (thread/DB/HTTP) - არ დაეყრდნო ლიმიტებს.
რეზერვი: ავტო სკეიტი CPU- მდე 60-70% და ლაზერული-ტრიგერი (p95).

კაში

Hit-ratio, სასტუმრო, ღონისძიება, შენიშვნა.
რეზერვი: მეხსიერება - 1. 2 × hotset, ქსელის headroom - 30%.

მონაცემთა ბაზები

QPS/TPM, p95 მოთხოვნა, ბლოკირება, ბუფერული ქეში, WAL/რეპლიკა lag.
IOPS და latence დისკი არის 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 ლატენცია, RPS, რიგები).
Warm pools: წინასწარი დათბობის ინსტანციები აყვავებამდე.
ეტაპი: ნაბიჯები cooldown- დან, ისე რომ არ „დაჭრილი“.
რეაქციის დრო: შემოღობილი T _ scale - 1-2 წუთი წინა ხაზის ფენისთვის; DD- სთვის - წინასწარ.

შეზღუდვები და დაბლოკვა

Rate-limit по IP/ASN/device/route; კვოტები პარტნიორებისთვის.
ხაზები TTL- სთან, უარი „თავაზიანი“ (429/ბერძნულ-ხრტილის საშუალებით) უფრო ადრე, ვიდრე ტაიმაუტები.
Idempotence: გადახდის გასაღებები; retrai ერთად budget + jitter.
Request collapsing/SWR: არ გაიღვიძოთ origin ადიდების დროს.

სწრაფი გაანგარიშების მაგალითი

მოცემულია: 35k RPS- ის მწვერვალის პროგნოზი API- სთვის, p95-250 ms, საშუალო სერვისის დრო 8 ms თითო ინსტანციაზე 60% CPU- სთან - 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 ინსტანცია.
გადამოწმება: 57 - მწვანე ზონაში.

ფინანსური მოდელი (FinOps)

$1000 RPS ფენებში (edge, proxy, app, DB).
$/ms p95 (კუდის შემცირების ღირებულება).
TCO სცენარები: demand vs reserved vs spot (შეფერხების რისკის ქვეშ).
სიმძლავრის გეგმა: ანგარიშების/მტევნების კვარტალური ლიმიტები, ღრუბლის კვოტები, PSP/CDN ლიმიტები.

მზადყოფნა უარი თქვას და DR

Multi-AZ/region: თითოეული მხრის დატვირთვის 60% -ს შეადგენს.
Failover გეგმა: withdraw Anycast, GSLB გადართვა, TTL - 60-120.
კრიტიკული დამოკიდებულებები: PSP/ბანკების ლიმიტები, მეორადი პროვაიდერი.
პერიოდული სავარჯიშოები: თამაშის დღე PoP/BG/ქეში გამორთვით.

ადრეული გაჯერების დაკვირვება და სიგნალები

ზრდა p95/p99 და რიგები სტაბილური შესასვლელით.
Hit-ratio ქეშის დაცემა, origin egress- ის ზრდა.
retransmits/ECN CE- ის ზრდა, შემცირება TLS.
ზრდა 429/timeout და retry-rate.
BD- სთვის - კონფლიქტების ზრდა, checkpoint time, WAL fsync.

ოპერაციული პრაქტიკა

კაპიტალური მიმოხილვა ყოველთვიურად: ფაქტი vs გეგმა.
Windows Change ivents: freeze ბირთვები და ლიმიტები.
Prewarm (CDN/DNS/TLS/აუზები) მწვერვალამდე 10-30 წუთით ადრე.
ლიმიტის ვერსია: ჩაწერეთ Git- ში ჩამორთმევა-ლიმიტი/ტყვია.

სპეციფიკა iGaming/fintech

ტურნირები/მატჩები: პროფილები spike + plateau, ნაცრისფერი ბოტების მარშრუტები, ინდივიდუალური რეგისტრაციის/დეპოზიტების ლიმიტები.
გადახდები/PSP: პროვაიდერის/მეთოდის კვოტები, fallback მარშრუტები, egress-IP აუზები, SLA Time-to-Wallet.
შინაარსის პროვაიდერები: განაწილება სტუდიებში, ცხელი ქეშები, შარდ-აუზები.
ანტიფროდი/AML: წესების/მორიელის ლიმიტი, შუქის წესების დეგრადაცია მწვერვალზე.

ჩეკის განხორციელების სია

• მწვერვალების პროგნოზი (ბაზა/სეზონი/ტირაჟი), ორი სცენარი.
• SLO/მცდარი ბიუჯეტი და მიზნობრივი headroom - 30%.
• Sizing ფენებში (edge/proxy/app/cache/DB/IO/ქსელი).
• შეზღუდვები: rate-limit, რიგები, idempotence, retry-budget.
• HPA/KEDA + warm pools; წინსვლის გეგმა.
• Multi-AZ/region, failover-playbuks, TTL და GSLB.
• ღრუბლის კვოტები/PSP/CDN შეთანხმებულია და დოკუმენტირებულია.
• დაკვირვება: დაშბორდები capacity, ადრეული გაჯერების სიგნალები.
• DR სწავლებები და რეგულარული capacity მიმოხილვა.

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

საშუალო RPS გეგმა კუდების/ადიდების გარეშე.
ρ≈0. 9 „ქაღალდზე“ - ლატენტობა აფეთქდება მცირედი ხმაურით.
გარე სერვისების შეზღუდვების უგულებელყოფა (PSP/CDN/BD კლასტერის).
არ არსებობს 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. სტატუსის კომუნიკაცია, p95/შეცდომების კონტროლი.

ჭიდაობის ზრდა

1. შეამცირეთ retry-budget, ჩართეთ backoff + jitter.
2. ჩართეთ request-collapsing/SWR GET.
3. დროებით გამკაცრება „ხმაურიანი“ ASN- ისთვის.

შედეგი

ენერგიის დაგეგმვა არის მოთხოვნის პროგნოზი + საინჟინრო მოდელი + უსაფრთხოების ზღვარი + ოპერაციული ბერკეტები. ფორმალიზებული SLO და headroom, გაითვალისწინეთ გარე ლიმიტები, ავტომატიზირებული მასშტაბები და დეგრადაცია, გაზომეთ „მილიწამურის ღირებულება“ და ჩაატარეთ რეგულარული capacity მიმოხილვა. შემდეგ ტვირთის ზრდა გადაიქცევა არა რისკად, არამედ ბიზნესის კონტროლირებად მეტრად.