Πώς να οικοδομήσετε πραγματικά μια ασφαλή και αξιόπιστη αρχιτεκτονική cloud AWS χωρίς να χάσετε το μυαλό σας

Εισαγωγή

Αν έχετε προσπαθήσει ποτέ να σχεδιάσετε αρχιτεκτονική νέφους στο AWS από το μηδέν, πιθανότατα γνωρίζετε ήδη: πρόκειται για ίσα μέρη ελευθερίας και χάους. Υπάρχουν χίλιοι τρόποι για να φτιάξετε κάτι και εξίσου πολλοί τρόποι για να το καταστρέψετε.

Μια σύντομη ματιά στην τεκμηρίωση του AWS μπορεί να σας αφήσει να σκεφτείτε: "Ωραία, απλά θα τηρήσουμε τις πρακτικές πρώτης τάξεως". Αλλά σε πραγματικά-διεθνή περιβάλλοντα, οι πρώτης τάξεως πρακτικές δεν ζουν συχνά σε πρώτη επαφή με τις πραγματικές ανάγκες της εμπορικής επιχείρησης, τα όρια του εύρους τιμών ή το ανθρώπινο λάθος. Αυτός είναι ο λόγος για τον οποίο η συνεργασία με επαγγελματίες όπως η perfsys από νωρίς μπορεί να αποτρέψει το τζόγο με τρύπες προστασίας και επιπλοκές κλιμάκωσης αργότερα.

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

Ας ξεκινήσουμε με το προφανές: το AWS είναι ένα θηρίο

Μπορείτε να κατασκευάσετε πρακτικά τα πάντα με το AWS. Από νεοσύστατες επιχειρήσεις δύο ατόμων μέχρι εκτεταμένες επιχειρηματικές πλατφόρμες, τα δομικά στοιχεία είναι όλα εκεί - EC2, Lambda, RDS, S3, IAM, VPC, ο κατάλογος συνεχίζεται. Η παγίδα; Όσο περισσότερες επιλογές έχετε, τόσο πιο εύκολο είναι να δημιουργήσετε ένα μπερδεμένο χάος.

Δεν είναι ότι το AWS είναι κακοσχεδιασμένο. Απλώς πρέπει να το σχεδιάσετε σωστά. Διαφορετικά, καταλήγετε με αυτό που μερικές ομάδες αποκαλούν "σπαγγέτι του cloud": αλληλοεξαρτώμενες υπηρεσίες, σκληρά κωδικοποιημένα μυστικά, καμία επισήμανση, καμία καταγραφή και απολύτως καμία ιδέα για το τι κοστίζει πόσο.

Η αξιοπιστία και η ασφάλεια δεν είναι κάτι που πρέπει να έχετε

Είναι δελεαστικό να αντιμετωπίζετε την ασφάλεια και την αξιοπιστία ως μελλοντικό σας πρόβλημα. "Θα το ασφαλίσουμε αφού ξεκινήσουμε τη λειτουργία του". "Θα προσθέσουμε παρακολούθηση στο επόμενο σπριντ". Αλλά ρωτήστε όποιον έχει αντιμετωπίσει παραβίαση δεδομένων ή πολύωρη διακοπή λειτουργίας - παραλείποντας αυτά τα βήματα καταλήγετε να ξενυχτάτε.

Τι σημαίνει πραγματικά αξιοπιστία

Αυτό δεν έχει να κάνει με τις εγγυήσεις διαθεσιμότητας σε ένα slide deck. Πρόκειται για μηχανική για αποτυχία. Οι υπηρεσίες καταρρέουν. Οι δίσκοι αποτυγχάνουν. Τα APIs σταματούν να λειτουργούν. Αυτό που έχει σημασία είναι αν το σύστημά σας συνεχίζει να λειτουργεί όταν τα πράγματα χαλάνε.

Έχετε πλεονασμό σε όλες τις ζώνες διαθεσιμότητας; Μπορεί το σύστημά σας να αντέξει έναν αποτυχημένο κόμβο βάσης δεδομένων χωρίς να χάσει δεδομένα ή να εμφανίσει σφάλματα; Εκτελείτε κρίσιμους φόρτους εργασίας σε μία μόνο περιοχή επειδή "αυτό ήταν πιο εύκολο να αναπτυχθεί"; Αυτές είναι οι ερωτήσεις που διαχωρίζουν τα λειτουργικά συστήματα από τα ανθεκτικά.

Και η ασφάλεια; Δεν είναι μόνο το IAM

Ναι, η διαχείριση ταυτότητας και πρόσβασης (IAM) είναι το πρώτο τείχος. Αλλά η ασφάλεια εκτείνεται πολύ πέρα από αυτό. Δημόσια προσβάσιμοι κάδοι S3. Υπερβολικά εξουσιοδοτημένοι ρόλοι. Μυστικά κωδικοποιημένα σε συναρτήσεις Lambda. Απενεργοποιημένη καταγραφή "για εξοικονόμηση κόστους". Όλα αυτά είναι ωρολογιακές βόμβες.

