Introduction

Dans la partie 8, nous présentons le concept derrière la fonction Spring Cloud et dans la partie 9, nous avons démontré comment développer AWS Lambda avec Spring Cloud Function à l'aide de Java 21 et Spring Boot 3.2. Dans cet article de la série, nous mesurerons l'heure de démarrage à froid et à chaud, notamment en activant SnapStart sur la fonction Lambda, mais également en appliquant diverses techniques d'amorçage telles que l'amorçage de l'invocation DynamoDB et l'amorçage (proxy) de l'ensemble de la requête API Gateway sans passer par le réseau. . Nous utiliserons l'exemple d'application Spring Boot 3.2 pour nos mesures, et pour toutes les fonctions Lambda, nous utiliserons JAVA_TOOL_OPTIONS : "-XX: TieredCompilation -XX:TieredStopAtLevel=1" et leur attribuerons 1 024 Mo de mémoire Lambda.

Mesurer les démarrages à froid et les temps chauds avec Spring Cloud Function et utiliser Java 21 et Spring Boot 3.2

Commençons par expliquer comment activer AWS SnapStart sur la fonction Lambda, car elle (avec l'amorçage en haut) offre le plus grand potentiel d'optimisation des performances Lambda (en particulier les temps de démarrage à froid). Ce n'est qu'une question de configuration :

SnapStart:
  ApplyOn: PublishedVersions 

appliqué dans les propriétés de la fonction Lambda ou dans la section des fonctions globales du modèle SAM. J'aimerais approfondir la façon d'utiliser diverses techniques d'amorçage en plus de SnpaStart pour notre cas d'utilisation. J'ai expliqué les idées derrière l'amorçage dans mon article AWS Lambda SnapStart - Mesurer l'amorçage, la latence de bout en bout et le temps de déploiement

1) Le code pour l'amorçage de la requête DynamoDB peut être trouvé ici.

Cette classe implémente en outre l'interface import org.crac.Resource du projet CraC.

Avec cette invocation

Core.getGlobalContext().register(this);

La classe GetProductByIdWithDynamoDBRequestPrimingHandler s'enregistre en tant que ressource CRaC.

Nous améliorons également l'invocation DynamoDB en implémentant la méthode beforeCheckpoint à partir de l'API CRaC.

      @Override
      public void beforeCheckpoint(org.crac.Context extends Resource> context) throws Exception {
             productDao.getProduct("0");
      }

que nous appellerons pendant la phase de déploiement de la fonction Lambda et avant la prise de l'instantané de la microVM Firecracker.

2) Le code pour l'amorçage de l'ensemble de la requête API Gateway peut être trouvé ici.

Cette classe implémente également l'interface import org.crac.Resource comme dans l'exemple ci-dessus.
Nous réutiliserons la technique laide, que j'ai décrite dans mon article AWS Lambda SnapStart - Partie 6 Amorçage de l'invocation de requête pour les frameworks Java 11 et Micronaut, Quarkus et Spring Boot. Je ne recommande pas d'utiliser cette technique en production, mais elle démontre les potentiels supplémentaires de réduction du démarrage à froid en utilisant l'amorçage de l'ensemble de la requête API Gateway en préchargeant le mappage entre les modèles Spring Boot et Spring Cloud Function et le modèle Lambda exécutant également DynamoDB. amorçage d'invocation.

La construction de la requête API Gateway du /products/{id} avec l'identifiant est égal à 0. La requête API Gateway JSON ressemble à ceci :

      private static String getAPIGatewayRequestMultiLine () {
             return  """
                        {
                      "resource": "/products/{id}",
                      "path":  "/products/0",
                      "httpMethod": "GET",
                      "pathParameters": {
                            "id": "0" 
                        },
                       "requestContext": {
                          "identity": {
                        "apiKey": "blabla"
                      }
                      }
                    }
           """;
      }

Le beforeCheckpoint lorsqu'il amorce (proxies) l'ensemble de la requête API Gateway sans passer par le réseau à l'aide de la classe Spring Cloud Function FunctionInvoker qui invoque sa méthode handleRequest en transmettant le flux d'entrée de l'API Requête Gateway JSON construite ci-dessus comme ceci :

