Panoramica

I servizi AWS Edge sono componenti importanti per la creazione di applicazioni web ad alta disponibilità. Oltre alla loro originaria elevata disponibilità grazie alla loro natura distribuita, i servizi AWS Edge fungono da punto di accesso alle applicazioni web e possono instradare le richieste alle partizioni disponibili nell'infrastruttura di origine (ad esempio zona di disponibilità o Regione).

Decisioni sull'architettura

Un'applicazione web ad alta disponibilità può essere progettata in diversi modi, in base ai requisiti in termini di disponibilità SLO, costi e complessità. Come minimo, è necessario prendere le seguenti decisioni tecniche in base ai requisiti aziendali:

  • Hai un'architettura attiva/attiva o attiva/passiva?
  • Hai origini diverse? Zone di disponibilità diverse? Regioni diverse?
  • Qual è la logica di instradamento tra le origini per l'architettura attiva/attiva? Quali sono i criteri di failover per l'architettura attiva/passiva?

Gestione degli errori transienti dell'origine

CloudFront può aiutarti a mitigare l'impatto degli errori transienti 5xx che possono occasionalmente compromettere un numero limitato di richieste degli utenti. Spesso ciò è dovuto a un'origine sovraccaricata da improvvisi picchi di traffico o da problemi transienti di rete. Puoi mitigare gli errori transienti 5xx con CloudFront in diversi modi.

Riprova. CloudFront può essere configurato per riprovare la connessione TCP fino a tre volte con un timeout di connessione configurabile quando non è possibile stabilire una connessione con l'origine. CloudFront riprova anche l'idempotente GET/HEAD in base al numero di tentativi configurato.

Rispondi con contenuti obsoleti. Se i tentativi falliscono con l'origine, CloudFront per impostazione predefinita fornisce una versione obsoleta dell'oggetto, se disponibile nella cache, anziché restituire una risposta di errore. Questo comportamento può essere disabilitato utilizzando la direttiva Cache-Control: stale-if-error=0.

Failover dell'origine all'origine secondaria. Puoi configurare CloudFront in modo che fallisca su un'origine secondaria per la specifica richiesta fallita utilizzando la funzionalità Failover dell'origine. Il failover dell'origine si applica solo alle richieste GET/HEAD idempotenti. Tieni presente che se usi Lambda@Edge sugli eventi di origine, CloudFront esegue la funzione anche in caso di failover. In questo scenario, puoi dedurre nella funzione Lambda@Edge se la richiesta riguardava l'origine primaria o secondaria per differenziarne la logica. Per farlo, hai configurato la stessa intestazione personalizzata di origine in entrambe le origini, ma con valori diversi che Lambda@Edge può leggere.

Failover regolare. Se il failover dell'origine su un'altra origine non è desiderabile (ad esempio per mantenere un'altra infrastruttura di origine), prendi in considerazione il failover su un file statico ospitato in una posizione diversa (ad esempio il bucket S3) utilizzando la Pagina di errore personalizzata. Per impostazione predefinita, la stessa pagina viene utilizzata per tutte le richieste che generano errori, tuttavia si crea una risposta più dinamica seguendo il terzo schema di questo blog.

Failover stateful durante le interruzioni dell'origine

Failover basato sulla policy di Route 53

Puoi utilizzare la policy di routing di failover di Route 53 con controlli dell'integrità del nome di dominio di origine configurato come origine in CloudFront. Quando l'origine primaria non è integra, Route 53 la rileva e quindi inizia a risolvere il nome di dominio di origine con l'indirizzo IP dell'origine secondaria. CloudFront rispetta il TTL del DNS di origine, il che significa che il traffico inizierà a fluire verso l'origine secondaria all'interno del TTL del DNS. La configurazione ottimale (Fast Check attivato, una soglia di failover di 1 e un TTL del DNS di 60 secondi) prevede che il failover abbia bisogno di almeno 70 secondi. In tal caso, tutto il traffico viene trasferito all'origine secondaria, poiché si tratta di un failover stateful. Tieni presente che questo design può essere ulteriormente esteso con Route 53 Application Recovery Control per un failover delle applicazioni più sofisticato su più Regioni AWS, zone di disponibilità e on-premise. Questo approccio può essere combinato con la funzionalità CloudFront Failover dell'origine per le richieste GET/HEAD,in modo da ridurre gli errori mentre Route 53 esegue il failover sull'origine secondaria. Questo modello è descritto in questo blog.

Quando le diverse origini non condividono lo stesso nome di dominio, ad esempio per le origini basate su S3, Route 53 non può essere utilizzata nel modo proposto sopra. In questo scenario, è necessaria una funzione Lambda@Edge configurata sull'evento di richiesta di origine per fare una query in Route 53 sull'origine da selezionare, quindi reinstradare la richiesta verso l'origine selezionata, modificando il nome del dominio di origine e con l'intestazione dell'host. Per saperne di più su questa implementazione, leggi i seguenti casi di studio di Contentful.

Failover con Global Accelerator

Le applicazioni che utilizzano Global Accelerator possono trarre vantaggio dalle sue funzionalità di failover native. Utilizzando Global Accelerator, la tua applicazione può essere distribuita in una singola Regione AWS, su più zone di disponibilità o su più Regioni AWS. Global Accelerator monitora lo stato degli endpoint delle applicazioni mediante controlli dell'integrità e instrada il traffico lontano dagli endpoint non integri in poche decine di secondi.

Architetture Active-Active

Instradamento basato sulla latenza

CloudFront può essere utilizzato con la policy basata sulla latenza di Route 53 per instradare le richieste degli utenti verso la Regione AWS più vicina in cui è stata replicata l'origine in un'architettura multiregionale Active-Active. Per farlo, configura il nome di dominio di origine in CloudFront con una policy basata sulla latenza in Route 53. Quando CloudFront risolve il nome di dominio di origine per connettersi e inviare la richiesta all'origine, Route 53 restituisce l'IP di origine più vicino in base alla latenza. Tieni presente che la posizione da cui CloudFront risolve il nome di dominio di origine dipende dalla configurazione della distribuzione e dal tipo di traffico. In generale, il nome di dominio viene risolto nella posizione edge per le richieste dinamiche e nelle cache edge regionali per i contenuti memorizzabili nella cache. Questo blog ti guida attraverso un'implementazione active-active multiregionale per il Gateway API.

Quando le diverse origini non condividono lo stesso nome di dominio, ad esempio per le origini basate su S3, Route 53 non può essere utilizzata nel modo proposto sopra. In questo scenario, è necessario che Lambda@Edge sia configurato sull'evento di richiesta dell'origine per effettuare l'instradamento verso l'origine più vicina. Per saperne di più su questa attuazione, leggi i seguenti blog:

Instradamento avanzato

In alcuni scenari, l'instradamento delle richieste richiede una logica a livello di applicazione. Quando la logica è semplice, ad esempio l'instradamento verso origini diverse in base al percorso (ad esempio, indirizza /api1 all'origine 1 e /api2 all'origine 2), puoi semplicemente utilizzare la funzionalità di comportamento della cache nativa di CloudFront. Se la logica è più sofisticata, l'evento Lambda@Edge sulla richiesta dell'origine consente di indirizzare il traffico in base agli attributi a livello di applicazione, come URL, cookie, intestazioni, Paese, ecc. La logica può essere stateless e completamente incorporata nel codice della funzione oppure può essere archiviata in una posizione esterna come S3 o DynamoDB, da cui Lambda@Edge recupera la regola di instradamento per eseguirla.

Risorse

Questa pagina è stata utile?

 Feedback