Η χρήση του καλά σχεδιασμένου πλαισίου της aws μπορεί να βοηθήσει στον εντοπισμό αυτών των ζητημάτων πριν εκραγούν. Διαχωρίζει την αρχιτεκτονική σε πέντε βασικούς τομείς - ασφάλεια, αξιοπιστία, λειτουργική αριστεία, αποδοτικότητα απόδοσης και βελτιστοποίηση κόστους - και αναγκάζει τις ομάδες να αξιολογήσουν τον καθένα, με ειλικρίνεια. Δεν είναι μια ασημένια σφαίρα, αλλά σας ωθεί να κάνετε δύσκολες ερωτήσεις.

Τα δομικά στοιχεία που έχουν πραγματικά σημασία

Εντάξει, ας μπούμε στο ζουμί της υπόθεσης. Ακολουθούν τα στοιχεία που έχουν σημασία όταν χτίζετε ασφαλή, αξιόπιστη αρχιτεκτονική στο AWS - και τα σημεία στα οποία οι ομάδες κάνουν συχνότερα λάθη.

Χρησιμοποιήστε τους ρόλους IAM με τον σωστό τρόπο (ναι, πραγματικά)

Οι ρόλοι IAM είναι ισχυροί. Πολύ ισχυροί, μερικές φορές. Είναι πάρα πολύ εύκολο να βάλεις τον ρόλο "AdministratorAccess" επειδή κάτι δεν λειτουργεί, να υποσχεθείς ότι θα το διορθώσεις αργότερα... και στη συνέχεια να μην το διορθώσεις ποτέ.

Πρέπει να το κλειδώσετε από νωρίς. Η αρχή των λιγότερων προνομίων δεν είναι απλώς μια βέλτιστη πρακτική - είναι ο μόνος λογικός τρόπος λειτουργίας. Αυτό σημαίνει:

• Ρόλοι ανά υπηρεσία

• Αποφυγή μπαλαντέρ στα δικαιώματα

• Πιστοποιητικά σύντομης διάρκειας

• Υποχρεωτική MFA για τους ανθρώπινους χρήστες

Ακούγεται ενοχλητικό; Είναι. Αλλά το ίδιο και το να εξηγήσετε στο αφεντικό σας γιατί κάποιος διέρρευσε δεδομένα πελατών από ένα λανθασμένα ρυθμισμένο Lambda.

Διαχωρίστε το δίκτυό σας όπως το εννοείτε

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

• Δημόσια υποδίκτυα μόνο για πράγματα που πρέπει να βλέπουν στο διαδίκτυο (π.χ. ALB)

• Ιδιωτικά υποδίκτυα για όλα τα υπόλοιπα

• Πύλες NAT για ελεγχόμενη εξερχόμενη πρόσβαση

• Τελικά σημεία VPC για την κυκλοφορία υπηρεσιών AWS χωρίς να φτάνει στο δημόσιο διαδίκτυο

Ένα επίπεδο VPC με τα πάντα στο ίδιο υποδίκτυο μπορεί να φαίνεται εύκολο. Μέχρι που κάτι χαλάει και τα παίρνει όλα μαζί του.

Καταγραφή και παρακολούθηση: Παρακολούθηση: Δεν μπορείτε να διορθώσετε ό,τι δεν μπορείτε να δείτε

Αυτό δεν θα έπρεπε καν να αποτελεί πλέον αντικείμενο συζήτησης. Η καταγραφή δεν είναι προαιρετική. Αν δεν καταγράφετε τα CloudTrail, τις μετρήσεις του CloudWatch και τα αρχεία καταγραφής ροής VPC, πετάτε στα τυφλά.

Αλλά εδώ είναι η παγίδα - η καταγραφή από μόνη της δεν είναι αρκετή. Πρέπει να εξετάζετε πραγματικά τα αρχεία καταγραφής. Δημιουργήστε ειδοποιήσεις για τα πράγματα που έχουν σημασία. Φιλτράρετε το θόρυβο. Και βεβαιωθείτε ότι τα αρχεία καταγραφής είναι συγκεντρωμένα σε όλους τους λογαριασμούς και τις περιοχές. Η κατακερματισμένη ορατότητα δεν είναι ορατότητα.

Κρυπτογράφηση των πάντων (χωρίς εξαιρέσεις)

Χρησιμοποιήστε KMS για δεδομένα σε κατάσταση ηρεμίας. Χρησιμοποιήστε TLS για δεδομένα κατά τη μεταφορά. Εναλλαγή κλειδιών. Παρακολουθήστε την πρόσβαση. Αυτός είναι ένας από εκείνους τους τομείς όπου το να είστε τεμπέληδες τώρα κοστίζει πολύ ακριβά αργότερα.

Και μην ξεχνάτε πράγματα όπως η κρυπτογράφηση RDS, οι ρυθμίσεις όγκου EBS και η επιβολή TLS στην πύλη API. Αυτές οι μικρές λεπτομέρειες συσσωρεύονται.

Υποδομή ως κώδικας ή καταστροφή

Εξακολουθείτε να αναπτύσσετε κάνοντας κλικ στην κονσόλα του AWS; Αυτό είναι καλό για την ανάπτυξη, επικίνδυνο για την παραγωγή.

