Análisis posterior al incidente de Kagi de la semana pasada

Resolución del problema de inestabilidad del servicio de Kagi.com

• Investigando - Después del despliegue surgió un problema y el equipo estuvo trabajando en resolverlo. (12 de enero, 16:45 UTC)
• Monitoreando - Se revirtió el cambio de configuración que se estima fue la causa del problema y se sigue monitoreando que el servicio vuelva a la normalidad. (12 de enero, 18:30 UTC)
• Actualización - Para recuperar completamente la estabilidad, se suspenderá temporalmente el tráfico y se redirigirá a los usuarios a esta página. Se compartirán más detalles conforme avance la situación mientras el servicio se restablece de manera controlada. (12 de enero, 20:26 UTC)
• Monitoreando - El tráfico ya fue restablecido y se sigue monitoreando que el servicio vuelva completamente a la normalidad. (12 de enero, 21:14 UTC)
• Resuelto - Todos los servicios están operando con normalidad. Agradecen a los usuarios por esperar mientras se resolvía el problema.

Análisis posterior

• Zac, líder técnico de Kagi, compartió un análisis posterior detallado sobre la interrupción del servicio de la semana pasada.
• En respuesta a este incidente, el ingeniero senior Seth y el ingeniero de DevOps Luan trabajaron juntos.
• Hubo actores que abusaron del servicio y explotaron cuellos de botella en la infraestructura; se tomaron medidas inmediatas de mitigación y se están realizando mejoras en varias áreas del código y de la comunicación.

Cómo ocurrió el incidente

• Alrededor de las 5:30 p. m. del 12 de enero, detectaron un problema en la infraestructura a través del monitoreo interno y de reportes de usuarios.
• La naturaleza del problema provocaba cargas lentas o timeout de página para usuarios en distintas regiones.
• Resolver el problema tomó bastante tiempo, y aquí explican el contexto, el desarrollo de los hechos y los planes a futuro.

Proceso técnico de resolución

• Al principio, el problema coincidió casualmente con una actualización de recursos de RAM adicional en una VM.
• El monitoreo reportó alta latencia y problemas en el pool de conexiones a la base de datos de la aplicación.
• El pool de conexiones llegó a saturarse, lo que significaba que la cantidad total de conexiones superaba el límite máximo configurado.
• Mientras evaluaban la salud interna de la base de datos y el rendimiento de las consultas, probaron reemplazar algunas instancias para ver si eso ayudaba a reducir la congestión.
• Como parecía que reemplazar parte de las instancias ayudaba, pausaron temporalmente el tráfico de usuarios para restablecer por completo todos los pools de conexiones de una sola vez.
• Al revisar el estado de la base de datos, quedó claro que la causa raíz era una alta contención sobre filas de la tabla de usuarios.
• Esa contención incrementó bruscamente la latencia de escritura, generó backpressure sobre el pool de conexiones de la aplicación y finalmente agotó todas las conexiones disponibles.
• Hasta ahora, Kagi había estado usando la base de datos de un solo núcleo más barata disponible en GCP, lo que implicaba el riesgo de dejar la base de datos inutilizada con facilidad.
• Identificaron a los actores maliciosos y encontraron cuentas creadas en menos de 24 horas, además de una sola cuenta de usuario que realizó más de 60,000 búsquedas en poco tiempo.
• Se eliminó la capacidad de búsqueda de esa cuenta y se publicó un hotfix que desactiva la escritura específica que causó el problema.
• Para la medianoche, el problema quedó completamente resuelto, y siguen monitoreando de cerca cualquier señal de que esos actores regresen.

Próximas acciones

• Aprendieron mucho de este incidente y ya están en marcha planes inmediatos para reforzar más el sistema y mejorar el proceso de comunicación durante incidentes.
• Primero, reconocen que las actualizaciones de la página de estado no fueron lo suficientemente rápidas.
• Planean migrar a una plataforma de página de estado que permita exponer más fácilmente a los usuarios el monitoreo interno automatizado, para que puedan ver en tiempo real la salud de la plataforma.
• Están mitigando directamente las consultas problemáticas y ejecutando pruebas de carga para ver si existen fallas similares adicionales.
• También instalarán monitoreo adicional para apuntar más rápido al lugar correcto dentro de la infraestructura y evitar perder tiempo siguiendo señales equivocadas como ocurrió esta vez.
• Están reforzando los sistemas que detectan este tipo de abuso, y como este no solo afecta el rendimiento sino que también genera costos directos, necesitan establecer límites automatizados para hacerlos cumplir.
• Las nuevas restricciones ya estaban activas al momento de esta publicación, y seguirán monitoreando su impacto y ajustándolas según sea necesario.
• Si alguien cree que su acceso a Kagi fue bloqueado por error, piden que se comunique a [e-mail].

Opinión de GN⁺

