Visualización de la latencia de los centros de datos de AWS

• Es una página de visualización que muestra la latencia entre centros de datos de AWS dividida en 3 rangos de ms
• La leyenda distingue entre menos de 100 ms, 100~200 ms y más de 200 ms, lo que permite comparar rápidamente el nivel de latencia
• Con la información proporcionada, no es posible confirmar qué centros de datos o regiones están incluidos
• No se proporciona el método de medición, el momento de la medición ni los valores individuales de latencia entre centros de datos
• Por lo tanto, el alcance que puede verificarse en este resumen se limita a los criterios de rangos de la visualización

---

Leyenda de latencia

• X < 100ms: menos de 100 ms
• X 100ms - 200ms: 100~200 ms
• X > 200ms: más de 200 ms

Detalles que no pueden verificarse

• No se proporciona una lista específica de centros de datos de AWS ni nombres de regiones
• No es posible verificar el método de medición, el momento de la medición ni los valores de latencia entre centros de datos individuales

[devenv]

Parece que us-east-1 está en la mejor ubicación de cara a Occidente.

[GN⁺]

Opiniones de Hacker News

• Más que mostrar solo el valor de ping, estaría bueno mostrar también qué tan malo es frente al óptimo teórico.
  Tengo entendido que la velocidad de la luz en un medio de fibra óptica es aproximadamente 30% más lenta que la luz en el vacío.
  Varias veces, en reuniones de arquitectura, hubo quejas por la latencia entre centros de datos, y después resultó que en realidad estaba bastante cerca de lo que era teóricamente posible desde el principio.

  • Dentro de los hiperescaladores y de los grandes proveedores de colocación/hosting, seguramente ya conocen bien este tipo de métricas.
    Cuando un cliente diseña sistemas de alta disponibilidad o recuperación ante desastres, es importante evitar que elija por error una región o zona primaria con latencia “artificialmente” alta.
    Mi empresa actual se especializa en migraciones de SAP a la nube, y desde que en el pasado nos pegamos contra una latencia inaceptable por supuestos incorrectos, siempre tenemos esta conversación con especialistas de redes de AWS y GCP durante la etapa de cotización y definición de alcance.
  • Esto no parece ser un ping real, y eso es más bien bueno.
    No usa ping ICMP, sino que establece una conexión de stream por socket vía tcp/443.
    El ping puede ser una métrica inadecuada.
    https://github.com/mda590/cloudping.co/blob/8918ee8d7e632765...
  • Para hacer eso habría que mapear todas las rutas de los cables.
    La luz dentro de un cable de fibra óptica viaja a aproximadamente el 70% de la velocidad de la luz, unos 210.000 km/s.
    La circunferencia de la Tierra es de unos 40.000 km, y una ruta en línea recta hasta el lado opuesto del planeta daría unos 100 ms de ida y unos 200 ms de ida y vuelta.
  • Al hacer clic en el mapa, no se ven muchos casos en los que la latencia se desvíe mucho respecto de la distancia.
    Claro que, con fibra óptica de núcleo hueco y rutas de fibra cercanas a una línea recta, en teoría se podría mejorar alrededor de un 40% más, pero son pocos los que querrían pagar ese costo.
  • Soy el autor. Es interesante; también me propusieron la misma idea en X.
    Me pregunto si habrá buenos recursos para calcular este valor con precisión.

• Tengo daltonismo rojo-verde, así que me resulta difícil o imposible distinguir las líneas de menos de 100 ms de las de más de 200 ms.
  Eso corresponde a alrededor del 8% de la población masculina, así que estaría bueno agregar un modo para daltónicos.
  La visualización en sí está muy buena.

  • Como atajo rápido, se puede aplicar un filtro CSS a toda la página.
    En las herramientas de desarrollo, agregá la regla filter: hue-rotate(60deg); al elemento body, o ejecutá javascript:void(document.body.style.filter='hue-rotate(60deg)') en la barra de direcciones.
  • Soy el autor. Gracias por la sugerencia.
    Me gustaría saber cuáles son los mejores ejemplos que hayan visto de soluciones a este problema en el pasado; si tienen enlaces, compártanlos.
  • No veo las líneas en absoluto; solo veo los puntos azules que representan repetidamente los centros de datos.
    Es bastante confuso.
  • Me pregunto si existe alguna herramienta de accesibilidad para este tipo de casos.
    Algo como un filtro que cambie los colores de toda la pantalla de una forma específica para que se puedan distinguir.
  • Como persona daltónica, es importante tener en cuenta el daltonismo al elegir colores, pero no todos los hombres de ese 8% realmente son incapaces de distinguir dos colores.
    La proporción es menor, y aun entre las personas daltónicas la percepción del color varía.
    Que algo se vea bien para una persona no significa que se vea bien para otra, y lo contrario también aplica.

