Μετρήστε πριν επιστρέψετε από το cloud: διαστασιολόγηση εξόδου από την πραγματική χρήση

Το πιο ακριβό λάθος στην αποχώρηση από το public cloud είναι να αντιγράψετε την υποδομή όπως είναι. Τα περιβάλλοντα cloud μεγαλώνουν με provisioning, και το provisioned δεν είναι το used: μεγέθη instances που επιλέχθηκαν βιαστικά, volumes διαστασιολογημένα για μια αιχμή που δεν ήρθε ποτέ, υπηρεσίες που κανείς δεν θυμάται να ξεκίνησε. Μεταφέρετέ τα ένα προς ένα και κουβαλάτε τη σπατάλη σε ένα σταθερό συμβόλαιο. Εδώ είναι πώς μετράτε τι πραγματικά τρέχει πριν κανείς σχεδιάσει κάτι νέο.

Το πρόβλημα: ο λογαριασμός περιγράφει τι νοικιάζετε, όχι τι χρησιμοποιείτε

Ένα τιμολόγιο cloud απαριθμεί τύπους instances, μεγέθη volumes και επίπεδα υπηρεσιών. Τίποτα από αυτά δεν σας λέει πόση CPU κατανάλωσε η εφαρμογή σας στην πιο φορτωμένη της ώρα, πόσα IOPS έκανε πραγματικά η βάση δεδομένων, ή πόση μνήμη κρατά πραγματικά η cache. Αυτοί είναι οι αριθμοί που χρειάζεται ένας σχεδιασμός φυσικής υποδομής ή private cloud, και ο πάροχος cloud τους κατέγραφε για εσάς όλο αυτό τον καιρό.

Βήμα πρώτο: απογράψτε τα πάντα, όχι μόνο τους servers

Ξεκινήστε με μια πλήρη λίστα πόρων σε κάθε region που χρησιμοποιήσατε ποτέ. Τα tags βοηθούν, αλλά οι πόροι χωρίς tags είναι ακριβώς αυτοί που πρέπει να βρείτε:

for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  aws resourcegroupstaggingapi get-resources --region "$r" \
    --query 'ResourceTagMappingList[].ResourceARN' --output text
done | tr '\t' '\n' | sort > inventory.txt

Μετά ομαδοποιήστε ανά υπηρεσία. Οι servers είναι συνήθως το εύκολο κομμάτι. Η δουλειά είναι σε ό,τι τους περιβάλλει: managed βάσεις δεδομένων, caches, load balancers, ζώνες DNS, ουρές, object buckets, πιστοποιητικά, προγραμματισμένες functions, και οι ρόλοι IAM και τα security groups που τα δένουν μεταξύ τους. Καθένα χρειάζεται έναν ιδιοκτήτη και μια απόφαση: μεταφορά, αντικατάσταση, διατήρηση ή απόσυρση.

Βήμα δεύτερο: διαβάστε εκατοστημόρια, όχι μέσους όρους

Για κάθε υπολογιστικό πόρο, τραβήξτε τουλάχιστον έναν μήνα χρήσης, και διαβάστε το 95ο εκατοστημόριο και το μέγιστο αντί για τον μέσο όρο. Ο μέσος όρος μιας ήσυχης νύχτας και ενός φορτωμένου απογεύματος δεν περιγράφει κανένα από τα δύο.

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=<instance-id> \
  --start-time "$(date -u -d '-30 days' +%FT%TZ)" --end-time "$(date -u +%FT%TZ)" \
  --period 3600 --extended-statistics p95 \
  --query 'Datapoints[].ExtendedStatistics.p95' --output text \
  | tr '\t' '\n' | sort -n | tail -1

Η μνήμη είναι το κενό: οι μετρικές του hypervisor δεν βλέπουν μέσα στον guest. Αν είναι εγκατεστημένος ο CloudWatch agent, οι μετρικές μνήμης του βρίσκονται στο namespace CWAgent. Αν όχι, συλλέξτε από μέσα από τα instances για κάνα δυο εβδομάδες με sar ή με την υπάρχουσα παρακολούθησή σας πριν διαστασιολογήσετε οτιδήποτε. Το να μαντεύετε τη μνήμη είναι ο τρόπος που οι σχεδιασμοί καταλήγουν είτε στερημένοι είτε σπάταλοι.

Κάντε το ίδιο για το storage: τα VolumeReadOps και VolumeWriteOps ανά volume σας δίνουν πραγματικά IOPS, και τα VolumeReadBytes και VolumeWriteBytes την απόδοση. Για managed βάσεις δεδομένων, διαβάστε CPUUtilization, FreeableMemory, ReadIOPS και WriteIOPS. Για caches, τη μνήμη που πραγματικά χρησιμοποιείται και τον αριθμό συνδέσεων. Για την κίνηση, το NetworkOut ανά instance δείχνει από πού έρχεται πραγματικά το egress, που έχει σημασία για τον σχεδιασμό του δικτύου, όχι μόνο για το τιμολόγιο.

Βήμα τρίτο: χτίστε το φύλλο διαστασιολόγησης

