A história de um CTO que apostou a carreira e desceu até o nível de bits para hackear o banco de dados
(tech.devsisters.com)- A interrupção de 36 horas do CookieRun: Kingdom, a mais longa da história da Devsisters
- Uso do CockroachDB como banco de dados distribuído principal: 4 nós, 12 TB de armazenamento, 7 réplicas
- Durante um trabalho de expansão do banco de dados, metade dos nós caiu
- Com isso, ocorreu uma falha total do serviço, e o engenheiro de suporte da CockroachDB concluiu que a recuperação era impossível
- Por isso, este texto organiza os esforços feitos para encontrar diretamente os dados armazenados no storage
24 comentários
É um texto particularmente polêmico, né..? Não sei como isso seria do ponto de vista do serviço, mas imagino que os desenvolvedores que trabalharam nisso devem ter sentido um baita orgulho.
Não sei qual foi a reação dos usuários, mas só pelo esforço para evitar um rollback eu, como usuário, gostaria de dar um voto de elogio.. Mesmo que, considerando a evasão de usuários e a experiência do cliente ao longo dessas 36 horas, o prejuízo possa ter sido maior, do ponto de vista de um desenvolvedor eu diria que foi um desafio interessante. Como teria sido se a empresa não fosse um jogo, mas um banco?
Dizem que o Pokémon Go usa o Spanner do GCP (https://cloud.google.com/blog/topics/…), e realmente não parece haver uma alternativa adequada na AWS.
Com base neste documento, ao entender a intenção da equipe de desenvolvimento, parece que neste projeto eles não deveriam ter usado o CockroachDB.
Qual DB vocês deveriam ter usado?
Dependendo do serviço, é um conteúdo que pode dar arrepios.
Li com prazer.
Pelo que vi, esse blog publicou uma série de textos sobre essa falha. Lendo tudo em sequência, o desespero mental que as pessoas tentando resolver isso devem ter sentido foi realmente impressionante.
Não sei se, do ponto de vista do negócio, foi realmente a decisão certa passar 36 horas restaurando as informações de todos os usuários, em vez de fazer um rollback que prejudicaria a experiência de alguns usuários, mas protegeria a maioria. Do ponto de vista de desenvolvedor, é um conteúdo interessante.
No conteúdo do texto, há uma passagem assim.
Nossa missão é proporcionar a melhor experiência aos clientes, e nos esforçamos para colocar isso em prática com sinceridade. Ninguém desanimou nem desistiu.
É desanimador ouvir aqui também que, por dinheiro, alguns usuários podem simplesmente ser descartados; isso me faz sentir mais uma vez como os usuários são tratados na indústria de jogos coreana.
Acho que essa é uma interpretação forçada demais e, olhando em retrospectiva, se não tivesse conseguido resolver o problema, teria desperdiçado tempo e ainda recebido reclamações tanto pelo tempo perdido quanto pelo rollback.
E a perspectiva de que, ao não conseguir manter o serviço no ar, você está abandonando os usuários durante esse período continua sendo a mesma.
Concordo de forma muito, muito intensa...
Do ponto de vista de desenvolvedor, foi uma leitura muito interessante (incluindo o título chamativo), mas eu também acabei vendo por um ângulo parecido. Como foi algo mencionado em uma matéria um pouco antiga, pode haver diferença em relação à realidade, mas parece que a receita de CookieRun: Kingdom passou de 300 bilhões de wones, então provavelmente foi uma decisão tomada comparando a receita esperada correspondente a 36 horas de downtime com o valor das compensações pagas após o rollback.
Acho também que o fato de ser uma organização com uma cultura de engenharia fortemente voltada para resolver problemas deve ter influenciado em certa medida.
Eu ainda não sei muito bem que decisão teria tomado no lugar deles.
Hoje em dia, em jogos, especialmente os que têm mecânicas de gacha aleatório, rollback é algo que... só pode ser usado no pior dos casos mesmo... A menos que seja como o jogo L, que não liga para a própria imagem, é praticamente impossível, então neste caso em especial, em vez de fazer rollback, eles deram uma compensação grande depois, e os usuários até brincavam entre si: se estiver faltando recurso, será que o servidor não vai cair de novo? Então eu acho que foi a decisão certa.
Como é um jogo, parece que, se tivessem feito um rollback de 36 horas, poderia ter havido um prejuízo financeiro grande por causa do cash.
Também voto que não parece ter sido uma decisão empresarialmente correta.
Um erro de configuração não intencional (esse foi o erro humano absurdo e mais crítico. Acabar fazendo desse jeito uma alteração enorme que impede o funcionamento da réplica; mesmo reunindo todos os desenvolvedores do projeto do banco de dados, isso não teria recuperação)
Então, como não dava para simplesmente perder todos os dados... mesmo abrindo mão da consistência dos dados mais recentes, foram localizar diretamente os dados do banco no formato binário final salvo (7 TB) e escrever um programa em Go para converter isso em CSV... ?
Fazer esse programa de conversão em Go, por melhor que fosse, teria lá muito sentido...?
Puxa... só de pensar nisso já dá uma sensação sufocante. Por que isso teve que acontecer assim...
O mais importante deve ser fortalecer o processo para que esse tipo de erro humano não aconteça. Melhor nem falar do sufoco de lidar com a falha enquanto convertiam os binários.
Existe algum outro motivo para não contar esse tipo de história? Só o fato de divulgar o post-mortem já tem valor.
Na minha opinião, se o objetivo é escrever um texto realmente útil, o título não deveria ser algo assim?
"Análise da causa e lições aprendidas com o erro de indisponibilidade do cluster provocado por uma configuração incorreta dos nós"
Esse tipo de texto pode ser publicado separadamente; “análise da causa da falha” e “processo de resolução da falha” são tópicos distintos, e ambos são importantes, então é difícil entender a atitude de diminuir o valor do texto só porque não houve uma “análise da causa da falha”...
Seria ainda melhor dizer que seria ótimo se ele também escrevesse depois um texto de análise da causa, mas dizer antes disso que não tem valor não é uma boa postura.
Para ser rigoroso, isso não foi um "processo de resolução de incidente", mas sim um processo braçal de "recuperação de dados incompletos". No máximo, conseguimos reduzir um pouco a extensão da perda? Algo nesse nível.
Onde, no texto acima, diz que a recuperação dos dados foi “incompleta”? Pelo menos pelo conteúdo do texto, eles afirmam que conseguiram uma recuperação completa. E, além disso, se recuperar um banco de dados que foi destruído não é resolver uma falha, então o que seria? Depois desse incidente, aquele serviço encerrou as operações imediatamente?
Mas isso não é um motivo para não contar essa história, né?
Nossa, como você complica a própria vida.