Estrategia de migración de base de datos para contenedores docker en AWS ECS

7

Estoy trabajando en la creación de un conjunto de microservicios en Docker (usando .net core y AWS RDS como backbone, pero eso no es relevante).

Como parte del despliegue, el contenedor antiguo y el nuevo contenedor coexisten durante un corto período de tiempo (generalmente en menos de 30 segundos) para garantizar que no haya tiempo de inactividad.

Sin embargo, esto significa que si mi esquema es incompatible con la versión anterior del microservicio (o el esquema anterior es incompatible con la nueva versión), un conjunto de contenedores no funcionará correctamente.

Mis pensamientos son:

  1. Realizar migraciones compatibles con versiones anteriores solamente. Es decir, no hay delete column migraciones. No estoy impresionado con este enfoque, ya que daría lugar a una acumulación de desorden (concedido, con el tamaño del microservicio no será tan malo, pero será un esquema desagradable en un par de años)

  2. Obsoleto: elimina implementaciones de dos pasos. En v2, eliminamos el código que consume el esquema, pero no el esquema en sí, y en v3 eliminamos el esquema. El problema aquí es que debemos hacer dos implementaciones consecutivas seguidas, lo que parece estúpido, o asegurarnos de que los desarrolladores recuerden verificar esas eliminaciones en la próxima versión, lo que es potencialmente propenso a errores humanos y dará lugar a que se acumule el desorden nuevamente. p>

  3. Tiene dos tipos de implementaciones: de ruptura y no de ruptura; con la implementación de última hora, hacer el servicio de parada de la vieja escuela, migrar, abrir un nuevo servicio. El problema aquí es que hay tiempo de inactividad para los usuarios finales.

¿Con qué irías y por qué? (O, si ya tienes algo más, por favor díselo).

    
pregunta zaitsman 24.09.2017 - 01:27

2 respuestas

3

Un cambio solo debe cambiar lo que es necesario. Eliminar las columnas no utilizadas en un esquema de base de datos no es un cambio necesario, es un tipo de cambio no funcional y de mantenimiento. Por lo tanto, no hay razón para bloquear esos cambios para que ocurran en la misma iteración de cualquier servicio (o, para el caso, ser parte de una implementación de servicio).

Si bien es cierto que podría desarrollar un sistema que imponga una migración en cada implementación después de un tipo de implementación de "cambio radical", me parece un poco de optimización excesiva o YAGNI.

La forma en que lo manejaría en una de mis aplicaciones es simplemente agregar el paso a mi proceso de control de cambios, en el que cualquier implementación de microservicio no debe interrumpirse como en tu # 1, pero seguiría el rastro de qué columnas son candidatas a la eliminación, y realizan una limpieza trimestral (o así) (con la participación de los usuarios comerciales), posiblemente en un horario continuo, de manera que cualquier columna eliminada propuesta tenga que transcurrir cierto tiempo antes de que en realidad elimínelo, b / c, usted sabe que en muchas configuraciones de negocios, lo que estamos seguros que nunca volveremos a necesitar es en realidad una característica que vemos solicitada en aproximadamente seis meses.

    
respondido por el Paul 24.09.2017 - 20:33
1
  1. ¿Cuál es su "presupuesto de error"? es decir, ¿cuánto tiempo de inactividad puede permitirse tener y aún estar dentro del acuerdo de nivel de servicio acordado? Si el tiempo de actividad de su SLA es de 99.95% y su servicio está sirviendo a 99.999%, entonces usted puede hacerlo.

  2. Si hay 30 segundos de tiempo de inactividad, ¿cuánto de SLA reduce eso? Si se reduce significativamente, entonces no puede haber lanzamientos constantes, pero si está planeando un lanzamiento mensual, 30 segundos de tiempo de inactividad de 30 días no dañarán los números acordados.

  3. ¿Son realmente 30 segundos? Si la aplicación es errónea, ¿cuánto tiempo lleva la reversión? ¿Existe una estrategia de implementación azul-verde?

  4. Desde arriba, ¿es necesario cero tiempo de inactividad? Si es así, entonces el paso de "eliminación obsoleta" es necesario. Lo bueno es que se están separando las preocupaciones en cada paso para que pueda manejar cada caso de falla (es decir, la estrategia de reversión)

El concepto de SLA y el presupuesto de error provienen de este libro SRE de Google

En mi experiencia, esta es una forma de hacerlo:

  1. Versión de su API para que pueda desaprobar / eliminar ese código, luego puede BORRAR columnas

  2. Cada conjunto de códigos tiene una versión de migración mínima, de modo que ese código no se puede implementar a menos que se implemente la versión de migración mínima.

  3. La migración siempre es compatible con versiones anteriores. Entiendo su preocupación acerca de los "pasos de twp obsoletos-eliminados", pero ¿la mayoría del software no maneja la compatibilidad con versiones anteriores (es decir, en desuso, eliminación)?

respondido por el tsuz 28.04.2018 - 03:22

Lea otras preguntas en las etiquetas