Resultados Exp2 - shiomar-salazar/MISW-PF-Grupo1-Backend GitHub Wiki
El Experimento sufrio una pequeña modificacion, segun los comentarios del tutor, se puede ver la version mas actualizada del experimento aqui
Experimento #2: Reduccion de Latencia en el Registro de Usuarios Simultaneos
Hipotesis de Diseño:
Con el experimento se espera poder comprobar los siguientes comportamientos:
- El establecimiento de parametros base en temas de instancias de Escalamiento Horizontal que nos sirvan como punto de partida al momento del desarrollo del proyecto final nos ayude reducir el riesgo, la incertidumbre y el consumo de recursos .
- Determinar si es necesaria la aplicacion de nuevas tacticas dado el efecto negativo de la Táctica de Retiro de la Operacion ante la indisponibilidad del servico de registro de usuarios.
Puntos de Sensibilidad:
Garantizar que el sistema puedo procesar las peticiones de registro de usuario de al menos 1000 nuevos usuarios concurrentes con un tiempo de respuesta menor a 3 segundos por cada peticion.
Historia de Arquitectura Asociada
Como usuario, cuando envíe el formulario para registrarme en la aplicación dado que el sistema opera normalmente, quiero obtener una notificación de que la operación fue exitosa y también la clasificación en el grupo de riesgo y recomendación de los planes para iniciar un entrenamiento adecuado, basado en mis características fisiológicas, historial deportivo y lugar de residencia. Esto debe suceder en menos de 3 segundos
Diagrama de Implementacion del Experimento:
Pasos para el Despliegue:
Debemos autenticarnos a Artifactory Registry con nuestra cuenta de GCP desde una terminal
gcloud auth configure-docker us-central1-docker.pkg.dev
Realizamos la construcción de las imágenes de los microservicios
docker build -t us-central1-docker.pkg.dev/proyecto1-experimentos/experimentos-misw4501-g1-exp2/gusuarios:1.0 --target prod .
docker build -t us-central1-docker.pkg.dev/proyecto1-experimentos/experimentos-misw4501-g1-exp2/gentrenamientos:1.0 --target prod .
docker build -t us-central1-docker.pkg.dev/proyecto1-experimentos/experimentos-misw4501-g1-exp2/gplannutricional:1.0 --target prod .
Procedemos a subir las imagenes creadas al Artifact Registry.
docker push us-central1-docker.pkg.dev/proyecto1-experimentos/experimentos-misw4501-g1-exp2/gusuarios:1.0
docker push us-central1-docker.pkg.dev/proyecto1-experimentos/experimentos-misw4501-g1-exp2/gentrenamientos:1.0
docker push us-central1-docker.pkg.dev/proyecto1-experimentos/experimentos-misw4501-g1-exp2/gplannutricional:1.0
Creación de la red virtual del proyecto:
gcloud compute networks create vpn-proyecto1-experimentos --project=proyecto1-experimentos --subnet-mode=custom --mtu=1460 --bgp-routing-mode=regional
Creación de la subred correspondiente a los Pods del proyecto:
gcloud compute networks subnets create red-proyecto1-experimentos --range=192.168.32.0/19 --network=vpn-proyecto1-experimentos --region=us-central1 --project=proyecto1-experimentos
Creación de la subred correspondiente a la Base de datos que se utilizará en el proyecto:
gcloud compute addresses create red-dbs-proyecto1-experimentos --global --purpose=VPC_PEERING --addresses=192.168.0.0 --prefix-length=24 --network=vpn-proyecto1-experimentos --project=proyecto1-experimentos
Conceder accesos a la red virtual:
gcloud services vpc-peerings connect --service=servicenetworking.googleapis.com --ranges=red-dbs-proyecto1-experimentos --network=vpn-proyecto1-experimentos --project=proyecto1-experimentos
Adicion de regla de firewall:
gcloud compute firewall-rules create allow-db-ingress --direction=INGRESS --priority=1000 --network=vpn-proyecto1-experimentos --action=ALLOW --rules=tcp:5432 --source-ranges=192.168.1.0/24 --target-tags=basesdedatos --project=proyecto1-experimentos
Datos de Creacion de la Base de Datos
-> Instancia:
Nombre: postgres
Contraseña: postgres
Versión: PostgreSQL 15
Región: us-central1
Disponibilidad zonal: Única
-> Maquina y Almacenamiento:
Tipo de máquina: De núcleo compartido, 1 core y 1.7 GB de RAM
Almacenamiento 10 GB de HDD
No habilitar los aumentos automáticos de almacenamiento.
-> Conexiones:
Asignación de IP de la instancia: privada
Red: vpn-proyecto1-experimentos
Rango de IP asignado: red-dbs-proyecto1-experimentos
Creacion de Clusters de Kubernetes
No usar Copilot
Nombre Kubernetes: proyecto1-experimentos
Red: vpn-proyecto1-experimentos
Subred del nodo: red-proyecto1-experimentos
Nodos: 2
Autoescalamiento de Nodos: minimo 1 maximo 3
Resto de configuraciones en default
Acceder al cluster de Kubernetes desde la consola
gcloud container clusters get-credentials proyecto1-experimentos --region us-central1 --project proyecto1-experimentos
Implementación de los secrets
kubectl apply -f secrets-exp2.yml
Realizamos el despliegue de los servicios del proyecto
kubectl apply -f k8s-experimento2.yaml
Realizamos el despliegue del ingress del proyecto
kubectl apply -f k8s-ingress-deployment2.yaml
Diseño y Ejecicion de Pruebas:
Prueba diseñada:
- Utilizando la Herramienta JMeter se simularan 50 usuarios que se registraran en el sistema de forma concurrente.
- Utilizando la Herramienta JMeter se simularan 1000 usuarios que se registraran en el sistema de forma concurrente.
Caso 1:
| Usuarios | Ramp-up | Tiempo de la prueba (minutos) |
|---|---|---|
| 50 | 1 | 2 |
| Servicios | No. de instancias |
|---|---|
| Microservicio de Gestor de Entrenamientos | Minimas 1, Maxima 1 |
| Microservicio de Gestor de Plan Nutricional | Minimas 1, Maxima 1 |
| Microservicio de Gestor de Usuarios | Minimas 1, Maxima 1 |
Configuracion de JMeter:
Grupo de hilos:
Solicitud HTTP:
Configuracion de Kubernetes GCP:
Cargas de trabajo:
Evidencias:
Estadistica Resultados JMeter
Reporte resumen
Gráfica de resultados
Estadisticas GCP
Caso 2:
| Usuarios | Ramp-up (Segundos) |
|---|---|
| 1000 | 5 |
| Servicios | No. de instancias |
|---|---|
| Microservicio de Gestor de Entrenamientos | 6 |
| Microservicio de Gestor de Plan Nutricional | 6 |
| Microservicio de Gestor de Usuarios | 12 |
Asignacion de recursos a los pods:
Configuración JMeter:
Grupo de hilos:
Solicitud HTTP:
Aserción de duración:
Configuración GCP:
Cluster:
Cargas de trabajo:
Evidencias:
Estadistica Resultados JMeter
Reporte resumen
Resultado en arbol
Gráfica de resultados
Gráfico con la media y el promedio de tiempo de las peticiones
Estadisticas GCP
Consumo de CPU
Consumo de memoria
Resumen ingress
Resultados Obtenidos:
Simulación 50 usuarios que se registran en el sistema de forma concurrente
| Resultado | Situacion |
|---|---|
| Exitoso | Como se visualizó en la sección de ejecución del caso de prueba No. 1, usando el número de instancias planteados (mínimas 1 y máxima 1) de los Microservicios Gestor de Entrenamientos, Gestor de Plan Nutricional y Gestor de Usuarios, se pudo cumplir con el objetivo latencia inferior a 3 segundos cuando existe una concurrencia de 50 usuarios registrándose al mismo tiempo. Este caso de prueba no presentó ninguna dificultad y se esperaba que esto fuera asi, ya que es el caso base con el cual validamos la capacidad de una sola instancia. |
Simulación 1000 usuarios que se registran en el sistema de forma concurrente
| Resultado | Situacion |
|---|---|
| Exitoso | Este caso de prueba al tener un crecimiento realmente superior en cuanto a usuarios concurrentes que realizan el registro en el sistema se refiere en comparación con el caso de prueba No. 1, se realizaron varios intentos en los cuales se implementaron diferentes combinaciones asociadas a la asignación de recursos para cada instancia, asi como tambien el número de instancias mínimas y máximas para cada microservicio, hasta lograr que el sistema pudiera soportar dicha concurrencia de 1000 usuarios con un Ramp-up de 5. El resultado fue como se describe en el apartado Caso 2, tener 6 instancias para el Microservicio de Gestor de Entrenamientos, 6 instancias Microservicio de Gestor de Plan Nutricional y 12 para el Microservicio de Gestor de Usuarios funcionando al mismo tiempo, adicional a esto se efectuó la configuración personalizada del Clúster de Kubernentes, en donde se implementaron 2 Nodos, cada uno con una capacidad de 4 CPUs y 4 GB de memoria RAM, para una capacidad total de 8 CPUs y 8GB de RAM. Con esta capacidad de cómputo y la distribución de instancias mencionada anteriormente para cada Microservicio se pudo obtener el resultado exitoso. |
Conclusiones:
Del experimiento podemos concluir lo siguiente:
- Se debe desechar el uso de Clústers creados con Autopilot para el despliegue final, debido a que esta forma de configurar tiene limitaciones en cuanto a la escalabilidad de los Pods asociados a cada nodo, por lo que es mejor implementar una configuración personalizada, como la que se usó en el caso de prueba No. 2.
- Para la configuración del número de instancias y asignación de recursos asociados a los casos de pruebas, se evidencio que no es tomar y empezar a colocar valores aleatorios, sino que se debe calcular de forma adecuada la distribución y asignación de recursos con base a la capacidad de computo que tenemos en el Clúster, las instancias necesarias para nuestros microservicios y al peso que queremos darle a cada uno. Por lo que realizar un tabla de calculos como la que se muestra en el apartado "Asignación de recursos a los pods" es necesaria y nos permite efectuar este proceso de forma sencilla y acertada.