Problemi di svuotamento connessione AWS/ELB

Question

Questa domanda è stata posta nei forum di AWS senza alcuna risposta. Segue la domanda originale

---

Ciao!

Stiamo eseguendo aggiornamenti a rotazione delle nostre istanze API dietro un ELB e stiamo osservando in modo allarmante tempi lunghi in attesa del completamento della connessione. Lo scenario è il seguente:

Stiamo eseguendo due sistemi identici, 4x c3.large dietro un ELB, un sistema per dev e un sistema per la produzione. L'unica differenza tra i due sistemi è che il sistema di produzione serve continuamente le richieste.

Un aggiornamento continuo sul sistema di sviluppo richiede circa 3 minuti per tutte le 4 istanze in assenza di traffico. Sul sistema di produzione questi tempi oscillano tra 6 e 17+ minuti. Per motivi, abbiamo bisogno di fare questi aggiornamenti in rotazione in media circa 2 volte all'ora e poi 17+ minuti per un aggiornamento progressivo sta iniziando a diventare un problema.

Tutte le nostre chiamate API sono < 100 ms quindi non ci sono richieste a lungo termine che dovrebbero mantenere la connessione drenante per così tanto tempo. Abbiamo giocato con la modifica dei valori sia per il ritardo di inattività che per il drenaggio delle connessioni sull'ELB senza risultati positivi.

Quando si abbassa il timeout di interruzione della connessione, vengono visualizzate 502 risposte dall'API, poiché l'eliminazione forzata delle connessioni e la riduzione del timeout di inattività sembrano non avere alcun effetto.

Tutto sommato, vorremmo sapere cosa si può fare per ridurre questi tempi. Poiché le nostre richieste sono tutte a < 100 ms, in teoria non dovrebbe richiedere più di un secondo o due per drenare le connessioni da un'istanza. C'è qualcosa che ci manca qui?

Un'ultima nota: abbiamo provato a disattivare la connessione drenando tutti insieme e questo sembrava funzionare meglio di ridurre il tempo di esaurimento della connessione. In media c'erano solo 1 o 2 errori per test run e alcune run non avevano errori. Questo perché i tempi di risposta sono così veloci? Anche le nostre risposte sono relativamente piccole, quindi potrebbe essere possibile che la risposta TCP sia salvata nel buffer di output del sistema operativo in modo che possa rispondere anche se il drenaggio della connessione è disattivato? Qual è la differenza tra il timeout del drenaggio della connessione impostato su 0 e disattivato?

Ulteriori informazioni:

• Tutto il traffico è HTTPS
• terminazione SSL accade sulle istanze
• keep-alive è abilitato su nginx (cercato di variare il valore anche qui senza alcun risultato)

Grazie!

Answer 1

Questa è una domanda complessa con un numero di variabili e quindi posso dare alcuni suggerimenti per esaminare.

1) Controllare le impostazioni di Intervallo di controllo integrità, Timeout risposta e Soglia non salutare. Se, come parte dell'aggiornamento progressivo, si interrompono le istanze mentre l'ELB sta ancora eseguendo i controlli di integrità, l'ELB attenderà la durata del "Tempo di risposta" indipendentemente dal drenaggio della connessione. Se il timeout è impostato per 1 minuto con 3 tentativi ("Soglia non salutare") è 3 minuti per server prima che l'ELB dichiari l'istanza morta.Quindi, anche con lo scollegamento della connessione impostato su zero, nessuna nuova richiesta verrà inviata a quell'istanza, ma l'ELB aspetterà per 3 minuti finché non deciderà che l'istanza è effettivamente morta.

Caso peggiore: moltiplica per 4 istanze e sei a 12 minuti prima che l'ELB capisca che tutte le istanze sono morte. In altre parole, l'ELB è occupato ad aspettare che gli healthcheck falliscano effettivamente.

2) Annullare la registrazione delle istanze dall'ELB prima di terminarle? Questo evita il problema al punto 1 sopra.

3) Disattivazione di collegamento Scarico e di una connessione a drenante con un valore di timeout di zero deve fornire la funzionalità equivalente