Traducerea articolului a fost pregătită special pentru studenții cursului . Ești interesat de dezvoltarea în acest domeniu? Urmărește masterclass-ul lui Egor Zuev (TeamLead la InBit) și alătură-te celei mai apropiate grupe de curs: începere 26 septembrie.
Din ce în ce mai mulți oameni trec la AWS Lambda pentru scalabilitate, performanță, economii și capacitatea de a gestiona milioane și chiar trilioane de solicitări pe lună. Pentru aceasta, nu trebuie să gestionezi infrastructura pe care rulează serviciul. Iar scalarea automată permite gestionarea a mii de solicitări simultane pe secundă. Cred că AWS Lambda poate fi considerat cu dreptate unul dintre cele mai solicitate servicii AWS.
AWS Lambda
AWS Lambda este un serviciu de calcul fără server, bazat pe evenimente, care permite executarea codului fără alocarea și administrarea serverelor, completând alte servicii AWS în funcție de logica utilizatorului. Lambda răspunde automat la diferite evenimente (cunoscut sub numele de trigger-e), cum ar fi solicitările HTTP prin Amazon API Gateway, modificarea datelor în coșurile Amazon S3 sau tabelele Amazon DynamoDB; sau poți să îți lansezi codul prin apeluri API, folosind AWS SDK și tranziții între stări în AWS Step Functions.
Lambda execută codul pe o infrastructură de calcul de înaltă disponibilitate și se ocupă complet de administrarea platformei de bază, inclusiv întreținerea serverelor și a sistemului de operare, alocarea resurselor, scalarea automată, monitorizarea codului și logarea. Asta înseamnă că trebuie doar să încarci codul tău și să configurezi cum și când acesta ar trebui să ruleze. În schimb, serviciul va avea grijă de lansarea acestuia și va asigura disponibilitatea ridicată a aplicației tale.
Când să treci la Lambda?
AWS Lambda este o platformă de calcul convenabilă, potrivită pentru o varietate de scenarii de aplicare, desigur, dacă limbajul și mediul de execuție al codului tău sunt suportate de serviciu. Dacă vrei să te concentrezi pe cod și logica de afaceri, lăsând întreținerea serverelor, alocarea resurselor și scalarea unui furnizor terț pentru un preț rezonabil, cu siguranță ar trebui să treci la AWS Lambda.
Lambda este ideal pentru crearea interfețelor de programare, iar dacă utilizați serviciul împreună cu API Gateway, puteți reduce semnificativ costurile și să ajungeți mai repede pe piață. Există diverse modalități de a utiliza funcțiile Lambda și opțiuni pentru organizarea arhitecturii fără server — fiecare poate alege ceva potrivit în funcție de obiectivul stabilit.
Lambda permite executarea unei game largi de sarcini. De exemplu, datorită suportului CloudWatch, puteți crea sarcini programate și automatiza procese separate. Nu există restricții cu privire la natura și intensitatea utilizării serviciului (se iau în considerare consumul de memorie și timpul), iar nimic nu vă împiedică să lucrați constant la un microserviciu complet bazat pe Lambda.
Aici puteți crea acțiuni orientate spre servicii, care nu sunt executate constant. Un exemplu tipic este scalarea imaginilor. Chiar și în cazul sistemelor distribuite, funcțiile Lambda rămân relevante.
Deci, dacă nu doriți să vă ocupați de alocarea și administrarea resurselor de calcul — încercați AWS Lambda; dacă nu aveți nevoie de calcule grele și consumatoare de resurse — de asemenea, încercați AWS Lambda; dacă codul dvs. este executat periodic — este corect, ar trebui să încercați AWS Lambda.
Securitate
Până acum, nu au existat plângeri legate de securitate. Pe de altă parte, deoarece multe procese interne și caracteristici ale implementării acestui model sunt ascunse utilizatorului mediului de execuție AWS Lambda, unele reguli acceptate în mod obișnuit privind securitatea în cloud își pierd relevanța.
Ca majoritatea serviciilor AWS, Lambda este furnizat pe principiul responsabilității comune între AWS și client în ceea ce privește securitatea și conformitatea normativă. Acest principiu reduce sarcina operațională asupra clientului, deoarece AWS își asumă responsabilitățile de întreținere, administrare și control al componentelor serviciului — de la sistemul de operare al gazdei și nivelul de virtualizare până la securitatea fizică a infrastructurii.
Dacă vorbim specific despre AWS Lambda, AWS se ocupă de gestionarea infrastructurii de bază, a serviciilor conexe, a sistemului de operare și a platformei aplicațiilor. În timp ce clientul este responsabil pentru securitatea codului său, stocarea datelor confidențiale, controlul accesului la acestea, precum și la serviciul și resursele Lambda (Identity and Access Management, IAM), inclusiv în cadrul funcțiilor utilizate.
Diagrama de mai jos prezintă modelul de responsabilitate comună aplicabil AWS Lambda. Domeniul de responsabilitate al AWS este marcat cu portocaliu, iar responsabilitatea clientului este marcată cu albastru. Așa cum vedeți, AWS își asumă mai multe responsabilități pentru aplicațiile desfășurate pe serviciu.
Modelul de responsabilitate comună aplicabil AWS Lambda
Mediul de execuție Lambda
Principalul avantaj al Lambda este că, executând o funcție în numele dumneavoastră, serviciul alocă singur resursele necesare. Puteți să nu vă pierdeți timpul și energia administrând sistemele și să vă concentrați pe logica de afaceri și scrierea codului.
Serviciul Lambda este împărțit în două planuri. Primul este planul de control. Conform Wikipediei, planul de control (control plane) este partea rețelei responsabilă pentru transportul semnalului și rutare. Este componenta principală, luând decizii globale privind alocarea, întreținerea și distribuția sarcinilor de lucru. În plus, planul de control servește ca topologie de rețea a furnizorului de soluții, responsabilă pentru rutarea și gestionarea traficului.
Al doilea plan este planul de date. Acesta, la fel ca și planul de control, are sarcinile sale. Planul de control oferă API-uri pentru gestionarea funcțiilor (CreateFunction, UpdateFunctionCode) și controlează interacțiunea Lambda cu celelalte servicii AWS. Planul de date gestionează apelurile API (Invoke API), care declanșează funcțiile Lambda. După apelarea funcției, planul de control alocă sau selectează un mediu de execuție existent, pregătit anterior pentru această funcție, și apoi execută codul în acesta.
AWS Lambda suportă mai multe limbaje de programare, inclusiv Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 și altele, prin intermediul mediilor de execuție corespunzătoare. AWS le actualizează regulat, distribuie corecții de securitate și efectuează alte operațiuni de întreținere a acestor medii. Lambda permite utilizarea și altor limbaje cu condiția ca utilizatorul să implementeze singur mediul de execuție relevant. În acest caz, va trebui să te ocupi și de întreținerea sa, inclusiv de monitorizarea securității.
Cum funcționează toate acestea și cum va executa serviciul funcțiile tale?
Fiecare funcție rulează într-unul sau mai multe medii dedicate, care există doar pe durata ciclului de viață al acestei funcții și apoi sunt distruse. În fiecare mediu, se execută simultan doar un apel, dar acesta este reutilizat dacă apar mai multe apeluri consecutive ale aceleași funcții. Toate mediile de execuție rulează pe mașini virtuale cu virtualizare hardware — pe ceea ce se numește microVM. Fiecare microVM este atribuit unui anumit cont AWS și poate fi utilizat de mai multe ori de către medii pentru a executa diverse funcții în acest cont. MicroVM-urile sunt grupate în module ale platformei hardware Lambda Worker, deținute și gestionate de AWS. Același mediu de execuție nu poate fi utilizat de diferite funcții, la fel cum microVM-urile sunt unice pentru diferite conturi AWS.
Modelul de izolare în AWS Lambda
Izolarea mediilor de execuție este realizată prin intermediul mai multor mecanisme. La cel mai înalt nivel, fiecare mediu are copii separate ale următoarelor componente:
- Codul funcției
- Orice straturi Lambda selectate pentru funcție
- Mediul de execuție al funcției
- Spațiul utilizator minim bazat pe Amazon Linux
Pentru izolarea diferitelor medii de execuție, se aplică următoarele mecanisme:
- cgroups — restricționarea accesului la resursele CPU, memorie, lățimea de bandă a stocării și rețea pentru fiecare mediu de execuție;
- namespaces — gruparea ID-urilor proceselor, ID-urilor utilizatorilor, interfețelor de rețea și altor resurse gestionate de nucleul Linux. Fiecare mediu de execuție funcționează în propriul spațiu de nume;
- seccomp-bpf — restricționarea apelurilor de sistem care pot fi utilizate în mediu de execuție;
- iptables și tabele de rutare — izolarea mediilor de execuție una de cealaltă;
- chroot — furnizarea unui acces limitat la sistemul de fișiere de bază.
În combinație cu tehnologiile proprietare de izolare AWS, mecanismele enumerate garantează o separare fiabilă a mediilor de execuție. Mediile astfel izolate nu pot accesa sau modifica datele altor medii.
Deși mai multe medii de execuție ale aceleași cont AWS pot rula pe aceeași microVM, în nicio împrejurare microVM-urile nu pot fi partajate între conturi diferite AWS. Pentru izolarea microVM-urilor, AWS Lambda utilizează doar două mecanisme: instanțele EC2 și Firecracker. Izolarea oaspeților în Lambda bazată pe instanțele EC2 este aplicată din 2015. Firecracker este un nou hipervizor open-source, special conceput de AWS pentru sarcini de lucru serverless, lansat în 2018. Echipamentele fizice pe care rulează microVM-urile sunt partajate între sarcini de lucru ale diferitelor conturi.
Păstrarea mediilor și stărilor proceselor
Deși mediile de execuție Lambda sunt unice pentru diferite funcții, aceeași funcție poate fi apelată din nou, adică mediu de execuție poate exista câteva ore înainte de a fi distrus.
Fiecare mediu de execuție Lambda are, de asemenea, un sistem de fișiere cu permisiuni de scriere, accesibil prin directorul /tmp. Conținutul acestuia nu poate fi accesat din alte medii de execuție. În ceea ce privește păstrarea stărilor proceselor, fișierele scrise în /tmp există pe întreaga durată de viață a mediului de execuție. Astfel, este posibilă acumularea rezultatelor mai multor apeluri, ceea ce este deosebit de util pentru operațiuni costisitoare, cum ar fi încărcarea modelelor de învățare automată.
Transmiterea datelor apelurilor
Interfața Invoke API poate fi activată în două moduri: modul eveniment și modul "cerere - răspuns". În modul eveniment, apelul este adăugat într-o coadă pentru executarea ulterioară. În modul "cerere - răspuns", funcția este apelată imediat cu payload-ul furnizat, după care se returnează un răspuns. În ambele cazuri, funcția este executată în mediu Lambda, dar cu diferite căi de payload.
În timpul apelurilor de tip „request-response”, payload-ul provine de la API-ul de procesare a cererilor (API Caller), cum ar fi AWS API Gateway sau AWS SDK, la un load balancer și apoi la serviciul de invocare Lambda (Invoke Service). Acesta din urmă determină mediul adecvat pentru executarea funcției și transmite payload-ul pentru a finaliza apelul. Load balancer-ul primește traficul cu protecție TLS prin Internet. Traficul în cadrul serviciului Lambda — după load balancer — trece printr-un VPC intern în anumite regiuni AWS.
Modelul de procesare a apelurilor AWS Lambda: modul „request-response”
Apelurile bazate pe evenimente pot fi executate imediat sau adăugate în coadă. În anumite cazuri, coada este implementată prin serviciul Amazon SQS (Amazon Simple Queue Service), care transmite apelurile către serviciul de invocare Lambda printr-un proces intern de polling. Traficul transferat este protejat prin TLS, iar criptarea suplimentară a datelor stocate în Amazon SQS nu este prevăzută.
Apelurile bazate pe evenimente nu returnează răspunsuri — orice informație de răspuns este pur și simplu ignorată de Lambda Worker. Apelurile bazate pe evenimente din Amazon S3, Amazon SNS, CloudWatch și alte surse sunt procesate de serviciul Lambda în modul de evenimente. Apelurile din fluxurile Amazon Kinesis și DynamoDB, apelurile din cozile SQS, load balancer-ul aplicațiilor și API Gateway sunt procesate în modul „request-response”.
Monitorizare
Puteți monitoriza și audita funcțiile Lambda folosind diferite mecanisme și servicii AWS, inclusiv următoarele.
Amazon CloudWatch
Colectează diverse statistici, cum ar fi numărul de cereri, durata de execuție a cererilor și numărul de cereri care au eșuat.
Amazon CloudTrail
Permite înregistrarea, monitorizarea continuă și păstrarea informațiilor despre activitățile din contul dvs., legate de infrastructura AWS. Veți avea o cronologie completă a acțiunilor efectuate prin AWS Management Console, AWS SDK, instrumente de linie de comandă și alte servicii AWS.
AWS X-Ray
Oferă vizibilitate completă asupra tuturor etapelor procesării cererilor din aplicația dvs., pe baza unei hărți a componentelor sale interne. Permite analizarea aplicațiilor în timpul dezvoltării și în medii de producție.
AWS Config
Veți putea urmări modificările configurației funcțiilor Lambda (inclusiv ștergerea acestora) și a medii de execuție, etichetelor, numelui handler-ului, dimensiunii codului, alocării memoriei, setărilor de timeout și parametrilor de paralelism, precum și a rolului de execuție Lambda IAM, subrețelei și legăturii grupurilor de securitate.
Concluzie
AWS Lambda oferă un set puternic de instrumente pentru crearea de aplicații sigure și scalabile. Multe metode de asigurare a securității și conformității în AWS Lambda nu diferă de cele utilizate în celelalte servicii AWS, deși există unele excepții. La momentul din martie 2019, Lambda respectă cerințele SOC 1, SOC 2, SOC 3, PCI DSS, legea americană referitoare la continuitatea și responsabilitatea asigurărilor medicale (HIPAA) și alte reglementări. Așadar, atunci când luați în considerare implementarea unei noi aplicații, luați în considerare serviciul AWS Lambda – poate fi soluția perfectă pentru nevoile dumneavoastră.
Sursa: habr.com