• Hace un tiempo hice una planificación relacionada con esto para un cliente.
  Al medir la latencia de AWS, descubrimos que si medíamos una longitud aproximada de cable submarino en km y la dividíamos por 150, el resultado coincidía con la latencia real dentro de un 10%.
  No era sorprendente, pero sí muy consistente; después creo que resultó ser 155.

  • Esto me recuerda la historia del correo electrónico de 500 millas.
    https://www.ibiblio.org/harris/500milemail.html
  • Creo que esto se debe a la velocidad de la luz dentro del medio.
    “Mediante LabVIEW se calculó que la velocidad de la luz dentro de la fibra óptica era de aproximadamente 2.054 x 10^8 m/s, un valor típico correspondiente a un índice de refracción n ≈ 1.4606”.
    https://web.phys.ksu.edu/posters/2009/juma-Adv-Lab-S09.pdf
  • En el modelado del mundo real, sorprendentemente a menudo se puede lograr una precisión satisfactoria solo con multiplicaciones y sumas.
  • Esta página está muy bien hecha como mapa interactivo, y me resultó muy entretenida.
    Me pregunto si la explicación matemática de esa regla empírica sería más o menos así.
    https://news.ycombinator.com/user?id=Hikikomori corrigió la velocidad de la luz en el medio de fibra óptica: no es 3e5, sino 2e5.
    La velocidad de la luz es 2e5 km/s, es decir, unos 2e2 km/ms, así que queda algo como longitud (km) / 200 (km/ms), y en definitiva latencia (ms) ≈ K' × longitud (km).
    Me pregunto si K es de alrededor de 1,3 y K' es 1/155, e incluye factores como distancia no rectilínea, overhead de red y conmutación, y error de medición de ida y vuelta.
  • Al mirar la visualización, la mayoría, o quizá todas, las líneas rojas corresponden a rutas largas, como de Norteamérica a Sudáfrica.

• Interesante. Si hacés clic en los círculos azules que representan centros de datos, se muestra la latencia hasta otros centros de datos.
  Me llevó un rato descubrirlo, así que estaría bueno agregar al sitio una indicación como hacé clic en un centro de datos para seleccionarlo.

  • Técnicamente, estos no son centros de datos, sino agregaciones a nivel de región.
    Una región está compuesta por componentes de red y cómputo de varios niveles de abstracción, es decir, una mezcla de centros de datos, ubicaciones edge, etc.
    Incluso dentro de una región hay mucha variación entre zonas, así que la metodología de medición es importante.

• AWS ofrece en Network Manager métricas de latencia entre regiones, entre zonas de disponibilidad y dentro de una zona de disponibilidad.
  Sirve para establecer una línea base de latencia y ver si hay algún problema del lado de AWS.
  https://docs.aws.amazon.com/network-manager/latest/infrastru...

  • AWS también ofrece un dashboard que muestra interrupciones de regiones o servicios, pero viendo el historial queda claro que, precisamente por ese mismo motivo, es difícil confiar ciegamente en ese tipo de dashboards.

• La visualización y el concepto están geniales, pero estaría bueno que los colores no fueran por rangos, sino un gradiente continuo.
  Con el método actual, 100 ms se ve muchísimo peor que 99 ms, pero a la vez se ve igual que 200 ms.
  Por ejemplo, al hacer clic en us-east-1, las latencias de los centros de datos de Europa occidental se ven bastante distintas: eu-central-1 y eu-south-1 apenas difieren unos 9 ms, pero se ven completamente diferentes, mientras que eu-north-1 y ap-south-1 difieren unos 88 ms y se ven iguales.
  También se menciona la idea de comparar las mediciones con la latencia mínima posible según la velocidad de la luz, pero el problema es que la velocidad de la luz en el vacío, c, no es la velocidad de transmisión de información dentro de una fibra óptica.
  El mejor caso teórico real difícilmente supera el 70% de c incluso considerando solo la velocidad de la luz en el medio, y hay muchos factores desconocidos como la latencia de los repetidores.

  • Soy el autor. Un gradiente es una muy buena idea.
    La visualización actual hace que una latencia de 90 ms parezca “buena”, pero en realidad es un valor totalmente inaceptable para muchas aplicaciones.
    Especialmente cuando para procesar una sola solicitud se necesitan varios viajes de ida y vuelta.

