Amazon Elastic Beanstalk Worker Tier

Question

Ho bisogno di fare un po 'di lavoro asincrono dato una richiesta web che invierò periodicamente fino a quando non è completa. Ho l'intero stack installato e funzionante localmente ma non riesco a capire concettualmente come spostarlo sul livello di lavoro EBS. Sto usando Django con Celery e RabbitMQ localmente e sono riuscito a sostituire RabbitMQ con Amazon SQS. Tuttavia, quando ho provato a creare un livello di lavoro che operasse dallo stesso database RDS della webapp, ma non ha avuto successo. Sono bloccato al punto in cui posso mettere in coda i messaggi ma non posso leggerli dalla coda. Ho bisogno di usare quei messaggi per eseguire alcune costose operazioni sul database e preparare il risultato per il consumatore. C'è qualche pezzo architettonico che mi manca? Come e dove posso ottenere un demone di sedano per elaborare i messaggi SQS?

Answer 1

Dal Elastic Beanstalk documentation:

Quando si avvia un ambiente AWS Elastic Beanstalk, si sceglie un ambiente di livello, la piattaforma, e il tipo di ambiente. Il livello di ambiente scelto determina se AWS Elastic Beanstalk fornisce risorse per supportare un'applicazione Web che gestisce richieste HTTP (S) o un'applicazione Web che gestisce attività di elaborazione in background.

AWS Elastic Beanstalk installa un daemon su ogni istanza Amazon EC2 nel gruppo Auto Scaling per elaborare i messaggi Amazon SQS nel livello dell'ambiente di lavoro. Il daemon estrae i dati dalla coda di Amazon SQS, li inserisce nel corpo del messaggio di una richiesta POST HTTP e li invia a un percorso URL configurabile dall'utente sull'host locale. Il tipo di contenuto per il corpo del messaggio all'interno di una richiesta POST HTTP è application/json per impostazione predefinita.

Dal punto di vista dello sviluppatore, l'applicazione in esecuzione sul livello di lavoro è solo un semplice servizio web. Riceverà chiamate dal demone AWS Elastic Beanstalk fornito per te sull'istanza.

Le richieste vengono inviate al valore Path HTTP configurato. Questo viene fatto in modo tale da apparire all'applicazione web nel livello dell'ambiente di lavoro che il daemon ha originato la richiesta. In questo modo, il daemon svolge un ruolo simile a un sistema di bilanciamento del carico in un livello di ambiente del server Web.

Il livello dell'ambiente di lavoro, dopo aver elaborato i messaggi nella coda, inoltra i messaggi tramite il loopback locale a un'applicazione Web in un URL designato dall'utente. L'URL della coda è accessibile solo dall'host locale. Poiché è possibile accedere solo all'URL della coda dalla stessa istanza EC2, non è necessaria alcuna autenticazione per convalidare i messaggi consegnati all'URL.

Un'applicazione Web in un livello dell'ambiente di lavoro deve essere ascoltata solo sull'host locale.Quando l'applicazione Web nel livello dell'ambiente di lavoro restituisce una risposta di 200 OK per confermare che ha ricevuto ed elaborato correttamente la richiesta, il daemon invia una chiamata DeleteMessage alla coda SQS in modo che il messaggio venga eliminato dalla coda. (SQS elimina automaticamente i messaggi che sono rimasti in coda più a lungo di RetentionPeriod configurato.) Se l'applicazione restituisce una risposta diversa da 200 OK o non c'è risposta entro il periodo di InactivityTimeout configurato, SQS rende di nuovo il messaggio visibile nella coda e disponibile per un altro tentativo di elaborazione.

Answer 2

Attualmente sto utilizzando un livello web "standard" (configurato con un numero maggiore di processi e thread) con la mia app Django + Celery e ho un'istanza EC2 con un'AMI personalizzata che esegue RabbitMQ. SQS non è completamente supportato da sedano, da http://docs.celeryproject.org/en/latest/getting-started/brokers/sqs.html:

Il trasporto SQS ha bisogno di miglioramenti in molti settori e ci sono parecchi insetti aperti.

Onestamente non ho mai capito cosa si suppone debba essere/un livello di web worker, ma la mia configurazione attuale sembra funzionare piuttosto bene (uso anche il beat di Celery per gestire le attività del periodo). I ha demonizzato Celery usando Supervisor (che è già utilizzato da Elastic Beanstalk per gestire apache).