Traduzione dell'articolo preparata appositamente per gli studenti del corso . Ti interessa svilupparti in questa direzione? Guarda il masterclass di Egor Zuev (Team Lead presso InBit) e unisciti al prossimo gruppo del corso: inizio il 26 settembre.
Sempre più persone passano a AWS Lambda per la scalabilità, le prestazioni, il risparmio e la possibilità di gestire milioni e persino trilioni di richieste al mese. Per questo non è necessario gestire l'infrastruttura su cui opera il servizio. Il ridimensionamento automatico consente di gestire migliaia di richieste simultanee al secondo. Credo che AWS Lambda possa essere giustamente considerato uno dei servizi più richiesti di AWS.
AWS Lambda
AWS Lambda è un servizio di calcolo serverless orientato agli eventi che consente di eseguire codice senza dover allocare e gestire server e complementare altri servizi AWS basati sulla logica dell'utente. Lambda risponde automaticamente a vari eventi (chiamati trigger), come richieste HTTP tramite Amazon API Gateway, modifiche ai dati nel bucket Amazon S3 o nelle tabelle Amazon DynamoDB; oppure è possibile avviare il proprio codice tramite chiamate API, utilizzando l'AWS SDK e i passaggi tra stati in AWS Step Functions.
Lambda esegue codice su un'infrastruttura di calcolo ad alta disponibilità e si occupa completamente della gestione della piattaforma sottostante, inclusi la manutenzione dei server e del sistema operativo, l'allocazione delle risorse, il ridimensionamento automatico, il monitoraggio del codice e la registrazione. Quindi, devi solo caricare il tuo codice e configurare come e quando deve essere eseguito. Il servizio si occuperà di avviarlo e garantire l'alta disponibilità della tua applicazione.
Quando passare a Lambda?
AWS Lambda è una piattaforma di calcolo conveniente, adatta a molteplici scenari, ovviamente se il linguaggio e l'ambiente di esecuzione del tuo codice sono supportati dal servizio. Se desideri concentrarti sul codice e sulla logica aziendale, delegando la gestione dei server, l'allocazione delle risorse e il ridimensionamento a un fornitore esterno a un prezzo ragionevole, vale sicuramente la pena passare a AWS Lambda.
Lambda è ideale per la creazione di interfacce software e, se utilizzato insieme ad API Gateway, può ridurre significativamente i costi e accelerare il time-to-market. Ci sono vari modi per utilizzare le funzioni Lambda e diverse opzioni per organizzare un'architettura serverless—ognuno può scegliere qualcosa di adatto a seconda degli obiettivi prefissati.
Lambda consente di eseguire un'ampia gamma di attività. Ad esempio, grazie al supporto di CloudWatch, è possibile creare attività pianificate e automatizzare singoli processi. Non ci sono limiti sulla natura e sull'intensità dell'utilizzo del servizio (si considerano il consumo di memoria e il tempo), e nulla vi impedisce di lavorare in modo graduale su un microservizio completo basato su Lambda.
Qui è possibile creare azioni orientate ai servizi che non vengono eseguite continuamente. Un esempio tipico è la ridimensionamento delle immagini. Anche nei sistemi distribuiti, le funzioni Lambda rimangono rilevanti.
Quindi, se non volete occuparvi dell'allocazione e della gestione delle risorse di calcolo—provate AWS Lambda; se non avete bisogno di calcoli gravosi e dispendiosi in termini di risorse—provate anche AWS Lambda; se il vostro codice viene eseguito periodicamente—esatto, dovreste provare AWS Lambda.
Sicurezza
Finora non ci sono state lamentele riguardo alla sicurezza. D'altra parte, dal momento che molti processi interni e caratteristiche di implementazione di questo modello sono nascosti all'utente dell'ambiente di esecuzione gestito AWS Lambda, alcune regole comuni di sicurezza cloud perdono rilevanza.
Come la maggior parte dei servizi AWS, Lambda è fornito secondo il principio di responsabilità condivisa tra AWS e il cliente in materia di sicurezza e conformità normativa. Questo principio riduce il carico operativo per il cliente, poiché AWS si occupa delle attività di manutenzione, amministrazione e controllo dei componenti del servizio—dal sistema operativo dell'host e dal livello di virtualizzazione alla sicurezza fisica delle infrastrutture.
Parlando specificamente di AWS Lambda, AWS è responsabile della gestione dell'infrastruttura sottostante, dei servizi di base correlati, del sistema operativo e della piattaforma applicativa. Mentre il cliente è responsabile della sicurezza del proprio codice, della conservazione dei dati riservati, del controllo dell'accesso a essi, nonché al servizio e alle risorse Lambda (Identity and Access Management, IAM), anche nell'ambito delle funzioni utilizzate.
Nello schema sottostante è mostrato il modello di responsabilità condivisa applicabile ad AWS Lambda. L'area di responsabilità di AWS è colorata in arancione, mentre la responsabilità del cliente è evidenziata in blu. Come potete vedere, AWS si assume maggiori responsabilità per le applicazioni implementate sul servizio.
Il modello di responsabilità condivisa applicabile ad AWS Lambda
Ambiente di esecuzione Lambda
Il principale vantaggio di Lambda è che, eseguendo una funzione per vostro conto, il servizio gestisce autonomamente le risorse necessarie. Non dovete perdere tempo e sforzi nell'amministrazione dei sistemi, potendo così concentrarvi sulla logica aziendale e sulla scrittura del codice.
Il servizio Lambda è suddiviso in due piani. Il primo è il piano di controllo. Secondo Wikipedia, il piano di controllo (control plane) è la parte della rete responsabile del trasporto del traffico di segnalazione e del routing. È il principale componente che prende decisioni globali sulla allocazione, manutenzione e distribuzione dei carichi di lavoro. Inoltre, il piano di controllo svolge il ruolo di topologia di rete del fornitore, responsabile per il routing e la gestione del traffico.
Il secondo piano è il piano dati. Anch'esso, come il piano di controllo, ha i propri compiti. Il piano di controllo fornisce API per gestire le funzioni (CreateFunction, UpdateFunctionCode) e controlla le interazioni di Lambda con altri servizi AWS. Il piano dati gestisce le API di chiamata (Invoke API), che attivano le funzioni Lambda. Dopo la chiamata della funzione, il piano di controllo assegna o seleziona un ambiente di esecuzione esistente, previamente preparato per quella funzione, e poi esegue il codice al suo interno.
AWS Lambda supporta numerosi linguaggi di programmazione, tra cui Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 e altri, tramite i rispettivi ambienti di runtime. AWS li aggiorna regolarmente, distribuisce patch di sicurezza ed esegue altre operazioni di manutenzione su questi ambienti. Lambda consente di utilizzare anche altri linguaggi a condizione che tu implementi il relativo ambiente di runtime. E in tal caso, sarai tu a doverti occupare della sua manutenzione, compreso il monitoraggio della sicurezza.
Come funziona tutto questo e come il servizio eseguirà le tue funzioni?
Ogni funzione opera in uno o più ambienti dedicati, che esistono solo durante il ciclo di vita di quella funzione e poi vengono distrutti. In ciascun ambiente viene eseguita solo una chiamata alla volta, ma viene riutilizzato se ci sono molte chiamate seriali della stessa funzione. Tutti gli ambienti di runtime operano su macchine virtuali con virtualizzazione hardware — sui cosiddetti microVM. Ogni microVM è assegnata a un particolare account AWS e può essere riutilizzata da ambienti per eseguire diverse funzioni in quell'account. Le microVM sono incapsulate in strutture hardware della piattaforma Lambda Worker, di proprietà e gestite da AWS. Lo stesso ambiente di runtime non può essere utilizzato da funzioni diverse, così come le microVM sono uniche per diversi account AWS.
Il modello di isolamento in AWS Lambda
L'isolamento degli ambienti di runtime è attuato tramite diversi meccanismi. A livello superiore, ogni ambiente presenta copie separate dei seguenti componenti:
- Codice della funzione
- Eventuali layer Lambda selezionati per la funzione
- Ambiente di runtime della funzione
- Spazio utente minimale basato su Amazon Linux
Per isolare i diversi ambienti di runtime vengono applicati i seguenti meccanismi:
- cgroups — limitazione dell'accesso alle risorse CPU, memoria, larghezza di banda dello storage e rete per ogni ambiente di runtime;
- namespaces — raggruppamento degli ID dei processi, ID degli utenti, interfacce di rete e altre risorse gestite dal kernel Linux. Ogni ambiente di runtime opera nel proprio namespace;
- seccomp-bpf — limitazione delle chiamate di sistema che possono essere utilizzate nell'ambiente di runtime;
- iptables e routing tables — isolamento degli ambienti di runtime tra loro;
- chroot — fornitura di accesso limitato al filesystem sottostante.
Combinati con le tecnologie proprietarie di isolamento di AWS, i meccanismi descritti garantiscono un'affidabile separazione degli ambienti di esecuzione. Gli ambienti isolati in questo modo non possono accedere ai dati di altri ambienti né modificarli.
Sebbene più ambienti di esecuzione di un singolo account AWS possano funzionare sulla stessa microVM, in nessun caso le microVM possono essere condivise da diversi account AWS. Per isolare le microVM, AWS Lambda utilizza solo due meccanismi: istanze EC2 e Firecracker. L'isolamento degli ospiti in Lambda basato su istanze EC2 è in uso dal 2015. Firecracker è un nuovo hypervisor open source, progettato specificamente da AWS per carichi di lavoro serverless e presentato nel 2018. L'hardware fisico su cui vengono eseguite le microVM è condiviso da carichi di lavoro di diversi account.
Salvataggio degli ambienti e degli stati dei processi
Sebbene gli ambienti di esecuzione Lambda siano unici per diverse funzioni, la stessa funzione può essere richiamata più volte, il che significa che l'ambiente di esecuzione può esistere per diverse ore prima di essere distrutto.
Ogni ambiente di esecuzione Lambda ha anche un filesystem scrivibile, accessibile tramite la directory /tmp. Il suo contenuto non è accessibile da altri ambienti di esecuzione. Per quanto riguarda il salvataggio degli stati dei processi, i file scritti in /tmp esistono durante tutto il ciclo di vita dell'ambiente di esecuzione. Questo consente di accumulare i risultati di più invocazioni, il che è particolarmente utile per operazioni dispendiose come il caricamento di modelli di machine learning.
Trasferimento dei dati delle invocazioni
L'interfaccia Invoke API può essere utilizzata in due modalità: modalità eventi e modalità 'richiesta - risposta'. In modalità eventi, l'invocazione viene messa in coda per l'esecuzione successiva. In modalità 'richiesta - risposta', la funzione viene invocata immediatamente con il payload fornito, dopodiché viene restituita la risposta. In entrambi i casi, la funzione viene eseguita nell'ambiente Lambda, ma con percorsi diversi per il payload.
Durante le chiamate di tipo "richiesta - risposta", il payload arriva dall'API di elaborazione delle richieste (API Caller), come AWS API Gateway o AWS SDK, al bilanciatore di carico e poi al servizio di esecuzione delle chiamate Lambda (Invoke Service). Quest'ultimo determina l'ambiente appropriato per l'esecuzione della funzione e invia lì il payload per completare la chiamata. Il bilanciatore di carico riceve traffico protetto da TLS tramite Internet. Il traffico all'interno del servizio Lambda, dopo il bilanciatore di carico, passa attraverso un VPC interno in una specifica regione AWS.
Modello di elaborazione delle chiamate AWS Lambda: modalità "richiesta - risposta"
Le chiamate basate su eventi possono essere eseguite immediatamente oppure aggiunte a una coda. In alcuni casi, la coda è implementata tramite il servizio Amazon SQS (Amazon Simple Queue Service), che trasmette le chiamate al servizio di esecuzione delle chiamate Lambda tramite un processo di polling interno. Il traffico trasmesso è protetto da TLS, senza alcuna crittografia aggiuntiva per i dati memorizzati in Amazon SQS.
Le chiamate basate su eventi non restituiscono risposte: qualsiasi informazione di risposta Lambda Worker viene semplicemente ignorata. Le chiamate basate su eventi da Amazon S3, Amazon SNS, CloudWatch e altre fonti vengono elaborate dal servizio Lambda in modalità eventi. Le chiamate da stream Amazon Kinesis e DynamoDB, le chiamate alle code SQS, al bilanciatore di carico dell'applicazione e all'API Gateway vengono elaborate in modalità "richiesta - risposta".
Monitoraggio
Puoi monitorare e auditare le funzioni Lambda utilizzando diversi meccanismi e servizi AWS, tra cui i seguenti.
Amazon CloudWatch
Raccoglie diverse statistiche, come il numero di richieste, la durata delle esecuzioni delle richieste e il numero di richieste terminate con errore.
Amazon CloudTrail
Consente di tenere registri, monitoraggio continuo e conservazione delle informazioni sulle attività all'interno del tuo account, relative alla tua infrastruttura AWS. Avrai una cronologia completa delle azioni eseguite tramite la console AWS Management Console, AWS SDK, strumenti da riga di comando e altri servizi AWS.
AWS X-Ray
Fornisce una visibilità completa di tutte le fasi di elaborazione delle richieste nella tua applicazione sulla base della mappa dei suoi componenti interni. Consente di analizzare le applicazioni durante lo sviluppo e in ambiente di produzione.
AWS Config
Potrete monitorare le modifiche alla configurazione delle funzioni Lambda (inclusa la loro eliminazione) e all'ambiente di esecuzione, ai tag, ai nomi dei gestori, alle dimensioni del codice, alla ripartizione della memoria, alle impostazioni di timeout e ai parametri di parallelismo, oltre al ruolo di esecuzione Lambda IAM, alla sottorete e all'associazione dei gruppi di sicurezza.
Conclusione
AWS Lambda offre un potente insieme di strumenti per costruire applicazioni sicure e scalabili. Molti dei metodi di sicurezza e conformità normativi in AWS Lambda non differiscono da quelli utilizzati negli altri servizi AWS, anche se ci sono delle eccezioni. A partire da marzo 2019, Lambda soddisfa i requisiti SOC 1, SOC 2, SOC 3, PCI DSS, la legge statunitense sulla portabilità e responsabilità dell'assistenza sanitaria (HIPAA) e altre normative. Pertanto, quando pensate di implementare una nuova applicazione, considerate il servizio AWS Lambda: potrebbe essere la scelta migliore per il vostro progetto.
Fonte: habr.com
