Mobil inkişafda Stress Test: nədir, məqsədləri və necə aparılır

Stress Test nədir?

Stress Test (stress testi) — hesablanmış göstəriciləri aşan şəraitdə sistemin iş qabiliyyətini qiymətləndirmə prosesidir. Mobil tətbiq üçün bu, normada 1000 olduğu halda 10000 eyni vaxtda push bildirişi, backend üçün — gözlənilən 5000 RPS əvəzinə 50000 RPS demək ola bilər. Stress Test-in Load Test-dən əsas fərqi ondan ibarətdir ki, məqsəd performansı təsdiqləmək deyil, sistemin layihə gücündən kənar davranışını öyrənməkdir. Netflix Engineering (2024) Stress Test-i “sistemin proqnozlaşdırıla bilən şəkildə sıradan çıxacağı hipotezinin yoxlanılması” kimi təyin edir.

Stress testi iki məcburi mərhələni əhatə edir: nasazlığa qədər yük və bərpanın müşahidəsi. Bərpa (recovery) — yük götürüldükdən sonra sistemin normal işə qayıtma qabiliyyətidir. Yenidən başlatmadan bərpa olunmayan sistem, hətta qısamüddətli yükə tab gətirsə belə, kövrək sayılır. AWS Well-Architected Framework (2024)-ə görə, Stress Test-dən sonra bərpa müddəti 5 dəqiqədən çox olmamalıdır.

Mobil müştərilər üçün Stress Test proseslərin məcburi dayandırılması, şəbəkənin kəsilməsi və RAM-ın tükənməsi şəraitində işin yoxlanılmasını əhatə edir. Android Low Memory Killer RAM çatışmazlığı zamanı fon prosesini dayandıra bilər — stress testi tətbiqin bu cür dayandırmadan sonra vəziyyəti düzgün bərpa etdiyini yoxlamalıdır. Apple UIKit (2024) tətbiqin hər ekranında memory warning ssenarilərinin test edilməsini tövsiyə edir.

Stress Test-in məqsədləri

Nasazlıq nöqtəsinin təyini

Stress Test-in ilk məqsədi — nasazlıq nöqtəsinin təyini (breaking point). Bu, əsas performans göstəricilərindən birinin kritik həddi keçdiyi andır: p95 cavab müddəti 10 saniyəni keçir, HTTP 5XX xəta faizi 5%-i keçir və ya ötürmə qabiliyyəti baseline-dan 50% aşağı düşür. Nasazlıq nöqtəsinin qeydə alınması komandaya sistemin miqyaslama həddini əvvəlcədən bilməyə imkan verir. Capacity planning məhz Stress Test məlumatlarına əsaslanır, Load Test-ə deyil, çünki Load Test sərhəd şərtlərini yoxlamır.

Bərpa mexanizmlərinin yoxlanılması

İkinci məqsəd — bərpa mexanizmlərinin yoxlanılması. Yük normal səviyyəyə endikdən sonra sistem standart göstəricilərə qayıtmalıdır. Verilənlər bazasına qoşulma hovuzu boşalmırsa və ya keş etibarsızlaşmırsa, Stress Test bu problemi üzə çıxaracaq. Circuit breaker (Hystrix, Resilience4j) həddindən artıq yük zamanı işə düşməli və stabilləşmədən sonra əlaqəni avtomatik bərpa etməlidir. Health check endpoint-ləri test zamanı hər bir xidmətin vəziyyətini izləməyə kömək edir.

Auto-scaling-in validasiyası

Üçüncü məqsəd — auto-scaling-in validasiyası. İnfrastruktur Kubernetes və ya AWS Auto Scaling istifadə edirsə, Stress Test yeni pod-ların və ya instansiyaların kifayət qədər tez yaradıldığını yoxlayır. Google Kubernetes Engine (2024)-ə görə, HPA (Horizontal Pod Autoscaler) metrikası işə düşdüyü andan yeni pod-un yerləşdirilmə müddəti 30 saniyədən çox olmamalıdır. HPA CPU, yaddaş və fərdi metrikalar əsasında miqyaslanmalıdır. Cluster Autoscaler mövcud qovşaqlar pod-ları yerləşdirməzsə, yeni qovşaqlar əlavə edir.

Stress Test metodologiyası

