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

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

დატვირთვის ტესტირება არის რეალისტური და ექსტრემალური სცენარების ქვეშ პროდუქტიულობის და სტაბილურობის სისტემური შემოწმება. წარმატების საფუძველი: SLO- ს მიერ ჩაწერილი სწორი ტრაფიკის მოდელი, სუფთა მეტრიკა (შეცდომები/გაჯერება), წარმომადგენლობითი მონაცემები, ავტომატიზაცია და განმეორება. შედეგი არ არის „RPS ფიგურა“, არამედ გამოსავალი: სად არის ვიწრო ადგილები, რა ღირს პროდუქტიულობა, სად არის უარის თქმის ბარიერი და როგორ უნდა გადავიდეს იგი.

SLO/SLI და სამიზნე მეტრიკა

SLO (მაგალითი): p95 API - 250 ms, p99-600 ms; შეცდომა 0. 3 %/30 დღე.
SLI: latency (p50/p95/p99), throughput (RPS/CPS/QPS), saturation (CPU/heap/GC/FD/conn), ошибки (5xx, timeouts), очереди (depth/lag), DB (locks, slow queries), кэш (hit-ratio).
შეცდომების ბუდეტები და სატურნის გამომწვევი (მაგალითად, CPU> 75% ან queue depth> X დეგრადაცია).

ტესტის ტიპები

1. Baseline/Benchmark - ერთჯერადი მომსახურება/endpoint, „იდეალური“ პირობები.
2. Load არის რეალისტური „სამუშაო დღე“ + ramp-up/ramp-down.
3. სტრესი - ჩვენ ვზრდით დატვირთვას breakpoint- ის დეგრადაციამდე და ფიქსაციამდე.
4. Spike - მკვეთრი ნახტომი (x2-x10 წამში/წუთში).
5. Soak/Endurance - გრძელი პროგონი (8-72 საათი): მეხსიერების გაჟონვა, ლატენტობის დრიფტი.
6. Capacity არის ეტაპობრივი დატვირთვა შესრულების მრუდის ასაშენებლად და კონტეინერის დაგეგმვისთვის.
7. Degradation/Chaos-mix - დატვირთვა + ნაწილობრივი უკმარისობა (ნელი BD, ქეში ვარდნა, „გატეხილი“ აპლინი).

ტრაფიკის მოდელები: Open vs Closed

