Análise pós-incidente do caso da Kagi da semana passada

Resolução do problema de instabilidade do serviço Kagi.com

• Investigando - Após o deploy, surgiu um problema e a equipe está trabalhando na correção. (12 de janeiro, 16:45 UTC)
• Monitorando - A alteração de configuração considerada a provável causa do problema foi revertida, e o retorno do serviço ao normal está sendo monitorado continuamente. (12 de janeiro, 18:30 UTC)
• Atualização - Para restaurar totalmente a estabilidade, o tráfego será interrompido temporariamente e os usuários serão redirecionados para esta página. Mais detalhes serão fornecidos conforme a situação evoluir enquanto o serviço for restaurado de forma controlada. (12 de janeiro, 20:26 UTC)
• Monitorando - O tráfego foi restaurado, e o retorno completo do serviço ao normal continua sendo monitorado. (12 de janeiro, 21:14 UTC)
• Resolvido - Todos os serviços estão operando normalmente. Agradecemos aos usuários pela paciência enquanto o problema era resolvido.

Análise pós-incidente

• Zac, líder técnico da Kagi, compartilhou uma análise detalhada do incidente de indisponibilidade do serviço da semana passada.
• Em resposta a esse incidente, o engenheiro sênior Seth e o engenheiro de DevOps Luan trabalharam juntos.
• Houve agentes que abusaram do serviço e exploraram gargalos da infraestrutura, e medidas imediatas de mitigação foram tomadas, enquanto melhorias em várias áreas do código e da comunicação estão em andamento.

Cronologia do incidente

• Por volta das 17h30 de 12 de janeiro, foi identificado um problema de infraestrutura por meio do monitoramento interno e de relatos de usuários.
• A natureza do problema causava carregamento lento ou timeout de páginas para usuários em várias regiões.
• A resolução levou um tempo considerável, e são explicados o contexto, o andamento e os próximos passos.

Processo técnico de resolução

• No início, o problema aconteceu por coincidência ao mesmo tempo em que os recursos extras de RAM da VM eram ampliados.
• O monitoramento reportou alta latência e problemas no pool de conexões com o banco de dados da aplicação.
• O pool de conexões chegou à saturação, o que significava que o número total de conexões excedia o limite máximo configurado.
• Enquanto a saúde interna do banco de dados e o desempenho das queries eram avaliados, algumas instâncias foram substituídas para testar o efeito de reduzir o congestionamento.
• Como a substituição de parte das instâncias pareceu ajudar, o tráfego de usuários foi pausado para redefinir completamente todos os pools de conexão de uma só vez.
• Ao analisar o estado do banco de dados, ficou claro que a alta contenção em linhas da tabela de usuários era a causa raiz.
• Essa contenção aumentou drasticamente a latência de escrita, gerando backpressure no pool de conexões da aplicação e, por fim, esgotando todas as conexões disponíveis.
• Até então, a Kagi vinha usando o banco de dados single-core mais barato disponível no GCP, o que carregava o risco de paralisar facilmente o banco.
• Após identificar os agentes maliciosos, foram encontradas contas criadas em menos de 24 horas e uma única conta de usuário que realizou mais de 60.000 buscas em pouco tempo.
• A funcionalidade de busca dessa conta foi removida, e foi publicado um hotfix para desativar a escrita específica que causava o problema.
• Até a meia-noite, o problema foi totalmente resolvido, e continua havendo monitoramento atento de sinais de retorno desses agentes.

Próximas ações

• Muito foi aprendido com esse incidente, e já estão em andamento planos imediatos para fortalecer ainda mais o sistema e melhorar o processo de comunicação em casos de incidentes.
• Primeiro, foi reconhecido que as atualizações da página de status não foram rápidas o suficiente.
• Haverá migração para uma plataforma de página de status que permita expor com mais facilidade o monitoramento interno automatizado aos usuários, para que eles possam acompanhar em tempo real a saúde da plataforma.
• Estão sendo executadas ações para mitigar diretamente as queries problemáticas e testes de carga para verificar se existem outras falhas semelhantes.
• Também será instalado monitoramento adicional para apontar mais rapidamente para os locais corretos na infraestrutura, evitando desperdício de tempo seguindo sinais incorretos como aconteceu desta vez.
• O sistema de detecção desse tipo de abuso está sendo reforçado e, como isso gera impacto não apenas em desempenho, mas também diretamente em custos, é necessário definir limites automatizados para sua aplicação.
• Os novos limites já estavam em vigor no momento desta publicação, e seu impacto será monitorado, com ajustes contínuos conforme necessário.
• Caso alguém acredite que o acesso à Kagi foi bloqueado por engano, é solicitado que entre em contato com [e-mail].

Opinião do GN⁺

