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.
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:
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...)
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.
Ahora que tenemos estas dos infraestructuras, ¿cómo podemos interconectarlas?
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.
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
Avg = 11,934 / 2 = 5,967 ms
Tamaño de ventana 128K - Ejecución 2
Avg= 16.441 / 2 = 8.2205 ms
Tamaño de ventana 256K - Ejecución 1
Promedio = 11.928 / 2 = 5.964 ms
Tamaño de ventana 256K - Ejecución 2
Promedio = 16.451 / 2 = 8.2255 ms
Tamaño de ventana 512K - Ejecución 1
Promedio = 11.946 / 2 = 5.973 ms
Tamaño de ventana 512K - Ejecución 2
Promedio = 16,452 / 2 = 8,226 ms
Tamaño de ventana 1024K - Ejecución 1
Promedio = 11.975 / 2 = 5.9875 ms
Tamaño de ventana 1024K - Ejecución 2
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)