Open Model (უფრო რეალისტური ინტერნეტისთვის): მომხმარებლები მოდიან ინტენსივობით (Poisson მსგავსი ნაკადი). თუ სისტემა შენელებულია, მოთხოვნები გროვდება და არა „გაყინვა“.
Closed model: ვირტუალური მომხმარებლების ფიქსირებული რაოდენობა (VU) think time- ით. შეფერხების ზრდის დროს, RPS ხელოვნურად ეცემა - ფრთხილად დასკვნებით.
რეკომენდაცია: გამოიყენეთ ღია მოდელი წინა ხაზის API- სთვის (k6 'arrival-rate "), შიდა სინქრონული სცენარისთვის - დააკავშირეთ closed.

დატვირთვის პროფილები (შაბლონები)

„ჩვეულებრივი დღე“: ძირითადი ფონი + დღის რყევები.
Peak-ivent: დაწყებამდე 10-30 წუთი (დათბობა), თავიდანვე მკვეთრი spike, პლატო, კუდი.
„ტურნირი/ნაკადი“: ნაბიჯების ხე, განმეორებითი მწვერვალები ინტერვალებით.
„ინფრასტრუქტურის დეგრადაცია“: ქეშის ნახევარი ცარიელია, ერთი რეგიონი გამორთულია, PSP- ის ლატენტობის ზრდა.
Failover: ტრეფიკი მიედინება რეზერვში 1-5 წუთში; ჩვენ ვამოწმებთ skale/HPA/Retry ქარიშხლები.

მონაცემები და გარემოს მომზადება

ტესტის მონაცემები: რეალისტური კარდინალობა (პროვაიდერები, ვალუტები, ქვეყნები), „ბინძური“ ველები, მოთხოვნების განაწილება (Pareto/Zipf).
საიდუმლოებები/PII: ანონიმიზაცია; გასაღებები/PSP - sandbox.
გარემო: იზოლირებული perf-stand, იზოლაცია ინტეგრაციიდან (mock/სტაბილურობიდან), ფიქსირებული ვერსიები.
დაკვირვება: მეტრიკა (Prometheus), ლოგები (Loki/ELK), ბილიკები (OTel). დაფიქსირდა გადახდა პასუხებში.

ქარიშხლის საწინააღმდეგო და იდემპოტენტობა

Retrai მხოლოდ idempotent ოპერაციებისთვის; განათავსეთ retry-budget (მაგ., ტრეფიკის 10%).
Exponential backoff + jitter; „კოლაფსინგი“ იდენტური GET.
გადახდებისთვის - idempotent გასაღებები და აშკარა სტატუსები.
Thundering herd- ისგან დაცვა: ქეში-ლოკი, SWR, ადგილობრივი სემფორები.

ინსტრუმენტები და ნიმუშები

k6 (სკრიპტი, ღია მოდელი, კარგი ანგარიშგებები), Locust (Python სცენარები), Gatling (Scala), JMeter (პროტოკოლის ფართო სპექტრი).
ოქმები: HTTP/1. 1/2/3, gRPC, WebSocket, TCP/UDP; არ გამოსცადოთ სერვერი „როგორც GET“.
ტრაფიკის გამომუშავება: გენერატორების ჰორიზონტალური სკალირება, ქსელის ვიწრო ადგილის კონტროლი.
პროფილების ჭამა: pprof/async-profiler/ebpf დატვირთვის ქვეშ, OTel მარშრუტები.

მინი მაგალითი k6 (ღია მოდელი + spike):

javascript import http from 'k6/http';
import {check, sleep} from 'k6';

export const options = {
scenarios: {
warmup: { executor: 'ramping-arrival-rate', startRate: 50, timeUnit: '1s',
preAllocatedVUs: 200, stages: [ { target: 200, duration: '5m' } ] },
spike: { executor: 'constant-arrival-rate', rate: 1200, timeUnit: '1s',
preAllocatedVUs: 2000, startTime: '6m', duration: '3m' }
},
thresholds: {
http_req_failed: ['rate<0. 3%'],
http_req_duration: ['p(95)<250', 'p(99)<600']
}
};

export default function () {
const res = http. get(`${__ENV. BASE_URL}/api/v1/catalog? c=${Math. floor(Math. random()1000)}`);
check(res, { 'status is 200': (r) => r. status === 200 });
sleep(Math. random()0. 9) ;//think time (for closed parts of the script)
}

ჩატარების ტექნიკა

1. ჰიპოთეზა - რა ვიწრო ადგილებია სავარაუდო (CPU, BD, ქეში, ქსელი, TLS, GC).
2. პროფილი - სკრიპტები/მარშრუტები, ტრაფიკის წილი, მოდელები (Open/closed), მონაცემები.
3. გაათბეთ ქეში/კონექტორები/TLS/თარჯიმნები.
4. ეტაპის ზრდა სამიზნე ინტენსივობამდე.
5. პლატო - სტაბილური მეტრიკის და მარშრუტების შეგროვება.
6. სტრესი/რეცესია - შესვენების წერტილის ძებნა, სკეიტის მანქანის მონიტორინგი.
7. ანალიზი - მეტრიკის კორელაცია, flamegraph, მოხსენება და ცვლილების გეგმა.
8. რეპრუფტი - რეპლიკა paypline CI (Regression Perf) საშუალებით.

შედეგების ანალიზი

მრუდი „დატვირთვა, შეფერხება/შეცდომა“: ჩვენ მუხლზე ვეძებთ (კაპიტალი).
Breakdown ლატენტობა: ქსელი (DNS/TLS/კავშირი), მარიონეტული, პროგრამა, BD, გარე გამოწვევები.
სატურნა: CPU> 75-85%, GC pause> p95, I/O მოლოდინი, დავალებების რიგი.
ელასტიურობა: ავტო სკეილის რეაქციის დრო (HPA/KEDA), „ცივი დასაწყისი“, ქეში თბება.
ღირებულება: $1000 RPS სამიზნე SLO, ბიუჯეტის პროგნოზი მწვერვალზე.

საინჟინრო პრაქტიკა

დეგრადაციის ინდიკატორები: p99 „კუდები“, რიგების ზრდა, hit-ratio- ს ვარდნა, ჭიდაობის მცდელობების ზრდა.
გამორიცხეთ კონფიგურატორები: ფაილური აღწერილობების ლიმიტები, sysctl, conn-pool, 'reuseport', TLS ჯაჭვები, OCSP.
BD: ინდექსები/გეგმები/მოთხოვნის ქეში, ნაერთების აუზები, საბრძოლო ოპერაციები, მწარმოებლების დაბომბვა.
ქეში: ზომა/მოვლენები პოლიტიკა, ცხელი გასაღებები, რეპლიკაცია.
ქსელი/edge: HTTP/2/3, resumption - 70%, Brotli, CDN გასაღები ქეში, tiered-cache.

დაკვირვება დატვირთვის ქვეშ

მეტრიკა: სისტემური (CPU/mem/IO), runtime (GC/heap), ქსელი (RTT/loss/ECN), L7 (p95/99, 5xx/429), რიგები, BD/ქეშის მტევანი.
ტრეისები: ჩართეთ ნიმუშები „tail-based“ (tail-based), ნიშნები build-id/canareiks.
ლოგოები: შეცდომების დაყოფა მოცულობის შეზღუდვით (ისე, რომ არ იყოს „DOSILE“ ლოგო).
ექსპერიმენტები: feature-flags და კონფიგურაცია უნდა იყოს ჩაწერილი მოხსენებაში.

ავტომატიზაცია და CI/CD

Perf-jobs in CI (smoke 3-5 წუთი, nightly 30-60 წუთი, ყოველკვირეული soak).
დაშვების საზღვრები: ლატენტობა/შეცდომები/რესურსები - რეგრესიის დროს „დაარღვიეთ ბილეთი“.
არტეფაქტები: გრაფიკა, flamegraphs, პროფილები, JSON მოხსენებები (k6/jtl).
მონაცემთა და სკრიპტების ვერსია, PR- სკრიპტების PR- მიმოხილვა.

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

ტურნირები/მატჩები: spike + plateau; გაათბეთ TLS/DNS/CDN, გაზრდილი ტყვიის ლიმიტები, „ნაცრისფერი“ ბოტების მარშრუტები.
გადახდა/PSP: sandbox ლიმიტები, იდემპოტენტურობა, მკაცრი ტაიმაუტები; degrade mode (საცნობარო წიგნების ქეში, რიგები).
ჯეკპოტი/ტირიფი: ატომურობა და თანმიმდევრობა, დუბლირების ნაკლებობა, დატვირთვა RNG/ლიდერებზე.
ანტიფროდი/AML: დატვირთვა წესებზე/ML Scoring, backpressure, მოვლენების დედაპლაცია.
მარეგულირებელი: მეტრიული და ვერსიების გაუმჯობესება მწვერვალებზე, აუდიტის მოხსენებები.

ჩეკის გაშვების სია

ჩაწერილია SLO/SLI და „წითელი ხაზები“ (შეცდომა/ლატენტობა/სატურაცია).
დამტკიცებულია სკრიპტები და დატვირთვის პროფილები (Open/closed, spike/soak/stress).
მონაცემები რეალისტურია, PII შენიღბულია, ინტეგრაცია - sandbox/mock.
დაკვირვება მზად არის: მეტრიკა/ტრეისი/ლოგები, გამოშვების ჭდეები.
სისტემის კონფიგურაცია (ulimit/sisctl/pools) დოკუმენტირებულია.
მანქანის სკეილის გეგმა/ქეში და rollback კრიტერიუმები.
ბარიერი ალერტები და გუნდური კომუნიკაციის გეგმა (on-call).
მომზადებულია საანგარიშო შაბლონი (გრაფიკა, დასკვნები, მოქმედებები).

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

cllosed მოდელის ტესტი იძლევა „მწვანე“ შედეგს, ხოლო პროდი ეცემა (ღია მოდელის უგულებელყოფა შეუძლებელია).
არაპრეზენტაციული მონაცემები (ერთი ვალუტა/ერთი პროვაიდერი) არის ყალბი დასკვნები.
ნულოვანი მომზადება: ცივი ქეში/TLS/კონექტები - თავიდანვე გადაჭარბებული ლატენტობა.
Retrais გარეშე ლიმიტები, ქარიშხალი და კასკადის ვარდნა.
იგივე პროფილები ყველა მომსახურებისთვის არის რეალური „ცხელი წერტილების“ გამოტოვება.
არ ჩანს soak-gons- ის არარსებობა, მეხსიერების გაჟონვა და დრიფტი.
გაუმჭვირვალე შედეგები: არ არსებობს მარშრუტები/ფლეიმგრაფები, შეუძლებელია ვიწრო ადგილის ლოკალიზაცია.

მინი ფლეიბუკები

მაქსიმალური გამტარუნარიანობის განსაზღვრა

1. 10-20% დატვირთვის ნაბიჯები ყოველ 5-10 წთ. 2) ჩვენ აღვნიშნავთ იმ მომენტს, სადაც p95 მკვეთრად იზრდება და შეცდომები> SLO. 3) ამოიღეთ პროფილები CPU/BD/ქეში. 4) ოპტიმიზაციის გეგმა და გამეორება.