Χρησιμοποιήστε Terraform, CloudFormation ή CDK. Ό,τι προτιμά η ομάδα σας - απλά επιλέξτε ένα και μείνετε σε αυτό. Ελέγξτε τα πρότυπά σας. Χρησιμοποιήστε CI/CD για την ανάπτυξη. Αυτοματοποιήστε τις επαναφορές. Οι χειροκίνητες αναπτύξεις είναι μια ανοιχτή πρόσκληση για λάθη.

Επίσης: επισημάνετε τα πάντα. Οι πόροι χωρίς ετικέτες είναι σαν τα καλώδια χωρίς ετικέτες - κανείς δεν ξέρει για τι προορίζονται και όλοι φοβούνται να τους αγγίξουν.

Κλιμάκωση χωρίς βύθιση

Ας το ξεκαθαρίσουμε: το AWS λατρεύει όταν κάνετε over-provision. Εσείς παίρνετε "επιδόσεις", εκείνοι παίρνουν τα χρήματά σας. Η αποτελεσματική κλιμάκωση έχει να κάνει με το να γνωρίζετε τα μοτίβα σας - και να τα σχεδιάζετε.

Χρησιμοποιήστε ομάδες αυτόματης κλιμάκωσης, spot instances (προσεκτικά) και επίπεδα προσωρινής αποθήκευσης. Αλλά το πιο σημαντικό: κάντε δοκιμές υπό φορτίο. Το τελευταίο πράγμα που θέλετε είναι να ανακαλύψετε ότι το RDS instance σας λιώνει κάτω από πραγματική κίνηση δύο ημέρες μετά την έναρξη λειτουργίας.

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

Τα σχέδια αποκατάστασης από καταστροφές δεν είναι προαιρετικά

Τι συμβαίνει αν μια περιοχή πέσει; Τι γίνεται αν καταστραφεί η κύρια βάση δεδομένων σας; Αν η απάντηση είναι "ε... θα έχουμε πρόβλημα", τότε ήρθε η ώρα να αναθεωρήσετε τη στρατηγική DR σας.

Αυτό δεν σημαίνει ότι πρέπει να δημιουργήσετε ένα πανομοιότυπο αντίγραφο της υποδομής σας σε μια άλλη περιοχή. Σημαίνει να γνωρίζετε:

• Τι θα επαναφέρετε

• Πόσο χρόνο θα χρειαζόταν

• Ποια δεδομένα θα χαθούν (αν υπάρχουν)

• Ποιος είναι υπεύθυνος για τι κατά τη διάρκεια μιας αποτυχίας

Και ναι - θα πρέπει να δοκιμάσετε το σχέδιο αποκατάστασης. Διαφορετικά, πρόκειται απλώς για φαντασία.

Κοινά αντι-πρότυπα προς αποφυγή

Ας ρίξουμε μια γρήγορη φωτιά σε μερικά μη-όχι που εμφανίζονται πολύ συχνά:

• Ένας μεγάλος λογαριασμός για τα πάντα: χρησιμοποιήστε AWS Organizations. Διαχωρίστε prod, dev, staging κ.λπ.

• Αφήστε ανέγγιχτα τα προεπιλεγμένα VPC και τις ομάδες ασφαλείας: κλειδώστε τα.

• Υπερβολική στήριξη σε t2.micro instances "για δοκιμές" - θα καταλήξουν τελικά στο prod.

• Μη κατάρτιση προϋπολογισμού για το κόστος του CloudWatch: ναι, η καταγραφή κοστίζει χρήματα. Η μη καταγραφή κοστίζει περισσότερο.

• Δίνοντας πρόσβαση στο "απλά διορθώστε το γρήγορα": διορθώστε αντ' αυτού τη διαδικασία σας.

Τελικές λέξεις; Μείνετε ευέλικτοι, μείνετε λογικοί

Η αρχιτεκτονική νέφους δεν έχει να κάνει με την εύρεση της τέλειας εγκατάστασης. Έχει να κάνει με τη δημιουργία κάτι που είναι ευέλικτο, στιβαρό και κατανοητό από περισσότερους από το άτομο που το έγραψε.

Ποτέ δεν είσαι πραγματικά "έτοιμος" - και αυτό δεν πειράζει. Αυτό που έχει σημασία είναι να είσαι σκόπιμος. Να κάνεις δύσκολες ερωτήσεις νωρίς. Συχνός έλεγχος. Να αυτοματοποιείς εκεί που μετράει. Και να ξέρεις πότε να καλέσεις βοήθεια.

Επειδή ας είμαστε ειλικρινείς - το AWS είναι ισχυρό, αλλά είναι επίσης εύκολο να χαθείς μέσα του. Η συνεργασία με έμπειρους μηχανικούς που ζουν και αναπνέουν την αρχιτεκτονική του cloud μπορεί να κάνει τη διαφορά μεταξύ του "λειτουργεί, ως επί το πλείστον" και του "κοιμόμαστε τη νύχτα".

Και γι' αυτό αξίζει να χτίζετε.