Optimización del rendimiento
Optimizar la plataforma
Antes de realizar cualquier ajuste, es recomendable realizar mediciones sobre el desempeño actual.
Escalabilidad
La solución del ecosistema es escalable en diferentes formas:
- vertical, mediante el incremento de recursos disponibles (CPU, RAM, etc.) al servicio en particular
- horizontal, mediante el despliegue de instancias adicionales del servicio en particular
Escalabilidad horizontal
Se refiere a desplegar múltiples instancias de un mismo servicio de un módulo. Por ej, escalar el servicio idp del módulo arai-usuarios. Normalmente no presenta límites en cuanto al número de nodos a escalar.
En Docker Swarm, se logra incrementando el número de contenedores para un servicio definido mediante una configuración del estilo:
...
deploy:
mode: replicated
replicas: 2
restart_policy:
condition: any
delay: 10s
max_attempts: 4
window: 120s
La entrada replicas permite establecer la cantidad de contenedores a generar. También es posible hacerlo mediante un
comando del estilo:
docker service scale usuarios_api=2
En cualquiera de los casos, el efecto se verá reflejado en el número de réplicas del servicio, o lo que es lo mismo la cantidad de contenedores en ejecución.
Atención: no todos los servicios funcionan en forma correcta al ser escalados horizontalmente.
Servicios básicos
| servicio | escalable | condiciones requeridas | observaciones |
|---|---|---|---|
| reverse proxy | si | solo corre en nodos "manager" |
Arai-Usuarios
| servicio | escalable | condiciones requeridas | observaciones |
|---|---|---|---|
| api | si | requiere storage compartido y sesiones en memcached | |
| idp | si | requiere storage compartido y sesiones en memcached | |
| idm | no | requiere storage compartido y sesiones en memcached | |
| memcached | no | al escalar, el cliente tiene que apuntar a las nuevas IP del nodo, no es transparente |
Arai-documentos
| servicio | escalable | condiciones requeridas | observaciones |
|---|---|---|---|
| api | si | ||
| worker | no | requiere implementar un manejador de colas |
Huarpe
| servicio | escalable | condiciones requeridas | observaciones |
|---|---|---|---|
| web | si | requiere sesiones en memcached | |
| memcached | no | al escalar, el cliente tiene que apuntar a las nuevas IP del nodo, no es transparente |
Sudocu
| servicio | escalable | condiciones requeridas | observaciones |
|---|---|---|---|
| login | |||
| gestion | |||
| cache | |||
| api-server | |||
| mpc | |||
| mpd | |||
Escalabilidad vertical
Se logra modicando la asignación de los recursos de CPU y RAM para un servicio en particular.
En Docker Swarm, se debe modificar los valores en las secciones similares a
...
deploy:
resources:
limits:
cpus: '0.25'
memory: 128M
reservations:
cpus: '0.1'
memory: 20M
La entrada reservations especifica los valores "iniciales" de recusos asignados, mientras que la entrada limits
permite configurar el valor máximo. Docker Swarm no asigna recursos pasado este valor.
A continuación se detallan los ajustes particulares a cada módulo para la configuración de la memoria RAM que utilizan.
Arai-Usuarios
Arai-Documentos
Huarpe
Sudocu
Alta Disponibilidad
Muchas veces se requiere que un servicio esté disponible sin importar si sufre inconvenientes.
En parte, esto se logra:
- mediante escalado horizontal, desplegando múltiples instancias del mismo servicio
- disponiendo de diferentes nodos del cluster Docker Swarm, de modo que si uno cae otro pueda asumir el servicio
- tolerancia a caídas de diferentes servicios críticos, sin cortes del servicio o pérdidas de datos
Actualmente lograr alta dispnibilidad o HA puede requerir cambios en el código principalmente en el manejo de sesiones de usuario distribuidas.