DEV Community

Cover image for Midiendo la latencia hacia la nueva región de AWS España (eu-south-2 en Zaragoza)
Luis Horvath for AWS Español

Posted on

Midiendo la latencia hacia la nueva región de AWS España (eu-south-2 en Zaragoza)

A principios de año, me encontraba en el AWS re-cap en Madrid para conocer las novedades del re:Invent del 2022 y para ver de primera mano la presentación de la nueva región de AWS de España en Zaragoza.

En la sesión de preguntas, hice una pregunta acerca de las latencias desde Madrid hasta Zaragoza.

Antes de meternos y profundizar un poco... ¿qué es la latencia?

La latencia es un término utilizado para describir el retardo de tiempo en un medio de transmisión.

En el vacío, la luz viaja a 299.792.458 metros por segundo. Esto equivale a 299,792 metros por microsegundo (µs) o 3,34µs por kilómetro.

En la fibra óptica, la luz viaja más despacio por la refracción. Lo que nos da una medición aproximada de 5µs por kilómetro.

Quería saber cuál es la latencia (RTT --> De ida y vuelta) para un cliente en España que quiera utilizar el servicio de Direct Connect desde Interxion MAD, hasta Zaragoza, al nuevo clúster de AWS.

Zaragoza está a unos 320 km de Madrid (aproximadamente), el clúster no está en la misma área metropolitana, como se puede observar.

Image description

Mi pregunta tiene un poco de mala leche, porque no se tratan de los km de fibra que tiene que atravesar la luz, sino también del número de dispositivos de red por los que debe pasar el flujo de datos hasta llegar al destino.

Se me dijo "aproximadamente menos de 10ms" como respuesta.

Después de muchos meses, decidí resolver la ecuación y hacer esta medición; somos ingenieros y nos gusta la precisión ;)

Intentaré que la solución sea sencilla y que lo podamos entender; empecemos:

Para realizar esta medición, he creado la siguiente infraestructura en AWS:

Image description

La idea detrás de este diseño es poder acceder a mi Host Privado 1 en la subred privada vía SSH desde el bastión, que está accesible en desde internet, en la subnet pública.

(También podría haber usado una IP elástica directamente para el Host Privado, simplificando el diseño, sin tener que crear un bastion host ni dos subnets distintas...)

Image description

Visto así, parece fácil, ¿verdad?

Ahora imagina replicar la misma infraestructura utilizando una dirección de red diferente pero manteniendo la misma configuración.

Image description

Ahora que tenemos estas dos infraestructuras, ¿cómo podemos interconectarlas?

Image description

Utilizando el Servicio de Direct Connect (DX) y con la ayuda de un socio/partner de interconexión. Para este laboratorio, utilizaré a DE-CIX.

Interconectaremos el VPC1 con una conexión DX hosteada, en una ubicación donde AWS y el partner están presentes → en Interxion Madrid.

Haremos lo mismo con la VPC2 utilizando otra conexión DX que termine en el mismo DC (en Interxion MAD).

Una vez interconectados, haremos un ping desde el Host Privado 1, al Host Privado 2 para medir el camino hasta Madrid desde Zaragoza.

Quizás os preguntaréis, ¿cómo vais a interconectar las dos DXcon? ¿Tienes allí un rack con dispositivos de networking para enrutar y hacer mediciones?

La respuesta a la última pregunta es sí y no; utilizaremos el Cloud Router de DE-CIX para interconectar las dos Conexiones de AWS en Interxion.

El Cloud Router es una instancia VRF (Virtual Routing & Forwarding) ejecutada en un equipo de red de grado carrier.

Image description

Image description

Si enviamos un ping desde el Host Privado 1 al Host Privado 2, el ping fluye de Zaragoza a Madrid y de Madrid a Zaragoza, terminando en el Host Privado 2 y volviendo al Host Privado 1.

Como queremos obtener la latencia de medio camino (sólo de Zaragoza a Madrid), debemos dividirla por dos si realizamos un ping.

Medidas

He realizado dos ejecuciones de ping con diferentes tamaños de ventana para realizar las mediciones. Como podéis ver, la latencia puede variar un poco. Esto depende de la ruta que esté tomando AWS dentro de su backbone. Parece que hay dos formas diferentes de llegar al destino, una con menos latencia que la otra.

También, debido a que hay diferentes zonas de disponibilidad (AZs), la latencia puede variar dependiendo de donde se encuentren nuestros recursos.

Tamaño de ventana 128K - Ejecución 1

Image description

Avg = 11,934 / 2 = 5,967 ms

Tamaño de ventana 128K - Ejecución 2

Image description

Avg= 16.441 / 2 = 8.2205 ms

Tamaño de ventana 256K - Ejecución 1

Image description

Promedio = 11.928 / 2 = 5.964 ms

Tamaño de ventana 256K - Ejecución 2

Image description

Promedio = 16.451 / 2 = 8.2255 ms

Tamaño de ventana 512K - Ejecución 1

Image description

Promedio = 11.946 / 2 = 5.973 ms

Tamaño de ventana 512K - Ejecución 2

Image description

Promedio = 16,452 / 2 = 8,226 ms

Tamaño de ventana 1024K - Ejecución 1

Image description

Promedio = 11.975 / 2 = 5.9875 ms

Tamaño de ventana 1024K - Ejecución 2

Image description

Image description

Promedio = 16,492 / 2 = 8,246 ms

Media de las muestras tomadas:
Ejecución 1 ≈ 5,97 ms
Ejecución 2 ≈ 8,23 ms

Conclusión

La respuesta a mi pregunta varía y depende; depende por la ruta interna del backbone de AWS pase y dónde estén tus recursos; pero objetivamente no son 10ms, son 6 u 8 ms (aprox.) para llegar a la nube desde Madrid a Zaragoza.

Top comments (0)