Hayden.
Y bienvenidos de nuevo.
En el vídeo de hoy hablaremos de la política de enrutamiento de latencia en Route 53.
Ahora puedo explicar el enrutamiento basado en la latencia de la forma más sencilla con la ayuda de Google Maps.
Así que estoy seguro de que la mayoría de ustedes ya han utilizado Google Maps.
Así que si quieres llegar a un destino específico ahora Google Maps puede darte múltiples caminos para llegar
a ese destino.
Ahora bien, la ruta que te dará Google Maps dependerá de las condiciones del tráfico y de lo rápido que
puedas llegar.
Así que no es que el camino que Google Map te ha dado hoy vaya a ser el mismo camino que Google Maps te pueda
dar mañana.
Puede ser un camino diferente dependiendo de las condiciones del tráfico.
Ahora, el enrutamiento de latencia sigue un planteamiento similar.
Ahora bien, si su aplicación está alojada en una región de varios niveles, podemos mejorar el rendimiento para
los usuarios sirviendo su solicitud desde la región que proporcione la latencia más baja.
Ahora, como hemos discutido que la latencia entre los servidores puede cambiar con el tiempo, por lo que puede haber
ciertos cambios en la red troncal, ciertos cambios de enrutamiento que pueden ocurrir.
Así, dependiendo de la región que ofrezca la latencia más baja, Route 53 dirigirá el tráfico a esa
región específica.
Así, por ejemplo, una solicitud que hoy se envía a la región de Singapur, mañana podría enviarse a la
región de India.
De nuevo, depende de la latencia global.
Así que permítanme mostrarles rápidamente cómo se vería esto exactamente con una demostración rápida.
Así que para la demostración de hoy, tenemos una zona alojada pública de Zee Vodacom.
Así que este fue uno de los dominios que pensé que vamos a utilizar para la prueba de una cierta cantidad de tiempo y para el enrutamiento
basado en la latencia.
Necesitamos una zona de acogida pública.
Así que ahora si ves aquí, tengo dos conjuntos de registros que están disponibles ambos tienen el registro de latencia
o Vodacom y tienes latencia 20. com.
Ahora cada uno de estos registros tiene un valor diferente.
El primero tiene el récord de 35, el segundo de 54.
Ahora, si hago clic en uno de los registros establecidos en su, verá que la política de enrutamiento es de tipo latencia.
Y la segunda, la política de enrutamiento de nuevo es de tipo latencia.
Así, cada vez que un usuario hace una petición de latencia a Vodacom, el conjunto de registros que se serviría depende
de la latencia global.
Digamos que tengo un servidor en la región de Mumbai y otro en la región de Estados Unidos.
Ahora, si un usuario intenta conectarse a la latencia a superar, será redirigido a la región de EE.UU. allí.
Sin embargo, si alguien de Singapur, alguien de Asia que podría tratar de conectarse a la misma latencia
de dominio a Vodacom, que podría ser redirigido al servidor más cercano.
Veamos cómo podría ser exactamente.
Así que voy a hacer clic, vamos a hacer rápidamente una búsqueda en latencia punto Z, Vodacom.
Por lo tanto, como actualmente me encuentro en la India, se me redirigirá al conjunto de registros que tenga la latencia
más baja desde mi ubicación.
Así que son 35. 1 54.
Muy bien, ahora hagamos una cosa.
Así que voy a abrir uno de los sitios web, que básicamente puede hacer una buena búsqueda.
De acuerdo.
Así que este sitio web en su mayoría, creo que esto sería en la región de EE.UU..
Así que digamos que voy a decir latencia a Z Vodacom.
Ahora esto va a funcionar porque la zona actual es una zona pública alojada, así que vamos a hacer un ir ahora.
Y ahora ves aquí básicamente dar una dirección de 54 a 110.
Sin embargo, dentro de la CLI, dio la dirección de 35. 1 54.
Ahora una de las preguntas que viene es cómo es diferente de la geolocalización, porque incluso con la geolocalización,
puedo decir que cualquier solicitud procedente de la región de EE.UU. iría a los recursos de EE.UU. de nosotros.
Sin embargo, hay ciertas diferencias.
Digamos que tienes un servidor en Bombay y otro en Singapur.
Ahora la petición se redirigirá a uno de los servidores que tenga la latencia más baja.
No es así.
Pongamos que en Mumbai y alguien de la India está tratando de conectarse a mi dominio.
Sin embargo, el servidor de la región de Bombay tiene la latencia más alta, por lo que la petición se dirigiría al servidor
de la región de Singapur.
Ahí es donde los registros basados en la latencia son realmente útiles.
Así que antes de concluir, permítanme mostrar rápidamente una cosa, así que voy a ir a la CE dos.
Así que, en general, si quieres crear una política de enrutamiento basada en la latencia, de nuevo, estoy seguro de que ya conoces
las formas básicas en las que puedes crear una política de enrutamiento.
Es muy sencillo.
Digamos que voy a decir como mi latencia de demostración.
Ahora tienes que dar el valor y antes de dar eso, sólo tienes que seleccionar la política de enrutamiento aquí como latencia.
Ahora dentro de la instancia EC two, vamos a seleccionar una región de Singapur y dentro de la región de Singapur
voy a crear una IP elástica aquí.
Vamos a crear rápidamente una IP elástica.
Muy bien, así que voy a copiar la IP elástica aquí y voy a pegarlo en el campo de valor y verás que detecta
automáticamente la región asociada a la IP elástica.
Esto es algo que me gusta mucho.
Esto es muy interesante.
Así que puedes darle un ID aquí, puedes darle, digamos, la región de Singapur y puedes seguir adelante y hacer una
creación.
De acuerdo.
Así que ahora tienes mi demo latencia zillow. com.
Puede crear varios conjuntos de registros en función de la IP elástica que pueda dar.
La región se autodetectaría en caso de IP elástica.
Una vez que lo hayas hecho, podrás probarlo y comprobar si el enrutamiento basado en la latencia funciona
para tu conjunto práctico.
Este es el resumen de alto nivel sobre el enrutamiento basado en la latencia.
Espero que este vídeo te haya resultado informativo y, de nuevo, si has creado una IP elástica,
no olvides liberarla, de lo contrario te cobrarán innecesariamente.
Así que con esto concluyo este vídeo.