Stress Test στην ανάπτυξη εφαρμογών για κινητά: τι είναι, στόχοι και πώς διεξάγεται

Τι είναι το Stress Test;

Stress Test (δοκιμή αντοχής) είναι η διαδικασία αξιολόγησης της ικανότητας του συστήματος να λειτουργεί υπό συνθήκες που υπερβαίνουν τις υπολογισμένες παραμέτρους. Για μια εφαρμογή για κινητά, αυτό μπορεί να σημαίνει 10000 ταυτόχρονες ειδοποιήσεις push με κανόνα 1000, για το backend — 50000 RPS έναντι των αναμενόμενων 5000. Η κύρια διαφορά μεταξύ Stress Test και Load Test είναι ότι ο στόχος δεν είναι η επιβεβαίωση της απόδοσης, αλλά η μελέτη της συμπεριφοράς του συστήματος πέρα από τη σχεδιασμένη χωρητικότητά του. Η Netflix Engineering (2024) ορίζει το Stress Test ως “έλεγχο της υπόθεσης ότι το σύστημα θα αποτύχει με προβλέψιμο τρόπο”.

Οι δοκιμές αντοχής περιλαμβάνουν δύο υποχρεωτικά στάδια: φόρτωση μέχρι αποτυχίας και παρατήρηση ανάκτησης. Ανάκτηση (recovery) είναι η ικανότητα του συστήματος να επιστρέψει στην κανονική λειτουργία μετά την άρση της υπερφόρτωσης. Ένα σύστημα που δεν ανακάμπτει χωρίς επανεκκίνηση θεωρείται εύθραυστο, ακόμα κι αν αντέχει βραχυπρόθεσμη υπερφόρτωση. Σύμφωνα με το AWS Well-Architected Framework (2024), ο χρόνος ανάκτησης μετά από Stress Test δεν πρέπει να υπερβαίνει τα 5 λεπτά.

Για κινητούς πελάτες, το Stress Test περιλαμβάνει έλεγχο λειτουργίας υπό αναγκαστικό τερματισμό διεργασιών, αποσύνδεση δικτύου και εξάντληση μνήμης RAM. Android Low Memory Killer μπορεί να τερματίσει μια διεργασία παρασκηνίου όταν η RAM είναι ανεπαρκής — η δοκιμή αντοχής πρέπει να ελέγξει ότι η εφαρμογή ανακτά σωστά την κατάσταση μετά από έναν τέτοιο τερματισμό. Η Apple UIKit (2024) συνιστά τη δοκιμή σεναρίων memory warning σε κάθε οθόνη της εφαρμογής.

Στόχοι των δοκιμών αντοχής

Προσδιορισμός του σημείου αποτυχίας

Ο πρώτος στόχος του Stress Test — προσδιορισμός του σημείου αποτυχίας (breaking point). Αυτή είναι η στιγμή που ένας από τους βασικούς δείκτες απόδοσης υπερβαίνει ένα κρίσιμο όριο: ο χρόνος απόκρισης p95 υπερβαίνει τα 10 δευτερόλεπτα, το ποσοστό σφαλμάτων HTTP 5XX υπερβαίνει το 5% ή η απόδοση πέφτει κάτω από το 50% της βασικής γραμμής. Η καταγραφή του σημείου αποτυχίας επιτρέπει στην ομάδα να γνωρίζει εκ των προτέρων το όριο επεκτασιμότητας του συστήματος. Capacity planning βασίζεται ακριβώς στα δεδομένα του Stress Test, όχι του Load Test, επειδή το Load Test δεν ελέγχει οριακές συνθήκες.

Έλεγχος μηχανισμών ανάκτησης

Ο δεύτερος στόχος — έλεγχος μηχανισμών ανάκτησης. Αφού το φορτίο μειωθεί σε κανονικό επίπεδο, το σύστημα πρέπει να επιστρέψει στις τυπικές ενδείξεις. Εάν η δεξαμενή συνδέσεων στη βάση δεδομένων δεν ελευθερώνεται ή η προσωρινή μνήμη δεν ακυρώνεται, το Stress Test θα αποκαλύψει αυτό το πρόβλημα. Ο circuit breaker (Hystrix, Resilience4j) πρέπει να ενεργοποιείται κατά την υπερφόρτωση και να αποκαθιστά αυτόματα τη σύνδεση μετά τη σταθεροποίηση. Health check τελικά σημεία βοηθούν στην παρακολούθηση της κατάστασης κάθε υπηρεσίας κατά τη διάρκεια της δοκιμής.

Επικύρωση αυτόματης κλίμακας

Ο τρίτος στόχος — επικύρωση αυτόματης κλίμακας. Εάν η υποδομή χρησιμοποιεί Kubernetes ή AWS Auto Scaling, το Stress Test ελέγχει αν νέα pods ή στιγμιότυπα δημιουργούνται αρκετά γρήγορα. Σύμφωνα με το Google Kubernetes Engine (2024), ο χρόνος ανάπτυξης ενός νέου pod δεν πρέπει να υπερβαίνει τα 30 δευτερόλεπτα από τη στιγμή ενεργοποίησης της μέτρησης HPA (Horizontal Pod Autoscaler). HPA πρέπει να κλιμακώνεται με βάση την CPU, τη μνήμη και προσαρμοσμένες μετρήσεις. Το Cluster Autoscaler προσθέτει νέους κόμβους εάν οι υπάρχοντες δεν χωρούν τα pods.

