Construyendo un servicio web de alta disponibilidad sin base de datos

Construyendo un servicio web de alta disponibilidad sin base de datos

Exploración

• En el caso de una startup nueva, normalmente se eligen frameworks web como Rails, Django o Node, y bases de datos como MySQL, PostgreSQL o MongoDB
• Pero, ¿qué pasaría si se pudiera combinar el servicio web y la instancia de base de datos en una sola cosa? Es posible abordar esto almacenando todos los datos en RAM
• Si se usa la RAM como base de datos, ya no hace falta serializar los datos mediante consultas SQL
• Los índices pueden implementarse usando tablas hash en memoria
• Las tareas en segundo plano pueden manejarse como hilos dentro de un proceso grande
• Si el proceso falla, es posible recuperarlo tomando snapshots periódicos de la RAM y registrando los cambios en disco

Escalado

• Cuando aparecen clientes que requieren alta disponibilidad, los servidores se replican usando el algoritmo de consenso Raft
• Si el servidor líder se cae, se elige un nuevo líder para procesar las solicitudes
• Con este método, es posible hacer despliegues rolling sin reiniciar los servidores

Extracción

• Cuando aumenta la cantidad de clientes grandes, el servicio web puede dividirse mediante sharding
• Se proporciona un clúster dedicado a cada cliente enterprise
• El principal cuello de botella puede ser el rendimiento del hilo de commit

Nuestro stack

• Uso de Common Lisp: ofrece un excelente soporte para multihilo y es adecuado para hot reloading de código
• Uso de bknr.datastore y bknr.cluster: se usa la librería Braft de Baidu para implementar Raft
• Uso de EFS para almacenar archivos de imagen: facilita más el manejo de errores y las pruebas que S3

Resumen

• Esta arquitectura es adecuada para startups nuevas, y con Common Lisp muchas herramientas ya están listas
• Agradecimientos a las contribuciones de bknr.datastore, Braft y Raft

Resumen de GN⁺

• Este artículo presenta una nueva arquitectura para construir un servicio web de alta disponibilidad sin base de datos
• Usa RAM como base de datos y garantiza alta disponibilidad mediante el algoritmo de consenso Raft
• Usa Common Lisp para soportar multihilo y hot reloading de código
• Esta arquitectura es adecuada para startups nuevas y permite desarrollo y depuración rápidos
• Proyectos con funciones similares incluyen Redis y Memcached

[GN⁺]

Opiniones de Hacker News

• Es raro crear tu propio registro de transacciones en lugar de usar SQLite

  • Si los datos caben en un solo servidor, es mejor simplemente ejecutar la base de datos en ese servidor
  • Si los datos caben en RAM, usar un ramdisk y replicar al almacenamiento persistente con herramientas estándar es más simple

• Crear tu propia base de datos en memoria sin usar MySQL, Postgres, Redis o MongoDB es complejo

  • Hay que serializar las transacciones y escribirlas en disco
  • Hay que sincronizar el registro de transacciones entre servidores web y actualizar la base de datos en memoria
  • Hay que escribir un algoritmo de resolución de conflictos
  • Hay que hacer sharding de los servidores web por tenant y escribir una capa de balanceo de carga

• No querer aprender los aspectos básicos de MySQL o Postgres es una pérdida de tiempo

  • Al ejecutarlo en un proveedor de nube pública, con el ajuste básico se pueden resolver problemas de concurrencia
  • Agregar 10 millones de filas no es un gran problema
  • Es más inteligente esperar a que llegue una situación peor y resolverlo entonces

• Es una arquitectura similar a la de HashiCorp con Nomad, Consul y Vault

  • La experiencia de desarrollo es buena
  • Se puede configurar el estado en memoria como uno quiera
  • No es adecuada para una startup nueva
  • Las actualizaciones son especialmente difíciles

• Existe el malentendido de que la RAM es muy barata

  • El rendimiento de SSD y vCPU ha mejorado mucho, pero el precio de la RAM no ha bajado tanto
  • El precio de la DRAM fluctúa cíclicamente, y recién hace poco se abarató un poco

• He visto proyectos que usan directorios del sistema de archivos como tablas y archivos JSON como filas

  • Consideraron Redis, Mongo y Postgres, pero terminaron construyendo su propia base de datos
  • Usar tokens innovadores para construir una base de datos es ineficiente

• Usar una base de datos relacional es más estable

  • Tiene redundancia integrada, registro de transacciones, respaldo y recuperación
  • En la mayoría de los casos, conviene usar una base de datos

• Implementaron su propia capa de consenso Raft para evitar cosas complejas

  • Usar Redis podría ser más simple

• Las apps modernas de escritorio y móviles suelen usar bases de datos como SQLite

  • El almacenamiento relacional de datos y las consultas son útiles

• Construir tu propia base de datos en memoria no es más simple que instalar Postgres o SQLite

  • Es más fácil escribir SQL que escribir código de concurrencia