Hay algunos problemas en la publicación cruzada debido al dialecto de descuento en la publicación original. Especialmente no se muestran los diagramas que existen en la publicación original. Así que por favor revise el original también si está interesado. Creo que el original es más comprensible

Actualización de HBase además de Event Sourcing y arquitectura CQRS en 3 semanas

TL;RD

Utilizamos una estrategia de implementación azul-verde para la actualización de la versión de HBase además del sistema de arquitectura Event Sourcing y CQRS.
El enfoque de implementación funcionó bastante bien y tomó solo 3 semanas en total para lograr el objetivo del proyecto. Esta experiencia fue nueva y emocionante para nosotros. Así que quiero compartirlo :)

Acerca de la actualización de la base de datos

Una actualización de la base de datos siempre es problemática y cada vez que se enfrenta a tales circunstancias en escenarios de producción, estaría súper nervioso (diría 100 veces en comparación con otras operaciones de producción con las que está lidiando) .

Este sentimiento es difícil de compartir con personas que no tienen la experiencia o exposición en la operación de entornos de base de datos. Y creo que el 99,9% de las personas estaría de acuerdo si tiene la experiencia y ha pasado por momentos difíciles al tratar con las operaciones relacionadas con la base de datos. Es arriesgado y cuesta mucho, pero actualizarse en sí no significa que aporte un nuevo valor al producto y aunque no se prioriza en muchos casos a no ser que haya algún motivo de urgencia.

Al mismo tiempo, es un gran riesgo oculto si la base de datos se vuelve "intocable" y cómo lidiar con este problema ha sido un tema recurrente, muchos desarrolladores y operadores han estado luchando con tales situaciones

Enfoque de actualización

En general, tendría dos opciones.

actualización gradual

Una es una actualización continua. Actualizar la versión de la base de datos una por una de manera secuencial.
Encontré una buena explicación aquí. Lea esto si no está familiarizado con la palabra.

¿Qué significa una actualización gradual en el desarrollo de software?

Ventajas
- Los datos están en un solo lugar. Por lo tanto, no necesita pensar en cómo sincronizar los datos entre diferentes clústeres y cómo garantizar que la sincronización funcione perfectamente.
Contras
- Una vez finalizada la actualización, no hay una manera fácil de revertirla. Entonces, si la actualización desencadena un problema de rendimiento de alguna manera, estaría en un gran problema.
- La base de datos de ejecución prolongada tiene un estado inesperado que no puede reproducir en el entorno de prueba. A veces es necesario lidiar con el problema en lo que respecta a la producción. Y esa posibilidad te pone realmente nervioso.

implementación azul-verde

El otro es un despliegue azul-verde. En este caso, debe aprovisionar el clúster de base de datos actualizado por separado y cambiar la aplicación para usar la nueva en algún momento.
Consulte esta publicación de blog si no está familiarizado con la palabra "implementación azul-verde".

Despliegue AzulVerde

Creo que este enfoque está muy extendido en la implementación de aplicaciones web, pero si reemplaza la palabra "enrutador" por "aplicación" y "servidor web" por "base de datos", se puede aplicar el mismo enfoque a la actualización de la base de datos.

Ventajas
- No toca la base de datos de producción en ejecución durante la actualización. Eso hace que su vida sea mucho más fácil en comparación con el enfoque de actualización progresiva.
- Puede volver fácilmente al clúster anterior cuando ocurre algún problema inesperado. Y también puede distribuir las solicitudes gradualmente para que pueda minimizar el alcance en caso de que tenga algún problema (para hacer esto, como en "Contras", debe sincronizar los datos del nuevo clúster con el antiguo)
- Debido al factor anterior, puede acortar un poco las pruebas de carga en el entorno de prueba y puede continuar con el proyecto rápidamente.
Contras
- Debe asegurarse de que los datos estén sincronizados entre ambos clústeres de bases de datos. No solo del clúster anterior al clúster nuevo, sino también del clúster nuevo al clúster anterior si desea tener una manera fácil de revertir después de la actualización. Pero la replicación mutua de datos es bastante difícil en muchos casos. Puede ser posible escribir en dos clústeres en cada operación, pero debe prepararse cuando solo un clúster está inactivo y la operación en ese clúster solo falla. Ese manejo sería realmente complicado.
- Debe tener servidores del doble del tamaño mientras ejecuta ambos clústeres. Eso costará algo de dinero y puede ser difícil si su sistema no está en la infraestructura de la nube.

Nuestro enfoque

Básicamente, nuestro enfoque es la implementación azul-verde. Y debido a que tenemos a Kafka al frente como bus de abastecimiento de eventos, fue mucho más fácil lidiar con el problema de sincronización de datos en "Contras" mencionado anteriormente.

Arquitectura actual

Primero, permítanme presentarles la arquitectura básica. Por cierto, llamamos a todo el subsistema de mensajes de chat "Falcon". Es por eso que el ícono del halcón está en el diagrama.

cuando un usuario final publica un mensaje de chat, write-api coloca los datos del mensaje en Kafka
read-model-updater ("rmu" en resumen) obtiene datos de Kafka, los convierte a read-model y los coloca en HBase
cuando un usuario final lee mensajes de chat, la API de lectura extrae datos de mensajes de HBase

