Cómo instalar Redis en un VPS y configurarlo para producción

Definir primero qué papel tendrá Redis

La configuración correcta cambia según el uso. Una caché de páginas puede perder todas sus claves y reconstruirse desde la base principal. Una cola no debería descartar trabajos para liberar RAM. Un almacén de sesiones puede tolerar cierta pérdida según la aplicación, pero expulsar una clave cerrará la sesión de un usuario. Tratar esos tres escenarios como si fueran iguales produce políticas peligrosas.

Antes de instalar, responde cuatro preguntas: ¿Redis es la fuente única de algún dato?, ¿cuánto dato puedes perder al fallar?, ¿qué latencia de recuperación acepta el servicio? y ¿qué ocurrirá cuando alcance el límite de memoria? Esas respuestas determinan persistencia, maxmemory-policy, backups y alertas.

Instalar Redis en Ubuntu

La opción sencilla es utilizar los paquetes de Ubuntu, que se actualizan junto con el sistema. Instala el servidor, habilítalo y confirma la versión activa:

sudo apt update
sudo apt install -y redis-server
sudo systemctl enable --now redis-server
sudo systemctl status redis-server --no-pager
redis-server --version
redis-cli ping

La respuesta esperada al último comando es PONG. Ese resultado solo demuestra que un cliente local pudo llegar al proceso; todavía no confirma aislamiento de red, límites, ACL ni persistencia.

En Ubuntu el archivo principal suele ser /etc/redis/redis.conf. Haz una copia con permisos conservados antes de editarlo:

sudo cp -a /etc/redis/redis.conf /etc/redis/redis.conf.bak
sudo nano /etc/redis/redis.conf

Valida cada cambio en una segunda terminal y usa sudo systemctl restart redis-server únicamente después de revisar la configuración. Un error de sintaxis impide el arranque; la sesión SSH abierta te permitirá restaurar la copia.

Mantener el puerto 6379 fuera de Internet

Si la aplicación vive en el mismo VPS, Redis debe escuchar solo en loopback. Conserva estas directivas:

bind 127.0.0.1 ::1
protected-mode yes
port 6379

Reinicia y comprueba la dirección real:

sudo systemctl restart redis-server
sudo ss -ltnp | grep 6379

Deberías ver 127.0.0.1:6379 y, si IPv6 está habilitado, [::1]:6379; no 0.0.0.0:6379. No abras UFW porque la aplicación local no atraviesa el firewall para conectarse a loopback.

Cuando el cliente está en otra máquina, usa una red privada o un túnel WireGuard y enlaza Redis solo a la IP privada del servidor. Permite en el firewall una dirección de origen concreta:

sudo ufw allow from 10.20.0.10 to any port 6379 proto tcp
sudo ufw status numbered

Una contraseña no convierte en segura una instancia pública. Exponer Redis agrega intentos automatizados, facilita ataques de denegación de servicio y deja el servicio a merced de cualquier futura vulnerabilidad. La defensa principal es la red; ACL y TLS agregan controles sobre los clientes autorizados.

Crear usuarios con ACL en lugar de compartir una clave

Las ACL permiten asignar a cada aplicación su propia contraseña, patrones de claves y grupos de comandos. Esto evita que un servicio dedicado a sesiones pueda borrar una cola o ejecutar comandos administrativos. Deshabilita el usuario default si todos tus clientes admiten nombre de usuario:

user default off
user miapp on >CAMBIA_ESTA_CLAVE_LARGA ~miapp:* +@read +@write -@dangerous

El patrón ~miapp:* restringe el usuario a claves con ese prefijo. Las categorías @read y @write conceden operaciones habituales, mientras -@dangerous niega acciones administrativas o destructivas. Esta es una base que debes probar contra los comandos reales del cliente; algunas bibliotecas necesitan PING, CLIENT SETNAME, scripts Lua o operaciones de pub/sub.

Guarda las ACL en un archivo separado para no exponer contraseñas cada vez que compartes redis.conf:

aclfile /etc/redis/users.acl

Protege el archivo y recarga:

sudo chown redis:redis /etc/redis/users.acl
sudo chmod 640 /etc/redis/users.acl
sudo systemctl restart redis-server
redis-cli --user miapp --askpass PING

No escribas la contraseña en la línea de comandos con -a, porque puede quedar en el historial o ser visible en la lista de procesos. Usa --askpass, una variable de entorno protegida durante una tarea puntual o el gestor de secretos de la plataforma.

Elegir un límite de memoria que no ahogue al VPS

