Una base de datos resiliente para la autoridad de certificación de Fastly
Esta es la última entrada de una serie de publicaciones en las que hablamos sobre cómo creamos Certainly, la nueva autoridad de certificación de confianza pública de Fastly. Ya hemos explicado algunas de las decisiones que tomamos en lo relativo a la arquitectura de Certainly. En el artículo de hoy, vamos a ver una de las principales dificultades que supuso la creación de un entorno efímero en la nube cuyos sistemas se destruyen y reconstruyen de forma automática y periódica.
Al igual que ocurre con otras autoridades de certificación, las operaciones de Certainly dependen de una base de datos sólida, fiable y resiliente. Gracias a su excelente diseño, la arquitectura de la base de datos de Certainly permite almacenar y recuperar datos de certificados de una forma eficiente y, además, ofrece escalabilidad para dar respuesta a las crecientes necesidades de las empresas. En la actualidad, utilizamos MariaDB con el motor de bases de datos InnoDB y la replicación habilitada en todos los centros de datos. La replicación ayuda con la redundancia de datos, facilita la recuperación en caso de desastre y, por consiguiente, nos da confianza en nuestras operaciones, pero esto no ha sido así siempre. Antes utilizábamos la configuración de clústeres MariaDB Galera, con los engorros, la inestabilidad y las dificultades operativas que conllevaba. Como nos daba problemas día sí y día también, al final decidimos pasarnos a la replicación con MariaDB, lo cual supuso una serie de ventajas:
1. Menor complejidad
La arquitectura de clústeres Galera, basada en varios nodos principales, requería que todos los nodos de la base de datos repartidos por nuestras instalaciones estuvieran siempre comunicados para garantizar la homogeneidad y la sincronización de la información. La replicación con MariaDB parte de un diseño con un único nodo principal y varias réplicas. Al haber un solo nodo principal dedicado a la escritura, se simplifican la configuración y el mantenimiento y se reduce la sobrecarga operativa. Esta menor complejidad se ha traducido en una disminución considerable del número de alertas y problemas, así como en una mejora sustancial de la efectividad y la motivación del equipo de Site Reliability Engineering de Certainly.
2. Escalabilidad dinámica
Durante la preparación cara al lanzamiento, teníamos que asegurarnos de que la escalabilidad no fuera un obstáculo a medida que creciera la cantidad de usuarios. El clúster Galera nos ofrecía replicación síncrona de varios nodos principales, pero también tenía sus limitaciones puesto que añadir nuevos nodos al clúster era complejo y laborioso. En cambio, la replicación con MariaDB nos daba flexibilidad para incluir más réplicas de lectura sin que las operaciones del nodo principal se vieran afectadas, de modo que pudimos ampliar las operaciones de lectura en horizontal sin aumentar la carga de trabajo del equipo.
3. Réplicas por caso de uso
El nuevo diseño de la base de datos nos permite crear más réplicas para distintos casos de uso, como operaciones de lectura, copias de seguridad, informes y análisis. A diferencia de lo que ocurre con Galera, añadir o eliminar nodos no afecta a las operaciones, por lo que el principal puede seguir funcionando con la eficiencia habitual.
4. Efimeridad
Una de las piedras angulares de Certainly es la efimeridad. Esto significa que los nodos de la base de datos se reconstruyen desde cero periódicamente. Cuando pensamos en la efimeridad, damos por hecho que se aplica a componentes sin estado y que las bases de datos están diseñadas para almacenar datos de manera persistente, concepto al que hemos dado la vuelta gracias a un innovador diseño de infraestructura que nos proporciona más agilidad, escalabilidad y resiliencia. Como ya hemos dicho, Galera requiere una comunicación constante entre los nodos, cosa que no encajaba muy bien con la naturaleza efímera de nuestra infraestructura. Como los nodos salían del clúster y regresaban a él con frecuencia, Galera tenía que recalcular el cuórum. Si a esto le sumamos factores conocidos, como las copias de seguridad y la conectividad de red, y también algunos elementos sin identificar, el resultado era que Galera no llegaba al cuórum y se cerraba más veces de lo esperado. Si la base de datos no funciona, Certainly tampoco. El nuevo diseño nos da la opción de retirar réplicas de reconstrucciones sin preocuparnos de que eso tenga efectos negativos sobre el nodo principal, por lo que el sistema es indudablemente más sólido.
5. Recuperaciones de fallos sin complicaciones
MariaDB Orchestrator es la solución de código abierto que utilizamos para gestionar las recuperaciones de fallos junto con herramientas especializadas que hemos creado para las comprobaciones del estado, la detección de errores, el deterioro del rendimiento y las recuperaciones de fallos. Orchestrator se encarga de ofrecer una vista precisa y actualizada de la topología del clúster de la base de datos en todo momento, incluidas las funciones de cada nodo (principal o réplica) y las relaciones que existen entre ellos, información que nos ayuda a gestionar las recuperaciones de fallos y mantener la base de datos en buen estado. Por si fuera poco, hace que haya menos probabilidades de pérdidas de datos y divergencias durante una recuperación.
6. Flexibilidad para el futuro
El diseño actual de nuestra base de datos nos da la flexibilidad necesaria para ampliarla y adaptarla a los constantes cambios en el sector de las PKI.
En definitiva, sustituir Galera por la replicación con MariaDB ha contribuido a mejorar la escalabilidad, impulsar el rendimiento y simplificar las aplicaciones. Esta decisión nos ha puesto en una posición idónea para hacer frente a nuevos retos, y estamos convencidos de que contamos con las herramientas necesarias para evolucionar y llegar a clientes de todo el mundo.
