Tengo algo que llamaré "microservicio" que se ejecuta en AWS Lambda (usando node.js).
Básicamente, ofrece resúmenes condensados extraídos de unos cientos de megabytes de blobs binarios. Hay muchos resultados posibles y pregenerar todas las posibilidades no es una opción, y debe tener una capacidad de respuesta razonable (en menos de un segundo en el peor de los casos, por ejemplo) ya que se accede a él (a través de API Gateway) desde páginas web interactivas que permiten parámetros. cambiar rápidamente. Los patrones de acceso en el blob son esencialmente aleatorios, aunque cualquier resumen producido normalmente solo habrá accedido a entre el 0,1% y el 1% de los datos totales. Los datos y los patrones de acceso no son muy compatibles con el almacenamiento de datos en una base de datos (aunque consulte la mención de DynamoDB a continuación).
Mi enfoque actual es tener el gran blob binario alojado en S3 y hacer que los controladores Lambda almacenen el blob localmente entre invocaciones de Lambda (como un búfer en el código javascript, con alcance fuera de la función del controlador; obviamente, la memoria de Lambda está lo suficientemente configurada). grande). Las instancias del controlador parecen ser lo suficientemente persistentes como para que, una vez que un servidor esté en funcionamiento, funcione bien y tenga una gran capacidad de respuesta. Sin embargo, hay al menos un par de desventajas:
La recuperación inicial de los datos de S3 parece ser de alrededor de 50-60 MByte/s (parece estar de acuerdo con otros informes sobre el ancho de banda de S3 que he visto), por lo que puede haber un molesto retraso de varios segundos en el primer acceso.
En relación con el punto anterior, si el cliente está muy activo y/o la carga de usuarios aumenta, se activan más instancias de servidor y los usuarios pueden encontrar sus solicitudes enrutadas a instancias que se detiene en la recuperación del blob de datos, lo que genera fallas molestas en un cliente que de otro modo funcionaría sin problemas.
Admito libremente que probablemente estoy esperando demasiado de lo que realmente pretende ser un servicio "sin estado" al tener en realidad una gran parte de estado (el blob binario), pero me pregunto si se puede hacer algo para mejorar la situación. Tenga en cuenta que los datos no son particularmente comprimibles (podría ser posible quitarles 1/3, pero ese no es el tipo de orden de magnitud que estoy buscando, o al menos es solo parte de la solución en el mejor de los casos) .
¿Alguna sugerencia sobre cómo introducir los datos en Lambda más rápido? El tipo de cosas que estoy imaginando es:
Extraiga sus datos de otro lugar donde Lambdas tenga un ancho de banda mucho mayor... pero ¿qué? ¿DynamoDB (dividido en tantos registros binarios de 400k como sea necesario)? ¿ElastiCache? Hay algo más en el "menú" de AWS que no he notado.
Utilice algún truco astuto (¿qué?) para "precalentar" las instancias lambda.
Está utilizando la herramienta completamente equivocada para el trabajo; usar... en su lugar? (Sin embargo, realmente me gusta el modelo Lambda; no hay necesidad de preocuparse por todo ese aprovisionamiento y escalado automático de instancias, solo concéntrese en la funcionalidad).
Si las ofertas similares a Lambda anunciadas recientemente por Google o Microsoft (sobre las cuales sé poco) tienen algún atributo que ayudaría mejor con este caso de uso, esa también sería información muy interesante.
Una opción que he contemplado es convertir los datos binarios en un "paquete de implementación", pero el límite de 250 MBytes es demasiado bajo para algunos casos de uso previstos (incluso si el blob estaba comprimido).
Respuesta1
Si el blob binario tiene solo unos pocos cientos de megabytes, puede incluirlo en su función como una "dependencia". Puede agregarlo como un archivo junto con su código y hacer referencia a él en consecuencia.
Otra opción sería tener dos funciones lambda. Una función no hace más que servir el blob (que usted crea como se indicó anteriormente enviando el blob con la función) y luego puede usar un temporizador (básicamente cron) para "hacerle cosquillas" a esa función cada minuto para mantenerla activa. Luego, su segunda lambda es la que hace el trabajo, y lo primero que hace al inicio es llamar a la primera lambda para obtener el blob. Las llamadas lambda a lambda tienen un gran ancho de banda, por lo que el tiempo de inicio no debería ser un problema.
La solución ideal sería encontrar una manera de resumir los datos y almacenarlos en DynamoDB, pero parece que intentó esa ruta y no tenía sentido para usted.