Redis guarda datos, índices internos, buffers de clientes y estructuras de replicación en RAM. maxmemory limita principalmente el conjunto de datos sujeto a expulsión; el proceso puede consumir más por fragmentación, buffers y operaciones temporales. Por eso no asignes el cien por ciento de la memoria del VPS.

En un servidor de 4 GB compartido con sistema, proxy y aplicación, empezar con 1 o 2 GB para Redis puede ser razonable, pero la cifra correcta surge de medir los demás procesos. Configura un límite explícito:

maxmemory 1536mb
maxmemory-policy allkeys-lru

La política debe corresponder al papel del servicio:

noeviction preserva datos existentes, pero la aplicación recibirá errores de escritura y debe manejarlos. Una política allkeys-* mantiene Redis disponible sacrificando claves. Para una cola, expulsar silenciosamente trabajos es peor que rechazar una publicación y activar una alerta.

Consulta el consumo y la fragmentación:

redis-cli --user miapp --askpass INFO memory
redis-cli --user miapp --askpass INFO stats

Observa used_memory, used_memory_rss, mem_fragmentation_ratio, evicted_keys y rejected_connections. Un crecimiento continuo sin aumento previsto de claves puede indicar TTL ausente, clientes con buffers grandes o una carga que guarda valores demasiado pesados.

Diseñar expiraciones y nombres de claves

Una caché sin TTL se convierte en una base de datos accidental. La aplicación debe establecer vencimientos al escribir y usar prefijos que identifiquen dueño y entorno, por ejemplo produccion:catalogo:producto:123. Evita KEYS * en producción: recorre todo el espacio de claves y bloquea el hilo principal durante el trabajo. Para inspección usa SCAN, que devuelve resultados por lotes:

redis-cli --user miapp --askpass --scan --pattern 'miapp:*' | head

Comprueba claves sin expiración mediante muestreo y corrige la aplicación, no con una limpieza manual recurrente. Borrar millones de claves de golpe con DEL puede bloquear; UNLINK libera la memoria de forma asíncrona y suele ser más seguro para valores grandes.

El tamaño de cada valor importa tanto como el número de claves. Guardar respuestas JSON gigantes o archivos binarios aumenta memoria, tráfico y tiempo de serialización. Redis debe almacenar identificadores y datos de acceso frecuente; archivos y blobs suelen pertenecer a almacenamiento de objetos.

Escoger entre RDB, AOF o ninguna persistencia

RDB toma snapshots periódicos. Su recuperación es rápida y el archivo es compacto, pero una caída puede perder los cambios desde el último snapshot. AOF registra operaciones de escritura; reduce la ventana de pérdida según su política de sincronización, a cambio de más I/O y archivos mayores.

Para una caché pura puedes desactivar persistencia si la aplicación reconstruye los datos y aceptas el arranque en frío. Para sesiones, colas o datos no reconstruibles, define explícitamente el objetivo de pérdida. Una configuración común combina snapshots con AOF:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec
aof-use-rdb-preamble yes

appendfsync everysec busca un equilibrio: en una caída abrupta podría perderse aproximadamente el último segundo de escrituras. always sincroniza cada operación y aumenta latencia; no delega la decisión al sistema operativo y amplía la ventana. Ningún modo promete cero pérdida ante cualquier falla de hardware.

Revisa el estado de persistencia:

redis-cli INFO persistence
sudo ls -lh /var/lib/redis
sudo journalctl -u redis-server --since today

Si rdb_last_bgsave_status o aof_last_bgrewrite_status marca error, revisa espacio, permisos y memoria. Durante BGSAVE o reescritura AOF el proceso hace fork; con muchas páginas modificadas, el consumo temporal puede crecer. Deja margen y no ejecutes esas tareas cuando el VPS ya está al límite.

Hacer backups sin copiar archivos activos a ciegas

Un snapshot RDB es portable, pero copiar dump.rdb mientras Redis lo reemplaza puede capturar un estado inesperado. Solicita primero un guardado y verifica la hora del último éxito:

redis-cli --user administrador --askpass BGSAVE
redis-cli --user administrador --askpass LASTSAVE
sudo cp --preserve=mode,ownership /var/lib/redis/dump.rdb /var/backups/redis-dump.rdb

El usuario de aplicación no debería tener permiso para BGSAVE; usa una cuenta operativa limitada o la conexión local administrativa. Si trabajas con AOF multiparte, respalda el directorio completo conforme al método soportado por tu versión, no solo un archivo que parezca principal.

