El apagón de Braze del 29 de abril: qué sucedió, por qué ocurrió y cómo estamos respondiendo

Publicado: 2024-05-04

El lunes 29 de abril de 2024, los clústeres de la plataforma Braze en EE. UU. experimentaron una interrupción casi total que persistió total o parcialmente durante casi 11 horas, lo que afectó el acceso de los clientes a nuestro panel, así como el procesamiento de datos y el envío de mensajes. En los 13 años de historia de Braze, este es el primer y único incidente de esta magnitud que hemos tenido. Nuestra relación con los clientes se basa en la confianza y siempre nos hemos sentido tremendamente orgullosos de crear sistemas resistentes que han permitido que nuestra plataforma permanezca disponible y funcionando, incluso bajo cargas de trabajo exigentes. Durante esta interrupción, no cumplimos esa promesa y lamentamos profundamente el impacto que esto ha tenido en todos y cada uno de nuestros clientes.

Para ayudarlo a comprender mejor lo que sucedió y por qué, le brindaré un contexto importante sobre nuestra arquitectura, describiré las causas de la interrupción en detalle, lo guiaré a través de los cambios que ya hemos realizado y describiré en qué trabajaremos. implementar en el corto plazo y en el futuro.

Comprender la arquitectura de servicios de la plataforma Braze

Braze mantiene conjuntos separados de servidores para cada uno de nuestros ocho clústeres de EE. UU. Los clústeres Braze US 01 a 07 están alojados en Amazon Web Services (AWS), mientras que el clúster Braze US 08 está alojado en Microsoft Azure. En cada uno de estos entornos, Braze utiliza múltiples zonas de disponibilidad y tiene redundancias para cada parte de nuestro sistema. En caso de una falla en una zona de disponibilidad, deshabilitamos de manera rutinaria y transparente el enrutamiento y procesamiento de las zonas de disponibilidad deterioradas. Eso nos permite mantener de manera confiable la capacidad de entrega del servicio durante una interrupción del proveedor de servicios en la nube.

Con pocas excepciones, cada uno de los clústeres de EE. UU. tiene su propia infraestructura dedicada y, excepto por un puñado de componentes que se utilizan en todos los entornos en una región de nube determinada, estos clústeres están muy aislados entre sí, para reducir el riesgo. que una interrupción en un grupo afectará a otros grupos.

Debido a la intensidad de la carga de trabajo de procesamiento en tiempo real de la plataforma Braze, desde 2013 hemos complementado nuestro uso de AWS y Azure asociándonos con Rackspace para alojar hardware configurado a medida para ejecutar bases de datos MongoDB. Nuestros entornos AWS y Azure están configurados con conectores de nube privada AWS Direct Connect y Azure ExpressRoute, vinculando el entorno de nube a nuestra red interna mantenida en los centros de datos de Rackspace a través de un cable de fibra óptica dedicado. Esta conexión cifrada, que funciona con enlaces de red que admiten múltiples interfaces que impulsan más de 100 gigabits de tráfico de red por segundo, proporciona un acceso de alto rendimiento entre nuestra nube y los entornos de Rackspace.

Nuestro entorno personalizado en Rackspace alberga cientos de servidores físicos ubicados en gabinetes dedicados a Braze. Esta configuración incluye fuentes de alimentación redundantes y conmutadores redundantes en la parte superior del rack. Los conmutadores de la parte superior del rack son dispositivos de red que se ubican en un rack de servidores y conectan los dispositivos y servidores en el mismo rack de servidores. Estos conmutadores se prueban al menos una vez al año para comprobar su conmutación por error sin impacto; La prueba del año pasado se realizó con éxito el 3 de agosto de 2023. En este entorno personalizado, mantenemos decenas de miles de contenedores virtualizados para bases de datos MongoDB. De manera similar a nuestros entornos de nube, mantenemos altos niveles de aislamiento físico entre contenedores en diferentes clústeres de EE. UU. para minimizar las interrupciones y reducir el riesgo de que un contenedor pueda afectar a otros contenedores dentro de nuestras bases de datos.

La causa del apagón del 29 de abril y cómo respondimos

El fallo parcial inicial del interruptor

