Gestión de esquemas con Skeema

Nota: Esta publicación proviene del equipo de ingeniería de SendGrid. Para obtener más publicaciones de ingeniería técnica como esta, consulte nuestra lista de blogs técnicos.

La gestión del esquema de la base de datos abarca desde un salvaje oeste en el que cualquiera puede "hacerlo en vivo" en el proceso de producción hasta un proceso de revisión de varios equipos y varios pasos al estilo cascada en el que solo una persona ungida puede tocar la base de datos de producción.

A medida que los datos contenidos en bases de datos relacionales se vuelven más valiosos para una empresa y la disponibilidad de la base de datos se vuelve más importante para el negocio, surgen barreras para posibles cambios de esquema.

Al principio, los administradores de bases de datos (DBA) se convirtieron en los guardianes de la base de datos para proteger la base de datos de las cosas malas que sucedían. Pero tener un DBA de la vieja escuela sentado entre los desarrolladores y la base de datos de su aplicación puede causar una ralentización significativa en el ciclo de vida de desarrollo de una aplicación, crear silos de desarrollo y operaciones y generar fricción entre los equipos.

En el mundo actual orientado al desarrollo de operaciones de microservicios, los desarrolladores deben poder administrar los cambios en el esquema de la base de datos por sí mismos porque son sus datos y son los responsables en última instancia del rendimiento y el tiempo de actividad de la aplicación. Los DBA y los equipos de operaciones deben proporcionar las herramientas y el asesoramiento adecuados para ayudar a los equipos de desarrollo a convertirse en propietarios de su base de datos.

Cómo gestionamos el esquema

Nuestro proceso de administración de esquemas actual utiliza un único repositorio de Git para almacenar el esquema inicial de todos nuestros clústeres de bases de datos y contiene todos los cambios posteriores a ese esquema a medida que se aplican modificaciones/creaciones y eliminaciones de tablas individuales:

• Un desarrollador realiza un cambio de esquema localmente y genera una declaración de modificación/creación/eliminación y la agrega como una solicitud de extracción a una rama de integración.
• Se crea un conjunto de tickets de Jira para el equipo de operaciones de datos para revisar y aplicar los cambios de esquema a nuestros entornos de prueba/escenario y producción.
• Un miembro del equipo de operaciones de datos revisa el cambio solicitado y aplica el cambio al entorno de prueba/preparación y fusiona el PR con la rama de integración.
• El desarrollador solicitante prueba el cambio en nuestros entornos de prueba/preparación y aprueba el cambio para que se envíe a producción.
• Finalmente, Data Operations fusiona la rama de integración para dominar y aplica el cambio de esquema al entorno de producción.

Dado el valor de los datos almacenados en nuestras bases de datos y el deseo de tener esas bases de datos funcionando bien todo el tiempo, nos decidimos por esta secuencia bizantina de eventos para protegernos de nosotros mismos.

Proteger la base de datos es una cosa, pero este proceso presenta varios obstáculos para realizar cambios en el esquema de manera confiable y eficiente:

• La revisión y la realización de cambios en el esquema ocurren dos veces por semana y pueden descarrilarse fácilmente cuando varios equipos trabajan en diferentes bases de datos en el mismo repositorio de Git y todos dependen de alguien en el equipo de operaciones de datos para revisar y realizar cambios en varios entornos.
• Tener un repositorio para todos los esquemas de bases de datos relacionales puede generar procesos de lanzamiento desafiantes. Un cambio en un esquema que está listo para la producción no puede ir a la producción si hay otros cambios de esquema que no están listos para pasar a la producción, pero que están esperando pruebas adicionales.
• El equipo de operaciones de datos, que es un equipo pequeño, se convierte en un cuello de botella al tratar de administrar qué cambio puede y no puede pasar a producción y cuándo. Los conflictos de programación y la disponibilidad del personal realmente pueden ralentizar el lanzamiento de nuevas funciones o correcciones a las aplicaciones actuales.
• Estamos aplicando manualmente estos cambios a los sistemas de producción utilizando comentarios en solicitudes de extracción y tickets de Jira; a veces copiar y pegar puede salir terriblemente mal.

Entra Skeema (y algunos ayudantes)

Para eliminar estos obstáculos del proceso, hacer que los cambios de esquema sean menos propensos a errores humanos, permitir que los desarrolladores administren el esquema de su propia aplicación y aumentar potencialmente la velocidad de desarrollo, el equipo de operaciones de datos se ha esforzado mucho en automatizar y simplificar la administración de esquema de base de datos

Automatizamos la aplicación de cambios de esquema desde el desarrollo local hasta la producción utilizando nuestras herramientas existentes, Git, Buildkite CI y pt-online-schema-change, con la adición de una más, Skeema.

La idea es dividir nuestro repositorio monolítico de esquemas de base de datos en repositorios de esquemas individuales, uno por clúster de base de datos, y permitir que los desarrolladores realicen sus propios cambios de esquema en un entorno que les resulte familiar. También queremos tener medidas de protección sensatas para ayudar a los desarrolladores a buscar asistencia adicional para realizar cambios de esquema grandes, complejos o potencialmente destructivos.

Skeema es una herramienta CLI que administra el esquema MySQL de forma declarativa mediante SQL.

Puede generar el lenguaje de definición de datos (DDL) para cada tabla en una base de datos y exportar el DDL a un sistema de archivos local para la integración con un repositorio de seguimiento a través de Git. Skeema puede comparar los archivos SQL en un repositorio Git con una base de datos MySQL en vivo y generar esas diferencias como declaraciones DDL.

