Come utilizzare AWS SQS/SNS come coda di notifica push per attività di elaborazione pesanti tramite PHP?

Question

Ho un singolo server in esecuzione su rackspace che ospita una singola app web PHP.

L'app web PHP accetta l'invio di un modulo che deve quindi eseguire un'attività in base alle voci del campo modulo.

L'attività (chiamiamola attività di generazione dei metadati) richiede molto tempo di elaborazione. Mi chiedevo come consentire all'invio del modulo di essere un semplice salvataggio nel database e mostrare immediatamente la pagina di successo all'utente mentre eseguivo l'attività di generazione dei metadati in background.

Ho installato "aws/aws-sdk-php": "~3.11" utilizzando il compositore nella stessa app Web.

Il mio piano è inizialmente questo:

codice che gestisce l'invio del modulo

$result = $model->save($_POST); 
// this code will send the information to either SQS or SNS 
$awsClient->sendsMessage($_POST); 
if ($result) { 
    $this->redirect('success.html'); 
} 

Ho letto circa la fanout architecture dichiarato da AWS.

I miei problemi con l'esempio di architettura fan-out (se ho capito bene) sono questo:

1. il server che invia il messaggio a uno SQS o SNS sarà anche lo stesso server che elabora il compito di generare metadati. In effetti, è la stessa app web.
2. SQS soddisfa la parte della coda (perché voglio eseguire le attività in una FIFO e le attività richiedono molto tempo per essere soddisfatte). Tuttavia, richiede che la mia app Web effettui il polling di SQS continuamente. Voglio una notifica push (da AWS alla mia app Web) piuttosto che la mia app Web che esegue il polling continuo di AWS per verificare l'esecuzione delle attività.

ho trovato una possibile soluzione suggerita here

La soluzione suggerita è:

1. inviare il messaggio ad un argomento SNS.

2. L'argomento SNS invia un messaggio sia alla coda SQS che alla mia app Web.

3. mio web app, dopo essere stato attivato, il polling la stessa coda SQS che ora è in coda il messaggio in modo continuo fino a quando la coda è vuota

Lo svantaggio che vedo da questo è che la mia web app eseguirà il polling della coda prima che la coda stessa abbia il messaggio.

Qual è il modo migliore per implementare le code di push utilizzando i servizi AWS?

Answer 1

mia web app sarà polling coda prima della coda stessa ha il messaggio

Non hai provato, allora, giusto? :) Ho paura che tu stia pensando troppo a questo.SQS ha polling lungo, che provoca la sospensione della richiesta di polling sul lato SQS fino a quando almeno un messaggio è disponibile, a quel punto verrà restituito il messaggio (fino al numero massimo richiesto). È possibile impostare il tempo di attesa per il polling lungo da 1 a 20 secondi. Se non sono disponibili messaggi entro questo intervallo di tempo, la risposta viene restituita senza messaggi.

Se si esegue il polling della coda in risposta alla notifica da SNS, è possibile trovare se si utilizza il polling lungo. È possibile che i messaggi vengano ritardati, ma è improbabile .

L'altro problema, tuttavia, è la tua affermazione che non vuoi che l'app esegua costantemente il polling SQS. Incontro questa obiezione abbastanza spesso, ed è spesso fuori luogo. Con il polling lungo SQS, "costantemente" il polling di una coda vuota significa una richiesta ogni 20 secondi. Questo è 3 req/minuto, 180 req/ora, 4320 req/giorno, 129600 req/mese ... che risulta essere inferiore alle 1 milione di richieste gratuite consentite ogni mese.

Il problema con il server che reagisce alle notifiche piuttosto che eseguire il polling di una coda in background con un numero appropriato di lavoratori è che potresti essere facilmente sopraffatto da una grande quantità di lavori che arrivano all'incirca nello stesso momento. Se ricevi 10 richieste simultanee, puoi gestirle? 100? 1000? Spesso, per lavori asincroni come questo, costa meno (in termini di risorse) richiedere il lavoro piuttosto che eseguire il lavoro (ad esempio, il caricamento di un'immagine richiede molto meno CPU rispetto al ridimensionamento di tale immagine). A meno che non si coordinhi la risposta di reazione, si potrebbe sopraffare il sistema.

Non cadere in una trappola concettuale di "polling è male, push is good" dove non si applica. La stragrande maggioranza delle volte, questo sentimento è assolutamente corretto ... il polling è quasi sempre la soluzione sbagliata ... ma con il polling SQS lungo, quello che hai veramente è un meccanismo di push racchiuso in un modo che lo rende compatibile con HTTP e gran parte del male intrinseco del sondaggio ... scompare. Se sei nel bel mezzo di un lungo sondaggio, la coda è vuota e arriva un messaggio, il tuo lungo sondaggio tornerà quasi immediatamente con quel messaggio. Non si siede in attesa che si verifichi il timeout. Un processo in background che osserva la coda potrebbe essere un buon modo per andare dopo tutto.