Βάλτε τις μετρήσεις σε ένα φύλλο, μία γραμμή ανά φόρτο εργασίας:

Φόρτος εργασίας	CPU p95	Μνήμη σε χρήση p95	IOPS p95	Μερίδιο egress	Αναμενόμενη ανάπτυξη

Μετά διαστασιολογήστε καθέναν στη μετρημένη αιχμή του με περιθώριο που μπορείτε να δικαιολογήσετε, όχι στο instance όπου τρέχει σήμερα. Δύο κανόνες που εφαρμόζουμε σε κάθε σχεδιασμό:

• Ποτέ μην δίνετε σε μια εικονική μηχανή περισσότερα vCPU από όσους φυσικούς πυρήνες έχει ένα CPU socket, ούτε περισσότερη μνήμη από όση εξυπηρετεί ένας κόμβος NUMA. Μια VM απλωμένη σε δύο sockets πληρώνει ποινή απομακρυσμένης μνήμης σε κάθε πρόσβαση και συχνά τρέχει πιο αργά από μια μικρότερη. Αν ένας φόρτος εργασίας χρειάζεται περισσότερα από ένα socket, χρειάζεται να κλιμακώσει οριζόντια ή να πάει σε bare metal.
• Σωστό μέγεθος, και μετά σταματάτε. Οι υποδομές cloud είναι συστηματικά υπερδιαστασιολογημένες επειδή η αλλαγή μεγέθους ήταν ριψοκίνδυνη. Σε αποκλειστική υποδομή το σωστό μέγεθος είναι φθηνότερο και συχνά ταχύτερο.

Βήμα τέταρτο: αντιστοιχίστε κάθε managed υπηρεσία σε κάτι δικό σας

Για κάθε managed υπηρεσία, γράψτε τι την αντικαθιστά και τι αλλάζει για την εφαρμογή:

Managed υπηρεσία	Αντικατάσταση που σας ανήκει	Τι αντιλαμβάνεται η εφαρμογή
Managed MySQL ή MariaDB	Percona XtraDB Cluster ή replicated MariaDB, πίσω από ProxySQL	ένα νέο endpoint, τίποτα άλλο
Managed Redis	Valkey ή Redis με Sentinel	σύνδεση μέσω Sentinel
Application load balancer	Ζεύγος HAProxy με floating διευθύνσεις	τίποτα
Managed DNS	η δική σας υποδομή PowerDNS	τίποτα, αν η μεταφορά γίνει με σειρά
Managed Kubernetes	OpenShift ή OKD σε bare metal	τα ίδια manifests, με τα storage classes ελεγμένα

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

Βήμα πέμπτο: σχεδιάστε για τα failure domains που αφήνετε πίσω

Τα availability zones έκαναν πραγματική δουλειά για εσάς, οπότε ο νέος σχεδιασμός πρέπει να κάνει την ίδια δουλειά ρητά. Αντιστοιχίστε κάθε tier σε ξεχωριστούς hosts, ξεχωριστές συστοιχίες storage και, όπου μετράει, ξεχωριστά sites. Οι υπηρεσίες με quorum (βάσεις δεδομένων, caches, coordinators) χρειάζονται τρία μέλη σε τρία failure domains. Γράψτε το tier προς tier. Το «ήταν multi AZ» δεν είναι σχεδιασμός.

Βήμα έκτο: σχεδιάστε τη μεταφορά του DNS ως το κρίσιμο μονοπάτι που είναι

Το DNS είναι συνήθως το τελευταίο που μεταφέρεται και αυτό που μπορεί να σπάσει τα πάντα μονομιάς. Αν η ζώνη είναι υπογεγραμμένη με DNSSEC, βάλτε σε σειρά την αλλαγή κλειδιού και εγγραφής DS ώστε οι validating resolvers να μη δουν ποτέ σπασμένη αλυσίδα. Περιγράφουμε την πλήρη μεταφορά ενός πελάτη από το AWS DNS στη σελίδα managed DNS.

Η checklist σας

• Μια πλήρης απογραφή σε όλα τα regions, με ιδιοκτήτη και απόφαση ανά πόρο.
• Τουλάχιστον ένας μήνας χρήσης p95 και αιχμής για CPU, μνήμη, IOPS και egress.
• Μνήμη μετρημένη από μέσα από τους guests, όχι μαντεμένη.
• Ένα φύλλο διαστασιολόγησης που διαστασιολογεί σε μετρημένες αιχμές, με τις VM μέσα σε ένα socket.
• Κάθε managed υπηρεσία αντιστοιχισμένη σε αντικατάσταση, ή συνειδητά διατηρημένη.
• Failure domains σχεδιασμένα ρητά, και η μεταφορά DNS σε σειρά.

Αν ζυγίζετε μια επιστροφή σε υποδομή που σας ανήκει, ευχαρίστως να ξεκινήσουμε με τη μέτρηση.

CTA

Μιλήστε με έναν μηχανικό

Related

Σχετικά: Επιστροφή από το cloud και έξοδοι από colocation · Μεταφορές datacenter με διαχείριση, με πρόβα · Κατασκευές πλατφορμών υψηλής διαθεσιμότητας