Cada cliente debería tener una instancia de Redis con su propia contraseña y su propio límite de memoria. En un servidor compartido, los clientes pueden leer y vaciar los datos de los demás, y un sitio grande puede desplazar la caché de todos los otros.
¿Por qué es un problema un servidor Redis compartido?
Redis está diseñado para clientes de confianza dentro de entornos de confianza, como indica su documentación de seguridad. Los clientes de un hosting ejecutan los plugins que eligen, por lo que no cumplen esa condición. Un servidor compartido suele tener una sola contraseña para todos.
| Riesgo | Servidor compartido | Instancia por cliente |
|---|---|---|
| Riesgo: Acceso | Servidor compartido: Quien se conecta puede leer todas las claves, incluidas las sesiones y opciones de otros sitios | Instancia por cliente: Una contraseña abre los datos de un solo cliente |
| Riesgo: Vaciados | Servidor compartido: FLUSHDB o FLUSHALL vacía la caché de todos los clientes del servidor | Instancia por cliente: Un vaciado afecta a un solo cliente |
| Riesgo: Memoria | Servidor compartido: maxmemory se aplica a todo el servidor, y una tienda grande expulsa las claves de los sitios pequeños | Instancia por cliente: Cada instancia tiene su propio límite y su propia política |
| Riesgo: Memoria llena con noeviction | Servidor compartido: Las escrituras de todos los clientes fallan | Instancia por cliente: Las escrituras de un solo cliente fallan |
| Riesgo: Monitorización | Servidor compartido: La tasa de aciertos, la memoria y las conexiones no se pueden distinguir por cliente | Instancia por cliente: Cada instancia tiene sus propias cifras |
| Riesgo: Reinicios y actualizaciones | Servidor compartido: Afectan a todos los clientes a la vez | Instancia por cliente: Pueden hacerse instancia por instancia |
| Riesgo: Operación | Servidor compartido: Un solo proceso que mantener | Instancia por cliente: Un proceso por cliente, lo que requiere automatización |
Las bases de datos numeradas no añaden separación. SELECT cambia entre ellas, y la documentación de Redis desaconseja usarlas para aplicaciones no relacionadas.
¿Bastan los usuarios ACL?
Redis 6 incorporó los usuarios ACL, y un patrón de claves como ~tenant1:* puede limitar a un usuario a un prefijo. Los patrones de claves solo cubren los comandos que nombran claves. FLUSHALL, FLUSHDB y SWAPDB hay que retirarlos de cada usuario de forma explícita.
Las ACL resuelven el problema del acceso, pero la memoria, la expulsión y los reinicios siguen compartidos. Sirven para un proveedor que ejecuta una aplicación de confianza por usuario. Para clientes que instalan sus propios plugins, una instancia separada es el límite más claro.
¿Qué debe tener una instancia de Redis por cliente?
- Su propia contraseña, generada, visible solo para el cliente y rotable en cualquier momento.
- Su propio maxmemory, dimensionado para el cliente, con una política de expulsión como allkeys-lru, para que una caché llena siga aceptando escrituras.
- Una conexión cifrada o interna. El tráfico de Redis transporta opciones, sesiones y datos personales, y debe circular por una red interna o a través de TLS.
- Monitorización de la memoria, las conexiones, la tasa de aciertos y el tiempo de actividad por instancia, visible para el proveedor y para el cliente.
- Límites por cliente para el número de instancias y la memoria total, y un límite de capacidad por servidor.
- Persistencia solo donde haga falta. Un Object Cache puede reconstruirse, así que los archivos RDB y AOF suelen añadir solo escrituras en disco.
¿Cómo se conecta un sitio a su instancia?
El cliente necesita host, puerto, contraseña y el ajuste de TLS. La mayoría de los plugins de Redis para WordPress leen estos datos de constantes en wp-config.php, así que un panel que muestre un bloque listo para copiar ahorra consultas al soporte.
Varios sitios de un mismo cliente pueden compartir una instancia si cada uno tiene su propio prefijo de claves. Un vaciado en una instancia así debe limitarse a ese prefijo.
¿Cómo puede construirlo un proveedor?
Para la parte de Redis bastan contenedores o unidades de systemd con una configuración por cliente. El trabajo está en el aprovisionamiento, la rotación de contraseñas, los límites y una vista para el cliente.
Para ISPConfig, CachePilot Server de CMS ADMINS, actualmente en beta, cubre estas partes. Los clientes crean instancias en el panel, listas en unos 60 segundos, con 128, 256 o 512 MB. Ejecuta Redis estándar por cliente y no incluye usuarios ACL, sockets Unix, copias de seguridad ni configuración automática de WordPress. La página de CachePilot Server detalla el alcance completo.
Fuentes
- Documentación de Redis, seguridad: clientes de confianza, acceso a la red, TLS.
- Documentación de Redis, ACL: patrones de claves y comandos sin argumentos de clave.
- Documentación de Redis, SELECT: bases de datos numeradas.
- Documentación de Redis, expulsión de claves: maxmemory y políticas.
- README.md y CHANGELOG.md de la extensión de ISPConfig, versiones 1.0.0 y 1.1.0.
- redis_instance.tform.php de la extensión de ISPConfig: tamaños de memoria.
