Tenho algo que chamarei de "microsserviço" em execução no AWS Lambda (usando node.js).
Basicamente, ele fornece resumos condensados extraídos de algumas centenas de megabytes de blob binário. Existem muitas saídas possíveis e pré-gerar todas as possibilidades não é uma opção, e precisa ser razoavelmente responsivo (menos de um segundo, na pior das hipóteses, digamos) à medida que é acessado (via API Gateway) a partir de páginas da web interativas que permitem parâmetros ser alterado rapidamente. Os padrões de acesso no blob são essencialmente aleatórios, embora qualquer resumo produzido normalmente tenha acessado apenas cerca de 0,1-1% do total de dados. Os dados e os padrões de acesso não são muito compatíveis com o armazenamento de dados em um banco de dados (embora veja a menção ao DynamoDB abaixo).
Minha abordagem atual é ter o grande blob binário hospedado no S3 e fazer com que os manipuladores do Lambda armazenem o blob em cache localmente entre as invocações do Lambda (apenas como um buffer no código javascript, com escopo fora da função do manipulador; obviamente, a memória do Lambda está configurada o suficiente grande). As instâncias do manipulador parecem ser persistentes o suficiente para que, uma vez instalado e funcionando, o servidor funcione bem e seja muito responsivo. No entanto, existem pelo menos algumas desvantagens:
A busca inicial dos dados do S3 parece estar em torno de 50-60MByte/s (parece estar de acordo com outros relatórios sobre largura de banda do S3 que vi), portanto pode haver um atraso irritante de vários segundos no primeiro acesso.
Relacionado ao ponto anterior, se o cliente estiver muito ativo e/ou a carga do usuário aumentar, mais instâncias do servidor serão ativadas e os usuários poderão encontrar suas solicitações roteadas para instâncias que estão paralisadas na busca do blob de dados, o que leva a falhas irritantes em um caso contrário, um cliente funcionando perfeitamente.
Admito francamente que provavelmente estou esperando muito do que realmente pretende ser um serviço "sem estado", por ter uma grande parte do estado nele (o blob binário), mas estou me perguntando se algo pode ser feito para melhorar a situação. Observe que os dados não são particularmente compressíveis (pode ser possível retirar 1/3 deles, mas esse não é o tipo de ordem de grandeza que estou procurando, ou pelo menos é apenas parte da solução, na melhor das hipóteses) .
Alguma sugestão de como colocar os dados no Lambda mais rapidamente? O tipo de coisa que estou imaginando é:
Extraia seus dados de algum outro lugar onde os Lambdas tenham largura de banda muito maior... mas o quê? DynamoDB (dividido em quantos registros binários de 400 mil forem necessários)? ElastiCache? Outra coisa no "menu" da AWS que não percebi.
Use algum truque astuto (o quê?) para "pré-aquecer" as instâncias lambda.
Você está usando a ferramenta completamente errada para o trabalho; usar... em vez disso? (Eu realmente gosto do modelo Lambda; não há necessidade de se preocupar com todo aquele provisionamento de instância e escalonamento automático, apenas concentre-se na funcionalidade).
Se as ofertas semelhantes ao Lambda anunciadas recentemente pelo Google ou pela Microsoft (sobre as quais eu sei pouco) tiverem quaisquer atributos que possam ajudar melhor neste caso de uso, isso também seria uma informação muito interessante.
Uma opção que considerei é incorporar os dados binários em um "pacote de implantação", mas o limite de 250 MByte é muito baixo para alguns casos de uso previstos (mesmo que o blob tenha sido compactado).
Responder1
Se o blob binário tiver apenas algumas centenas de megabytes, você pode simplesmente incluí-lo em sua função como uma "dependência". Você pode adicioná-lo como um arquivo junto com seu código e referenciá-lo adequadamente.
Outra opção seria ter duas funções lambda. Uma função não faz nada além de servir o blob (que você cria como acima, enviando o blob com a função) e então você pode usar um cronômetro (basicamente cron) para "agradar" essa função a cada minuto para mantê-la ativa. Então o seu segundo lambda é aquele que faz o trabalho, e a primeira coisa que ele faz na inicialização é chamar o primeiro lambda para obter o blob. As chamadas lambda para lambda têm largura de banda alta, portanto o tempo de inicialização não deve ser um problema.
A solução ideal seria descobrir uma maneira de resumir os dados e armazená-los no DynamoDB, mas parece que você tentou esse caminho e não fez sentido para você.