Eu tenho algo que chamarei de "microservice" em execução no AWS Lambda (usando node.js).
Basicamente serve resumos condensados de algumas centenas de megabytes de blob binários. Há muitos resultados possíveis e pré-gerar todas as possibilidades não é uma opção, e precisa ser razoavelmente responsivo (sub-segundo no pior, digamos) conforme é acessado (via API Gateway) a partir de páginas interativas que permitem parâmetros para ser mudado rapidamente. Os padrões de acesso no blob são essencialmente aleatórios, embora qualquer resumo produzido normalmente tenha acessado apenas 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 dos dados em um banco de dados (apesar de ver o DynamoDB abaixo).
Minha abordagem atual é ter o grande binário binário hospedado no S3 e fazer com que os manipuladores do Lambda armazenem o blob no cache localmente entre as invocações do Lambda (como um buffer no código javascript, com escopo fora da função hander; obviamente a memória do Lambda está configurado suficientemente grande). As instâncias do manipulador parecem ser persistentes o suficiente para que, quando um servidor estiver em funcionamento, ele funcione bem e seja muito responsivo. No entanto, existem pelo menos algumas desvantagens:
-
A busca inicial dos dados do S3 parece estar por volta
50-60MByte / s (parece estar de acordo com outros relatórios no S3
largura de banda que eu vi) para que possa haver um atraso de vários segundos irritante
no primeiro acesso.
-
Relacionado ao ponto anterior, se o cliente estiver muito ativo e / ou
a carga do usuário aumenta, mais instâncias do servidor são geradas e os usuários podem
encontrar seus pedidos encaminhados para instâncias que estão paralisados na busca
a bolha de dados, o que leva a falhas irritantes em um caso contrário
cliente funcionando sem problemas.
Eu admito que provavelmente estou esperando muito do que realmente pretende ser um serviço "sem estado", pois ele tem um grande pedaço de estado (o blob binário), mas eu estou querendo saber se alguma coisa pode ser feito para melhorar a situação. Note que os dados não são particularmente compressíveis (pode ser possível tirar 1/3 dele, 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 é:
-
Puxe seus dados de algum outro lugar que o Lambdas tenha uma largura de banda muito maior para ... mas o que? DynamoDB (dividido em quantos registros binários de 400k, conforme necessário)? ElastiCache? Outra coisa no "menu" da AWS que eu não notei.
-
Use algum truque astucioso (o que?) para "pré-aquecer" instâncias lambda.
-
Você está usando completamente a ferramenta errada para o trabalho; usar ... em vez disso? (Eu realmente gosto do modelo Lambda; não é preciso se preocupar com todo o provisionamento e ajuste automático de instâncias, apenas se concentre na funcionalidade).
Se o Google ou a Microsoft recentemente anunciaram ofertas similares ao Lambda (sobre as quais eu sei pouco) têm quaisquer atributos que ajudariam com este caso de uso melhor, isso seria uma informação muito interessante também.
Uma opção que eu tenho contemplado é assar os dados binários em um "pacote de implantação", mas o limite de 250MByte é muito baixo para alguns casos de uso antecipados (mesmo se o blob foi compactado).