Studiu de caz: De ce folosesc AWS Cloud Infrastructure pentru produsele mele

Ca platformă pentru rularea unui produs software complex și solicitant, AWS oferă flexibilitate prin utilizarea resurselor atunci când este necesar, la scara necesară. Este la cerere și instantaneu, permițând control deplin asupra mediului de rulare. Atunci când propuneți o astfel de soluție de arhitectură cloud unui client, infrastructura furnizată și prețul acesteia depind în mare măsură de cerințele care trebuie configurate în avans.

Acest articol va prezenta o astfel de arhitectură a infrastructurii cloud AWS, propusă și implementată pentru LEVELS, o rețea socială cu o funcție de plată facială integrată care găsește și aplică toate beneficiile pe care utilizatorii le-ar putea obține pentru programele de carduri în care se află, lucrurile pe care le dețin sau locurile pe care le dețin. ei trăiesc în.

Cerințe

Clientul avea două cerințe principale pe care soluția propusă trebuia să le îndeplinească:

1. Securitate
2. Scalabilitate

Cerința de securitate a vizat protejarea datelor utilizatorilor împotriva accesului neautorizat din exterior, dar și din interior. Cerința de scalabilitate se referea la capacitatea infrastructurii de a sprijini creșterea produselor, adaptându-se automat la creșterea traficului și la vârfuri ocazionale, precum și la failover-ul și recuperarea automată în cazul defecțiunilor serverelor, minimizând timpul de nefuncționare potențial.

Prezentare generală a conceptelor de securitate AWS

Unul dintre principalele beneficii ale configurarii propriei infrastructuri AWS Cloud este izolarea completă a rețelei și controlul deplin asupra cloudului dvs. Acesta este motivul principal pentru care ați alege ruta Infrastructure as a Service (IaaS), în loc să rulați medii Platform as a Service (PaaS) ceva mai simple, care oferă valori implicite de securitate solide, dar nu dispun de controlul complet și fin pe care îl obțineți. configurați-vă propriul cloud cu AWS.

Deși LEVELS era un produs tânăr când au abordat Toptal pentru serviciile de consultanță AWS, ei au fost dispuși să se angajeze în AWS și știau că vor securitate de ultimă generație cu infrastructura lor, deoarece sunt foarte preocupați de datele utilizatorilor și de confidențialitate. În plus, plănuiesc să sprijine procesarea cardurilor de credit în viitor, așa că știau că va trebui să asigure conformitatea PCI-DSS la un moment dat.

Virtual Private Cloud (VPC)

Securitatea pe AWS începe cu crearea propriului Amazon Virtual Private Cloud (VPC) - o rețea virtuală dedicată care găzduiește resursele dvs. AWS și este izolată logic de alte rețele virtuale din AWS Cloud. VPC-ul primește propriul interval de adrese IP, subrețele complet configurabile, tabele de rutare, liste de control al accesului la rețea și grupuri de securitate (în mod efectiv, un firewall).

Cu LEVELS, am început prin a izola mediul nostru de producție de mediile de dezvoltare, testare și QA. Prima idee a fost să ruleze fiecare dintre ele ca propriul VPC complet izolat, fiecare rulând toate serviciile cerute de aplicație. După câteva analize, s-a dovedit că am putea permite o anumită partajare a resurselor în cele trei medii non-producție, ceea ce a redus costul într-o oarecare măsură.

Astfel, ne-am stabilit pe mediul de producție ca un singur VPC, cu medii de dezvoltare, testare și QA ca un alt VPC.

Izolarea accesului la nivel de VPC

Configurarea cu două VPC izolează mediul de producție de celelalte trei medii la nivel de rețea, asigurându-se că configurarea greșită accidentală a aplicației nu poate depăși această limită. Chiar dacă configurația mediului care nu este de producție ar trebui să indice în mod eronat resursele mediului de producție, cum ar fi bazele de date sau cozile de mesaje, nu există nicio modalitate de a obține acces la acestea.

Cu mediile de dezvoltare, testare și QA care partajează același VPC, accesul transfrontalier este posibil în caz de configurare greșită, dar, deoarece acele medii folosesc date de testare, nu există nicio problemă reală de securitate cu lipsa izolării acolo.

Modelul de securitate al magazinului de active

