Cloud Talk - AWS Ouage - Service Outage Resiliency

Cómo afecta la interrupción del servicio a las organizaciones y cómo hay que prepararse

Lo último que quiere escuchar una operación de comercio electrónico justo antes del Black Friday es que "se cayó AWS".

Lo último que quiere escuchar una operación de comercio electrónico justo antes del Black Friday es que "se cayó AWS". Y eso es exactamente lo que ocurrió a primera hora de la mañana del miércoles, 25 de noviembre de 2020, el día anterior al Día de Acción de Gracias y dos días antes del primer día de compras importante de las fiestas. Las consecuencias de la interrupción afectaron a miles de servicios en línea de terceros, y el problema se resolvió finalmente a las 10:23 p. m., hora del Pacífico.

Amazon Web Services (AWS) dijo que la interrupción del servicio ocurrió en su región de Virginia del Norte, US-East-1. Tuvo lugar durante una "pequeña adición de capacidad" a su flota front-end de servidores de Amazon Kinesis, después de que todos los servidores comenzaran a exceder el número máximo de subprocesos que permite su configuración actual del sistema operativo.  

En este episodio de Cloud Talk, tres expertos de Rackspace Technology analizan la interrupción, por qué ocurrió, sus consecuencias en las empresas y qué pueden hacer estas para evitar verse afectadas por futuras interrupciones. El presentador, Jeff DeVerter, director de Tecnología, recibe a Myles Anderson, vicepresidente de Professional Services y a Ethan Schumann, gerente sénior de Arquitectura e Ingeniería.

"Las interrupciones del servicio son eventos muy poco frecuentes, pero pueden ser devastadoras cuando se producen", dijo Anderson. "Pero AWS es una organización de clase mundial, y reaccionó rápido y solucionó la interrupción".

Durante este episodio, el presentador y los invitados analizan muchas cuestiones sobre el tema, incluso lo siguiente:

  • Entender cómo funciona AWS como una empresa de servicios que presta servicios a miles de personas.
  • Los pasos que pueden tomar las organizaciones para evitar convertirse en víctimas de la próxima interrupción de servicio importante.
  • Cómo ha cambiado la naturaleza de la recuperación ante desastres y por qué la pérdida de datos ya no es tan relevante.
  • Por qué las organizaciones ya no solo realizan cambios en la arquitectura durante las noches y los fines de semana.
  • Por qué la planificación de redundancia y disponibilidad requiere un enfoque de día cero.
  • Por qué necesita determinar el retorno de la inversión de desarrollar sistemas altamente disponibles.

Una de las preguntas clave después de la interrupción fue: "¿Por qué quedaron inactivas tantas empresas?", preguntó DeVerter.

La respuesta habla de "uno de los hechos menos conocidos sobre cómo funciona AWS", dijo Schumann. "AWS ejecuta sus propios servicios en sus propios servicios. Por lo tanto, maneja sus propios servicios de la misma manera que maneja los servicios de sus clientes. Cada vez que uno de sus servicios intrínsecos de red troncal, como Kinesis, se cae, tiene un efecto dominó en todos los clientes y en muchos otros servicios auxiliares".

Otro factor es que AWS opera dentro de 22 zonas en el país. "Cuando usted comienza a implementar una solución, empieza con los servicios básicos", explicó Schumann. "Residen dentro de una región geográfica. Dentro de las regiones, cuenta con zonas de disponibilidad. Desarrollar redundancia y confiabilidad dentro de una zona de disponibilidad es bastante fácil y simple".

"Donde las cosas se complican es en intentar evitar una falla de un servicio que da soporte a una región entera. Esto requiere tener soluciones disponibles en otras regiones y hacer una prueba de fallas muy rápido. Sin embargo, esto podría implicar replicar los datos y las soluciones en más de una región, y no hay un botón para esto".

Algunas organizaciones pueden cuestionar el momento en que se actualizaron los servicios de Kinesis de AWS. Después de todo, las actualizaciones y los cambios a la infraestructura del centro de datos solían programarse para la medianoche.

"Hacer un cambio importante a mitad del día fue una movida osada", comentó Anderson. "Pero esa movida es, en gran medida, una consecuencia de la cultura de AWS. Pretenden modernizar, lo que incluye agregar más capacidad a su disponibilidad y aumentar su velocidad cuando lo necesiten. Se suponía que la actualización de noviembre era solo otro de los cientos de cambios insignificantes en la capacidad. Llevan a cabo con éxito cientos al día y nunca nos damos cuenta".

Listen & Follow

 

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.

Subscribe
Disaster Recovery

No puede predecir el futuro, pero sí puede estar preparado.

About the Authors

rackspace logo

Rackspace Technology Staff - Solve

The Solve team is made up of a curator team, an editorial team and various technology experts as contributors. The curator team: Srini Koushik, CTO, Rackspace Technology Jeff DeVerter, Chief Technology Evangelist, Rackspace Technology The editorial team:  Gracie LePere, Program Manager Royce Stewart, Chief Designer  Simon Andolina, Design Tim Mann, Design Abi Watson, Design Debbie Talley, Production Manager  Chris Barlow, Editor  Tim Hennessey Jr., Writer Stuart Wade, Writer Karen Taylor, Writer Meagan Fleming, Social Media Specialist Daniel Gibson, Project Manager

Read more about Rackspace Technology Staff - Solve