En Brightcove, utilizamos Amazon S3 como parte de nuestras soluciones de entrega, publicación y gestión de reproductores de vídeo, y con razón, ya que es líder en el sector y ofrece un gran rendimiento. Sin embargo, un gran rendimiento no significa que sea infalible. Hemos invertido mucho tiempo y esfuerzo en reforzar nuestros servicios para que soporten una interrupción en previsión de un evento de este tipo y nuestros esfuerzos han dado sus frutos.
INCIDENCIA SERVICIO AMAZON S3
El jueves 14 de septiembre de 2017, durante un breve periodo de tiempo en torno a las 13:37 (hora de verano del este de EE. UU.) y después durante aproximadamente una hora a partir de las 14:40 (hora de verano del este de EE. UU.), el servicio Amazon S3 comenzó a ralentizar injustificadamente las solicitudes en la región este de EE. UU.. Como resultado, se rechazaron muchas solicitudes perfectamente válidas para obtener y colocar archivos.
Muchos clientes de S3 se vieron afectados, incluidos algunos de los sitios web más visitados de Internet que dependen de esta infraestructura en la nube de alta fiabilidad. Aunque Brightcove sufrió un aumento de las tasas de error en algunos contenidos de vídeo almacenados en caché en frío, nos complace informar de que las cargas de reproductores, almacenados o no en caché, no se vieron afectadas. Lo que podría haber sido un evento mucho mayor se contuvo en gran medida.
He aquí algunos datos sobre el incidente, según informa The Register. La información que Amazon compartió durante el incidente fue la siguiente (horas ajustadas a EDT):
- 2:58 PM EDT. Estamos investigando el aumento de las tasas de error de las solicitudes de Amazon S3 en la región US-EAST-1.
- 3:20 PM EDT. Podemos confirmar que algunos clientes están recibiendo errores de estrangulamiento al acceder a S3. Actualmente estamos investigando la causa raíz.
- 3:38 PM EDT. Seguimos trabajando para resolver el aumento de los errores de limitación de las solicitudes de Amazon S3 en la región US-EAST-1. Hemos identificado el subsistema responsable de los errores, hemos identificado la causa raíz y estamos trabajando para resolver el problema. Hemos identificado el subsistema responsable de los errores, la causa raíz y estamos trabajando para resolver el problema.
- 3:49 PM EDT. Ahora estamos viendo la recuperación en las tasas de error de aceleración de acceso a Amazon S3. Hemos identificado la causa raíz y hemos tomado medidas para evitar que se repita.
- 4:05 PM EDT. Entre las 2:40 PM y las 3:56 PM EDT experimentamos errores de limitación al acceder a Amazon S3 en la región US-EAST-1. El problema se ha resuelto y el servicio funciona con normalidad. El problema se ha resuelto y el servicio funciona con normalidad.
A las 13:37, mucho antes del acuse de recibo de Amazon, los primeros errores activaron nuestras alertas. En lugar de decirnos que había un problema con nuestros servicios, las alertas nos informaron de que la acción correctiva se había puesto en marcha automáticamente.
Durante todo este incidente, que se produjo en horas punta para Brightcove, respondimos sin problemas a más de 28 millones de solicitudes del reproductor de Brightcove. Esto incluyó a reproductores que ya estaban activos, así como a 79 reproductores que se publicaron durante el incidente.
TÁCTICAS DE RECUPERACIÓN DE JUGADORES
He aquí un vistazo a nuestra configuración S3.
Aunque utilizamos S3 en la región Este de EE.UU. (donde se produjo el incidente), hemos implementado opciones de replicación bidireccional entre regiones proporcionadas por Amazon.
También hemos creado nuestro propio proyecto Node.js de código abierto llamado s3-s3 que gestiona el cambio automático a diferentes buckets S3 según sea necesario. Esto significa que, en condiciones normales de funcionamiento, todos los archivos que subimos a U.S. East también se envían a nuestra región de conmutación por error.
Cada vez que los servicios de gestión y publicación de reproductores interactúan con S3, están preparados para lo peor. Si se produce un error, se reintenta automáticamente y, si los reintentos fallan, se pasa automáticamente a otra región.
Gestionamos la conmutación por error a nivel de solicitud individual. Las solicitudes empiezan siempre en la región principal y vuelven a la región de conmutación por error si es necesario. No es necesaria la intervención manual para conmutar los sistemas.
Gracias a nuestra replicación bidireccional, todos los archivos que deban enviarse a la región de conmutación por error se replicarán automáticamente en EE.UU. Este cuando vuelva a estar en buen estado.
El siguiente gráfico muestra nuestra conmutación por error automática en acción. Los servicios continuaron utilizando nuestro bucket S3 primario tan a menudo como fue posible, pero acabaron fallando bastante en el proceso. La alternativa: Todas las peticiones de la derecha habrían fallado causando problemas a nuestros clientes.
Así que si no sabías que había problemas con Amazon, así nos gusta.