Activele sunt stocate în stocarea obiectelor Amazon Simple Storage Service (S3) . Infrastructura de stocare S3 este complet independentă de VPC-uri, iar modelul său de securitate este diferit. Stocarea este organizată în compartimente S3 separate pentru fiecare mediu și/sau clase de active, protejând fiecare compartiment cu drepturile de acces corespunzătoare.

Cu LEVELS, au fost identificate mai multe clase de active: încărcări ale utilizatorilor, conținut produs LEVELS (videoclipuri promoționale și conținut similar), aplicații web și active UI (cod JS, pictograme, fonturi), configurație de aplicație și infrastructură și pachete de implementări pe server.

Fiecare dintre acestea primește o găleată S3 separată.

Managementul secretelor aplicației

Cu AWS, există un AWS Systems Manager Parameter Store criptat sau AWS Secrets Manager , care sunt servicii gestionate cheie-valoare concepute pentru a păstra secretele în siguranță (puteți afla mai multe la Linux Academy și 1Strategy).

AWS gestionează cheile de criptare subiacente și se ocupă de criptare/decriptare. Secretele în sine pot avea politici de permisiuni de citire și scriere aplicate pe baza prefixelor cheie, atât pentru infrastructură, cât și pentru utilizatori (servere și, respectiv, dezvoltatori).

Acces SSH la server

Accesul SSH la servere într-un mediu complet automatizat și imuabil nu ar trebui să fie deloc necesar. Jurnalele pot fi extrase și trimise către servicii de logare dedicate, monitorizarea fiind, de asemenea, descărcată către un serviciu de monitorizare dedicat. Totuși, ar putea fi nevoie de acces SSH ocazional pentru inspecția configurației și depanare.

Pentru a limita suprafața de atac a serverelor, portul SSH nu este expus rețelei publice. La servere se ajunge printr-o gazdă bastion, o mașină dedicată care permite accesul SSH extern, protejată suplimentar prin includerea în lista albă numai a intervalului de adrese IP permis la firewall. Accesul este controlat prin implementarea cheilor SSH publice ale utilizatorilor în casetele corespunzătoare (autentificarea prin parolă este dezactivată). O astfel de configurare oferă o poartă destul de rezistentă prin care atacatorii rău intenționați să o treacă.

Acces la baza de date

Aceleași principii prezentate mai sus se aplică serverelor de baze de date. De asemenea, ar putea exista o nevoie ocazională de a conecta și manipula datele direct în baza de date, deși aceasta nu este cu siguranță o practică recomandată și un astfel de acces trebuie protejat în același mod în care este protejat accesul SSH la server.

O abordare similară poate fi utilizată, utilizând aceeași infrastructură gazdă bastion cu tunel SSH. Este necesar un tunel SSH dublu, unul către gazda bastion, iar prin acesta, altul către serverul care are acces la baza de date (gazda bastion nu are acces la serverul bazei de date). Prin acel al doilea tunel, este acum disponibilă o conexiune de la computerul client al utilizatorului la serverul de baze de date.

Prezentare generală a conceptelor de scalabilitate AWS

Când vorbim doar despre servere, scalabilitatea este destul de ușor de realizat cu platforme mai simple decât AWS. Principalul dezavantaj este că este posibil ca anumite cerințe să fie acoperite de serviciile externe ale platformei, adică datele care circulă prin rețeaua publică și depășesc limitele de securitate. Continuând cu AWS, toate datele sunt păstrate private, în timp ce scalabilitatea trebuie proiectată pentru a realiza o infrastructură scalabilă, rezistentă și tolerantă la erori.

Cu AWS, cea mai bună abordare a scalabilității este prin folosirea serviciilor AWS gestionate cu monitorizare și automatizare testate în luptă pentru mii de clienți care folosesc platforma. Adăugați copii de siguranță ale datelor și mecanisme de recuperare în combinație și veți scăpa de multe preocupări de pe masă doar bazându-vă pe platforma în sine.

Având toate acestea descărcate, permite o echipă de operațiuni mai mică, compensând oarecum costul mai mare al serviciilor gestionate de platformă. Echipa LEVELS a fost bucuroasă să aleagă acea cale oriunde a fost posibil.

Amazon Elastic Compute Cloud (EC2)

Bazarea pe un mediu dovedit care rulează instanțe EC2 este încă o abordare destul de rezonabilă, în comparație cu supraîncărcarea suplimentară și complexitatea rulării containerelor sau conceptele arhitecturale încă foarte tinere și în schimbare rapidă ale calculului fără server.