Tədricən yük artımı (Ramp-up Stress Test) — ən geniş yayılmış ssenari. İlkin yük gözlənilənin 50% səviyyəsində qurulur, sonra hər 2 dəqiqədən bir sistem sıradan çıxana qədər 10% artırılır. Bu ssenari davamlılığın dəqiq sərhədini tapmağa imkan verir. Grafana Cloud k6 (2025) hamar cavab müddəti qrafiki əldə etmək üçün artım addımının 10%-dən çox olmamasını tövsiyə edir.

Kəskin yük sıçrayışı (Spike Stress Test) — yük 10-30 saniyə ərzində 10%-dən 500%-ə qədər artır. Bu ssenari viral məzmun yayılması və ya DDoS hücumu kimi vəziyyətləri modelləşdirir. Spike Stress Test performansdan daha çox sistemin canlılığını yoxlayır: tamamilə sıradan çıxmamaq və stabilləşmədən sonra işə qayıtma qabiliyyəti. API Gateway kəskin sıçrayışlardan backend-i qorumaq üçün rate limiting konfiqurasiya etməlidir.

Uzun müddətli yük saxlanması (Sustained Stress Test) — sistem 30-60 dəqiqə ərzində həddindən artıq yük vəziyyətində saxlanılır. Bu ssenari qısamüddətli testlərdə özünü göstərməyən resurs sızmalarını aşkar edir. Yaddaş sızması Java/Kotlin tətbiqlərində 20-40 dəqiqə intensiv iş ərzində toplanır və yalnız Sustained Stress Test onu aşkar edir.

Nasazlıq nöqtəsi və bərpanın təhlili

Nasazlıq nöqtəsi üç meyar əsasında müəyyən edilir: cavab müddəti, xəta faizi və ötürmə qabiliyyəti. Adətən ilk olaraq cavab müddəti həddi keçilir — sorğular müəyyən edilmiş limitdən daha uzun müddətə yerinə yetirilməyə başlayır. Sonra xəta faizi artır: server sorğuları emal etməyə vaxt tapmır və 503 qaytarır. Son olaraq Throughput düşür — sistem hətta minimal yükün öhdəsindən gələ bilmir. Metrika nasazlıq nöqtəsi güc planlaması üçün yük profilində qeydə alınır.

Bərpanın təhlili üç fazanı əhatə edir: dərhal reaksiya (yük götürüldükdən sonra ilk 30 saniyə), stabilləşmə (1-5 dəqiqə) və tam bərpa (5-30 dəqiqə). Dərhal reaksiya fazasında cavab müddəti baseline-dan aşağı düşməlidir — sistem növbələrdən boşalır. Bu baş vermirsə, problem yükdə deyil, toplanmış vəziyyətdədir. Graceful degradation — sistemin həddindən artıq yük zamanı qismən funksionallığı qoruma qabiliyyəti — memarlıq yetkinliyinin əsas göstəricisidir.

Chaos Engineering Stress Test-i qəsdən nasazlıqlar daxil etməklə tamamlayır: verilənlər bazası serverinin söndürülməsi, şəbəkə gecikməsi, mikroxidmətin dayandırılması. Netflix-dən Chaos Monkey (2024) təsadüfi olaraq istehsalatda prosesləri dayandırır, sistemin davamlılığını yoxlayır. Mobil tətbiqlər üçün Chaos Engineering ssenarilərin test edilməsi deməkdir: şəbəkənin olmaması, API-nin əlçatan olmaması, boş server cavabı.

Stress Test üçün alətlər

k6 ramping-arrival-rate ilə

k6 ramping-arrival-rate konfiqurasiyası ilə `execution` modulu vasitəsilə Stress Test-i dəstəkləyir. Bu rejim hər sorğunun yerinə yetirilmə vaxtından asılı olmayaraq saniyədə sorğuların sayını artırır. Load Test ilə müqayisədə, k6-da Stress Test daha aqressiv thresholds qurulmasını və kəskin nasazlığı simulyasiya etmək üçün gracefull-stop-un söndürülməsini tələb edir. Grafana Cloud cavab müddəti qrafikinin əyriliyinə əsasən nasazlıq nöqtəsini avtomatik aşkar edir. Kubernetes üçün k6-operator klasterdən paylanmış Stress Test-lər işə salmağa imkan verir.

Ultimate Thread Group ilə JMeter

