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

L'un des objectifs 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 d'apporter des modifications à la structure de votre code et à la configuration des clients de service.

Utilisez un AWS CRT-based client HTTP

Pour travailler avec AWS Lambda, nous recommandons les options AwsCrtHttpClient pour les scénarios synchrones et AwsCrtAsyncHttpClient pour 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 inutilisées du client HTTP

Outre l'utilisation explicite d'un AWS CRT-based client, vous pouvez supprimer d'autres clients HTTP que le SDK intègre par défaut. 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 JVM doit charger.

L'extrait suivant d'un pom.xml fichier Maven montre l'exclusion du client Apache-based HTTP et du Netty-based client HTTP. (Ces clients ne sont pas nécessaires lorsque vous utilisez un AWS CRT-based client.) 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 AWS CRT-based HTTP.

<project>
    <properties>
        <aws.java.sdk.version>2.27.21</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 de votre pom.xml fichier.

Configurer les clients de service pour rechercher des raccourcis

Spécifiez une région

Lorsque vous créez un client de service, appelez la region méthode sur le générateur de clients de service. 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 EnvironmentVariableCredentialProvider moment où vous créez un client de service, vous gagnez du temps dans le processus de recherche des informations d'identification du SDK.

Note

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

Si vous avez l'intention d'utiliser Lambda SnapStart pour Java à un moment donné, vous devez vous fier à la chaîne de fournisseurs d'informations d'identification par défaut pour rechercher les informations d'identification. Si vous spécifiez leEnvironmentVariableCredentialsProvider, la recherche initiale des informations d'identification fonctionne, mais lorsqu'elle SnapStart est activée, le moteur d'exécution Java définit les variables d'environnement des informations d'identification du conteneur. Lors de l'activation, les variables d'environnement utilisées par les variables d'environnement EnvironmentVariableCredentialsProvider —access key — ne sont pas disponibles dans le SDK Java.

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();

Initialiser le client du SDK en dehors du gestionnaire de fonctions Lambda

Nous vous 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 de fabrique statique. Si le conteneur géré par l'environnement Lambda est réutilisé, l'S3Clientinstance initialisée 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 Maven pour cibler 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 en sachant 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 découvrir un exemple de déploiement, consultez ce billet de blog.

Pensez à Lambda SnapStart pour Java

Si vos exigences d'exécution sont compatibles, AWS propose Lambda SnapStart pour Java. 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 l'instantané en cache pour le réutiliser.

Pour profiter pleinement des avantages du démarrage SnapStart, utilisez l'SdkWarmUpAPI pour préchauffer tous vos clients SDK avant que Lambda ne prenne le snapshot. L'instantané capture ensuite les clients réchauffés, de sorte que chaque fonction restaurée démarre avec eux prêts. Pour de plus amples informations, veuillez consulter Envisagez de configurer les clients du SDK avec SdkWarmUp.

Envisagez de configurer les clients du SDK avec SdkWarmUp

L'SdkWarmUpAPI du AWS SDK for Java 2.x réchauffe vos clients du SDK lors de l'initialisation de l'application. Par conséquent, votre premier appel d'API de service est plus rapide. L'échauffement crée un client et invoque une opération pour exercer le chemin de demande du SDK. Cela se produit avant que votre application ne gère le trafic réel. En un seul appel, vous pouvez activer tous les clients SDK de votre chemin de classe, ou uniquement les clients spécifiques utilisés par votre application.

Vous pouvez utiliser l'SdkWarmUpAPI avec des fonctionnalités Lambda qui réduisent les démarrages à froid, telles que Lambda SnapStart et la simultanéité provisionnée. Pour plus d'informations sur la configuration et l'utilisationSdkWarmUp, consultezRéchauffez les clients du SDK dans le AWS SDK for Java 2.x.

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 de 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 développer des fonctions Lambda qui n'est pas spécifique à Java.

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

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