2016-06-28 17 views
6

Stavo cercando di valutare SNS per un'applicazione in tempo reale che sto costruendo e ho avuto bisogno di un tempo di rotazione molto rapido < 2 secondi nel recapito del messaggio.Qual è l'SLA previsto (contratto a livello di servizio) sui messaggi Amazon SNS?

Dal momento che mi trovo nella regione APAC, ho un SNS a Singapore che ha un abbonato in Lambda in Us-east-1 location.

Dato questo setup ho eseguito un codice per cercare di capire la latenza nel richiamare lambda e fare l'elaborazione zero e solo registrare l'ora. Si potrebbe argomentare che si è verificata una latenza di chiamata lambda anche in questo caso. Che è vero. Ho bisogno che Lambda venga invocato ed eseguito e risposto entro < 2 secondi.

Ho inviato 23914 messaggi di cui ho una media di 653.520 ms per il trasporto + invocazione lambda. con picchi intorno a 600995 ms (~ 10 minuti), che è terribile latenza per una tecnologia come pubub. enter image description here Circa 20117 messaggi sono stati inviati e ricevuti da lambda in < 653 ms, che significa 3797 pacchetti o il 15% ha richiesto più del tempo medio.

2958 messaggi o 12,36% ha impiegato più di 1 secondo per essere eseguito. 379 messaggi o 1,59% hanno impiegato più di 2 secondi per essere invocati ed eseguiti (il che significa che l'1,6% dei miei messaggi non può essere considerato in tempo reale e devono essere ignorati) 82 messaggi in 10 secondi 64 oltre 20 secondi continua fino a ~ 45 secondi, dopo di che il ritardo è di 10 minuti. Ho 3 pacchetti con un ritardo di 10 minuti.

ciò che mi dà fastidio è che circa il 2% (se si include anche il tempo di elaborazione) dei miei messaggi non può essere elaborato in tempo reale per una piccola scala di ~ 24K messaggi.

Nel calcolo della scala che sto cercando di presentare, mi richiede di elaborare circa 216 miliardi di messaggi al mese. A questa scala sono preoccupato che non sarò in grado di elaborare 4,3 miliardi di messaggi in tempo reale.

Dato questo esperimento non sono sicuro di quanto bene SNS sarebbe scalare. il numero minore di messaggi in tempo reale (leggi> 2 secondi di ritardo) sarà più? o diminuirebbe?

Ora potrebbe esserci una tendenza a mettere in dubbio l'affidabilità della mia connessione internet, ho ripreso questo esperimento su EC2 e ho ottenuto risultati molto simili.

Infatti i ritardi nel tempo sono stati pari all'incirca alla stessa ora.

Domande specifiche

  1. quali sono gli SLA per SNS prestazioni?
  2. Indirettamente: come si traduce questo SLA in quello dei servizi AWS Lambda?
  3. Eventuali motivi per cui questi ritardi potrebbero verificarsi?
+0

Sembra * estremamente * improbabile che si tratti di limiti di scalabilità con SNS. Un percorso da indagare è [stato di consegna dei messaggi SNS] (http://docs.aws.amazon.com/sns/latest/dg/msg-status-topics.html), che può darti maggiori informazioni. [SNS non sembra avere uno SLA formale di deliverability] (https://forums.aws.amazon.com/thread.jspa?threadID=222330). –

risposta

0

Molto probabilmente quello che è successo qui era la limitazione della funzione Lambda. Il limite predefinito per concurrent Lambda invocations is 100. Se hai inviato messaggi a 20K, probabilmente hai superato tale limite, nonostante il breve tempo di esecuzione del lambda. Quando le funzioni lambda vengono limitate durante l'esecuzione di una richiesta SNS, la richiesta passa a una coda tentativi e viene rieseguita fino a 3 volte, che si verificano spesso per un lungo periodo di tempo (fino a un'ora).

È possibile visualizzare il numero di throttles nelle metriche di CloudWatch per la funzione (sfortunatamente, il test è stato eseguito prima di 6 mesi di conservazione di CloudWatch).

0

Ultimo controllo non esiste SLA per SNS. SNS è progettato per essere scalabile orizzontalmente e (quasi) non rilasciare mai un messaggio, non consegnarlo rapidamente.

C'è qualche motivo per cui non è possibile richiamare il lambda dall'editore tramite l'API e archiviare i dati all'interno dell'evento passato all'invocazione?

Problemi correlati