Μεθοδολογία Stress Test

Σταδιακή αύξηση φορτίου (Ramp-up Stress Test) — το πιο συνηθισμένο σενάριο. Το αρχικό φορτίο ορίζεται στο 50% του αναμενόμενου, στη συνέχεια κάθε 2 λεπτά αυξάνεται κατά 10% έως ότου το σύστημα αποτύχει. Αυτό το σενάριο επιτρέπει την εύρεση του ακριβούς ορίου αντοχής. Grafana Cloud k6 (2025) συνιστά βήμα αύξησης όχι μεγαλύτερο από 10% για την επίτευξη ομαλού γραφήματος χρόνου απόκρισης.

Απότομη αιχμή φορτίου (Spike Stress Test) — το φορτίο αυξάνεται από 10% σε 500% εντός 10–30 δευτερολέπτων. Αυτό το σενάριο προσομοιώνει καταστάσεις όπως η ιογενής διάδοση περιεχομένου ή επίθεση DDoS. Το Spike Stress Test ελέγχει όχι τόσο την απόδοση όσο τη βιωσιμότητα του συστήματος: την ικανότητα να μην καταρρεύσει εντελώς και να επιστρέψει στη λειτουργία μετά τη σταθεροποίηση. API Gateway πρέπει να ρυθμίσει τον περιορισμό ρυθμού (rate limiting) για την προστασία του backend από απότομες αιχμές.

Παρατεταμένη διατήρηση υπερφόρτωσης (Sustained Stress Test) — το σύστημα διατηρείται σε κατάσταση υπερφόρτωσης για 30–60 λεπτά. Αυτό το σενάριο αποκαλύπτει διαρροές πόρων που δεν εμφανίζονται σε βραχυπρόθεσμες δοκιμές. Διαρροή μνήμης σε εφαρμογές Java/Kotlin συσσωρεύεται σε 20–40 λεπτά εντατικής εργασίας και μόνο το Sustained Stress Test την ανιχνεύει.

Ανάλυση σημείου αποτυχίας και ανάκτησης

Σημείο αποτυχίας καθορίζεται με βάση τρία κριτήρια: χρόνο απόκρισης, ποσοστό σφαλμάτων και απόδοση. Συνήθως πρώτο υπερβαίνεται το όριο χρόνου απόκρισης — τα αιτήματα αρχίζουν να εκτελούνται περισσότερο από το καθορισμένο όριο. Στη συνέχεια αυξάνεται το ποσοστό σφαλμάτων: ο διακομιστής δεν προλαβαίνει να επεξεργαστεί αιτήματα και επιστρέφει 503. Τελευταία πέφτει η απόδοση — το σύστημα σταματά να ανταποκρίνεται ακόμα και σε ελάχιστο φορτίο. Μέτρηση του σημείου αποτυχίας καταγράφεται στο προφίλ φόρτωσης για τον προγραμματισμό χωρητικότητας.

Ανάλυση ανάκτησης περιλαμβάνει τρεις φάσεις: άμεση αντίδραση (τα πρώτα 30 δευτερόλεπτα μετά την άρση φορτίου), σταθεροποίηση (1–5 λεπτά) και πλήρη ανάκτηση (5–30 λεπτά). Στη φάση άμεσης αντίδρασης, ο χρόνος απόκρισης πρέπει να πέσει κάτω από τη βασική γραμμή — το σύστημα απελευθερώνεται από ουρές. Εάν αυτό δεν συμβεί, το πρόβλημα δεν είναι στο φορτίο αλλά στη συσσωρευμένη κατάσταση. Graceful degradation — η ικανότητα του συστήματος να διατηρεί μερική λειτουργικότητα υπό υπερφόρτωση — βασικός δείκτης ωριμότητας της αρχιτεκτονικής.

Το Chaos Engineering συμπληρώνει το Stress Test εισάγοντας σκόπιμα βλάβες: απενεργοποίηση διακομιστή βάσης δεδομένων, καθυστέρηση δικτύου, διακοπή μικροϋπηρεσίας. Chaos Monkey από τη Netflix (2024) τερματίζει τυχαία διεργασίες στην παραγωγή, ελέγχοντας την ανθεκτικότητα του συστήματος. Για εφαρμογές για κινητά, το Chaos Engineering σημαίνει δοκιμή σεναρίων: απουσία δικτύου, μη διαθεσιμότητα API, κενή απόκριση διακομιστή.

Εργαλεία για Stress Test

k6 με ramping-arrival-rate

