El incidente: La caída de Amazon Web Services

El 28 de febrero de 2017, Amazon Simple Storage Service –comúnmente conocido como Amazon S3- sufrió una indisponibilidad durante algunas horas. Este incidente afectó, entre otras, a numerosas compañías cuyos negocios se basan en su presencia online. Algunas de estas compañías se paralizaron durante la caída de Amazon Web Services, sin poder continuar con su negocio en marcha. Entre ellas había compañías que utilizamos cada día, como Slack, Quora y Lonely Planet.

Muchos se apresuraron a decir que todo AWS estaba fallando, pero esto es una percepción errónea. Amazon S3 solo tuvo problemas en la región Northern Virginia (US-EAST-1).

S3 es uno de los servicios más populares de AWS. Es tan popular que incluso otros servicios de AWS dependen de este en algún grado: si echamos un vistazo al dashboard de estado de AWS del 28 de febrero, más servicios comenzaron a fallar parcialmente o dejaron de funcionar adecuadamente (entre ellos, Amazon Athena, EMR, Amazon Kinesis Firehose, Auto Scaling y Amazon Cloud Formation).

El 2 de marzo, AWS publicó una nota para sus clientes explicando qué falló.

Debido a un error humano (al introducir una entrada incorrecta en la línea de comandos) se eliminó de forma no intencionada un extenso grupo de servidores. Estos servidores dan soporte a dos subsistemas de S3, uno de los cuales gestiona los metadatos y la información de localización de todos los objetos de S3 en la región. Aquello desencadenó una pérdida de capacidad significativa, y otros servicios que dependen de S3 para el almacenamiento, incluyendo la consola de S3 o los lanzamientos de nuevas instancias EC2, estuvieron afectados mientras las APIs de S3 no estaban disponibles.

El incidente de la caída de Amazon S3 afectó tan solo a una de las 16 regiones disponibles de AWS. Fue la región Northern Virgina (US-EAST-1), con algunos servicios caídos durante 4 horas y 20 minutos. Las demás regiones continuaron funcionando sin problemas y esa es la razón por la que otras compañías que confían en AWS para sus sistemas críticos, como Netflix, no sufrieron ninguna caída.

Entendiendo las Regiones y las Zonas de Disponibilidad de AWS

Para entender por qué la caída de Amazon Web Services solo afectó a algunas compañías, tenemos que aclarar las diferencias entre regiones y Zonas de Disponibilidad.

Amazon S3 es un servicio que se ofrece a nivel regional. Esto significa que cuando creamos un bucket de S3, podemos escoger la región donde lo queremos desplegar. Luego, AWS utiliza automáticamente las regiones de AWS disponibles en dicha región para mantener los datos disponibles y salvaguardados.

¿Cómo podemos evitar fallos de servicio regionales?

Para evitar fallos del servicio cuando ocurren incidentes como la caída de Amazon Web Services y S3, tenemos distintas posibilidades. Todas las soluciones deben tener en cuenta muchos factores: la criticidad de nuestro servicio, los factores económicos de la indisponibilidad del servicio, etc.

Nos gustaría presentarte una de ellas (¡aunque no es la única!): configurar DNS a prueba de fallos con Route 53 y permitir la replicación entre regiones.

Configurando la DNS a prueba de fallos con Route 53, podrás saber cuándo un bucket de S3 está caído, y automáticamente redirigir las solicitudes a un bucket en otra región. Para poder hacerlo, necesitas tener los mismos datos en dos regiones distintas, lo cual puedes hacer permitiendo la replicación entre regiones. Con estas dos acciones, estarás cubierto en el caso de que haya una caída similar en la región que aloja tus datos.

Esta solución solo cubre problemas con Amazon S3 pero, como hemos visto antes, otros servicios en la misma región también se vieron afectados por la caída. Tenemos que pensar también en los otros servicios (fallo de EC2, de EBS, etc.), y eso puede ser una tarea compleja e inabarcable (es posible diseñar teniendo en cuenta los fallos regionales).

La clave, en este caso, es trabajar con un buen compañero en la nube, un partner que conozca y entienda tus necesidades de negocio. Un buen SysArchitect te ayudará a instalar una infraestructura que atienda solicitudes en otras regiones con tus necesidades y limitaciones en mente (DR, Pilot light, escenario Activo-Activo, etc.). La nube nos permite construir infraestructuras diseñadas para responder a tus necesidades sin olvidarse de ser rentable. Si tienes algunas dudas o necesitas a alguien que te ayude a construir una infraestructura siempre disponible, puedes confiar en nuestro gran equipo de SysArchitects.

TAGS: Amazon S3 outage, amazon web services, aws, az, downtime, high-availability, regions, S3

speech-bubble-13-icon Created with Sketch.
Comentarios

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*
*