Aprovizionarea instanțelor EC2 trebuie să fie complet automatizată. Automatizarea este realizată prin AMI-uri personalizate pentru diferite clase de servere și Auto Scaling Groups care se ocupă de rularea flotelor de servere dinamice, păstrând numărul corespunzător de instanțe de servere care rulează în flotă, în funcție de traficul curent.

În plus, caracteristica de scalare automată permite setarea limitei inferioare și superioare a numărului de instanțe EC2 care urmează să fie rulate. Limita inferioară ajută la toleranța la erori, eliminând potențial timpul de nefuncționare în cazul unor defecțiuni. Limita superioară ține costurile sub control, permițând un anumit risc de oprire în cazul unor condiții extreme neașteptate. Scalare automată scala apoi dinamic numărul de instanțe în limitele respective.

Amazon Relational Database Service (RDS)

Echipa a rulat deja pe Amazon RDS pentru MySQL , dar strategia adecvată de backup, toleranță la erori și securitate nu a fost încă dezvoltată. În prima iterație, instanța bazei de date a fost actualizată la un cluster cu două instanțe în fiecare VPC, configurat ca master și ca replica de citire, care acceptă failoverul automat.

În următoarea iterație, odată cu disponibilitatea motorului MySQL versiunea 5.7, infrastructura a primit un upgrade la serviciul Amazon Aurora MySQL . Deși gestionată complet, Aurora nu este o soluție scalată automat. Oferă scalarea automată a stocării, evitând problema planificării capacității. Dar un arhitect de soluții trebuie încă să aleagă dimensiunea instanței de calcul.

Timpul de nefuncționare din cauza scalării nu poate fi evitat, dar poate fi redus la minimum cu ajutorul capacității de auto-vindecare. Datorită capacităților de replicare mai bune, Aurora oferă o funcționalitate de failover fără întreruperi. Scalare este executată prin crearea unei replici de citire cu puterea de calcul dorită și apoi executând transferul la acea instanță. Toate celelalte replici citite sunt apoi scoase din cluster, redimensionate și aduse înapoi în cluster. Necesită niște jongleri manuale, dar este mai mult decât fezabil.

Noua ofertă Aurora Serverless permite, de asemenea, un anumit nivel de scalare automată a resurselor de calcul, o caracteristică care merită analizată în viitor.

Servicii AWS gestionate

Pe lângă aceste două componente, restul sistemului beneficiază de mecanismele de auto-scalare ale serviciilor AWS complet gestionate. Acestea sunt Elastic Load Balancing (ELB), Amazon Simple Queue Service (SQS), stocarea obiectelor Amazon S3, funcțiile AWS Lambda și Amazon Simple Notification Service (SNS), unde nu este nevoie de un efort special de scalare din partea arhitectului.

Infrastructură mutabilă vs. imuabilă

Recunoaștem două abordări pentru gestionarea infrastructurii serverelor - o infrastructură mutabilă în care serverele sunt instalate și actualizate și modificate continuu în loc; și o infrastructură imuabilă în care serverele nu sunt niciodată modificate după furnizare, iar orice modificări de configurare sau actualizări de server sunt gestionate prin furnizarea de noi servere dintr-o imagine comună sau dintr-un script de instalare, înlocuindu-le pe cele vechi.

Cu LEVELS, alegerea este de a rula o infrastructură imuabilă, fără upgrade-uri, modificări de configurare sau acțiuni de management. Singura excepție o reprezintă implementările de aplicații, care au loc la locul lor.

Mai multe despre infrastructura mutabilă vs. imuabilă pot fi găsite pe blogul HashiCorp.

Privire de ansamblu asupra arhitecturii

Din punct de vedere tehnic, LEVELS este o aplicație mobilă și o aplicație web cu backend-ul REST API și unele servicii de fundal - o aplicație destul de tipică în zilele noastre. În acest sens, a fost propusă și configurată următoarea infrastructură:

Izolarea rețelei virtuale - Amazon VPC

Diagrama vizualizează o structură a unui mediu în VPC-ul său. Alte medii urmează aceeași structură (având aplicația Load Balancer (ALB) și clusterul Amazon Aurora partajate între mediile care nu sunt de producție din VPC-ul lor, dar configurația de rețea este exact aceeași).

