Soy muy nuevo en arquitectura en la nube pero tengo una experiencia decente en el desarrollo de aplicaciones. En este momento, estoy en el proceso de hacer que un gran proceso computacional sea más accesible para entre 5 y 10 usuarios a través de una aplicación web y estoy configurando todo esto en AWS.
Mi implementación actual es una aplicación web React liviana que utiliza dos API y un backend MySQL que permite a los usuarios poner en cola trabajos con parámetros y acceder a los resultados finales a través de la aplicación web o desde correos electrónicos enviados a los usuarios una vez finalizada la ejecución.
En medio de este proceso hay una dependencia de una pieza de software propietario que necesita una máquina muy pesada para calcular estos pasos (64 GB de RAM, 16 núcleos, 1 TB de disco duro) y puede funcionar hasta por 1,5 días solo para este paso. Este es mi mayor cuello de botella de todo el oleoducto.
Para ahorrar costos tanto como sea posible, estoy tratando de hacer que el cuello de botella/pieza de servicio sea escalable/rentable al tener múltiples "agentes" de instancia EC2 disponibles para activar, ejecutar los pasos, enviar un correo electrónico, escribir en la web. base de datos de la aplicación y luego detener la instancia a través de las funciones lambda de AWS que se activarían mediante una acción de la aplicación web.
Estoy planeando alojar una instancia EC2 para la aplicación web, 2 API y un servidor MySQL, ya que la simultaneidad/escalabilidad en esta pieza es muy pequeña. También tendré otras 1 a 3 instancias para que los servicios de cuello de botella compartan ejecuciones simultáneas de 5 a 10 usuarios, lo que podría permitir hasta 3 ejecuciones del paso pesado al mismo tiempo.
Dado que los servicios de cuello de botella requieren archivos similares para ejecutar los programas y la entrada para estos pasos a veces puede tener un tamaño de archivo de 150 GB, estoy pensando en usar almacenamiento EFS o S3 para guardar las entradas de modo que solo tenga que preocuparme por transferir la entrada. archivos a un lugar que podría compartirse entre instancias EC2 y no necesitaría asegurarme de que hayan comenzado a realizar el paso de transferencia. Esta es una pieza manual que tampoco he encontrado una buena manera de automatizarla más ya que los tamaños de archivos son muy grandes.
Mis preguntas son: ¿Mi configuración parece razonable? ¿Ve algún agujero en mis ideas de implementación? Actualmente estoy usando almacenamiento EBS para las instancias de servicio, pero quiero minimizar las ubicaciones de entrada para las transferencias/mantenimiento de 150 GB. Tampoco estoy seguro de la diferencia entre S3 y EFS, ya que ambos parecen ser montables en múltiples instancias, pero ¿cuál debo usar? ¿Y tiene sentido mantener la aplicación web, las API y la base de datos en una instancia EC2 si necesito que los servicios puedan escribir en la base de datos una vez que hayan terminado? Esa instancia estaría encendida todo el tiempo.
Gracias por tu ayuda y perdóname si he dicho algo ingenuamente.
Respuesta1
Su configuración parece razonable. Podría sugerirle que considere tener una puerta de enlace API para "alojar" su API y pensar si funciona para usted. También podría considerar tener sus instancias EC2 de carga pesada en un grupo de escalado automático y hacer que su control Lambda interactúe con él en lugar de hacerlo directamente con las instancias.
S3 y EFS son soluciones de almacenamiento de datos diferentes. S3 es almacenamiento de objetos, mientras que EFS es almacenamiento de archivos. S3 no es exactamente montable, aunque puede presentarse como si lo fuera a través de diferentes utilidades. Ya seacorrectoUsar S3 o EFS depende de cómo estés usando los archivos que tienes allí.
Para su base de datos, podría considerar ir a RDS, tal vez usando una clase de instancia ampliable o una de las opciones sin servidor. Pero esto dependerá de su presupuesto y caso de uso.
Respuesta2
En general, en la nube es bueno intentar utilizar servicios en lugar de servidores. Hay que vigilar los costos, pero esto puede hacer que las soluciones sean más sólidas, más rápidas y más compatibles.
Tengo un par de pensamientos sobre tu carga de trabajo:
- ¿Puede utilizar un orquestador como las funciones de AWS Step que llaman a muchas funciones lambda de AWS para realizar el cálculo? Observo que lambda es probablemente el tiempo de cálculo más caro en AWS, por lo que tal vez no sea ideal. Con los límites establecidos correctamente y una carga de trabajo adecuada, tal vez podría iniciar 10.000 lambdas y hacer el trabajo en paralelo en 15 minutos.
- En lugar de EFS/S3, ¿qué tal si creamos una imagen EC2/AMI dorada y luego, para cada trabajo, creamos una instancia EC2 puntual/dinámica lo suficientemente grande como para realizar el procesamiento de ese trabajo y se apaga cuando finaliza? ¿Lambda tal vez podría orquestar el trabajo en función de eventos de algún tipo? Eso evitaría cargos por transferencia de datos, aunque no estoy seguro si se cargan a EBS/S3 o no. La computación puntual es bastante económica y, si elige correctamente el tamaño de su región/AZ/instancia, las interrupciones deberían ser raras. Las instancias interrumpidas se cierran y el volumen de EBS se conserva, por lo que esto funcionaría mejor si su trabajo se escribe en el disco con regularidad y se puede reiniciar.
Probablemente también dedicaría algo de tiempo a optimizar ese enorme trabajo.