No explico por qué elegimos CQRS en esta publicación. Por lo tanto, consulte las diapositivas a continuación si desea obtener información detallada o si no está familiarizado con el concepto de CQRS.
Kafka Summit SF 2017:servicios de mensajería escalables y resistentes en todo el mundo con Kafka y Kafka Streams
Servicios de mensajería escalables y resistentes en todo el mundo de CQRS y Event Sourcing mediante Akka, Kafka Streams y HBase

Flujo de actualización de la base de datos

Ahora, voy a explicar cómo hicimos la actualización de la base de datos sobre esta arquitectura

Paso 1: Prepare nuevos clústeres y realice la restauración inicial desde la copia de seguridad.

Paso 2: Prepare otro consumidor (rmu2 en este diagrama) para sincronizar datos de Kafka con el nuevo clúster de base de datos. Reproducirá eventos antiguos de Kafka desde antes de la restauración inicial. Asegúrese de implementar la idempotencia en su consumidor. Quiero decir, el sistema debe funcionar correctamente incluso si el mismo evento se consume más de una vez.

Paso 3: Cuando el nuevo consumidor (rmu2) se haya puesto al día con los últimos mensajes de Kafka, prepare otra API de lectura extrayendo datos del nuevo clúster de base de datos. Y envíe solicitudes a la nueva API de lectura gradualmente.

Habría alguna diferencia de estado entre el clúster anterior y el nuevo, incluso si la sincronización de datos finaliza en un par de milisegundos. Tuvimos un pequeño problema debido a esta diferencia, por lo que debe confirmar y ejecutar una verificación de evaluación para ver qué tipo de problema puede desencadenarse a través de la diferencia entre los clústeres y la lógica de su aplicación de antemano. O si tiene algunas buenas capas frente a read-api para distribuir la solicitud de acuerdo con el atributo del usuario o algo (por ejemplo, enrutamiento a través de Nginx o Envoy como proxy), puede establecer la regla adecuada allí y la diferencia se puede manejar de manera eficiente y no será un problema.

Y en la retrospectiva de este proyecto, notamos que si puede duplicar las solicitudes de la API existente a la API nueva, puede realizar las pruebas de carga utilizando el tráfico de producción sin afectar a los usuarios finales.

Paso 4: Cambie a la nueva API de lectura al 100 % y apague los clústeres y las aplicaciones antiguos cuando esté seguro de que todo funciona a la perfección.

Por qué creo que este enfoque es mejor

Permítanme explicar la diferencia con el enfoque azul-verde normal. Un problema en el blue-green normal es que debe asegurarse de que los datos estén sincronizados en ambos clústeres, idealmente no solo antes de la actualización sino también después de la actualización. En este enfoque, en lugar de utilizar la funcionalidad de replicación que proporciona la base de datos, las actualizaciones de la base de datos se aplican por separado a través de la aplicación que escribimos y preparamos. Este enfoque nos trae muchos méritos.

Primero, debido a que funcionan por separado, no es necesario que te preocupes por cómo se sincronizan los datos en cada fase. Especialmente, necesitará un esfuerzo adicional (y bastante difícil en la mayoría de los casos) para sincronizar los datos del nuevo clúster con el antiguo si desea tener una manera fácil de revertir después de la actualización. Pero en este enfoque, solo están trabajando de forma independiente. Por lo tanto, puede volver a usar los antiguos en caso de que ocurra algún problema inesperado después de la actualización.

En segundo lugar, no necesita preocuparse por la compatibilidad de versiones entre los clústeres antiguos y los clústeres nuevos. Si usa la funcionalidad de sincronización de datos de clúster que proporciona la base de datos, podría haber alguna restricción de versión y un problema de compatibilidad que puede ocurrir en algunos casos extremos. Pero en este enfoque, todo lo que necesita hacer es preparar una aplicación independiente que coloque datos en cada base de datos. Creo que es el problema que puedes resolver mucho más fácilmente en la mayoría de los casos. Y en teoría, no solo actualiza la versión de la base de datos, sino que también puede cambiar el nuevo clúster a uno completamente diferente (por ejemplo, DynamoDB) utilizando el mismo enfoque. En ese caso, no puede usar los datos de respaldo para la configuración inicial y debe preparar el programa de migración de datos inicial. Eso llevará algo de tiempo, pero creo que es el elemento razonable con el que lidiar.

Conclusión

Los temas de CQRS y abastecimiento de eventos a menudo se tratan en la arquitectura de software. Desde un punto de vista operativo, tener una capa más como bus de eventos aumenta la complejidad de la infraestructura y el costo de operación. Hablando honestamente, no me gustó mucho este enfoque desde esa vista anterior. Pero notamos que también cambia la forma en que operamos la infraestructura y nos brinda tranquilidad en la operación de la base de datos. Y sí, me divierto mucho con CQRS y el abastecimiento de eventos ahora :)

Siguiente desafío

Quizás se pregunte qué actualizaríamos Kafka (bus de abastecimiento de eventos)? Sí, ese será nuestro próximo desafío. Espero que exista un mejor enfoque que la actualización gradual normal y la implementación azul-verde. ¡La vida del ingeniero continúa!