Nota: Bunny CDN es una red de distribución de contenido y alojamiento en la nube con sus propios servidores DNS.



Si bunny.net es más importante que el rendimiento, es la fiabilidad. Todo está pensado. Monitoreo redundante, reparación automática, reparación automática de múltiples capas, tres redes DNS de respaldo y un sistema que lo une todo y garantiza el tiempo de actividad.



Pero en nuestra situación, nada ayudó. El 22 de junio de 2021, después de casi dos años de funcionamiento impecable, una interrupción del DNS provocó el cierre completo de casi todos los sistemas. 750.000 sitios se desconectaron durante más de dos horas. En poco tiempo, perdimos más del 60% de nuestro tráfico y cientos de gigabits de ancho de banda. A pesar de todos los sistemas de respaldo, una simple actualización de un archivo provocó una falla global.



Este incidente nos disgustó muchísimo. Pero esperamos aprender una lección para construir una plataforma aún más robusta. Con un espíritu de transparencia, queremos compartir los detalles del incidente y cómo vamos a abordar problemas similares en el futuro. Quizás esta historia se convierta en una lección no solo para nosotros, sino también para otra persona.

Todo comenzó con una simple actualización.

Te lo diré enseguida: la historia es banal. Todo comenzó con una actualización estándar regular. Estamos realizando una actualización masiva para mejorar la confiabilidad y el rendimiento de toda la plataforma. Parte del proceso es mejorar el rendimiento del sistema de enrutamiento SmartEdge. Este sistema pasa una gran cantidad de datos que se sincronizan periódicamente con nuestros nodos DNS. Para una sincronización óptima, se utiliza nuestra plataforma Edge Storage, que distribuye grandes archivos de bases de datos en todo el mundo a través de Bunny CDN.



Para reducir el consumo de RAM, el tráfico y la carga del recolector de basura, recientemente cambiamos de JSON a la biblioteca de serialización binaria BinaryPack.... Funcionó muy bien durante varias semanas. Reducción del uso de memoria, tiempos de espera de GC, uso de CPU ... hasta que se estropeó



El 22 de junio a las 8:25 UTC, lanzamos una actualización para reducir el tamaño de la base de datos de optimización. Desafortunadamente, esto hizo que el archivo dañado se cargara en Edge Storage. El archivo dañado en sí no es un problema, porque DNS está diseñado para funcionar con o sin datos. E ignora con gracia cualquier excepción. Más precisamente, eso pensamos.



Resultó que el archivo dañado hizo que la biblioteca BinaryPack se ejecutara inmediatamente con un desbordamiento de pila, evitando cualquier manejo de excepciones simplemente terminando el proceso. En unos pocos minutos, la red global de cientos de servidores DNS se cayó casi por completo.





Horas de trabajo de los servidores DNS: UTC + 7

Entonces es más difícil ...

Me tomó algún tiempo darse cuenta de lo que estaba sucediendo. Después de diez minutos, nos dimos cuenta de que los servidores DNS no pueden volver a su estado original: se reinician y fallan constantemente.



Al principio parecía que todo estaba bajo control. Especialmente para tales casos, es posible revertir inmediatamente cualquier implementación con un clic de un botón. Pero pronto quedó claro que la situación es mucho más complicada de lo que parece. Revertimos rápidamente todas las actualizaciones de SmartEdge, pero ya era demasiado tarde.



Tanto SmartEdge como los sistemas de implementación envían datos a servidores DNS físicos a través de Edge Storage y Bunny CDN, y acabamos de eliminar la mayor parte de la CDN global.



Aunque el servidor DNS puede recuperarse automáticamente, cada vez que intenta cargar una implementación rota, simplemente vuelve a fallar. Como puede imaginar, los servidores DNS no pueden acceder a la CDN para descargar una actualización, y el círculo está cerrado.



A las 8:35 (15:35), varios servidores aún intentaban funcionar, pero no ayudó mucho, por lo que nuestro rendimiento se redujo a 100-150 Gbps. Tuvimos suerte solo de que todo sucedió a primera hora de la mañana, con un tráfico casi mínimo.





Gráfico de tráfico CDN: UTC + 7

... y aún más difícil

A las 8:45 am, se nos ocurrió un plan. ¡Lanzamos manualmente la actualización que deshabilitará SmartEdge en los hosts DNS! Al principio parecía que todo estaba funcionando. Pero estábamos muy, muy equivocados. Debido a una falla de CDN, los servidores DNS finalmente descargaron versiones corruptas de las bases de datos GeoDNS y, de repente, todas las solicitudes fueron a Madrid. Dado que este es uno de nuestros puntos más pequeños , cayó instantáneamente.



Para empeorar las cosas, ahora 100 servidores comenzaron a reiniciarse en un bucle, lo que provocó que la API central fallara, e incluso los pocos servidores que volvieron a la vida dejaron de iniciarse.



Nos tomó un tiempo descubrir qué estaba pasando realmente, pero después de numerosos intentos, abandonamos la idea de reconstruir la red.



La situación ha llegado a un punto muerto. Los servicios necesitaban desesperadamente ser iniciados, pero un solo archivo corrupto casi mata la plataforma.

Volvemos a controlar la situación