• Kagi sufrió un problema de latencia de escritura causado por contención de filas en la tabla de usuarios, lo que generó backpressure en el pool de conexiones de la aplicación y terminó provocando la caída del servicio.
• Este problema fue consecuencia del riesgo asociado a que Kagi utilizara la base de datos de un solo núcleo más barata de GCP.
• El equipo de Kagi mostró su intención de mejorar la estabilidad y la transparencia del servicio mediante acciones como reforzar el sistema, mejorar la comunicación con los usuarios y establecer límites automatizados para prevenir abusos. Estos esfuerzos reflejan la voluntad de Kagi de ofrecer un servicio más confiable a sus usuarios.

[GN⁺]

Opiniones en Hacker News

• Opiniones sobre el incidente ocurrido al mismo tiempo que una actualización de infraestructura

  • Se dice que fue una coincidencia total que el incidente ocurriera justo cuando realizaban una actualización de infraestructura agregando más RAM a la VM.
  • Se menciona que este tipo de "coincidencias" pasan con frecuencia y hacen que uno llegue a cuestionar su propia existencia mientras resuelve problemas.
  • Se advierte que, si uno entra en pánico durante la resolución del problema, puede aplicar un hotfix que rompa otra cosa, lo que puede convertirse en una cruel ley de Murphy para administradores de sistemas y desarrolladores.

• Experiencia de un usuario con la página de estado de Kagi

  • Un usuario comentó que le generó ansiedad ver que la página de estado de Kagi mostraba que todo funcionaba normalmente.
  • Lo comparó con servicios de los que dependió en el pasado, que actualizaban su página de estado de inmediato y le permitían saber que el problema no estaba en su dispositivo.
  • Mencionó que planea seguir usando Kagi, pero espera que, como se menciona en el análisis posterior al incidente, el código de la página de estado se migre a otro servicio o plataforma.

• Comentario que comparte una experiencia personal

  • Compartió que, a nivel personal, ha vivido varias veces el mismo tipo de caída del servicio y que intentó resolver problemas relacionados con la salud del pool de conexiones de la base de datos.
  • Señaló que los indicadores habituales de saturación de la base de datos (CPU%, IOPS, etc.) no cambian mucho durante este tipo de caídas, y que en su lugar la causa puede ser la contención de locks.
  • Como recomendación para el RDBMS que usa Kagi, sugirió graficar la latencia global de I/O, el tiempo de adquisición de locks y el tiempo de ejecución de consultas, entre otros.

• Comentario sobre la experiencia de las startups

  • Mencionó que todas las startups pasan por problemas como este en algún momento.
  • Dijo que quizá no tuvieron suficiente tiempo o recursos para desarrollar la capacidad de prevenirlo, o que simplemente no imaginaron que ese problema en particular iba a ocurrir.
  • Señaló que la transparencia y el aprendizaje son importantes, pero que a veces también importa compensar, y sugirió que Kagi considere ofrecer créditos de búsqueda por el tiempo en que el servicio no estuvo disponible.

• Comentario sobre la observabilidad de los sistemas internos

  • Indicó que debieron haber detectado el problema más rápido, y mencionó que el dashboard correcto de Datadog y las consultas adecuadas en Splunk deberían haber dejado el problema mucho más claro en menos tiempo.
  • Aconsejó invertir en un mejor monitoreo y tomarlo como una experiencia de aprendizaje.

• Opinión de un usuario de pago sobre la confiabilidad de Kagi

  • Un usuario de pago que sufrió el downtime de Kagi comentó que se dio cuenta de que daba por sentada la confiabilidad de Google.
  • Mencionó que perder acceso a un motor de búsqueda puede ser un problema importante, y compartió que, aunque le encanta Kagi, fue desagradable experimentar la caída.
  • Expresó su esperanza de que esta experiencia haga que Kagi se convierta en un servicio más sólido y confiable.

• Comentario sobre el scraper que provocó la caída del servicio

  • Respecto al hecho de que un scraper ejecutado por un usuario provocó una caída del servicio de 7 horas, se preguntó si durante las pruebas no se hicieron la pregunta: "¿qué pasa si se generan muchas búsquedas?".

• Comentario sobre la experiencia de uso de Kagi y el análisis posterior al incidente

  • Compartió que, después de usar Kagi durante unas semanas, no supo qué hacer cuando la semana pasada no cargó de inmediato.
  • Mencionó que ya se había olvidado del incidente incluso antes de que saliera el análisis posterior, y agradeció al equipo por ofrecer una experiencia de búsqueda en la que uno no tiene que pensar.

• Comentario sobre la base de datos de un solo núcleo usada en GCP

  • Reaccionó positivamente al hecho de que Kagi había estado usando la base de datos de un solo núcleo más barata disponible en GCP.
  • Sugirió considerar algo como PolyScale para manejar aumentos bruscos en la carga de lectura y exprimir un poco más el rendimiento.

• Comentario sobre el scraping automatizado

  • Mencionó que, después de bloquear la cuenta, el usuario que se puso en contacto afirmó que había usado la cuenta para scrapear resultados automáticamente.
  • Recomendó establecer límites de QPS (consultas por segundo) para todas las solicitudes RPC / API / HTTP entrantes, especialmente las públicas.