• Me da curiosidad cómo eligieron qué centros de datos incluir.
  Por ejemplo, falta España, eu-south-2.
  Hace un tiempo trabajé en un proyecto que requería que la latencia entre centros de datos fuera menor a 30 ms, y teníamos que usar eu-west-1 Irlanda y eu-south-2.
  Pero la latencia real rondaba los 42 ms, principalmente porque no hay un cable submarino entre Irlanda y Europa continental, así que había que ir por Reino Unido y luego volver a cruzar Reino Unido hacia un cable que conectara con el continente.

  • Al final de la página dice que son datos scrapeados de CloudPing, y también hay un enlace al dataset de CloudPing.
    Si entras a CloudPing, eu-south-2 no está en el dataset.
  • Soy el autor. Usé solo lo que estaba disponible en https://www.cloudping.co, y claramente faltan algunas ubicaciones.
    El repositorio de GitHub de CloudPing no ha tenido cambios de código en 4 años, así que es posible que hayan aparecido varias regiones nuevas desde la última vez que tuvo actividad.
  • Me da curiosidad cómo supiste que no hay cable entre Irlanda y Europa continental.
    Lo pregunto sinceramente: ¿dónde está publicada esa información?
  • En ese mapa faltan bastantes centros de datos.
  • También falta Israel, il-central-1.

• Los datos son muy útiles y el globo es visualmente impactante, pero para un uso real creo que sería mejor un mapa mundial plano.
  Podría mostrar todos los centros de datos a la vez, y como las líneas no quedarían excesivamente juntas, sería más fácil de leer.

  • Recuerdo que en la radioafición era popular este tipo de proyección azimutal equidistante.
    https://en.wikipedia.org/wiki/Azimuthal_equidistant_projecti...
  • Un mapa mundial 2D puede no transmitir bien qué tan lejos están realmente las ubicaciones.
    Sería mejor tener una opción para alternar entre ambas vistas.
  • Estoy de acuerdo. Se ve espectacular, pero no es la mejor visualización para leer los datos en la práctica.
  • Soy el autor. Hace falta un equilibrio cuidadoso entre lo vistoso y lo útil.

• El factor más grande en la latencia es, por supuesto, la distancia.
  Pero incluso entre regiones relativamente cercanas, a veces no hay fibra óptica conectada directamente, por lo que la latencia puede ser mala, por ejemplo por rutas que pasan por zonas polares.
  Me pregunto si hay casos de regiones que violen fuertemente la desigualdad triangular.
  Es decir, casos donde la latencia A–C sea mucho peor que la mejor latencia A–B + B–C.
  Por curiosidad, también me pregunto si con esta idea se podría inferir qué centros de datos tienen más probabilidades de estar conectados directamente por fibra y mostrar solo esas conexiones.

  • No puedo hablar directamente de AWS, pero en mi tesis doctoral encontré bastantes casos así usando probes de RIPE Atlas.
    Básicamente, el método consiste en buscar pares de probes donde el tiempo de ida y vuelta entre A y C sea mayor que A–B + B–C.
    Este método tiene los problemas habituales de ICMP y de las mediciones de ida y vuelta, y además el tráfico no necesariamente fue ruteado realmente pasando por el probe “intermedio”, pero esos pares existen.
    Hay un ejemplo en la página 84 de https://theses.hal.science/tel-03666771/document, si puedes leer francés.
  • Por la forma en que funciona el ruteo, no creo que esto ocurra mucho a gran escala.
    Si una ruta de “desvío” pasando por B es la forma más barata de que lleguen los paquetes ICMP, en la práctica también tomarán esa ruta.
    Más bien, si buscas lugares donde A–C sea casi igual a A–B + B–C, probablemente veas dónde ocurre eso.
    Además de la falta de fibra, también puede deberse a razones financieras, como acuerdos de peering más favorables.
  • En la zona entre Rusia, Mongolia e India hay muy pocos cables y la calidad también es mala.
    Hasta donde sé, de Mumbai al sur de Rusia no hay tanta distancia, pero la latencia es sorprendentemente alta.
    Por ejemplo, es mucho más alta que de Frankfurt a Moscú, aunque no sé si llega a violar la desigualdad triangular entre Frankfurt–Moscú–Mumbai.
  • El mapa mundial de cables de fibra óptica se puede ver simplemente aquí:
    https://www.submarinecablemap.com/
    Como tender cables submarinos es extremadamente costoso, es muy poco probable que existan cables no publicados.
  • Hay regiones notoriamente malas en calidad de red, como Sudamérica y el sur de Asia.
    En general, también suelen tener más pérdida de paquetes.

• Hace unos días estaba usando esto:
  https://aws-latency-test.com/

  • Soy el autor. Vi ese sitio mientras buscaba datos para esta visualización, y estaba bastante bien.