Dado que todas las distribuciones internas ahora estaban dañadas y servidas a través de una CDN, se tuvo que encontrar una alternativa. Aproximadamente a las 9:40 am, tuvimos otra idea. Si es posible enviar todas las solicitudes a una región, dirijámoslas a la más grande, como medida temporal. La actualización de enrutamiento redirigió todas las solicitudes a Frankfurt.



Este fue el primer éxito, y una parte decente del tráfico regresó a la red. Pero el problema no se puede resolver de esta manera. Implementamos manualmente la actualización en algunos servidores DNS, pero el resto aún envió consultas a Madrid. Era necesario actuar con rapidez.



Quedó claro: era hora de admitir la derrota. La única salida es abandonar completamente sus propios sistemas. Devops se puso manos a la obra y transfirió minuciosamente todos los archivos y sistemas de implementación al alojamiento en la nube de terceros.



A las 10:15 am todo estaba listo. Reconfiguramos el sistema de implementación y el software DNS para el nuevo alojamiento y hacemos clic en el botón Implementar . El tráfico regresó lenta pero seguramente, y a las 10:30 el sistema volvió a estar en línea. Más precisamente, así parecía.



Está claro que todo el mundo está en pánico y está inquieto. Intentamos poner el sistema en funcionamiento lo más rápido posible, mientras respondíamos simultáneamente a cientos de tickets de soporte y explicamos la situación. Por supuesto, a toda prisa, cometimos un montón de errores tipográficos y errores. Todo el mundo sabe lo importante que es mantener la calma en estas situaciones, pero es más fácil decirlo que hacerlo.



Resultó que rápidamente instalamos la versión incorrecta de la base de datos GeoDNS, por lo que los clústeres de DNS seguían enviando solicitudes a Madrid. La situación se volvió muy molesta, pero es hora de calmarse, volver a comprobar la configuración y llevar a cabo con calma el despliegue final.



A las 10:45 am, hicimos exactamente eso. A través de una nube de terceros, fue posible sincronizar la base de datos, implementar los últimos conjuntos de archivos y abrir todo el sistema.



Durante media hora, observamos de cerca el crecimiento del tráfico y verificamos meticulosamente los sistemas. El almacenamiento se llevó al límite, porque sin el sistema SmartEdge, estábamos entregando una gran cantidad de datos no almacenados en caché. Finalmente, a las 11:00, las cosas empezaron a estabilizarse y bunny.net volvió a funcionar.

Entonces, ¿qué salió mal?

Todos los sistemas fueron diseñados y ajustados para trabajar juntos. Se apoyaron unos en otros para incluir partes críticas de la infraestructura interna. Si está creando una gran cantidad de infraestructura interesante, entonces, por supuesto, desea aplicarla al número máximo de sus propios productos.



Desafortunadamente, debido a este enfoque, un archivo dañado redujo varios niveles de redundancia. Primero, el sistema DNS se descompuso, luego el CDN, luego el almacenamiento y, finalmente, el servicio de optimización del sitio.



De hecho, al devolver cientos de servidores, el efecto dominó también eliminó la API y el tablero, lo que a su vez provocó que el servicio de registro fallara.

Relleno de golpes para hacerse más fuerte!

Aunque tal "fracaso" podría haberse evitado, lo tomamos como una lección valiosa. El sistema no es perfecto, pero debes esforzarte por lograr el ideal. La única forma es aprender de tus errores.



En primer lugar, queremos pedir disculpas a todas las víctimas y asegurarnos que estamos abordando este tema con especial cuidado. No hemos tenido fallas en el sistema a gran escala durante varios años y estamos decididos a garantizar un funcionamiento estable en un futuro próximo.



El primer y más pequeño paso será eliminar gradualmente la biblioteca BinaryPack y probar todas las bibliotecas de terceros más a fondo en el futuro.



Se hizo evidente un problema más grave. La construcción de infraestructura dentro de su propio ecosistema puede tener consecuencias nefastas. Vimos el efecto dominó en el ejemplo de Amazon y esperábamos que esto no nos pasara a nosotros, pero calculamos mal ...



Actualmente estamos planeando una migración completa de las API internas a un servicio de terceros. Por lo tanto, si su sistema falla, solo perdemos el mecanismo de actualización. Pero si nuestro sistema falla, entonces será posible responder de manera rápida y confiable, evitando el efecto dominó cuando la infraestructura cae ladrillo a ladrillo.



También debe considerar cómo eliminar un solo punto de falla en múltiples clústeres de servidores debido a un solo archivo que de otra manera se considera no crítico. Siempre intentamos implementar actualizaciones gradualmente utilizando el método canary. Pero este incidente nos tomó por sorpresa, ya que la parte no crítica de la infraestructura se convirtió en un punto crítico único de falla para varios otros clústeres.



Finalmente, en el propio sistema DNS, debe mantener una copia local de todas las copias de seguridad con detección automática de fallas. Por lo tanto, aparece otro nivel de redundancia: todos los sistemas son lo más independientes posible entre sí, de modo que, en caso de falla, no se produce un efecto dominó.



Quiero agradecer a los chicos de soporte técnico que trabajaron incansablemente y mantuvieron a todos informados, así como a los usuarios por su paciencia mientras resolvíamos el problema.



Está claro que esta es una situación muy estresante para nuestros clientes. Por lo tanto, estamos tratando de aprender lecciones y, como resultado, convertirnos en un CDN aún más confiable que antes.