Leído el artículo en Newtral.es, que recomiendo para saber que es un CDN y porque son tan importantes, hablando de los problemas de conexión que afectaron este martes 8 de junio a sitios webs y servicios como Amazon, The New York Times, Twitch, Financial Times, Reddit, VICE, The Verge, Spotify, Vimeo, Shopify y CNN debido a un problema técnico en un proveedor de servicios ‘cloud’ llamado Fastly, voy a intentar explicar cómo funcionan estos servicios en la red.
Lo primero que hay que entender es ante todo que los servicios en la cloud no son entes libres de fallos. El hecho de que uno confíe en esos servicios, a pesar de que la publicidad de los mismos incluya términos como “infinitos”, no significa que sean infalibles y 100% tolerantes a fallos.
De hecho, cuando uno utiliza estos servicios normalmente se hace bajo un acuerdo que incluye que los mismos estarán operativos en un grado que va desde el 98% al 99,99%, siempre y cuando no existan problemas como los de este martes.
¿Cómo penaliza a una caída a los proveedores de servicios ‘cloud’?
Estos fallos penalizan al proveedor del servicio si exceden esos porcentajes de fallo, que se traducen en tiempo sin servicio, o con un servicio degradado, es decir, en malas condiciones. Esto es lo que llamamos SLAs, Service Level Agreement.
Los servicios de Fastly no son una excepción y están recogidos en sus condiciones. Normalmente son estos:
| Availability Percent | Period of Degraded Performance | Monthly Credit Percent |
| Below 100% – 99.99% | Up to 4.32 minutes | 1% |
| Below 99.99% – 99.9% | Up to 43.8 minutes | 5% |
| Below 99.9% – 99.0% | Up to 7.2 hours | 10% |
| Below 99.0% – 98.0% | Up to 14.4 hours | 25% |
| Below 98.0% | Greater than 864 minutes | 50% |
Quiere decirse que la “caída”, o más bien el problema que hemos visto, supondría en sus Clientes Gold o Enterprise, es decir los más importantes, entre un 5% y un 10% de lo que les cobra Fastly mensualmente por darles el servicio. Una cantidad que no será nada despreciable viendo las características de los mismos. No todo el mundo contrata las mismas condiciones, pero en líneas generales será muy cercano a esto.
Por supuesto estamos hablando de problemas que se originan en el proveedor, no en el cliente. Creo que hoy estamos ante ese caso. Y es probable que un mensaje, que para la mayoría pase desapercibido, nos dé claves de lo que ha ocurrido. Me refiero a ese error tan extraño que nos presentaba en las pantallas cuando queríamos acceder a nuestra web favorita. En concreto algo parecido a esto.
¿Dónde pudo estar el origen del fallo?
En internet todos oímos hablar de direcciones IPs. Son el equivalente a la dirección que debemos dirigirnos cuando queremos acceder a nuestras webs o servicios favoritos. Ahora bien, para traducir esas direcciones en algo más sencillo que recordar usamos lo que llamamos DNS.
Un DNS no hace más que traducir un nombre. Por ejemplo, www.twitch.com, en su dirección IP. Son la parte más básica del funcionamiento de internet, y sin su funcionamiento deberíamos recordar todas las direcciones IPs que utilizamos cuando navegamos en la red.
Claramente es más fácil recordar un nombre, Twitch, que una dirección IP. Por ejemplo: 52.88.15.144. En el caso de Twitch.tv, por ejemplo, se traduce en witch.map.fastly.net, y en definitiva, en una dirección IP 151.101.54.167.
Los CDNs suelen asignar una o varias direcciones IPs a los servicios de sus clientes. Y permiten gestionarlas de tal manera que uno puede elegir si sus clientes europeos serán dirigidos al sitio más cercano del CDN en Europa, los americanos a los suyos, los asiáticos a su sitio, etcétera.
Esto es posible porque el funcionamiento de los CDNs, y su negocio, consiste en replicar por continentes o países el contenido que sus clientes depositan en sus almacenamientos o servidores.
En un proceso que es transparente, cada vez que un cliente pone un nuevo contenido este es “copiado” en otra localización geográfica en otro contenedor. Los llamamos pops, points of presence. A estas réplicas con todo ese contenido las llamamos caches. El acercar esos contenidos geográficamente permite una ventaja como es un acceso más rápido por parte de los consumidores de esos contenidos.
En internet el concepto de tiempo lo medimos en lo que llamamos latencia. A más tiempo en que el contenido acabe en nuestros ordenadores más latencia. El número de “pasos” que debemos dar para llegar a ellos será más corto cuando más cercano el destino. Esto en contenidos como vídeo o música es vital. En general en todo, pero en estos casos es más evidente que en cuanto hacemos clic en el play, el contenido debe llegar.
El problema está en que para manejar todo este entramado -cuantos más contenidos y más clientes, se haría más complejo- si le sumamos la limitación de que las direcciones IPS, no son infinitas. Ese problema lo solucionan los CDNs asignando a una dirección IP un montón de nombres de servicios.
Cuando nosotros vamos a elegir uno, el CDN examina la petición que le hacemos y la traduce. Las peticiones a esos servicios las hacemos con nombres, recuerden. Si queremos ir a Twitch lo mandará a un sitio. Si a Amazon a otro. El problema de hoy es que por la razón que sea, y todo apunta a una mala configuración o un mal funcionamiento de estos “traductores de IPs y nombres” no eran capaces de identificar donde debía ir cada cosa. De ahí el mensaje unknown domain. Traducido “no conozco donde quieres ir”.
Opino, por tanto, que el fallo se ha producido ahí, y aventuro a que una mala actualización de las bases de datos donde se contienen esas traducciones de nombres a IPs y de IPs a nombres ha causado ese pequeño caos que hemos percibido esta mañana.
Lo que Fastly llama “service configuration”. Es decir, el 0,01 hasta 2% de fallo permisible en un sistema en cloud. Hoy debe ser un mal día para los técnicos de Fastly, aunque su reacción ha sido rápida. Eso normalmente es tan plausible como indicio de que el error se produjo allí, se detectó muy rápido porque era un cambio registrado, y se subsanó.
Y además lo creo porque si hay un concepto en todo servicio de cloud es el de redundancia. Todo está al menos duplicado una vez para impedir que el fallo de uno solo de los elementos, comunicaciones, alimentación, infraestructura, almacenamiento, etcétera, afecte a la globalidad del servicio.
Pero siempre existe un punto en común, y suele ser el humano. Una mala decisión o un fallo nuestro acaba así. De hecho, a todos nos deberían explicar que los servicios en la cloud se traducen en realidad por: “No te preocupes, estás utilizando el ordenador de otro”. Nada más. Ni nada menos.
