Sou muito novo em arquitetura de nuvem, mas tenho uma experiência decente em desenvolvimento de aplicativos. No momento, estou no processo de tornar um grande pipeline computacional mais acessível para 5 a 10 usuários por meio de um aplicativo da web e estou configurando tudo isso na AWS.
Minha implementação atual é um aplicativo Web React leve que usa duas APIs e um back-end MySQL que permite aos usuários enfileirar trabalhos com parâmetros e acessar os resultados finais por meio do aplicativo Web ou de e-mails enviados aos usuários após a conclusão de uma execução.
No meio desse pipeline está a dependência de um software proprietário que precisa de uma máquina muito robusta para calcular essas etapas (64 GB de RAM, 16 núcleos, HDD de 1 TB) e pode funcionar por até 1,5 dias apenas para esta etapa. Este é o meu maior gargalo em todo o pipeline.
Para economizar o máximo possível em custos, estou tentando tornar o gargalo/peça de serviço escalonável/econômico, tendo vários "agentes" de instância do EC2 disponíveis para serem ativados, executar as etapas, enviar um e-mail, escrever para a web banco de dados do aplicativo e, em seguida, interrompa a instância por meio de funções lambda da AWS que seriam acionadas por uma ação do aplicativo web.
Estou planejando hospedar uma instância EC2 para o aplicativo da web, 2 APIs e servidor MySQL, já que a simultaneidade/escalabilidade nesta peça é muito pequena. Também terei outras 1 a 3 instâncias para os serviços de gargalo compartilharem execuções simultâneas de 5 a 10 usuários, o que pode permitir até 3 execuções da etapa pesada ao mesmo tempo.
Como os serviços de gargalo exigem arquivos semelhantes para executar os programas e a entrada para essas etapas às vezes pode ter tamanhos de arquivo de 150 GB, estou pensando em usar o armazenamento EFS ou S3 para armazenar as entradas, de modo que só precise me preocupar em transferir a entrada arquivos para um local que possa ser compartilhado entre instâncias do EC2 e eu não precisaria garantir que eles fossem iniciados para realizar a etapa de transferência. Esta é uma peça manual que também não descobri uma boa maneira de ser mais automatizada, já que os tamanhos dos arquivos são muito grandes.
Minhas perguntas são: minha configuração parece razoável e você vê alguma falha em minhas ideias de implementação? Atualmente estou usando armazenamento EBS para as instâncias de serviço, mas quero minimizar os locais de entrada para transferências/manutenção de 150 GB. Também não tenho certeza da diferença entre S3 e EFS, pois ambos parecem ser montáveis em várias instâncias, mas qual devo usar? E faz sentido manter o aplicativo da web, as APIs e o banco de dados em uma instância do EC2 se eu precisar que os serviços sejam capazes de gravar no banco de dados depois de concluídos? Essa instância estaria ligada o tempo todo.
Obrigado pela sua ajuda e perdoe-me se eu disse algo ingenuamente.
Responder1
Sua configuração parece razoável. Posso sugerir que você procure um API Gateway para "hospedar" sua API e pense um pouco se funciona para você. Você também pode considerar ter suas instâncias do EC2 de carga pesada em um grupo de escalonamento automático e fazer com que seu Lambda de controle interaja com ele, em vez de diretamente com as instâncias.
S3 e EFS são soluções diferentes de armazenamento de dados. S3 é armazenamento de objetos, enquanto EFS é armazenamento de arquivos. O S3 não é exatamente montável, embora possa ser apresentado como se fosse por meio de diferentes utilitários. Quer sejacorretousar S3 ou EFS depende de como você está usando os arquivos que possui.
Para o seu banco de dados, você pode considerar usar o RDS, talvez usando uma classe de instância expansível ou uma das opções sem servidor. Mas isso dependerá do seu orçamento e caso de uso.
Responder2
Em geral, na nuvem é bom tentar usar serviços em vez de servidores. Você precisa ficar de olho no custo, mas isso pode tornar as soluções mais robustas, rápidas e compatíveis.
Tenho algumas idéias sobre sua carga de trabalho:
- Você pode usar um orquestrador como funções AWS Step chamando muitas funções lambda da AWS para fazer o cálculo? Observo que lambda é provavelmente o tempo de computação mais caro na AWS, então talvez não seja o ideal. Com os limites definidos corretamente e uma carga de trabalho adequada, talvez você possa iniciar 10.000 lambdas e fazer o trabalho em paralelo em 15 minutos.
- Em vez de EFS/S3, que tal criar uma imagem/AMI dourada do EC2 e, para cada trabalho, criar uma instância spot/dinâmica do EC2 grande o suficiente para fazer o processamento daquele trabalho ser encerrado quando estiver concluído? Lambda poderia talvez orquestrar o trabalho com base em algum tipo de evento? Isso evitaria cobranças de transferência de dados - embora não tenha certeza se elas são cobradas do EBS/S3 ou não. A computação spot é bastante barata e, se você escolher corretamente o tamanho da região/AZ/instância, as interrupções deverão ser raras. As instâncias interrompidas são encerradas e o volume do EBS mantido, portanto, isso funcionaria melhor se o seu trabalho fosse gravado no disco regularmente e pudesse ser reiniciado.
Eu provavelmente também dedicaria algum tempo para otimizar esse enorme trabalho.