Una copia válida debe arrancar en un entorno aislado. Levanta otra instancia en un puerto distinto, sin acceso externo, apunta a la copia y comprueba claves representativas. Registra cuánto tarda en cargar y cuánta memoria necesita. Conserva el respaldo fuera del VPS: si falla el disco o borras la máquina, una copia local desaparece con ella.

Integrar Redis con systemd y el kernel

El paquete de Ubuntu ejecuta Redis con un usuario dedicado y systemd. Conserva supervised systemd cuando corresponda y evita iniciarlo manualmente como root. Revisa límites efectivos:

systemctl cat redis-server
systemctl show redis-server -p User -p Group -p LimitNOFILE

Redis puede advertir sobre vm.overcommit_memory. Evalúa el ajuste porque las operaciones de persistencia necesitan reservar memoria virtual durante fork:

sysctl vm.overcommit_memory
echo 'vm.overcommit_memory = 1' | sudo tee /etc/sysctl.d/99-redis.conf
sudo sysctl --system

No desactives Transparent Huge Pages sin verificar la recomendación de tu versión y el comportamiento del host. Cualquier cambio de kernel afecta otras cargas del VPS y debe documentarse con una medición previa y posterior.

Medir latencia, clientes y comandos lentos

Redis procesa la mayoría de comandos en un hilo principal; una operación costosa retrasa a todos los clientes. El slow log registra comandos cuyo tiempo de ejecución supera el umbral configurado, sin contar el tiempo de red:

redis-cli --user miapp --askpass SLOWLOG GET 20
redis-cli --user miapp --askpass LATENCY DOCTOR
redis-cli --user miapp --askpass INFO clients
redis-cli --user miapp --askpass INFO commandstats

Busca escaneos completos, scripts Lua largos, colecciones gigantes y clientes bloqueados. MONITOR muestra todos los comandos en tiempo real, pero añade carga y puede revelar datos sensibles; úsalo solo durante una investigación breve y controlada.

La latencia vista por la aplicación incluye red, pool del cliente, serialización y servidor. Si redis-cli --latency desde el mismo host es estable pero la aplicación es lenta, revisa conexiones, DNS y tamaño de valores antes de culpar a Redis.

Probar reinicios y fallos antes de producción

Escribe una clave de prueba con vencimiento, reinicia el servicio y comprueba el resultado según la política de persistencia elegida:

redis-cli --user miapp --askpass SET miapp:prueba 'ok' EX 600
sudo systemctl restart redis-server
redis-cli --user miapp --askpass GET miapp:prueba
redis-cli --user miapp --askpass TTL miapp:prueba

Prueba también que una conexión desde una interfaz no autorizada falla y que el usuario de aplicación no puede ejecutar comandos administrativos. Una prueba negativa detecta reglas demasiado amplias que un PING exitoso nunca mostraría.

Si Redis alimenta una cola, pausa un worker, acumula algunos trabajos y recupéralo. Si guarda sesiones, reinicia bajo una sesión de prueba. Si funciona como caché, vacía únicamente el entorno de pruebas y mide el impacto del calentamiento. La validación debe imitar el uso real.

Resolver fallos habituales

No soluciones un OOM elevando maxmemory hasta ocupar toda la máquina. Si Redis comparte VPS, el kernel necesita memoria para el sistema, la aplicación y la caché de archivos. La guía qué hacer cuando el VPS se queda sin RAM ayuda a distinguir una carga legítima de una fuga o un límite mal calculado.

Checklist antes de conectar la aplicación

Confirma que el proceso corre como el usuario redis, el puerto no es público, el usuario ACL accede solo a su prefijo y la política de memoria coincide con el tipo de dato. Verifica persistencia, ejecuta un reinicio, restaura un backup aislado y activa alertas sobre memoria, expulsiones, errores de guardado, conexiones rechazadas y reinicios.

Durante la primera semana registra used_memory, RSS, claves, operaciones por segundo, aciertos y fallos de caché, latencia y crecimiento de AOF/RDB. Un promedio diario puede esconder picos de importaciones o campañas; conserva resolución suficiente para ver qué ocurrió durante el incidente.

Documenta cómo rotar una credencial ACL sin cortar clientes: crea una segunda contraseña o usuario, actualiza aplicaciones, comprueba conexiones y después retira la anterior. Esta secuencia evita que una rotación de seguridad se convierta en una caída coordinada de todos los servicios.

Detectar claves grandes, hot keys y diseños que bloquean Redis

Una instancia puede tener memoria libre y aun así sufrir picos de latencia por la forma de sus claves. Una big key contiene un valor o colección desproporcionada; una hot key recibe una fracción excesiva de las operaciones. La primera encarece lectura, borrado, serialización y replicación. La segunda concentra el trabajo en un único punto aunque el conjunto total de datos sea pequeño.