También se puede configurar para usar la herramienta pt-online-schema-change de Percona y formatear el comando pt-online-schema-change necesario para hacer coincidir el esquema de la base de datos MySQL en ejecución con el esquema definido en el repositorio de Git.

Skeema también puede administrar el esquema en varios entornos, como local, pruebas y producción con diferentes configuraciones en cada uno. Y finalmente, se puede adaptar fácilmente a un flujo de trabajo basado en solicitudes de incorporación de cambios.

La creación de repositorios de esquemas de bases de datos MySQL individuales desglosará nuestro repositorio Git monolítico db-schema actual y permitirá a los desarrolladores en equipos separados administrar el esquema MySQL de su aplicación en su propio repositorio en lugar de un repositorio compartido (db-schema).

Tener un repositorio separado para cada esquema de base de datos permitirá una mayor autonomía al equipo de desarrollo de aplicaciones. Esto elimina la necesidad de coordinar todos los cambios de esquema en un cronograma rígido y permite que los cambios pasen a producción según lo desee el equipo de la aplicación.

Un componente vital de la automatización de este proceso es la canalización de CI de Buildkite. Creamos una canalización que:

• Comprueba si hay errores de sintaxis SQL
• Crea un servidor MySQL de prueba utilizando la rama maestra actual del esquema de la base de datos y prueba la aplicación de los cambios en la solicitud de extracción (PR)
• Verifique las diferencias y aplique los cambios de PR a nuestro entorno de prueba MySQL
• Verifique las diferencias y aplique los cambios de PR a nuestro entorno de prueba y genere algunas estadísticas de tabla desde el entorno de producción.

Las estadísticas de salida de producción son el tamaño de la tabla en el disco y el recuento estimado de filas. Estas estadísticas pueden ayudar a determinar si el cambio de esquema podría causar algún nivel de interrupción del servicio y podría requerir un manejo especial. Una vez que el PR se fusiona con el maestro, la canalización de buildkite verifica las diferencias entre la rama maestra y lo que se ejecuta en producción.

Si las diferencias son los cambios esperados del PR, el desarrollador puede desbloquear este paso final y Skeema aplica los cambios al clúster de la base de datos MySQL de producción. Cada uno de estos pasos es un paso de bloqueo que requiere la aprobación del equipo de ingeniería responsable del cambio solicitado antes de pasar al siguiente paso.

En lo que respecta a las medidas de seguridad, hemos configurado Skeema para que no permita cambios de esquema destructivos en producción de forma predeterminada.

Se permiten cambios destructivos en nuestros entornos de prueba y ensayo.

También configuramos Skeema para usar pt-online-schema-change para realizar cambios de esquema. Esta es la misma herramienta de cambio de esquema con la que está familiarizado el equipo de DataOps y que ha estado en uso en SendGrid durante muchos años. Hemos desarrollado un conjunto de opciones razonables para que pt-online-schema-change revierta sus cambios si la replicación se retrasa o los subprocesos activos en la base de datos se vuelven excesivos.

Tener Skeema configurado de esta manera elimina los posibles errores de tener pasos manuales para la aplicación y la codificación manual de los comandos pt-online-schema-change por parte de los miembros del equipo de DataOps.

Con la adición de protecciones programáticas, los equipos individuales pueden ser responsables de la gestión de sus esquemas de base de datos MySQL y la aplicación de esos cambios a los entornos de preproducción y producción con relativa seguridad. Si se alcanzan las medidas de seguridad, el cambio de esquema fallará y se revertirá. Los motivos de la falla del cambio de esquema se envían a los registros de compilación para una revisión adicional.

Permitir que los desarrolladores guíen sus cambios desde la prueba local en una computadora portátil hasta la producción mejora en gran medida la autonomía del desarrollador y la propiedad de la base de datos que respalda su aplicación. La automatización e integración de Skeema en nuestro proceso de administración de bases de datos MySQL cubre fácilmente alrededor del noventa por ciento de nuestras tareas generales de administración de cambios de esquema.

La mayoría de los cambios de esquema son para agregar columnas, cambiar campos de enumeración, cambiar valores predeterminados y agregar índices. El diez por ciento restante de los cambios de esquema se relacionan con casos especiales de tablas grandes, bases de datos muy activas o tablas particionadas. A partir de esta publicación, Skeema aún no se ocupa de realizar cambios de esquema en las tablas particionadas, pero escuché que es una adición solicitada con frecuencia y el desarrollador de Skeema está solicitando activamente ayuda para implementar esa función.

La combinación de Git, pt-online-schema-change, Skeema y una canalización de Buildkite CI brinda un proceso programático confiable y repetible para los cambios de esquema de la base de datos MySQL. Permite a los desarrolladores gestionar de forma segura el esquema de sus bases de datos y controlar la rapidez con la que se implementan las funciones y las correcciones en la producción.

La inclusión de las medidas de seguridad adecuadas en los archivos de configuración para Skeema y pt-online-schema change proporciona una medida de confianza para los desarrolladores que implementan cambios de esquema y brinda comentarios valiosos sobre las posibles formas de proceder con el cambio de esquema si se alcanzan esas medidas de seguridad.

El equipo de operaciones de datos permanece disponible para ayudar al diez por ciento restante de los casos a los que no se puede aplicar este proceso y trabajará en herramientas adicionales para mejorar este proceso en el futuro.