Arquitectura, conclusiones y consideraciones

Tecnologías utilizadas

Funcionalidad	Nombre
Lenguajes  de programación	Python
Bases de datos	Mysql
Servicio de mensajería asincrono	Cloud Pub/Sub
Frameworks de desarrollo	Flask
Servicio de almacenamiento archivos	Cloud Storage
Instancias	Máquinas virtuales en GCP
Instancia Base de datos	Google Cloud SQL
Balanceador de carga	External Application Load Balancer GCP

Componentes

Listado de componentes	Propósito y comportamiento esperado	Tecnología Asociada	Instancia GCP
API	Gestiona la creación de los usuarios, generación del token y las tareas de conversión de archivos.	Python Flask, Mysql, VMs GCP, load balancer	web-api
Worker	Procesa la conversión del archivo.	Python Flask, Mysql, VMs GCP	worker
Mensajería asincrona	Gestionar los mensajes de las tareas para que puedan ser procesadas	Cloud Pub/Sub	Cloud Pub/Sub
Almacenamiento archivos	Recurso compartido para almacenamiento de archivos	Cloud Storage	Cloud Storage
HTTP Load Balancer	Recurso de red que balancea la carga entre las instancias activas de la capa web	Load Balancing	Load Balancer

Vista de contexto

Modelo de contexto

Vista funcional

Modelo componente - conector

Vista información

Modelo de clases

Modelo de información

Vista de despliegue

Modelo de despliegue

Conclusiones y Consideraciones

• A continuación, se muestran las reglas definidas de autoescalamiento.

Autoescalamiento Worker

Para el proceso de autoescalamiento del worker se implemento cloud Pub/Sub con estrategia pull donde múltiples instancias comparten el mismo subscription, los mensaje se entregan de un máximo de 5 por vez a una de las instancias, cada instancias procesa una tarea a la vez y cuando una instancia falla la cola tiene un tiempo de deadline definido en 60 segundos para volver a poner el mensaje disponible para que otra instancia le haga pull, una vez la instancia termina con sus 5 mensajes hara pull de otros 5 como máximo de los disponibles en la subscrition del topic.

El grupo de instancias tiene como máximo cinco maquinas y la señal de autoescalamiento será despues de 60% de uso de CPU una sola instancia.

Autoescalamiento API

• La seña de autoescalamiento es 60% de usabilidad de la CPU, este valor fue resultado de las pruebas de la semana pasada donde se evidenció que por encima del 60% las peticiones fallaban en una sola instancia.

• El número mínimo de instancias para las pruebas es uno y con máximo de 3.

• Cuando el grupo de instancias crea una nueva máquina se configuró un tiempo de inicialización de 90 segundos, dado que este es el tiempo necesario para que se inicien todos los servicios en el sistema operativo y se estabilice el uso de recursos, si este valor fuera menor el balancer podría estar creando otra instancia de manera errónea por considerar que el uso de recursos supera la métrica del 60%.

• El load balancer usa como frontend una ip estática reservada.

• El load balancer usa como backend un instance group que contiene las instancias de la capa web.

• También se implementó un nuevo endpoint para el health check.