Réduisez le temps de démarrage du SDK pour AWS Lambda - AWS SDK for Java 2.x

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Réduisez le temps de démarrage du SDK pour AWS Lambda

L'un des objectifs du AWS SDK for Java 2.x est de réduire la latence de démarrage des AWS Lambda fonctions. Le SDK contient des modifications qui réduisent le temps de démarrage, qui sont abordées à la fin de cette rubrique.

Tout d'abord, cette rubrique se concentre sur les modifications que vous pouvez apporter pour réduire les temps de démarrage à froid. Il s'agit notamment de modifier la structure de votre code et la configuration des clients de service.

Utiliser un client AWS HTTP CRT

Pour travailler avec AWS Lambda, nous recommandons l'utilisation AwsCrtHttpClientpour les scénarios synchrones et celle AwsCrtAsyncHttpClientpour les scénarios asynchrones.

La Configuration de clients AWS HTTP basés sur CRT rubrique de ce guide décrit les avantages de l'utilisation des clients HTTP, comment ajouter la dépendance et comment configurer leur utilisation par les clients de service.

Supprimer les dépendances du client HTTP inutilisées

Outre l'utilisation explicite d'un client AWS CRT, vous pouvez supprimer d'autres clients HTTP introduits par défaut par le SDK. Le temps de démarrage de Lambda est réduit lorsque moins de bibliothèques doivent être chargées. Vous devez donc supprimer tous les artefacts inutilisés que la machine virtuelle Java doit charger.

L'extrait de pom.xml fichier Maven suivant montre l'exclusion du client HTTP basé sur Apache et du client HTTP basé sur Netty. (Ces clients ne sont pas nécessaires lorsque vous utilisez un client AWS CRT.) Cet exemple exclut les artefacts du client HTTP de la dépendance du client S3 et ajoute l'aws-crt-clientartefact pour autoriser l'accès aux clients HTTP AWS basés sur CRT.

<project> <properties> <aws.java.sdk.version>2.25.51</aws.java.sdk.version> <properties> <dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>bom</artifactId> <version>${aws.java.sdk.version}</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>aws-crt-client</artifactId> </dependency> <dependency> <groupId>software.amazon.awssdk</groupId> <artifactId>s3</artifactId> <exclusions> <exclusion> <groupId>software.amazon.awssdk</groupId> <artifactId>netty-nio-client</artifactId> </exclusion> <exclusion> <groupId>software.amazon.awssdk</groupId> <artifactId>apache-client</artifactId> </exclusion> </exclusions> </dependency> </dependencies> </project>
Note

Ajoutez l'<exclusions>élément à toutes les dépendances des clients de service dans votre pom.xml fichier.

Configuration des clients de service pour des recherches de raccourcis

Spécifiez une région

Lorsque vous créez un client de service, appelez la region méthode dans le générateur de clients de services. Cela permet de raccourcir le processus de recherche de région par défaut du SDK, qui vérifie les Région AWS informations à plusieurs endroits.

Pour que le code Lambda reste indépendant de la région, utilisez le code suivant dans la region méthode. Ce code accède à la variable d'AWS_REGIONenvironnement définie par le conteneur Lambda.

Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable()))
Utilisation de la EnvironmentVariableCredentialProvider

Tout comme le comportement de recherche par défaut pour les informations de région, le SDK recherche les informations d'identification à plusieurs endroits. En spécifiant le EnvironmentVariableCredentialProvidermoment où vous créez un client de service, vous gagnez du temps dans le processus de recherche du SDK.

Note

L'utilisation de ce fournisseur d'informations d'identification permet d'utiliser le code dans Lambda les fonctions, mais risque de ne pas fonctionner sur Amazon EC2 d'autres systèmes.

L'extrait de code suivant montre un client de service S3 correctement configuré pour être utilisé dans un environnement Lambda.

S3Client s3Client = S3Client.builder() .region(Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable()))) .credentialsProvider(EnvironmentVariableCredentialsProvider.create()) .httpClient(AwsCrtHttpClient.builder().build()) .build();

Initialisez le client SDK en dehors du gestionnaire de fonctions Lambda

Nous recommandons d'initialiser un client SDK en dehors de la méthode du gestionnaire Lambda. Ainsi, si le contexte d'exécution est réutilisé, l'initialisation du client de service peut être ignorée. En réutilisant l'instance cliente et ses connexions, les appels ultérieurs de la méthode du gestionnaire se produisent plus rapidement.

Dans l'exemple suivant, l'S3Clientinstance est initialisée dans le constructeur à l'aide d'une méthode d'usine statique. Si le conteneur géré par l'environnement Lambda est réutilisé, l'instance initialisée S3Client est réutilisée.

public class App implements RequestHandler<Object, Object> { private final S3Client s3Client; public App() { s3Client = DependencyFactory.s3Client(); } @Override public Object handle Request(final Object input, final Context context) { ListBucketResponse response = s3Client.listBuckets(); // Process the response. } }

Minimiser l'injection de dépendance

Les frameworks d'injection de dépendances (DI) peuvent prendre plus de temps pour terminer le processus de configuration. Ils peuvent également nécessiter des dépendances supplémentaires, dont le chargement prend du temps.

Si un framework DI est nécessaire, nous vous recommandons d'utiliser des frameworks DI légers tels que Dagger.

Utilisez un archétype de ciblage Maven AWS Lambda

L'équipe du SDK AWS Java a développé un modèle Maven Archetype pour démarrer un projet Lambda avec un temps de démarrage minimal. Vous pouvez créer un projet Maven à partir de l'archétype et savoir que les dépendances sont configurées de manière appropriée pour l'environnement Lambda.

Pour en savoir plus sur l'archétype et travailler sur un exemple de déploiement, consultez ce billet de blog.

Pensez à Lambda SnapStart pour Java

Si vos exigences d'exécution sont compatibles, AWS Lambda SnapStart pour Java est disponible. Lambda SnapStart est une solution basée sur l'infrastructure qui améliore les performances de démarrage des fonctions Java. Lorsque vous publiez une nouvelle version d'une fonction, Lambda l' SnapStart initialise et prend un instantané chiffré immuable de l'état de la mémoire et du disque. SnapStart met ensuite en cache l'instantané pour le réutiliser.

Modifications de la version 2.x qui affectent le temps de démarrage

Outre les modifications que vous apportez à votre code, la version 2.x du SDK pour Java inclut trois modifications principales qui réduisent le temps de démarrage :

  • Utilisation de jackson-jr, une bibliothèque de sérialisation qui améliore le temps d'initialisation

  • Utilisation des bibliothèques java.time pour les objets de date et d'heure, qui font partie du JDK

  • Utilisation du SLF4j pour une façade en bois

Ressources supplémentaires

Le Guide du AWS Lambda développeur contient une section sur les meilleures pratiques pour le développement de fonctions Lambda qui n'est pas spécifique à Java.

Pour un exemple de création d'une application native pour le cloud en Java qui utilise AWS Lambda, consultez le contenu de cet atelier. L'atelier traite de l'optimisation des performances et d'autres meilleures pratiques.

Vous pouvez envisager d'utiliser des images statiques compilées à l'avance pour réduire le temps de latence au démarrage. Par exemple, vous pouvez utiliser le SDK pour Java 2.x et Maven pour créer une image native de GraalVM.