Empieza con las herramientas de muestreo incluidas en redis-cli, preferiblemente durante una ventana controlada:

redis-cli --user administrador --askpass --bigkeys
redis-cli --user administrador --askpass --memkeys
redis-cli --user administrador --askpass INFO keyspace
redis-cli --user administrador --askpass SLOWLOG GET 20

--bigkeys recorre el espacio con SCAN, por lo que es menos agresivo que KEYS *, pero sigue generando trabajo y debe probarse primero en una réplica o periodo de baja demanda. No pegues su salida completa en tickets públicos: los nombres pueden revelar correos, identificadores de clientes o estructura interna.

Cuando identifiques una clave sospechosa, consulta su tipo y memoria aproximada sin descargar todo el contenido:

redis-cli --user administrador --askpass TYPE miapp:clave
redis-cli --user administrador --askpass MEMORY USAGE miapp:clave SAMPLES 5
redis-cli --user administrador --askpass TTL miapp:clave

La corrección depende del modelo. Divide hashes o listas gigantes por cliente, fecha o partición lógica; pagina resultados; evita guardar documentos completos cuando solo necesitas dos campos y asigna TTL a datos reconstruibles. Para eliminar una clave grande, UNLINK permite liberar memoria en segundo plano y suele afectar menos al hilo principal que DEL, aunque debes comprobar que la versión y la política de tu aplicación toleran la desaparición.

Las hot keys requieren otra respuesta: caché local de corta duración, distribución de contadores, lectura desde réplicas cuando la consistencia lo permita o rediseño del patrón de acceso. Añadir RAM no elimina una concentración de operaciones. Mide siempre desde la aplicación: una clave “popular” puede ser legítima si mantiene baja latencia y no bloquea a otros clientes.

Separar aplicaciones: los números de base no son una frontera de seguridad

Redis permite seleccionar bases numeradas, pero todas comparten proceso, memoria, CPU, configuración, persistencia y credenciales salvo que las ACL se diseñen cuidadosamente. SELECT 1 organiza nombres; no aísla una aplicación problemática ni impide que una operación administrativa afecte a las demás. Por eso no debes tratar cada número como si fuera una base independiente comparable a PostgreSQL.

Para cargas del mismo nivel de confianza, los prefijos y patrones ACL pueden ser suficientes: tienda:sesion:, tienda:cache: o facturacion:cola:*. El usuario de cada aplicación debe acceder solo a sus patrones y a los grupos de comandos necesarios. Comprueba la negativa intentando leer una clave de otro prefijo con la credencial de aplicación.

Si una carga conserva datos críticos y otra usa Redis como caché descartable, sepáralas en instancias o servidores. Necesitan políticas de expulsión incompatibles: la caché puede usar una política que retire claves, mientras una cola debe rechazar escrituras antes de borrar trabajos. Separarlas también evita que un FLUSHDB, script costoso o crecimiento súbito de una aplicación afecte la disponibilidad de la otra.

Replicación y Sentinel no reemplazan los backups

Una réplica copia el estado del primario para facilitar lecturas o recuperación ante una caída; también replica borrados accidentales, expiraciones y escrituras de un cliente comprometido. Sentinel puede detectar fallos y promover una réplica, pero no conserva por sí mismo una versión anterior de los datos. Alta disponibilidad y recuperación histórica responden a riesgos diferentes.

Antes de diseñar failover, decide qué acepta la aplicación. Una promoción puede perder las últimas escrituras que todavía no llegaron a la réplica, y un cliente mal configurado puede seguir intentando el nodo antiguo. Prueba desconexión, elección del nuevo primario, reconexión y regreso a un estado estable con tráfico de ensayo. Observa el retraso de replicación y el resultado funcional, no solo que todos los procesos estén activos.

Los backups deben salir de la misma infraestructura y conservar versiones. Para RDB o AOF, ensaya el arranque de una instancia aislada con la copia, cuenta claves representativas y valida una operación de negocio. Si Redis es solo caché, quizá la mejor recuperación sea arrancar vacío y recalentar de forma controlada; documenta esa decisión para que nadie restaure datos obsoletos durante una emergencia.

Incluye en el ensayo qué ocurre con los clientes durante la recuperación. Deben aplicar tiempos de espera, reintentos limitados y degradación controlada; un bucle de reconexión sin pausa puede saturar justo la instancia que acaba de volver. Mide cuánto tarda la aplicación en estabilizarse, no únicamente cuánto tarda Redis en responder PONG.