Γιατί μεταφέραμε τους διακομιστές του Mythex σε ARM

Στις 19 Σεπτεμβρίου μεταφέραμε το backend παραγωγής του Mythex από διακομιστές x86 σε μικρότερα διακομιστές AWS Graviton βασισμένους σε ARM, και τη βάση δεδομένων της πλατφόρμας σε μηχάνημα Graviton. Η αιτία ήταν απλή: αφού μεταφέραμε τη βαριά δουλειά — την εκτέλεση και την κατασκευή κάθε εφαρμογής χρήστη — σε απομονωμένα sandboxes ανά έργο, οι κύριοι διακομιστές μας έφταναν σε περίπου το ένα τρίτο της μνήμης τους. Μικρότερα μηχανήματα ARM χωρούν το πραγματικό φορτίο και μείωσαν το μηνιαίο κόστος διακομιστών κατά περίπου 30%.

Τι κάνουν πλέον οι διακομιστές μας

Νωρίτερα, τα backend διακομιστές έκαναν πολλή δουλειά απευθείας. Περίπου στα μέσα Σεπτεμβρίου ολοκληρώσαμε τη μεταφορά των ακριβών μερών — εκτέλεση του κώδικα κάθε έργου, εγκατάσταση πακέτων, κατασκευή εφαρμογών — σε ιδιωτικά sandboxes cloud, ένα ανά έργο. Αυτό είναι επίσης που δίνει σε κάθε έργο το δικό του απομονωμένο περιβάλλον και τη ζωντανή προεπισκόπηση.

Ό,τι έμεινε στους δικούς μας διακομιστές είναι ο συντονισμός: το API, ο ενορχηστρωτής που διαχειρίζεται τα sandboxes και τις δημοσιεύσεις, η ταυτοποίηση, η χρέωση και η πύλη. Αυτή η δουλειά είναι σταθερή και ελαφριά. Μετά τη μεταφορά, οι διακομιστές έφταναν περίπου τα 1,3 GB μνήμης σε μηχανήματα με περίπου τριπλάσια χωρητικότητα.

Γιατί ARM

Οι επεξεργαστές Graviton της AWS είναι chips ARM που σχεδίασε η AWS. Για το ίδιο κόστος παίρνετε συνήθως περισσότερη χωρητικότητα από ένα συγκρίσιμο x86 instance, ή την ίδια χωρητικότητα φθηνότερα — και για φορτίο σαν το δικό μας (υπηρεσίες Node.js, Docker, Postgres) δεν υπάρχει τίποτα που να μας δεσμεύει στο x86.

Μεταφέραμε:

• Δύο διακομιστές εφαρμογών από instances x86 μεσαίου μεγέθους σε μικρά instances Graviton με 2 GB RAM το καθένα.
• Τη βάση δεδομένων της πλατφόρμας από μικρό instance βάσης x86 στο ισοδύναμο Graviton.

Η μία πραγματική περιπλοκή: εικόνες για δύο αρχιτεκτονικές

Το περιβάλλον staging μας τρέχει ακόμη σε μικρό διακομιστή x86. Η παραγωγή τρέχει τώρα ARM. Μια εικόνα container που χτίζεται για τη μία δεν τρέχει στην άλλη.

Γι' αυτό κάθε εικόνα χτίζεται πλέον για τις δύο αρχιτεκτονικές κάτω από μία ετικέτα — μια multi-arch εικόνα. Το Docker επιλέγει αυτόματα τη σωστή παραλλαγή σε κάθε μηχάνημα, και η αγωγή ανάπτυξης δεν χρειάζεται να ξέρει σε ποιο περιβάλλον στέλνει. Το κόστος είναι ένα μεγαλύτερο χτίσιμο CI· το όφελος είναι ότι το staging και η παραγωγή τρέχουν ακριβώς τον ίδιο κώδικα από ακριβώς την ίδια ετικέτα.

Σχεδιάζοντας την επαναφορά πριν τη μεταφορά

Η αλλαγή αρχιτεκτονικής CPU κάτω από ζωντανή υπηρεσία είναι το είδος αλλαγής που θέλετε να μπορείτε να αναιρέσετε σε λεπτά. Πριν αλλάξουμε, εμείς:

• κρατήσαμε την προηγούμενη έκδοση του template διακομιστή ως ονομασμένο στόχο επαναφοράς,
• πήραμε στιγμιότυπο της βάσης αμέσως πριν αλλάξουμε το μέγεθός της, και
• γράψαμε ένα runbook που καλύπτει τη μεταφορά και τον δρόμο της επιστροφής.

Δεν χρειαστήκαμε την επαναφορά. Θα την κάναμε και πάλι με τον ίδιο τρόπο.

Τι θα προσέχαμε

Οι μικρότεροι διακομιστές έχουν λιγότερο περιθώριο. Από αυτό προκύπτουν δύο πράγματα:

1. Αν ποτέ μεταφερθεί ξανά βαριά δουλειά σε αυτούς τους διακομιστές, τα 2 GB δεν θα αρκούν. Η λύση τότε είναι μεγαλύτερο μέγεθος Graviton, όχι επιστροφή στο x86.
2. Τα μικρά μηχανήματα χρειάζονται swap. Μια εβδομάδα αργότερα, ένας από αυτούς τους διακομιστές πάγωσε από πίεση μνήμης χωρίς τεχνικά να τελειώσει η μνήμη — η ιστορία του λείποντος αρχείου swap.

Τι κρατήσαμε από όλο αυτό

• Μετρήστε ξανά μετά από αλλαγές αρχιτεκτονικής. Η μεταφορά δουλειάς σε sandboxes άλλαξε τι χρειάζονταν οι διακομιστές μας· τα μεγέθη instances δεν είχαν προλάβει.
• Το ARM είναι χαμηλού κινδύνου κέρδος για τυπικές web στοίβες όταν οι εικόνες σας είναι multi-arch.
• Γράψτε πρώτα την επαναφορά. Κάνει την αλλαγή πιο ήρεμη, ακόμη κι αν ποτέ δεν τη χρειαστείτε.