El 29 de abril a las 09:15 UTC, hubo una falla parcial en un conmutador de red principal Cisco Nexus conectado a nuestros gabinetes de servidores Rackspace. El interruptor defectuoso falló de una manera que no activó automáticamente el interruptor de red secundario a través de una conmutación por error, sino que mantuvo el interruptor defectuoso como primario.

Los conmutadores de red enrutan el tráfico reenviando paquetes de red, llamados "tramas", a su destino. Para hacer esto de manera eficiente, estos conmutadores mantienen una comprensión de la topología de red que conecta los dispositivos entre sí. Es común que las rutas de red cambien dinámicamente en respuesta a fallas o lentitud de componentes individuales. Cuando ocurren estos cambios, los conmutadores y otros dispositivos de red se comunican entre sí para mantener una comprensión precisa de la topología de la red.

En redes grandes, a menudo existirá más de una ruta entre dispositivos, lo que puede provocar "bucles" de enrutamiento (es decir, una condición en la que los paquetes no se detienen en su destino previsto y, en cambio, regresan al lugar donde se originaron). Los bucles pueden crear "tormentas de transmisión", donde el tráfico termina dando vueltas indefinidamente, saturando los enlaces de la red y provocando interrupciones. Para evitar que esto suceda, los conmutadores están programados para enviar mensajes que ayudan a identificar enlaces redundantes. Esos mensajes se denominan unidades de datos del protocolo de puente de árbol de expansión (BPDU) y son parte de un protocolo de red llamado Protocolo de árbol de expansión (STP). Luego, los conmutadores utilizan esta información para bloquear los puertos de tráfico a fin de evitar que se produzcan bucles cuando enrutan el tráfico. Si falla un enlace físico o un conmutador, el STP ayuda a proporcionar redundancia, ya que puede usarse para identificar otros enlaces físicos a través de los cuales se puede enviar el tráfico y promover el enlace previamente pasivo (es decir, bloqueado) a activo para mantener las conexiones.

Al inicio del incidente del 29 de abril, cuando el conmutador comenzó a funcionar mal, comenzó a enviar continuamente notificaciones de cambios de topología y BPDU, inundando la red con esos avisos de cambios. Estos paquetes se propagaron a los conmutadores de distribución y otros conmutadores, lo que provocó un bucle de conmutación de árbol de expansión que resultó en una interrupción completa de la red. Si bien el STP está implementado para reducir los bucles de red mediante el bloqueo de los puertos de red donde se detectan bucles, durante el incidente del 29 de abril, el tráfico del árbol de expansión reenviado incorrectamente desde el conmutador que funcionaba mal provocó que otros conmutadores de la red volvieran a analizar sus topologías del árbol de expansión. Luego, debido a que esos otros conmutadores detectaron que un paquete BPDU de alta prioridad provenía del conmutador que funcionaba mal, los conmutadores de distribución comenzaron a reenviar puertos previamente bloqueados y dieron como resultado un bucle de conmutación que sobrecargó la red y la derribó.

La solución de Rackspace

Como resultado de esta actividad, los ingenieros del centro de datos de Rackspace recibieron alertas aproximadamente a las 09:20 UTC sobre problemas inesperados de conectividad de red y comenzaron a solucionar el problema. Entre las 09:39 y las 10:03 UTC, los ingenieros del centro de datos de Rackspace suspendieron el conmutador de red, apagaron y encendieron el conmutador principal y forzaron a las tarjetas de interfaz de red (NIC) en el gabinete del servidor a conmutar por error al conmutador secundario. Después de la conmutación por error de la NIC, se restableció la conectividad a los servidores físicos en el entorno Braze.

Cómo funcionan las bases de datos Braze MongoDB

Las bases de datos MongoDB utilizadas por Braze permiten almacenar datos en múltiples servidores de bases de datos conocidos como "fragmentos". MongoDB proporciona un servicio de enrutamiento llamado "mongoS", que procesa consultas de los servicios de la plataforma Braze, determina la ubicación de los datos relevantes en un clúster fragmentado y luego enruta una consulta a la base de datos MongoDB apropiada. Braze tiene cientos de bases de datos MongoDB distintas, que comprenden más de 15.000 procesos "mongoD", que son los programas que ejecutan la base de datos y almacenan datos para un fragmento de MongoDB en particular.

