La traduzione dell'articolo è stata preparata appositamente per gli studenti del corso . Sei interessato a svilupparti in questa direzione? Guarda la master class di Egor Zuev (TeamLead di InBit) e iscriviti al prossimo gruppo di corso: inizia il 26 settembre.
Sempre più persone stanno migrando ad AWS Lambda per ottenere scalabilità, prestazioni, risparmi e la capacità di gestire milioni o addirittura trilioni di richieste al mese. Per fare ciò, non è necessario gestire l'infrastruttura su cui viene eseguito il servizio. Inoltre, la scalabilità automatica ti consente di soddisfare migliaia di richieste simultanee al secondo. Penso che AWS Lambda possa essere giustamente definito uno dei servizi AWS più popolari.
AWS Lambda
AWS Lambda è un servizio di elaborazione serverless basato sugli eventi che ti consente di eseguire codice senza effettuare il provisioning o gestire i server ed estendere altri servizi AWS utilizzando la logica personalizzata. Lambda risponde automaticamente a vari eventi (chiamati trigger), come richieste HTTP tramite Amazon API Gateway, modifiche ai dati nei bucket Amazon S3 o nelle tabelle Amazon DynamoDB; oppure puoi eseguire il codice tramite chiamate API utilizzando l'SDK AWS e le transizioni di stato in AWS Step Functions.
Lambda esegue il codice su un'infrastruttura informatica ad alta disponibilità ed è pienamente responsabile dell'amministrazione della piattaforma sottostante, inclusa la manutenzione del server e del sistema operativo, il provisioning delle risorse, la scalabilità automatica, il monitoraggio del codice e il logging. Cioè, devi solo caricare il tuo codice e configurare come e quando dovrebbe essere eseguito. A sua volta, il servizio si occuperà del suo lancio e garantirà l'elevata disponibilità della tua applicazione.
Quando passare a Lambda?
AWS Lambda è una comoda piattaforma informatica adatta a una varietà di casi d'uso, purché il linguaggio e il runtime del codice siano supportati dal servizio. Se vuoi concentrarti sul codice e sulla logica aziendale esternalizzando la manutenzione, il provisioning e il dimensionamento dei server a un costo ragionevole, AWS Lambda è sicuramente la strada da percorrere.
Lambda è ideale per creare interfacce di programmazione e, se utilizzato insieme ad API Gateway, puoi ridurre significativamente i costi e arrivare sul mercato più velocemente. Esistono diversi modi per utilizzare le funzioni e le opzioni Lambda per organizzare un'architettura serverless: ognuno può scegliere qualcosa di adatto in base al proprio obiettivo.
Lambda ti consente di eseguire un'ampia gamma di attività. Pertanto, grazie al supporto di CloudWatch, puoi creare attività differite e automatizzare i singoli processi. Non ci sono restrizioni sulla natura e sull'intensità di utilizzo del servizio (vengono presi in considerazione il consumo di memoria e il tempo) e nulla ti impedisce di lavorare sistematicamente su un microservizio a tutti gli effetti basato su Lambda.
Qui puoi creare azioni orientate ai servizi che non vengono eseguite continuamente. Un tipico esempio è il ridimensionamento dell'immagine. Anche nel caso di sistemi distribuiti, le funzioni Lambda rimangono rilevanti.
Quindi, se non vuoi occuparti dell'allocazione e della gestione delle risorse di elaborazione, prova AWS Lambda; se non hai bisogno di calcoli pesanti e dispendiosi in termini di risorse, prova anche AWS Lambda; se il tuo codice viene eseguito periodicamente, è vero, dovresti provare AWS Lambda.
sicurezza
Finora non ci sono lamentele sulla sicurezza. D'altra parte, poiché molti dei processi interni e delle funzionalità di implementazione di questo modello sono nascosti all'utente dell'ambiente di runtime gestito AWS Lambda, alcune regole di sicurezza del cloud generalmente accettate diventano irrilevanti.
Come la maggior parte dei servizi AWS, Lambda viene fornito su una base di sicurezza e conformità condivisa tra AWS e il cliente. Questo principio riduce l'onere operativo per il cliente, poiché AWS si assume i compiti di manutenzione, amministrazione e monitoraggio dei componenti del servizio, dal sistema operativo host e il livello di virtualizzazione alla sicurezza fisica delle risorse infrastrutturali.
Parlando specificamente di AWS Lambda, AWS è responsabile della gestione dell'infrastruttura sottostante, dei servizi sottostanti associati, del sistema operativo e della piattaforma applicativa. Mentre il cliente è responsabile della sicurezza del proprio codice, della memorizzazione dei dati riservati, del controllo dell'accesso allo stesso, nonché al servizio e alle risorse Lambda (Identity and Access Management, IAM), anche nei limiti delle funzioni utilizzate.
Il diagramma seguente mostra il modello di responsabilità condivisa applicato ad AWS Lambda. La responsabilità di AWS è arancione e la responsabilità del cliente è blu. Come puoi vedere, AWS si assume maggiore responsabilità per le applicazioni distribuite sul servizio.
Modello di responsabilità condivisa applicabile ad AWS Lambda
Tempo di esecuzione Lambda
Il vantaggio principale di Lambda è che eseguendo una funzione per tuo conto, il servizio stesso alloca le risorse necessarie. Puoi evitare di sprecare tempo e fatica nell'amministrazione del sistema e concentrarti sulla logica aziendale e sulla codifica.
Il servizio Lambda è diviso su due piani. Il primo è il piano di controllo. Secondo Wikipedia, il piano di controllo è la parte della rete responsabile del trasporto e dell'instradamento del traffico di segnalazione. È il componente principale che prende decisioni globali in merito al provisioning, alla manutenzione e alla distribuzione dei carichi di lavoro. Inoltre, il piano di controllo funge da topologia di rete del fornitore della soluzione, responsabile dell'instradamento e della gestione del traffico.
Il secondo piano è il piano dati. Come il piano di controllo, ha i suoi compiti. Il piano di controllo fornisce API per la gestione delle funzioni (CreateFunction, UpdateFunctionCode) e controlla il modo in cui Lambda comunica con altri servizi AWS. Il piano dati controlla l'API Invoke, che esegue le funzioni Lambda. Dopo che una funzione è stata chiamata, il piano di controllo alloca o seleziona un ambiente runtime esistente già preparato per quella funzione, quindi esegue il codice in esso contenuto.
AWS Lambda supporta una varietà di linguaggi di programmazione, tra cui Java 8, Python 3.7, Go, NodeJS 8, .NET Core 2 e altri, attraverso i rispettivi ambienti di runtime. AWS li aggiorna regolarmente, distribuisce patch di sicurezza ed esegue altre attività di manutenzione su questi ambienti. Lambda ti consente di utilizzare anche altri linguaggi, a condizione che tu stesso implementi il runtime appropriato. E poi dovrai occuparti della sua manutenzione, compreso il monitoraggio della sua sicurezza.
Come funziona e in che modo il servizio svolgerà le tue funzioni?
Ogni funzione viene eseguita in uno o più ambienti dedicati, che esistono solo per la vita di quella funzione e vengono poi distrutti. Ogni ambiente effettua una sola chiamata alla volta, ma viene riutilizzata se sono presenti più chiamate seriali alla stessa funzione. Tutti gli ambienti runtime funzionano su macchine virtuali con virtualizzazione hardware, le cosiddette microVM. Ogni microVM viene assegnata a uno specifico account AWS e può essere riutilizzata dagli ambienti per eseguire diverse funzioni all'interno di tale account. Le microVM sono inserite negli elementi costitutivi della piattaforma hardware Lambda Worker, di proprietà e gestita da AWS. Lo stesso runtime non può essere utilizzato da funzioni diverse, né le microVM sono univoche per diversi account AWS.
Modello di isolamento AWS Lambda
L'isolamento degli ambienti runtime viene implementato utilizzando diversi meccanismi. Al livello più alto di ogni ambiente sono presenti copie separate dei seguenti componenti:
- Codice funzione
- Qualsiasi livello Lambda selezionato per la funzione
- Ambiente di esecuzione delle funzioni
- Spazio utente minimo basato su Amazon Linux
I seguenti meccanismi vengono utilizzati per isolare diversi ambienti di esecuzione:
- cgroups: limita l'accesso a CPU, memoria, storage e risorse di rete per ciascun ambiente runtime;
- spazi dei nomi: raggruppamento di ID processo, ID utente, interfacce di rete e altre risorse gestite dal kernel Linux. Ogni runtime viene eseguito nel proprio spazio dei nomi;
- seccomp-bpf - limita le chiamate di sistema che possono essere utilizzate nel runtime;
- iptables e tabelle di routing: isolamento degli ambienti di esecuzione gli uni dagli altri;
- chroot: fornisce accesso limitato al file system sottostante.
Combinati con le tecnologie di isolamento proprietarie di AWS, questi meccanismi garantiscono una separazione affidabile del runtime. Gli ambienti isolati in questo modo non possono accedere o modificare i dati di altri ambienti.
Sebbene più runtime dello stesso account AWS possano essere eseguiti su una singola microVM, in nessun caso le microVM possono essere condivise tra diversi account AWS. AWS Lambda utilizza solo due meccanismi per isolare le microVM: istanze EC2 e Firecracker. L'isolamento degli ospiti in Lambda basato sulle istanze EC2 è attivo dal 2015. Firecracker è un nuovo hypervisor open source progettato specificamente da AWS per carichi di lavoro serverless e introdotto nel 2018. L'hardware fisico che esegue le microVM è condiviso tra carichi di lavoro su account diversi.
Salvataggio di ambienti e stati di processo
Sebbene i runtime Lambda siano univoci per funzioni diverse, possono chiamare ripetutamente la stessa funzione, il che significa che il runtime può sopravvivere per diverse ore prima di essere distrutto.
Ogni runtime Lambda dispone inoltre di un file system scrivibile accessibile tramite la directory /tmp. Non è possibile accedere ai suoi contenuti da altri runtime. Per quanto riguarda la persistenza dello stato del processo, i file scritti in /tmp esistono per l'intero ciclo di vita dell'ambiente runtime. Ciò consente di accumulare i risultati di più chiamate, il che è particolarmente utile per operazioni costose come il caricamento di modelli di machine learning.
Trasferimento dati chiamata
L'API Invoke può essere utilizzata in due modalità: modalità evento e modalità richiesta-risposta. In modalità evento, la chiamata viene aggiunta a una coda per l'esecuzione successiva. Nella modalità richiesta-risposta, la funzione viene chiamata immediatamente con il payload fornito, dopodiché viene restituita la risposta. In entrambi i casi, la funzione viene eseguita in un ambiente Lambda, ma con percorsi di payload diversi.
Durante le chiamate di richiesta-risposta, il carico utile passa da un'API di elaborazione delle richieste (API Caller), come AWS API Gateway o AWS SDK, al sistema di bilanciamento del carico e quindi al servizio di chiamata Lambda (Invoke Service). Quest'ultimo determina l'ambiente appropriato per l'esecuzione della funzione e trasferisce lì il carico utile per completare la chiamata. Il sistema di bilanciamento del carico riceve traffico protetto da TLS su Internet. Il traffico all'interno del servizio Lambda, dopo il sistema di bilanciamento del carico, passa attraverso un VPC interno in una regione AWS specifica.
Modello di elaborazione delle chiamate AWS Lambda: modalità richiesta-risposta
Le chiamate agli eventi possono essere effettuate immediatamente o aggiunte a una coda. In alcuni casi, la coda viene implementata utilizzando Amazon SQS (Amazon Simple Queue Service), che trasmette le chiamate al servizio di evasione chiamate Lambda attraverso un processo di polling interno. Il traffico trasmesso è protetto da TLS e non è prevista alcuna crittografia aggiuntiva dei dati archiviati in Amazon SQS.
Le chiamate agli eventi non restituiscono risposte: il Lambda Worker ignora semplicemente qualsiasi informazione sulla risposta. Le chiamate basate su eventi da Amazon S3, Amazon SNS, CloudWatch e altre origini vengono elaborate da Lambda in modalità evento. Le chiamate dai flussi Amazon Kinesis e DynamoDB, dalle code SQS, dall'Application Load Balancer e dalle chiamate API Gateway vengono elaborate in modalità richiesta-risposta.
Monitoraggio
Puoi monitorare e controllare le funzioni Lambda utilizzando una varietà di meccanismi e servizi AWS, inclusi i seguenti.
Amazon Cloud Watch
Raccoglie varie statistiche come il numero di richieste, la durata delle richieste e il numero di richieste non riuscite.
Amazon Cloud Trail
Ti consente di registrare, monitorare continuamente e conservare le informazioni sull'attività dell'account associate alla tua infrastruttura AWS. Avrai una cronologia completa delle azioni eseguite utilizzando la Console di gestione AWS, l'SDK AWS, gli strumenti a riga di comando e altri servizi AWS.
Raggi X AWS
Fornisce visibilità completa su tutte le fasi di elaborazione delle richieste nella tua applicazione in base a una mappa dei suoi componenti interni. Consente di analizzare le applicazioni durante lo sviluppo e negli ambienti di produzione.
Configurazione AWS
Potrai tenere traccia delle modifiche alla configurazione della funzione Lambda (inclusa l'eliminazione) e ai runtime, ai tag, ai nomi dei gestori, alle dimensioni del codice, all'allocazione della memoria, alle impostazioni di timeout e di concorrenza, nonché al ruolo di esecuzione Lambda IAM, alla sottorete e ai collegamenti ai gruppi di sicurezza .
conclusione
AWS Lambda offre un potente set di strumenti per creare applicazioni sicure e scalabili. Molte delle pratiche di sicurezza e conformità in AWS Lambda sono le stesse di altri servizi AWS, anche se esistono delle eccezioni. A partire da marzo 2019, Lambda è conforme agli standard SOC 1, SOC 2, SOC 3, PCI DSS, Health Insurance Portability and Accountability Act (HIPAA) e ad altre normative. Pertanto, quando pensi di implementare la tua prossima applicazione, considera il servizio AWS Lambda: potrebbe essere la soluzione migliore per la tua attività.
Fonte: habr.com