VPC-ul este configurat în patru zone de disponibilitate dintr-o regiune AWS pentru toleranță la erori. Subrețelele și grupurile de securitate cu liste de control al accesului la rețea permit îndeplinirea cerințelor de securitate și control al accesului.

Extinderea infrastructurii în mai multe regiuni AWS pentru o toleranță suplimentară la erori ar fi fost prea complexă și inutilă într-un stadiu incipient al afacerii și al produsului său, dar este o opțiune în viitor.

Tehnica de calcul

LEVELS rulează un API REST tradițional cu unii lucrători de fundal pentru logica aplicației care se întâmplă în fundal. Ambele rulează ca flote dinamice de instanțe EC2 simple, complet automatizate prin Auto Scaling Groups. Serviciul gestionat Amazon SQS este utilizat pentru distribuirea sarcinilor de fundal (locuri de muncă), evitând nevoia de a rula, întreține și scala propriul server MQ.

Există, de asemenea, unele sarcini utilitare care nu au nicio logică de afaceri partajată cu restul aplicației, cum ar fi procesarea imaginilor. Astfel de tipuri de sarcini rulează extrem de bine pe AWS Lambda , deoarece Lambda sunt scalabile orizontal la nesfârșit și oferă o procesare paralelă de neegalat în comparație cu lucrătorii server.

Echilibrarea sarcinii, scalarea automată și toleranța la erori

Echilibrarea încărcăturii poate fi realizată manual prin Nginx sau HAProxy, dar alegerea Amazon Elastic Load Balancing (ELB) adaugă avantajul de a avea infrastructura de echilibrare a încărcăturii scalabilă intrinsec automat, foarte disponibilă și tolerantă la erori.

Este utilizată varianta Application Load Balancer (ALB) a ELB, utilizând rutarea stratului HTTP disponibilă la echilibrator de încărcare. Noile instanțe adăugate flotei sunt înregistrate automat la ALB prin mecanismele platformei AWS. ALB monitorizează, de asemenea, disponibilitatea instanțelor în orice moment. Are puterea de a anula înregistrarea și de a termina instanțe nesănătoase, declanșând Auto Scaling pentru a le înlocui cu altele noi. Prin această interacțiune între cele două, se realizează auto-vindecarea flotei EC2.

Magazin de date de aplicație

Magazinul de date al aplicației este un cluster Amazon Aurora MySQL , format dintr-o instanță principală și un număr de instanțe de replică citită. În cazul eșecului instanței master, una dintre replicile citite este promovată automat într-o nouă instanță master. Configurat ca atare, satisface cerința de toleranță la erori solicitată.

Replicile de citire, după cum sugerează și numele lor, pot fi utilizate și pentru distribuirea încărcării clusterului bazei de date pentru operațiunile de citire a datelor.

Stocarea bazei de date este scalată automat în trepte de 10 GB cu Aurora, iar backup-urile sunt, de asemenea, gestionate integral de AWS, oferind o restaurare la un moment dat în mod implicit. Toate acestea reduc sarcina de administrare a bazei de date practic la nimic, cu excepția creșterii puterii de calcul a bazei de date atunci când este nevoie - un serviciu care merită plătit pentru a rula fără griji.

Stocarea și servirea activelor

LEVELS acceptă conținutul încărcat de utilizatori care trebuie stocat. Stocarea obiectelor Amazon S3 este, destul de previzibil, serviciul care se va ocupa de acea sarcină. Există, de asemenea, elemente de aplicație (elementele UI - imagini, pictograme, fonturi) care trebuie să fie disponibile pentru aplicația client, astfel încât să fie stocate și în S3. Oferind copii de siguranță automate ale datelor încărcate prin replicarea lor de stocare internă, S3 asigură durabilitatea datelor în mod implicit.

Imaginile încărcate de utilizatori sunt de diferite dimensiuni și greutăți, adesea inutil de mari pentru a fi difuzate direct și supraponderale, punând o povară pentru conexiunile mobile. Producerea mai multor variații de dimensiuni diferite va permite difuzarea unui conținut mai optimizat pentru fiecare caz de utilizare. AWS Lambda este folosit pentru această sarcină, precum și pentru a face o copie a imaginilor originale încărcate într-o găleată de rezervă separată, pentru orice eventualitate.

