AWS lambda e applicazione web con sessioni e database - applicazioni web, aws-lambda

Siamo nella fase iniziale dello sviluppo di un nuovo applicazione web e voglio fare uso della piattaforma cloud di Amazon. Tuttavia, abbiamo una scelta di sviluppare applicazioni web utilizzando Java spring quadro o qualsiasi altra programmazionelingua / quadro. L'applicazione multipagina non è stateless, cioè l'applicazione deve tenere traccia della sessione utente per le transazioni una volta effettuato l'accesso. Una volta che tutte le informazioni richieste vengono acquisite dall'utente attraverso più pagine, la transazione viene impegnata nel database.

Tuttavia, c'è una possibilità di utilizzo AWS lambda servizi per questa applicazione. Sarebbe una decisione giusta per sviluppare un'applicazione web con i requisiti sopra riportati AWS Lambda (sapendo che il servizio Lambda è senza sessione)?

risposte:

La tua domanda non è specifica per Lambda. L'unico caso in cui la gestione delle sessioni è facile (ad es. Può essere risolta in memoria o in un archivio basato su file) è in un unico ambiente server. Probabilmente è da dove vieni.

Nel momento in cui inizi a ridimensionare orizzontalmente (putpiù server nel mix si oppongono semplicemente a mettere più RAM / CPU nel server) è necessaria una memoria centrale per le sessioni (e anche la cache). Questo è lo stesso se si sceglie il docker, o EC2 o anche i server di metallo dietro un sistema di bilanciamento del carico.

Questo perché non si può mai sapere se il prossimorichiesta dallo stesso utente atterrerà sullo stesso ambiente. Ovviamente questo vale anche per lambda, ma c'è una soluzione alternativa: cioè, se usi un loadbalancer per usare "sessioni adesive": questo instraderà ogni richiesta dello stesso utente sulla stessa macchina, vedi questo documento AWS sulla gestione delle sessioni. Ma la sessione appiccicosa è sempre subottimale (ad esempio ridimensionare significherebbe distruggere le sessioni) più per lambda, le sessioni appiccicose non sono possibili afaik.

La vera soluzione, come suggeriscono le altre risposte qui proposte, include l'archiviazione della sessione centrale tramite Elasticache. Una citazione dal link precedente:

Per affrontare la scalabilità e fornire al'archiviazione dei dati condivisa per le sessioni che possono essere accessibili da qualsiasi singolo server Web, è possibile astrarre le sessioni HTTP dai server Web stessi. Una soluzione comune per questo è sfruttare un archivio di chiavi / valori in memoria come Redis e Memcached.

È possibile che un'applicazione con stato sia in esecuzione su Lambda se è possibile utilizzare una memoria persistente esterna per i dati della sessione.

È possibile utilizzare DynamoDB o Elasticache, ad esempio come memoria temporanea per i dati della sessione e una volta che tutti i dati richiesti sono pronti, è possibile mantenerli permanentemente nelle query del database.

C'è molto da considerare quando si decide se un'architettura senza server è adatta alla propria applicazione. Non credo che ci sia una risposta "taglia unica" a questa domanda.

L'uso di Lambda al posto di, ad esempio, un contenitore di servlet, introduce effettivamente un po 'di overhead di sviluppo rispetto alla persistenza della sessione. Tuttavia, non penso che questo debba necessariamente essere un primario considerazione quando ti chiedi se un'architettura serverless è appropriata per la tua applicazione. Prima di preoccuparmi di come funzionerà la sessione, mi chiedo:

• Sono disposto e in grado di scrivere l'applicazione come una raccolta di microservizi, accettando le ulteriori complessità operative e di sviluppo che derivano da tale approccio?
• Sono disposto ad utilizzare un approccio di rendering lato client per la mia interfaccia utente? In caso contrario, la tecnologia di rendering lato server che ho scelto si integra facilmente con Lambda?
• Quanta logica aziendale posso incorporare (in modo sicuro) lato client?
• Quali sono i miei modelli di traffico (e per estensione, esigenze di scalabilità)? Il mio traffico è costante? Spiky? Ho lunghi periodi di dormienza?
• È serverless probabile avere un vantaggio di costo oltre EC2?
• Quanto dannosa sarà la partenza a freddo di Lambda per il tuo UX?
• Infine, per quanto riguarda la sessione, quanto sono sensibili i dati in sessione? Una sessione "senza stato" utilizza l'opzione JWT?

Se la tua applicazione è veramente adatta per un'architettura senza server, il sovraccarico di capire come perseguire la sessione probabilmente non è così costoso da essere un rompicapo.

Nella mia esperienza, sviluppatori (incluso me stesso)lottare molto di più con il cambio di paradigma verso i microservizi e (spesso) il rendering lato client, piuttosto che con le peculiarità di come la sessione viene implementata o mantenuta.