Hayden.
E bentornati.
Nel video di oggi si parlerà dei criteri di instradamento della latenza in Route 53.
Ora posso spiegare il routing basato sulla latenza nella forma più semplice con l'aiuto di Google Maps.
Sono certo che la maggior parte di voi ha già utilizzato Google Maps.
Quindi, se si vuole raggiungere una destinazione specifica, ora Google Maps può fornire più percorsi per raggiungere quella
destinazione.
Ora, il percorso che Google Maps vi fornirà dipenderà dalle condizioni del traffico e dalla velocità con cui riuscirete
a raggiungerlo.
Quindi non è detto che il percorso che Google Map vi ha dato oggi sia lo stesso che Google Maps potrebbe
darvi domani.
Il percorso potrebbe essere diverso a seconda delle condizioni del traffico.
Ora, il routing a latenza segue un approccio simile.
Ora, se l'applicazione è ospitata in regioni a più livelli, possiamo migliorare le prestazioni per
gli utenti servendo le loro richieste dalla regione che fornisce la latenza più bassa.
Ora, come abbiamo detto, la latenza tra i server può cambiare nel tempo, per cui possono
verificarsi cambiamenti nella rete dorsale e nell'instradamento.
Quindi, a seconda della regione che offre la latenza più bassa, la Route 53 instraderà il traffico verso quella
regione specifica.
Quindi, una richiesta che oggi viene inoltrata alla regione di Singapore, domani potrebbe essere inoltrata alla regione
dell'India.
Anche in questo caso, dipende dalla latenza complessiva.
Permettetemi quindi di mostrarvi rapidamente come potrebbe apparire esattamente con una rapida dimostrazione.
Per la dimostrazione di oggi, abbiamo una zona pubblica ospitata da Zee Vodacom.
Questo è uno dei domini che ho pensato di utilizzare per i test per un certo periodo di tempo e per il routing basato
sulla latenza.
Dobbiamo avere una zona ospitata dal pubblico.
Quindi, se vedete qui, ho due set di record disponibili, entrambi con il record di latenza o
Vodacom e voi con latenza 20. com.
Ora, ogni recordset ha un valore diverso.
La prima ha un record di 35, la seconda di 54.
Ora, se faccio clic su uno dei record impostati, si vedrà che la politica di routing è di tipo latenza.
Il secondo, la politica di routing, è di tipo latenza.
Quindi, ogni volta che un utente fa una richiesta di latenza a Vodacom, il set di dischi da servire dipende dalla
latenza complessiva.
Supponiamo di avere un server nella regione di Mumbai e un server nella regione degli Stati Uniti.
Ora, se un utente cerca di connettersi alla latenza da superare, verrà reindirizzato alla regione degli Stati Uniti.
Tuttavia, se qualcuno da Singapore o dall'Asia cerca di connettersi allo stesso dominio con la stessa
latenza di Vodacom, potrebbe essere reindirizzato al server più vicino.
Vediamo quindi rapidamente come potrebbe essere esattamente questo aspetto.
Faccio quindi clic su, facciamo una rapida ricerca su latenza punto Z, Vodacom.
Quindi, dato che attualmente mi trovo in India, verrò reindirizzato al record set con la latenza più bassa rispetto
alla mia posizione.
Quindi sono 35. 1 54.
Bene, ora facciamo una cosa.
Quindi aprirò uno dei siti web, che fondamentalmente può fare una bella ricerca.
Va bene.
Quindi questo sito web è principalmente, credo, nella regione degli Stati Uniti.
Quindi diciamo che la latenza a Z Vodacom.
Ora questo funzionerà perché la zona corrente è una zona ospitata pubblicamente, quindi proviamo ora.
E ora vedete che in pratica dà un indirizzo da 54 a 110.
Tuttavia, all'interno della CLI, ha fornito l'indirizzo 35. 1 54.
Una delle domande che ci si pone è quanto sia diverso dalla geolocalizzazione, perché anche con la geolocalizzazione,
posso dire che qualsiasi richiesta proveniente dalla regione degli Stati Uniti andrebbe alle risorse statunitensi di noi.
Tuttavia, c'è una certa differenza.
Supponiamo che abbiate un server a Mumbai e uno a Singapore.
Ora la richiesta verrebbe reindirizzata a uno dei server con la latenza più bassa.
Non è così.
Se ci troviamo a Mumbai e qualcuno dall'India sta cercando di connettersi al mio dominio.
Tuttavia, il server della regione di Mumbai ha la latenza più alta, quindi la richiesta verrebbe indirizzata al server
della regione di Singapore.
È qui che le registrazioni basate sulla latenza sono davvero utili.
Quindi, prima di concludere, permettetemi di mostrarvi rapidamente una cosa, quindi passerò alla CE due.
Quindi, in generale, se si vuole creare un criterio di routing basato sulla latenza, sono sicuro che si conoscono
già i modi di base per creare un criterio di routing.
È abbastanza semplice.
Diciamo che come latenza della mia demo.
Ora si deve indicare il valore e prima di darlo, selezionare il criterio di instradamento come latenza.
Ora, all'interno dell'istanza EC due, selezioniamo una regione di Singapore e all'interno della regione di
Singapore creerò un IP elastico.
Creiamo rapidamente un IP elastico.
Bene, quindi copierò l'IP elastico qui e lo incollerò nel campo del valore e vedrete che verrà rilevata
automaticamente la regione associata all'IP elastico.
Questo è un aspetto che mi piace molto.
Questo è piuttosto interessante.
Si può quindi assegnare un ID, ad esempio la regione di Singapore, e si può procedere alla creazione.
Va bene.
Quindi ora avete la mia demo della latenza di Zillow. com.
È possibile creare più set di record a seconda dell'IP elastico che si vuole fornire.
La regione verrebbe rilevata automaticamente in caso di IP elastico.
Una volta fatto questo, si può provare e verificare se il routing basato sulla latenza funziona
per il proprio set pratico.
Questa è la panoramica di alto livello sul routing basato sulla latenza.
Spero che questo video sia stato istruttivo per voi e, ancora una volta, se avete creato un IP elastico,
non dimenticate di rilasciarlo, altrimenti vi verrà addebitato inutilmente.
Con questo concludo il video.