• A Kagi enfrentou um problema de latência de escrita causado por contenção em linhas da tabela de usuários, o que gerou backpressure no pool de conexões da aplicação e levou à indisponibilidade do serviço.
• Esse problema foi resultado do risco envolvido no uso, pela Kagi, do banco de dados single-core mais barato do GCP.
• Com esse incidente, a equipe da Kagi demonstrou esforço para aumentar a estabilidade e a transparência do serviço ao fortalecer o sistema, melhorar a comunicação com os usuários e definir limites automatizados para evitar abusos. Esses esforços refletem o compromisso da Kagi em oferecer um serviço mais confiável aos usuários.

[GN⁺]

Comentários do Hacker News

• Opinião sobre o incidente ter ocorrido ao mesmo tempo que o upgrade de infraestrutura

  • Disseram que foi uma coincidência total o incidente ter acontecido justamente enquanto faziam um upgrade de infraestrutura adicionando mais RAM à VM.
  • Mencionam que esse tipo de "coincidência" acontece com frequência e faz a pessoa duvidar da própria sanidade enquanto tenta resolver o problema.
  • Alertam que, quando se entra em pânico durante a resolução de um problema, pode-se aplicar um hotfix que quebra outra coisa, o que pode virar uma cruel Lei de Murphy para administradores de sistemas e desenvolvedores.

• Experiência de um usuário com a página de status da Kagi

  • O usuário disse que ficou ansioso porque a página de status da Kagi mostrava que tudo estava funcionando normalmente.
  • Comparou com serviços dos quais dependeu no passado, que atualizavam a página de status imediatamente e deixavam claro que o problema não estava no dispositivo dele.
  • Disse que pretende continuar usando a Kagi, mas espera que, como mencionado na análise posterior ao incidente, o código da página de status seja movido para outro serviço/plataforma.

• Comentário compartilhando experiência pessoal

  • Compartilhou que já passou pessoalmente várias vezes pelo mesmo tipo de indisponibilidade de serviço e tentou resolver problemas relacionados à saúde do pool de conexões do banco de dados.
  • Apontou que métricas comuns de saturação do banco de dados (CPU%, IOPS etc.) não mudam muito durante essas interrupções e que, em vez disso, contenção de locks pode ser a causa do problema.
  • Como recomendação para o RDBMS usado pela Kagi, sugeriu colocar em gráficos a latência global de I/O, o tempo de aquisição de locks, o tempo de execução de queries etc.

• Comentário sobre a experiência de startups

  • Mencionou que toda startup acaba passando por esse tipo de problema em algum momento.
  • Disse que talvez não tenha havido tempo nem recursos suficientes para construir a capacidade de evitar isso, ou que talvez ninguém tenha imaginado que esse problema específico ocorreria.
  • Afirmou que transparência e aprendizado são importantes, mas que às vezes compensação também importa, e sugeriu considerar oferecer créditos de busca da Kagi pelo tempo em que o serviço ficou indisponível.

• Comentário sobre observabilidade dos sistemas internos

  • Apontou que o problema deveria ter sido percebido mais rapidamente e que os dashboards corretos no Datadog e as queries certas no Splunk deveriam ter tornado a causa muito mais clara bem antes.
  • Aconselhou investir em monitoramento melhor e tratar isso como uma experiência de aprendizado.

• Opinião de um usuário pagante sobre a confiabilidade da Kagi

  • Um usuário pagante que vivenciou a indisponibilidade da Kagi disse ter percebido que tomava como garantida a confiabilidade do Google.
  • Mencionou que perder o acesso a um mecanismo de busca pode ser um grande transtorno e compartilhou que ama a Kagi, mas que passar por uma indisponibilidade foi desagradável.
  • Disse esperar que essa experiência torne a Kagi um serviço mais robusto e confiável.

• Comentário sobre o scraper que causou a indisponibilidade

  • Sobre o fato de um scraper executado por um usuário ter causado 7 horas de indisponibilidade, questionou se durante os testes ninguém perguntou: "o que acontece se houver muitas buscas?"

• Comentário sobre a experiência de uso da Kagi e a análise posterior ao incidente

  • Compartilhou que, após usar a Kagi por algumas semanas, quando ela não carregou imediatamente na semana passada, não sabia o que fazer.
  • Mencionou que já havia até esquecido do incidente antes de a análise posterior ser publicada, e agradeceu à equipe por criar algo em que ele não precisa pensar ao pesquisar.

• Comentário sobre o banco de dados single-core usado no GCP

  • Reagiu positivamente ao fato de a Kagi ter usado o banco de dados single-core mais barato disponível no GCP.
  • Sugeriu considerar algo como o PolyScale, que poderia lidar com aumentos bruscos de carga de leitura e extrair mais desempenho.

• Comentário sobre scraping automatizado

  • Mencionou que, depois de a conta ser bloqueada, o usuário que entrou em contato alegou ter usado a conta para fazer scraping automatizado dos resultados.
  • Recomendou definir limites de QPS (queries por segundo) para todas as requisições RPC / API / HTTP recebidas, especialmente as públicas.