@Override
public void beforeCheckpoint(org.crac.Context extends Resource> context) throws Exception {
            
new FunctionInvoker().handleRequest( 
  new ByteArrayInputStream(getAPIGatewayRequestMultiLine().
  getBytes(StandardCharsets.UTF_8)),
  new ByteArrayOutputStream(), new MockLambdaContext());
}

Les résultats de l'expérience ci-dessous étaient basés sur la reproduction de plus de 100 démarrages à froid et d'environ 100 000 démarrages à chaud avec la fonction Lambda avec un réglage de mémoire de 1 024 Mo pour une durée d'1 heure. Pour cela, j'ai utilisé l'outil de test de charge, mais vous pouvez utiliser l'outil de votre choix, comme Serverless-artillerie ou Postman.

J'ai mené toutes ces expériences avec 4 scénarios différents :

1) Aucun SnapStart activé

Dans template.yaml, utilisez la configuration suivante :

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest    
      #SnapStart:
         #ApplyOn: PublishedVersions      

et nous devons invoquer la fonction Lambda avec le nom GetProductByIdWithSpringBoot32SCF qui est mappé à la classe Java GetProductByIdHandler Lambda Handler.

2) SnapStart activé mais aucun amorçage appliqué

Dans template.yaml, utilisez la configuration suivante :

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest 
    SnapStart:
      ApplyOn: PublishedVersions 

et nous devons invoquer la même fonction Lambda avec le nom GetProductByIdWithSpringBoot32SCF qui est mappée à la classe Java GetProductByIdHandler Lambda Handler.
3) SnapStart activé avec l'amorçage des invocations DynamoDB

Dans template.yaml, utilisez la configuration suivante :

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest    
    SnapStart:
      ApplyOn: PublishedVersions      

et nous devons invoquer la fonction Lambda avec le nom GetProductByIdWithSpringBoot32SCFAndDynamoDBRequestPriming qui est mappé à la classe Java GetProductByIdWithDynamoDBRequestPrimingHandler Lambda Handler.

4) SnapStart activé avec l'amorçage/le proxy d'appel de requête API Gateway

Dans template.yaml, utilisez la configuration suivante :

    Handler: org.springframework.cloud.function.adapter.aws.FunctionInvoker::handleRequest
    SnapStart:
      ApplyOn: PublishedVersions      

et nous devons invoquer la fonction Lambda avec le nom
GetProductByIdWithSpringBoot32SCFAndWebRequestPriming qui est mappé à la classe Java GetProductByIdWithWebRequestPrimingHandler Lambda Handler.

Abréviation c désigne le démarrage à froid et w désigne le démarrage à chaud.

Heure de démarrage à froid (c) et à chaud (w) en ms :

Conclusion

En activant SnapStart uniquement sur la fonction Lambda, cela réduit considérablement le temps de démarrage à froid de la fonction Lambda. En utilisant également l'amorçage des invocations DynamoDB, nous sommes en mesure d'obtenir des démarrages à froid légèrement supérieurs aux démarrages à froid décrits dans mon article AWS SnapStart - Mesure des démarrages à froid et à chaud avec Java 21 en utilisant différents paramètres de mémoire où nous avons mesuré les démarrages à froid et à chaud pour le Lambda pur. fonctionner sans utiliser de framework, y compris un paramètre de mémoire de 1 024 Mo, comme dans notre scénario.

En comparant les temps de démarrage à froid et à chaud que nous avons mesurés avec AWS Serverless Java Container dans l'article Mesurer les démarrages à froid et à chaud avec AWS Serverless Java Container et Mesurer les démarrages à froid et à chaud avec AWS Lambda Web Adapter, nous observons que la fonction Spring Cloud offre des temps de démarrage à froid plus élevés. des temps de démarrage supérieurs à ceux d'AWS Lambda Web Adaptor mais des temps de démarrage à froid assez comparables à ceux d'AWS Serverless Java Container (les résultats varient légèrement en fonction des percentiles). En termes de temps de démarrage/d'exécution à chaud, les 3 approches ont des résultats assez comparables, notamment en examinant les centiles inférieurs à 99,9.