JMeter Ultimate Thread Group — cədvəl şəklində yük profilini təyin edən plagin vasitəsilə Stress Test-i konfiqurasiya etməyə imkan verir: axınların sayı, isinmə vaxtı, saxlama vaxtı, enmə vaxtı. Ultimate Thread Group mürəkkəb çoxfazalı ssenarilər üçün əlverişlidir. JMeter Backend Listener nasazlıq nöqtəsinin qrafiklərini qurmaq üçün metrikaları InfluxDB-ə göndərir. Stress Test üçün JMeter-də həddindən artıq yük zamanı davranışı daha dəqiq ölçmək üçün qoşulma timeou-tlarının söndürülməsi tövsiyə olunur.

Chaos Engineering üçün Gremlin

Gremlin — infrastrukturun Stress Test-i üçün Chaos Engineering platforması. Gremlin şəbəkəni söndürməyə, CPU-nu yükləməyə, diski doldurmağa və ayrı-ayrı Kubernetes pod-ları səviyyəsində prosesləri dayandırmağa imkan verir. SRE komandaları kompleks Stress Test üçün Gremlin-i k6 ilə birlikdə istifadə edir: k6 yük yaradır, Gremlin nasazlıqlar daxil edir. Game Day — sistemin davamlılığını təhlil etmək üçün ”chaos report”-da sənədləşdirilən Gremlin ilə müntəzəm Stress Test sessiyaları.

k6-da Stress Test nümunəsi

k6-da təqdim olunan skript nasazlığa qədər tədricən yük artımı ilə Stress Test-i nümayiş etdirir. Ramping-arrival-rate hər sorğunun yerinə yetirilmə vaxtından asılı olmayaraq saniyədə sorğuların sayını artırır. Thresholds deqradasiyanın aqressiv aşkarlanması üçün qurulub: p95 2000 ms-dən çox deyil, error rate 5%-dən çox deyil. Həddlər keçildikdə k6 testi xəta kodu ilə bitirir, bu da Stress Test-in CI/CD pipeline-a daxil edilməsinə imkan verir.

import http from 'k6/http'
import check from 'k6'

export const options = {
    scenarios: {
        stress: {
            executor: 'ramping-arrival-rate',
            startRate: 50,
            timeUnit: '1s',
            stages: [
                { duration: '2m', target: 200 },
                { duration: '5m', target: 500 },
                { duration: '2m', target: 1000 },
            ],
            preAllocatedVUs: 50,
            maxVUs: 200,
        },
    },
    thresholds: {
        http_req_duration: ['p(95)<2000'],
        http_req_failed: ['rate<0.05'],
    },
}

export default function() {
    const res = http.get('https://api.example.com/health')
    check(res, {
        'status is 200': (r) => r.status === 200,
    })
}

Stress Test-in ən yaxşı təcrübələri

Stress Test-ə staging-də başlayın — istehsalatda stress testi qabaqcıl monitorinq və geri dönüş planı tələb edir. Google SRE (2024) memarlıq və güc baxımından istehsalatı təkrarlayan 100% izolə edilmiş mühitdə Stress Test keçirməyi tövsiyə edir. Staging-də uğurlu testdən sonra SRE nəzarəti altında istehsalata keçmək olar. Həddindən artıq yük zamanı funksionallığı söndürmək üçün Feature flag məcburi elementdir.

Stress Test-i CI/CD-də avtomatlaşdırın nasazlıq nöqtəsinin reqressiya təhlili üçün. Tətbiqin yeni versiyası əvvəlkindən 20% aşağı nasazlıq nöqtəsinə malikdirsə, bu, buraxılışdan əvvəl düzəldilməli reqressiyadır. Baseline breaking point metrikalarda saxlanılır və hər Stress Test-in nəticəsi ilə avtomatik müqayisə edilir. Nasazlıq nöqtəsi 10% düşdükdə alert işə düşür.

Hər Stress Test-i sənədləşdirin: yük profili, nasazlıq nöqtəsi, bərpa davranışı və aşkar edilmiş problemlərin siyahısı. Netflix Engineering (2024) “Game Day” — nəticələri “chaos report”-da sənədləşdirilən müntəzəm Stress Test sessiyaları aparır. Hesabat stress testi haqqında qeyd olunmuş nasazlıq nöqtəsi ilə “RPS — cavab müddəti” qrafikini ehtiva etməlidir.