Sergio Rademacher. Gerente Corporativo de Servicios de Data Center y Cloud -SONDA
El pasado 28 de febrero una falla en una vasta zona de AWS (Amazon Web Services), específicamente la US-1 con su servicio S3, provocó un colapso de páginas y servicios web que representan un segmento importante de la internet, afectando a millones de usuarios.
La falla se debió, como es frecuente, a un error humano. Al parecer un ingeniero de Amazon debía eliminar infraestructura obsoleta en el sistema de almacenamiento de objetos S3 y por equivocación eliminó servidores que eran necesarios para el correcto funcionamiento de la plataforma AWS, como por ejemplo el sistema de facturación. Esto obligó a un reinicio de la plataforma que tomó más tiempo de lo esperado. El operador se equivocó en un parámetro del comando (el clásico “error de tipeo”), sacando del sistema más servidores, lo que provocó la caída de una parte importante de la internet.
El downtime duró entre cuatro y once horas, dependiendo de los servicios usados, y se estima que afectó a cerca de 150.000 sitios web entre los que se encontraban Apple, Netflix, Reddit, Airbnb, Giphy, Adobe, Quora, Slack, Trello, Soundcloud, Medium, Mashable y Nest, entre otros. Según la consultora Cyence, el costo de la falla para las empresas afectadas fue de más de 300 millones de dólares, es decir 1.25 millones de dólares por minuto de downtime.
Amazon, al igual que otros proveedores, distribuye sus servicios en distintas zonas y la zona afectada fue US-East-1. A pesar de que es posible tener aplicaciones que corren en más de una zona, la mayoría de los sitios afectados no tenía contingencia en otra zona. ¿La razón? El mayor costo que esto implica, pues hay que pagar por el doble de infraestructura, así como por el tráfico de datos que circula entre las zonas. Pero además aumenta la complejidad del sistema, pues contar con una aplicación que funcione en paralelo en dos zonas no es trivial, tomando en consideración temas como latencia y ancho de banda, lo que afecta el rendimiento.
Lamentablemente, en este fallo, varios de los sitios que sí tenían contingencia no pudieron usarla, pues al fallar la zona primaria, automáticamente miles de sitios trataron de encender en paralelo su infraestructura de respaldo, lo cual saturó la plataforma. Es el síndrome de la evacuación de un estadio: si todos tratan de salir del estadio al mismo tiempo, nadie va a poder salir. Hay que hacerlo en forma ordenada, pero eso nos lleva al problema de quién define el orden de salida.
Esto nos debe recordar que, si bien la disponibilidad de las plataformas de cloud en general es muy alta, lo errores van a ocurrir siempre, especialmente los humanos, por lo que es importante diseñar sistemas tolerantes a fallas. Los sitios afectados podrían haber evitado el problema de varias formas: implementando redundancia entre zonas o contando con nubes de otro proveedor, como Azure de Microsoft, o teniendo una estrategia de cloud híbrida, con infraestructura tradicional en un datacenter conocido.
Esta caída dejó al desnudo una interdependencia desconocida entre distintos sitios web, lo que causó que sitios que no usaban directamente AWS, pero que dependían de sitios que sí lo usaban, fueran arrastrados en la caída.
Además de la mala publicidad, Amazon tendrá que lidiar con los reclamos de los clientes por el incumplimiento de los SLA de los contratos. Sin embargo, no hay que apuntar a Amazon con el dedo por este error: los sistemas pueden y van a seguir fallando. El problema es de los arquitectos de servicios, que confiaron en la disponibilidad histórica de la plataforma de cloud y se olvidaron de la regla de oro en tecnología: todos los sistemas eventualmente fallan, por lo que debemos estar preparados para enfrentarlos de manera eficiente o asumir las consecuencias.
No es mala idea recordar el viejo consejo de no poner todos los huevos en una misma canasta: y esa es justamente la premisa de los sistemas de cloud híbridos.