- La interrupción de 36 horas de CookieRun: Kingdom, la más larga en la historia de Devsisters
- Se usaba CockroachDB como base de datos distribuida principal: 4 nodos, 12 TB de almacenamiento y 7 réplicas
- Durante una tarea de escalado de la base de datos, se cayeron la mitad de los nodos
- Como consecuencia, se produjo una caída total del servicio, y el ingeniero de soporte del lado de CockroachDB determinó que la recuperación era imposible
- Por eso, este texto recopila los esfuerzos realizados para encontrar directamente los datos almacenados en el storage
24 comentarios
Vaya, este texto sí que ha generado mucha polémica... No sé cómo habrá sido desde el lado del servicio, pero seguro que los desarrolladores que trabajaron en eso debieron sentirse muy orgullosos.
No sé cómo habrán reaccionado los usuarios, pero como usuario sí me dan ganas de aplaudir que hayan intentado evitar un rollback. Aunque, pensando en la fuga de usuarios y la experiencia del cliente durante esas 36 horas, quizá la pérdida haya sido mayor; aun así, desde la perspectiva de un desarrollador, me parece que fue un reto interesante. ¿Qué habría pasado si la empresa no hubiera sido un juego, sino un banco?
Dicen que Pokémon Go usa Spanner de GCP (https://cloud.google.com/blog/topics/…), pero parece que en AWS no hay una alternativa realmente adecuada.
Al entender la intención del equipo de desarrollo con base en ese documento, parece que no debieron haber usado CockroachDB en ese proyecto.
¿Qué base de datos deberían haber usado?
Dependiendo del servicio, puede ser un contenido escalofriante.
Lo leí con gusto.
Veo que en ese blog dejaron una serie de publicaciones sobre ese incidente. Las leí de corrido y me impresionó mucho imaginar el nivel de caos mental que debieron sentir quienes estaban tratando de resolver eso.
No estoy muy seguro de si, desde el punto de vista del negocio, era la decisión correcta dedicar 36 horas a restaurar toda la información de todos los usuarios, en lugar de hacer un rollback que perjudicara la experiencia de algunos usuarios para proteger a la mayoría. Desde la perspectiva de un desarrollador, sí hay cosas interesantes.
En el cuerpo del texto aparece algo así.
Nuestra misión era ofrecer la mejor experiencia a los clientes, y nos esforzamos sinceramente por ponerlo en práctica. Nadie se desanimó ni se rindió.
Hasta aquí también termino escuchando que, por dinero, se puede desechar a algunos usuarios; una vez más me voy con la sensación de cómo se trata a los usuarios en la industria de los videojuegos de Corea.
Creo que eso es una interpretación demasiado rebuscada y, viéndolo en retrospectiva, si no hubiera logrado resolver el problema, habría desperdiciado el tiempo y además se habría ganado el resentimiento por el rollback.
Y desde la perspectiva de que, si el servicio no está disponible, durante todo ese tiempo se está abandonando a los usuarios, sigue siendo lo mismo.
Estoy muy, muy, muy intensamente de acuerdo...
Desde la perspectiva de un desarrollador fue una lectura muy interesante (incluido el título llamativo), pero yo también lo veía desde una óptica parecida. Como era algo mencionado en un artículo de hace ya un tiempo, puede haber diferencias con la realidad, pero parece que los ingresos de CookieRun: Kingdom superan los 300 mil millones de wones, así que seguramente fue una decisión tomada comparando las ventas esperadas de 36 horas de downtime con el monto de compensación a pagar después del rollback.
Creo que también influyó hasta cierto punto que se trate de una organización con una cultura de desarrollo muy enfocada en resolver problemas.
Si fuera yo, todavía no sé bien qué decisión habría tomado.
En los juegos de hoy en día, especialmente en los que tienen mecánicas de gacha aleatorio, un rollback es algo que de verdad solo se puede usar en el peor de los casos... A menos que sea como el juego de la empresa L, al que no le importa su imagen, es prácticamente imposible; por eso, en este caso más bien no hicieron rollback y después dieron una compensación grande, así que los usuarios hasta bromeaban diciendo: “si nos faltan recursos, ¿no se volverá a caer el servidor otra vez?”. Yo creo que fue la decisión correcta.
Como es un juego, da la impresión de que si hubieran hecho un rollback a 36 horas antes, podría haber habido muchas pérdidas económicas relacionadas con el efectivo del juego.
Yo también voto por que no parece una decisión correcta desde el punto de vista del negocio.
Un error de configuración no intencional (este es el error humano absurdo más crítico. Haber hecho de esta forma una modificación enorme que impedía que funcionara la réplica; ni trayendo a todos los desarrolladores que diseñaron la DB se puede recuperar esto).
Así que, como no podían perder todos los datos... renunciando incluso a la consistencia de los datos más recientes, fueron a buscar directamente los datos de la DB en su forma binaria final guardada (7 TB) y escribieron un programa en Go para convertir eso a CSV... ?
Aunque hagan muy bien ese programa de conversión en Go, ¿de verdad qué sentido tendría...?
Uf... de solo pensarlo da desesperación. ¿Por qué tuvo que llegar a esto...?
Lo más importante sería reforzar el proceso para que no ocurra este tipo de error humano. Mejor ni hablar de lo mucho que debieron sufrir manejando la caída y convirtiendo el binario.
¿Hay alguna otra razón para no contar este tipo de historias? Publicar el postmortem en sí mismo ya tiene valor.
En mi opinión, si de verdad se quisiera escribir un artículo útil, ¿no debería tener un título así?
"Análisis de la causa del error que impidió formar el clúster por una mala configuración de nodos y lecciones aprendidas"
Ese es un tema que se puede tratar en un texto aparte, y el “análisis de la causa de la falla” y el “proceso de resolución de la falla” son temas distintos; ambos son importantes, así que me cuesta entender que se le reste valor al texto por no incluir el “análisis de la causa de la falla”...
Podrían decir que estaría aún mejor si después también escribiera un texto de seguimiento sobre el análisis de la causa, pero decir antes de eso que no tiene valor no me parece una buena actitud.
Estrictamente hablando, no fue un "proceso de resolución de incidentes", sino más bien una "labor manual para recuperar datos incompletos". Solo logramos reducir un poco el alcance de la pérdida, más o menos eso.
¿Dónde dice el texto de arriba que la recuperación de datos fue “incompleta”? Al menos por lo que dice ese texto, se logró una recuperación completa. Y además, si recuperar una base de datos que se volaron no es resolver una incidencia, entonces ¿qué lo es? ¿Después de ese incidente ese servicio siguió operando tal cual o cerró sus operaciones?
¿Pero eso no es una razón para no contar esta historia, no?
Vaya, sí que se te hace difícil la vida.