ჭიდაობის ქარიშხალი

1. შეზღუდეთ retry-budget და ჩართეთ backoff + jitter. 2) შეიყვანეთ request-collapsing/SWR. 3) დაუშვეთ „დეგრადირებული რეჟიმი“ (შეზღუდული ფუნქციონირება). 4) შეამოწმეთ იდემპოტენტობა.

მწვერვალი (ტურნირი) - წინასწარი გეგმა

1. გაათბეთ CDN/DNS/TLS/აუზები. 2) გაზარდეთ target HPA, მოამზადეთ რეზერვი. 3) ცალკეული ლიმიტები ბოტებისთვის. 4) დაშბორდები „პიკის რეჟიმში“, საკომუნიკაციო ხიდი on-call.

Soak Night

1. 8-12 საათის სტაბილური დატვირთვა. 2) დააკვირდით heap/FD/conn/GC-pauses. 3) ჩვენ ვამოწმებთ p95 და hit-ratio დელტას. 4) ჩაწერეთ გაჟონვა და დრიფტი.

შედეგი

დატვირთვის ტესტირება არის საინჟინრო გადაწყვეტილებების მიღების პროცესი და არა „RPS რბოლა“. მოდელირება მოახდინეთ რეალურ პროფილებზე (განსაკუთრებით ღია მოდელზე), ჩაწერეთ SLO, ამოიღეთ მეტრიკები და ბილიკები, მოძებნეთ შესრულების მუხლზე და გაითვალისწინეთ შესრულების ღირებულება. ავტომატიზაცია მოახდინეთ programs, შეინარჩუნეთ ქარიშხლის ანტი-ქარიშხალი და დაგეგმეთ პიკის მოვლენები - ასე რომ, პლატფორმა პროგნოზირებადი და სტაბილური იქნება ყველაზე ინტენსიურ მომენტებში.