Είστε εφημερεύων για μια υπηρεσία ιστού: έναν load balancer μπροστά από έναν στόλο στιγμιοτύπων, μια cache μπροστά από μια βάση δεδομένων, και στόχο διαθεσιμότητας 99,9 %. Κάθε λεπτό το μοντέλο υπολογίζει καθυστέρηση ουράς, timeouts, cache hits και φορτίο βάσης δεδομένων από τύπους εγχειριδίου — και το κόστος των αποφάσεών σας.
Κατώτατο όριο για τον στόλο. Η αύξησή του ξεκινά αμέσως στιγμιότυπα — χρειάζονται όμως ακόμη την καθυστέρηση εκκίνησης πριν εξυπηρετήσουν.
Παρακολούθηση στόχου στη χρήση· καμία νέα κλιμάκωση προς τα πάνω όσο ακόμη εκκινούν στιγμιότυπα. Off = ακριβώς το ελάχιστο.
Χαμηλότερο = περισσότερο περιθώριο και περισσότερο κόστος. Η μετρούμενη χρήση δεν μπορεί να ξεπεράσει το 100 %, οπότε ένας κορεσμένος στόλος μεγαλώνει μόνο βήμα βήμα.
Μεγαλύτερο TTL = περισσότερα hits, αλλά οι απαντήσεις μπορεί να είναι παλαιότερες (μέση ηλικία ≈ TTL/2).
Φορτώνει δημοφιλή κλειδιά για 6 λεπτά (+12 % της cache ανά λεπτό) με κόστος 600 επιπλέον ερωτήματα βάσης δεδομένων/s.
Ποσοστό του 30 % χαμηλής προτεραιότητας (prefetch, batch, crawlers) που απορρίπτεται στον load balancer με «δοκιμάστε ξανά αργότερα».
Η βαριά λειτουργία προσθέτει 20 ms CPU και ένα ερώτημα βάσης δεδομένων ανά αίτημα. Off = ελεγχόμενη υποβάθμιση.
Αναπτύσσει ξανά την τελευταία καλή έκδοση σε νέο στόλο (5 min, χρεώνεται δύο φορές) και μετά αλλάζει την κίνηση. Αν πατήσετε ξανά, η προετοιμασία ξαναρχίζει· χωρίς κακή έκδοση σε λειτουργία, απλώς κοστίζει χρήματα.
| Ρυθμός κατανάλωσης (1 h) | 0,0 × |
|---|---|
| Αιτήματα | 1125 req/s |
| Στιγμιότυπα που εξυπηρετούν | 10 |
| Στιγμιότυπα που εκκινούν | 0 |
| Ποσοστό cache hit | 77 % |
| Χρήση βάσης δεδομένων | 19 % |
| Κίνηση που αποβλήθηκε | 0 % |
| Κόστος στόλου | 4,00 $/h |
| Κόστος μέχρι τώρα | 0,00 $ |
| Μέση ηλικία των απαντήσεων στη cache | 30 s |
| Κίνηση στην κακή έκδοση | 0 % |
| Προτάσεις διαθέσιμες | 100 % |
Μια νέα έκδοση βγαίνει στις 09:10. Ο μήνας ήταν ήδη δύσκολος: απομένει μόνο το 20 % του προϋπολογισμού σφαλμάτων. Λεπτά μετά την ανάπτυξη χτυπά η ειδοποίηση ρυθμού κατανάλωσης. Προστατέψτε τον προϋπολογισμό.
Ένας σύνδεσμος προς την υπηρεσία εξαπλώνεται γρήγορα και αναμένεται κορύφωση της κίνησης κάποια στιγμή σήμερα το πρωί — κανείς δεν ξέρει πότε ή πόσο μεγάλη. Οι νέες παρουσίες χρειάζονται σήμερα 8 λεπτά για να ξεκινήσουν. Όταν έρθει, κρατήστε χαμηλά τα σφάλματα και την καθυστέρηση χωρίς να καίτε χρήματα σε αναξιοποίητη δυναμικότητα.
Στη μεσημεριανή αιχμή ένα script συντήρησης αδειάζει ολόκληρη την cache. Κάθε αίτημα πηγαίνει τώρα στη βάση δεδομένων, που είχε διαστασιολογηθεί για το συνηθισμένο ποσοστό hit 85 %. Επαναφέρετε την υπηρεσία χωρίς να υπερφορτώσετε τη βάση δεδομένων.
Κάθε σχέση που χρησιμοποιεί ο προσομοιωτής, με την πηγή της. Οι σταθερές που σημειώνονται ως παραδοχές είναι ενδεικτικές βαθμονομήσεις.
λ(t) = base × (1 + 0.25·sin(2π(t + clock − 6 h)/24 h)) × surge(t), clock = time of day at the start (peak at 12:00); count/min ≈ N(60λ, √(60λ)) × (1 + N(0, 0.02))[6]Παραδοχή: αριθμοί workers, χρόνοι εξυπηρέτησης, χωρητικότητα βάσης δεδομένων, μέγεθος cache, ταχύτητα αναπλήρωσης, τιμές και το ποσοστό σφαλμάτων της κακής έκδοσης είναι ενδεικτικές τιμές για μια υπηρεσία ιστού μεσαίου μεγέθους.N = instances × 16 workers, a = λ·S; C(a, N) = B / (1 − (a/N)(1 − B)), B = Erlang B[3][6]P(W > t) = C·e^(−(N/S − λ)·t); timeouts = P(W > 2 s); a ≥ N ⇒ failed share = 1 − N/a[3]p99 ≈ S·ln 100 + ln(C/0.01)/(N/S − λ) (service + waiting quantile, an approximation)[3][6]Προσέγγιση: η πρόσθεση των ποσοστημορίων εξυπηρέτησης και αναμονής δεν είναι το ακριβές p99 του αθροίσματός τους (μπορεί να είναι λίγο υψηλό ή χαμηλό)· η ουρά αντιμετωπίζεται ως μόνιμη εντός κάθε λεπτού επειδή τα αιτήματα διαρκούν χιλιοστά του δευτερολέπτου.busy workers L = λ·S ⇒ utilization = λ·S / N[4]hit = warm × rT/(1 + rT), r = λ / 20,000 objects; mean age of a cached answer ≈ T/2[5]DB load = λ·q·(1 − hit); query time = 5 ms/(1 − ρ_db) (≤ 250 ms); S = S_app + (1 − hit)·q·query time[6]Παραδοχή: αριθμοί workers, χρόνοι εξυπηρέτησης, χωρητικότητα βάσης δεδομένων, μέγεθος cache, ταχύτητα αναπλήρωσης, τιμές και το ποσοστό σφαλμάτων της κακής έκδοσης είναι ενδεικτικές τιμές για μια υπηρεσία ιστού μεσαίου μεγέθους.budget = 1 − SLO = 0.1 %; burn = error rate / 0.1 %; Δbudget per min = burn / 43,200; burn (1 h) = mean error rate over the last 60 min / 0.1 % (window pre-filled with the opening minute)[1][2]desired = ⌈serving × utilization / target⌉ (utilization saturates at 100 %); new instances serve after the boot delay[6]Παραδοχή: αριθμοί workers, χρόνοι εξυπηρέτησης, χωρητικότητα βάσης δεδομένων, μέγεθος cache, ταχύτητα αναπλήρωσης, τιμές και το ποσοστό σφαλμάτων της κακής έκδοσης είναι ενδεικτικές τιμές για μια υπηρεσία ιστού μεσαίου μεγέθους.16 workers/instance · app time 50 ms (+20 ms and +1 query with the feature on) · 2 queries/request · DB 4,000 queries/s · 20,000 hot objects · cache refill τ = 30 min (slower while the DB is saturated) · warm-up job +12 %/min for 6 min, +600 queries/s · timeout 2 s · 30 % low-priority traffic · bad build +5 % errors, ×1.25 CPU · rollback 5 min · $0.40 per instance-hour · scale-in by ≤ 20 % of the fleet after 10 quiet minutes · up to 40 instancesΠαραδοχή: αριθμοί workers, χρόνοι εξυπηρέτησης, χωρητικότητα βάσης δεδομένων, μέγεθος cache, ταχύτητα αναπλήρωσης, τιμές και το ποσοστό σφαλμάτων της κακής έκδοσης είναι ενδεικτικές τιμές για μια υπηρεσία ιστού μεσαίου μεγέθους.Τυχαιότητα: γεννήτρια mulberry32 με seed· κατανομές που χρησιμοποιούνται — ομοιόμορφη, εκθετική (αντίστροφη CDF), κανονική (Box–Muller), Poisson (Knuth). Το seed εμφανίζεται και μπορεί να κοινοποιηθεί.
Εκπαιδευτικό μοντέλο — όχι για επιχειρησιακές αποφάσεις. Οι πραγματικές εγκαταστάσεις βαθμονομούν κάθε σταθερά με βάση τον δικό τους εξοπλισμό και δεδομένα.