k6 υποστηρίζει Stress Test μέσω της ενότητας `execution` με διαμόρφωση ramping-arrival-rate. Αυτή η λειτουργία αυξάνει τον αριθμό αιτημάτων ανά δευτερόλεπτο ανεξάρτητα από τον χρόνο εκτέλεσης κάθε αιτήματος. Σε σύγκριση με το Load Test, το Stress Test στο k6 απαιτεί ρύθμιση πιο επιθετικών thresholds και απενεργοποίηση του gracefull-stop για προσομοίωση απότομης αποτυχίας. Το Grafana Cloud ανιχνεύει αυτόματα το σημείο αποτυχίας βάσει της καμπής στο γράφημα χρόνου απόκρισης. k6-operator για Kubernetes επιτρέπει την εκτέλεση κατανεμημένων Stress Test από το σύμπλεγμα.

JMeter με Ultimate Thread Group

JMeter επιτρέπει τη διαμόρφωση Stress Test μέσω του Ultimate Thread Group — ενός πρόσθετου που ορίζει το προφίλ φόρτωσης σε μορφή πίνακα: αριθμός νημάτων, χρόνος προθέρμανσης, χρόνος διατήρησης, χρόνος πτώσης. Το Ultimate Thread Group είναι βολικό για σύνθετα πολυφασικά σενάρια. JMeter Backend Listener στέλνει μετρήσεις στο InfluxDB για τη δημιουργία γραφημάτων σημείου αποτυχίας. Για Stress Test στο JMeter, συνιστάται η απενεργοποίηση χρονικών ορίων σύνδεσης για ακριβέστερη μέτρηση της συμπεριφοράς υπό υπερφόρτωση.

Gremlin για Chaos Engineering

Gremlin — πλατφόρμα Chaos Engineering για Stress Test υποδομής. Το Gremlin επιτρέπει την απενεργοποίηση δικτύου, τη φόρτωση CPU, την πλήρωση δίσκου και τον τερματισμό διεργασιών σε επίπεδο μεμονωμένων pods Kubernetes. Οι ομάδες SRE χρησιμοποιούν το Gremlin μαζί με το k6 για ολοκληρωμένο Stress Test: το k6 δημιουργεί φορτίο, το Gremlin εισάγει βλάβες. Game Day — τακτικές συνεδρίες Stress Test με Gremlin που τεκμηριώνονται σε “αναφορά χάους” για ανάλυση ανθεκτικότητας του συστήματος.

Παράδειγμα Stress Test στο k6

Το παρουσιαζόμενο σενάριο στο k6 δείχνει ένα Stress Test με σταδιακή αύξηση φορτίου μέχρι αποτυχίας. Ramping-arrival-rate αυξάνει τον αριθμό αιτημάτων ανά δευτερόλεπτο ανεξάρτητα από τον χρόνο εκτέλεσης. Τα thresholds έχουν ρυθμιστεί για επιθετική ανίχνευση υποβάθμισης: p95 όχι περισσότερο από 2000 ms, error rate όχι περισσότερο από 5%. Κατά την υπέρβαση των ορίων, το k6 τερματίζει τη δοκιμή με κωδικό σφάλματος, επιτρέποντας την ενσωμάτωση του Stress Test στο CI/CD pipeline.

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 στο staging — οι δοκιμές αντοχής στην παραγωγή απαιτούν προηγμένη παρακολούθηση και σχέδιο επαναφοράς. Η Google SRE (2024) συνιστά τη διεξαγωγή Stress Test σε 100% απομονωμένο περιβάλλον που αναπαράγει την παραγωγή ως προς την αρχιτεκτονική και τις χωρητικότητες. Μετά από επιτυχημένη δοκιμή στο staging, μπορείτε να προχωρήσετε στην παραγωγή υπό την επίβλεψη του SRE. Feature flag για απενεργοποίηση λειτουργικότητας κατά την υπερφόρτωση είναι υποχρεωτικό στοιχείο.

Αυτοματοποιήστε το Stress Test στο CI/CD για ανάλυση παλινδρόμησης του σημείου αποτυχίας. Εάν μια νέα έκδοση της εφαρμογής έχει σημείο αποτυχίας 20% χαμηλότερο από την προηγούμενη, αυτό είναι μια παλινδρόμηση που πρέπει να διορθωθεί πριν από την κυκλοφορία. Baseline breaking point αποθηκεύεται σε μετρήσεις και συγκρίνεται αυτόματα με το αποτέλεσμα κάθε Stress Test. Ειδοποίηση ενεργοποιείται όταν το σημείο αποτυχίας πέσει κατά 10%.

Τεκμηριώστε κάθε Stress Test: προφίλ φόρτωσης, σημείο αποτυχίας, συμπεριφορά ανάκτησης και λίστα ανακαλυφθέντων προβλημάτων. Η Netflix Engineering (2024) διοργανώνει “Game Day” — τακτικές συνεδρίες Stress Test των οποίων τα αποτελέσματα τεκμηριώνονται σε “αναφορά χάους”. Αναφορά δοκιμών αντοχής πρέπει να περιέχει το γράφημα “RPS — χρόνος απόκρισης” με σημειωμένο το σημείο αποτυχίας.