În cele din urmă, o aplicație web care rulează prin browser este, de asemenea, un set de active statice - infrastructura de construcție cu integrare continuă compilează codul JavaScript și stochează și fiecare versiune în S3.

Odată ce toate aceste active sunt stocate în siguranță în S3, ele pot fi servite direct, deoarece S3 oferă o interfață HTTP publică sau prin Amazon CloudFront CDN. CloudFront face ca activele să fie distribuite geografic, reducând latența pentru utilizatorii finali și, de asemenea, activează suportul HTTPS pentru servirea activelor statice.

Aprovizionarea și managementul infrastructurii

Furnizarea infrastructurii AWS este o combinație de rețea, resurse și servicii gestionate de AWS și resursele simple de calcul EC2. Serviciile AWS gestionate sunt, bine, gestionate. Nu este mare lucru de făcut cu ele, cu excepția furnizării și aplicării securității corespunzătoare, în timp ce cu resursele de calcul EC2, trebuie să ne ocupăm de configurație și automatizare pe cont propriu.

Scule

Consola AWS bazată pe web face ca gestionarea infrastructurii AWS „asemănătoare cu cărămizile lego” să fie ceva mai puțin trivială și, ca orice lucru manual, mai degrabă predispusă la erori. De aceea, folosirea unui instrument dedicat pentru automatizarea acelei lucrări este foarte dorită.

Un astfel de instrument este AWS CloudFormation , dezvoltat și întreținut de AWS. Un altul este Terraform lui HashiCorp - o alegere puțin mai flexibilă prin oferirea de furnizori de platforme multiple, dar interesant aici în principal datorită filosofiei de abordare a infrastructurii imuabile a Terraform. Aliniat cu modul în care se rulează infrastructura LEVELS, Terraform, împreună cu Packer pentru furnizarea imaginilor AMI de bază, s-au dovedit a fi potrivite.

Documentatia infrastructurii

Un avantaj suplimentar al unui instrument de automatizare este că nu necesită documentație detaliată a infrastructurii, care devine depășită mai devreme sau mai târziu. Paradigma „Infrastructură ca cod” (IaC) a instrumentului de furnizare este denumită documentație, cu avantajul de a fi mereu la curent cu infrastructura actuală. A avea o imagine de ansamblu la nivel înalt, mai puțin probabil să fie schimbat și relativ ușor de întreținut odată cu eventualele modificări, documentată în lateral este atunci suficient.

Gânduri finale

Infrastructura AWS Cloud propusă este o soluție scalabilă capabilă să se adapteze la creșterea viitoare a produselor în cea mai mare parte automat. După aproape doi ani, reușește să mențină costurile de operare la un nivel scăzut, bazându-se pe automatizarea cloud fără a avea o echipă dedicată de operațiuni de sisteme de serviciu 24/7.

În ceea ce privește securitatea, AWS Cloud păstrează toate datele și toate resursele dintr -o rețea privată în același cloud. Nu sunt necesare date confidențiale pentru a călători prin rețeaua publică. Accesul extern este acordat cu permisiuni granulare fine la sistemele de suport de încredere (CI/CD, monitorizare externă sau alerte), limitând sfera de acces doar la resursele necesare rolului lor în întregul sistem.

Arhitecturat și configurat corect, un astfel de sistem este flexibil, rezistent, sigur și gata să răspundă tuturor cerințelor viitoare privind scalarea pentru creșterea produsului sau implementarea securității avansate, cum ar fi conformitatea PCI-DSS.

Nu este neapărat mai ieftin decât ofertele produse de la Heroku sau platforme similare, care funcționează bine atâta timp cât vă încadrați în tiparele obișnuite de utilizare acoperite de ofertele lor. Alegând AWS, obțineți mai mult control asupra infrastructurii dvs., un nivel suplimentar de flexibilitate cu gama de servicii AWS oferite și configurație personalizată cu capacitatea de reglare fină a întregii infrastructuri.

Citiți suplimentare pe blogul Toptal Engineering:

• Fă-ți temele: 7 Sfaturi pentru examenul AWS Certified Solutions Architect
• Terraform vs. CloudFormation: Ghidul definitiv
• Înregistrare SSH și gestionare a sesiunilor folosind AWS SSM
• Lucrul cu TypeScript și suport Jest: un tutorial AWS SAM