Cada fragmento de base de datos consta de un proceso mongoD primario y al menos dos procesos mongoD secundarios, lo que proporciona alta disponibilidad en caso de falla. Cada servidor mongoS mantiene una conexión de red con cada mongoD al que puede enrutar consultas. Estos procesos mongoD también se conectan a los primarios y secundarios en su configuración; esto se conoce como conjunto de réplicas. Si un mongoS no puede conectarse a un mongoD determinado, marcará ese proceso como fuera de línea y programará un reintento. De manera similar, si un mongoD no puede conectarse a otros miembros de mongoD de su conjunto de réplicas en un segundo, expirará el tiempo de espera, marcará esos procesos como fuera de línea y programará un reintento.

El impacto del bucle de red en nuestros procesos MongoDB y cómo respondimos

Durante el bucle de red, debido a que nuestros procesos MongoDB no podían conectarse normalmente, cada uno marcó todos sus procesos asociados como fuera de línea. Es decir, cada proceso mongoS marcó todos sus procesos mongoD asociados como fuera de línea, y cada proceso mongoD marcó sus miembros del conjunto de réplicas relacionados como fuera de línea. Sin embargo, incluso después de que Rackspace restableciera la conectividad de red en nuestros servidores físicos, ni los procesos mongoS ni mongoD restablecieron todas las conexiones con los otros procesos que habían sido marcados como desconectados.

En este punto, para ayudar en los esfuerzos de remediación de nuestro equipo de administrador de bases de datos (DBA) de Rackspace, los equipos de Braze DevOps comenzaron a depurar y probar rápidamente métodos para restaurar esa conectividad. Nuestra investigación determinó que la única opción disponible era reiniciar cada uno de los casi 16.000 procesos mongoD y más de 6.000 mongoS en sus contenedores virtualizados. Dada la magnitud de esta empresa y el hecho de que no existía la automatización para reiniciar tantos contenedores rápidamente, los ingenieros de Rackspace escribieron un nuevo código durante el incidente para crear una capacidad de automatización sobre la marcha.

Desafortunadamente, a medida que se aceleraba el proceso de reinicio, surgió otro problema en el sistema de nombres de dominio (DNS). A medida que los procesos mongoS y mongoD se conectan, solicitan información de los solucionadores de DNS en un proceso que se conoce como búsqueda de DNS. Con las búsquedas continuas de DNS impulsadas por la velocidad de los reinicios, los servidores DNS sufrieron una gran carga, lo que provocó tiempos de espera de conectividad en las capas de mongoS cuando se reconectaban a los procesos de mongoD. Para adaptarse a esta carga creciente, nuestro equipo de Rackspace aumentó la capacidad de la CPU de DNS, pero luego se vio obligado a reiniciar el nivel mongoS por segunda vez para crear conexiones saludables desde cada mongoS a sus procesos mongoD asociados.

Alrededor de las 17:05 UTC, el proceso de reinicio permitió que algunos clústeres comenzaran a volver a estar en línea. A medida que el rendimiento de la base de datos se recuperó y los clústeres se estabilizaron, Braze continuó aumentando la capacidad de procesamiento de datos y envío de mensajes; sin embargo, ese esfuerzo se vio complicado por el enorme retraso resultante de la falta de disponibilidad previa.

Dada la escala y la sofisticación de nuestro entorno de base de datos Rackspace, que consta de cientos de bases de datos distintas, la duración de la interrupción y el volumen resultante de nuestro trabajo pendiente (que representa miles de millones de mensajes y miles de millones de puntos de datos ingeridos), el proceso de recuperación requerido en -adaptación al momento de nuestros procesos normales de recuperación. Esto era necesario para garantizar que los recursos de la base de datos permanecieran en equilibrio con las demandas de procesamiento en curso, incluida la introducción de una cantidad masiva de capacidad de procesamiento general.

Sin embargo, al hacerlo, Braze alcanzó un límite de AWS en la cantidad de CPU virtuales que pudimos aprovisionar, lo que nos impidió agregar capacidad de servidor adicional. El equipo de Braze rápidamente intensificó esta circunstancia con nuestro equipo de AWS y recibió un aumento, lo que permitió a nuestros ingenieros aumentar la capacidad de procesamiento de nuestro servidor a un nivel récord, que era más de un 50 % mayor que nuestra capacidad máxima anterior, que se había alcanzado en Black. Viernes 2023.

