O impacto do loop de rede em nossos processos MongoDB e como respondemos
Durante o loop de rede, como nossos processos do MongoDB não conseguiram se conectar normalmente, cada um marcou todos os seus processos associados como offline. Ou seja, cada processo mongoS marcou todos os seus processos mongoD associados como offline e cada processo mongoD marcou seus membros do conjunto de réplicas relacionados como offline. No entanto, mesmo depois que a conectividade de rede foi restaurada aos nossos servidores físicos pela Rackspace, nem os processos mongoS nem mongoD restabeleceram todas as conexões com os outros processos que haviam sido marcados como offline.
Neste ponto, para ajudar nos esforços de correção da equipe de administradores de banco de dados (DBA) da Rackspace, as equipes Braze DevOps começaram a depurar e testar rapidamente métodos para restaurar essa conectividade. Nossa investigação determinou que a única opção disponível era reiniciar cada um dos quase 16.000 processos mongoD e mais de 6.000 processos mongoS em seus contêineres virtualizados. Dada a enorme escala desse empreendimento e o fato de que não existia automação para reiniciar tantos contêineres rapidamente, os engenheiros da Rackspace escreveram um novo código durante o incidente para criar capacidade de automação dinâmica.
Infelizmente, à medida que o processo de reinicialização se acelerou, surgiu outro problema no sistema DNS (Domain Name System). À medida que os processos mongoS e mongoD ficam online, eles solicitam informações dos resolvedores de DNS em um processo conhecido como pesquisa de DNS. Com as pesquisas contínuas de DNS impulsionadas pela velocidade das reinicializações, os servidores DNS ficaram sob carga pesada, levando a tempos limites de conectividade nas camadas mongoS à medida que se reconectavam aos processos mongoD. Para acomodar essa carga crescente, nossa equipe da Rackspace aumentou a capacidade da CPU do DNS, mas foi forçada a reiniciar a camada mongoS uma segunda vez para criar conexões íntegras de cada mongoS com seus processos mongoD associados.
Por volta das 17h05 UTC, o processo de reinicialização permitiu que alguns clusters começassem a ficar online novamente. À medida que o desempenho do banco de dados se recuperou e os clusters se estabilizaram, a Braze continuou a aumentar a capacidade de processamento de dados e envio de mensagens; no entanto, esse esforço foi complicado pelo enorme atraso resultante da indisponibilidade anterior.
Dada a escala e a sofisticação do nosso ambiente de banco de dados Rackspace, que consiste em centenas de bancos de dados distintos, a duração da interrupção e o volume resultante do nosso backlog (representando bilhões de mensagens e bilhões de pontos de dados ingeridos), o processo de recuperação necessário em -adaptação imediata dos nossos processos normais de recuperação. Isto foi necessário para garantir que os recursos da base de dados permanecessem em equilíbrio com as exigências de processamento contínuas, incluindo a introdução de uma enorme capacidade de processamento global.
No entanto, ao fazer isso, o Braze atingiu um limite da AWS no número de CPUs virtuais que conseguimos provisionar, impedindo-nos de adicionar qualquer capacidade adicional de servidor. A equipe Braze escalou rapidamente essa circunstância com nossa equipe AWS e recebeu um aumento, permitindo que nossos engenheiros aumentassem a capacidade de processamento de nosso servidor para um nível recorde, que era mais de 50% superior à nossa capacidade máxima anterior, que havia sido alcançada no Black. Sexta-feira de 2023.
Às 20h30 UTC, todos os nossos clusters nos EUA, exceto US 01, US 03 e US 08, haviam concluído o processamento de suas pendências, e os clusters restantes estavam processando nas taxas de pico ou acima do dia anterior ao incidente. Em poucas horas, todos os clusters voltaram ao processamento em tempo real e declaramos o incidente resolvido.