A las 20:30 UTC, todos nuestros clusters de EE. UU., excepto US 01, US 03 y US 08, habían terminado de procesar sus retrasos, y los clusters restantes estaban procesando a velocidades máximas o superiores al día anterior al incidente. En unas pocas horas, todos los clústeres volvieron a procesarse en tiempo real y declaramos que el incidente se resolvió.

Cómo Braze comunica las actualizaciones durante los incidentes

La comunicación clara y frecuente durante incidentes como este es esencial. Si bien los problemas técnicos en general ocurren raramente, y un problema de esta magnitud era nunca antes visto en Braze, siempre hacemos nuestro mejor esfuerzo para comunicarnos con las partes afectadas con claridad y rapidez.

En situaciones como esta, los principios rectores que informan nuestra estrategia de comunicación son la honestidad, la transparencia y la confianza. Sabemos que solo tenemos una oportunidad para ser honestos y directos sobre lo que está ocurriendo, y que la transparencia sobre los incidentes, tanto en el momento como después de su resolución, es esencial para mantener la confianza. Al final del día, queremos que nuestros clientes tengan la confianza de que Braze siempre hará todo lo que esté a nuestro alcance para explicar, remediar y evitar que se repita cualquier incidente.

Durante los incidentes, utilizamos nuestra página de estado para gestionar las comunicaciones y proporcionar actualizaciones periódicas sobre la situación; Recomiendo encarecidamente a los clientes que se registren para recibir actualizaciones desde esa página para mantenerse actualizados. Durante la interrupción del 29 de abril, complementamos estas actualizaciones frecuentes de la página de estado con un correo electrónico de mi compañero cofundador y nuestro director ejecutivo, Bill Magnuson. Ese mensaje se envió a todos los usuarios del panel de Braze y se proporcionó a nuestros equipos de cuentas para que lo compartieran con otras partes interesadas de los clientes según fuera necesario.

Cómo Braze siguió el incidente y futuros planes de prevención

Antes de este incidente, nuestra experiencia nos había llevado a creer que nuestra red era resistente debido a nuestros conmutadores de red redundantes. Sin embargo, la interrupción reveló que nuestra topología de red, que nos había brindado buen soporte durante más de una década, era vulnerable a fallas catastróficas. Ahora está claro que es necesario mejorarlo en el futuro.

Desde el incidente, Braze y Rackspace intercambiaron y reemplazaron el interruptor defectuoso, y el equipo de ingeniería de Rackspace completó una auditoría completa de la infraestructura de red de la que dependen los servicios de Braze. Si bien las fallas de hardware son increíblemente difíciles de predecir, especialmente con equipos en garantía, existe un monitoreo para detectar anomalías y garantizar una respuesta rápida. Ambos equipos están colaborando ahora para realizar cambios que eviten futuros bucles de red, incluso en caso de que el equipo funcione mal. Algunos cambios de red tomarán tiempo para implementarse, ya que planeamos realizar cambios significativos en nuestra topología de red para mejorar aún más la protección contra bucles. También hemos abierto tickets de soporte tanto con Cisco como con MongoDB para comprender mejor los escenarios de falla que experimentamos y para mejorar la capacidad de los procesos mongoD y mongoS de autocurarse después de fallas de red.

Hemos estado en contacto diario con Rackspace desde el incidente para tomar medidas sobre cambios a corto plazo y llevar a cabo una mejora mayor de la red, y continuaremos haciéndolo hasta que tengamos la confianza de que se ha logrado un diseño de red mejorado y más resistente.

Quiero disculparme nuevamente por este incidente y por el impacto que tuvo en su negocio y su relación con sus clientes. La cantidad de tiempo que Braze no estuvo disponible es inaceptable. Nuestro liderazgo de ingeniería y nuestro equipo ejecutivo están totalmente comprometidos a realizar todos los cambios necesarios para identificar y resolver las vulnerabilidades de las interrupciones de la manera más rápida y eficiente posible, para que podamos ganarnos una vez más su confianza como un socio confiable y de alto rendimiento.

—Jon