Reduzieren Sie die SDK-Startzeit für AWS Lambda

Eines der Ziele von AWS SDK for Java 2.x ist es, die Startlatenz für AWS Lambda Funktionen zu reduzieren. Das SDK enthält Änderungen, die die Startzeit verkürzen. Diese werden am Ende dieses Themas behandelt.

Zunächst konzentriert sich dieses Thema auf Änderungen, die Sie vornehmen können, um die Kaltstartzeiten zu verkürzen. Dazu gehören Änderungen an Ihrer Codestruktur und an der Konfiguration von Service-Clients.

Verwenden Sie eine AWS CRT-based HTTP-Client

Für die Arbeit mit AWS Lambda empfehlen wir den AwsCrtHttpClient für synchrone Szenarien und den AwsCrtAsyncHttpClient für asynchrone Szenarien.

Das AWS CRT-basierte HTTP-Clients konfigurieren Thema in diesem Handbuch beschreibt die Vorteile der Verwendung von HTTP-Clients, das Hinzufügen der Abhängigkeit und die Konfiguration ihrer Verwendung durch Service-Clients.

Entfernen Sie ungenutzte HTTP-Client-Abhängigkeiten

Neben der ausdrücklichen Verwendung eines AWS CRT-based Clients können Sie auch andere HTTP-Clients entfernen, die das SDK standardmäßig einbindet. Die Lambda-Startzeit wird reduziert, wenn weniger Bibliotheken geladen werden müssen. Sie sollten daher alle ungenutzten Artefakte entfernen, die die JVM laden muss.

Der folgende Ausschnitt einer pom.xml Maven-Datei zeigt den Ausschluss des HTTP-Clients und des Apache-based HTTP-Clients. Netty-based (Diese Clients werden nicht benötigt, wenn Sie einen AWS CRT-based Client verwenden.) In diesem Beispiel werden die HTTP-Client-Artefakte aus der S3-Client-Abhängigkeit ausgeschlossen und das aws-crt-client Artefakt hinzugefügt, um den Zugriff auf die AWS CRT-based HTTP-Clients zu ermöglichen.

<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>

Anmerkung

Fügen Sie das <exclusions> Element zu allen Service-Client-Abhängigkeiten in Ihrer pom.xml Datei hinzu.

Konfigurieren Sie die Service-Clients so, dass sie bei der Suche eine Verknüpfung herstellen

Geben Sie eine Region an

Wenn Sie einen Service Client erstellen, rufen Sie die region Methode im Service Client Builder auf. Dadurch wird der standardmäßige Regions-Suchvorgang des SDK verkürzt, bei dem an mehreren Stellen nach den AWS-Region Informationen gesucht wird.

Um den Lambda-Code unabhängig von der Region zu halten, verwenden Sie den folgenden Code innerhalb der region Methode. Dieser Code greift auf die vom AWS_REGION Lambda-Container festgelegte Umgebungsvariable zu.

Region.of(System.getenv(SdkSystemSetting.AWS_REGION.environmentVariable()))

Verwenden der EnvironmentVariableCredentialProvider

Ähnlich wie beim standardmäßigen Suchverhalten für die Regionsinformationen sucht das SDK an mehreren Stellen nach Anmeldeinformationen. Indem Sie angeben, EnvironmentVariableCredentialProvider wann Sie einen Service-Client erstellen, sparen Sie Zeit bei der Suche nach Anmeldeinformationen im SDK.

Anmerkung

Durch die Verwendung dieses Anbieters für Anmeldeinformationen kann der Code in Lambda Funktionen verwendet werden, funktioniert aber möglicherweise nicht auf Amazon EC2 anderen Systemen.

Wenn Sie Lambda SnapStart für Java irgendwann verwenden möchten, sollten Sie sich bei der Suche nach Anmeldeinformationen auf die standardmäßige Anbieterkette für Anmeldeinformationen verlassen. Wenn Sie die angebenEnvironmentVariableCredentialsProvider, funktioniert die anfängliche Suche nach Anmeldeinformationen, aber wenn sie aktiviert SnapStart ist, legt die Java-Laufzeitumgebung Umgebungsvariablen für Container-Anmeldeinformationen fest. Bei der Aktivierung sind die Umgebungsvariablen, die von den Umgebungsvariablen EnvironmentVariableCredentialsProvider —access key verwendet werden, für das Java SDK nicht verfügbar.

Der folgende Codeausschnitt zeigt einen S3-Serviceclient, der entsprechend für die Verwendung in einer Lambda-Umgebung konfiguriert ist.

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

Initialisieren Sie den SDK-Client außerhalb des Lambda-Funktionshandlers

Wir empfehlen, einen SDK-Client außerhalb der Lambda-Handler-Methode zu initialisieren. Auf diese Weise kann die Initialisierung des Service-Clients übersprungen werden, wenn der Ausführungskontext wiederverwendet wird. Durch die Wiederverwendung der Client-Instanz und ihrer Verbindungen erfolgen nachfolgende Aufrufe der Handler-Methode schneller.

Im folgenden Beispiel wird die S3Client Instanz im Konstruktor mithilfe einer statischen Factory-Methode initialisiert. Wenn der Container, der von der Lambda-Umgebung verwaltet wird, wiederverwendet wird, wird die S3Client initialisierte Instanz wiederverwendet.

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.
    }
}

Minimieren Sie das Einfügen von Abhängigkeiten

Für Frameworks zur Dependency Injection (DI) kann es zusätzliche Zeit in Anspruch nehmen, bis der Einrichtungsvorgang abgeschlossen ist. Sie benötigen möglicherweise auch zusätzliche Abhängigkeiten, deren Laden einige Zeit in Anspruch nimmt.

Wenn ein DI-Framework benötigt wird, empfehlen wir die Verwendung leichter DI-Frameworks wie Dagger.

Verwenden Sie ein Maven-Archetyp-Targeting AWS Lambda

Das AWS Java SDK-Team hat eine https://github.com/aws/aws-sdk-java-v2/tree/master/archetypes/archetype-lambda Maven-Archetype-Vorlage entwickelt, um ein Lambda-Projekt mit minimaler Startzeit zu booten. Sie können ein Maven-Projekt anhand des Archetyps erstellen und wissen, dass die Abhängigkeiten für die Lambda-Umgebung geeignet konfiguriert sind.

Um mehr über den Archetyp zu erfahren und eine Beispielbereitstellung durchzuarbeiten, lesen Sie diesen Blogbeitrag. https://aws.amazon.com/blogs/developer/bootstrapping-a-java-lambda-application-with-minimal-aws-java-sdk-startup-time-using-maven/

Ziehen Sie SnapStart Lambda für Java in Betracht

Wenn Ihre Laufzeitanforderungen kompatibel sind, AWS bietet Lambda SnapStart für Java an. Lambda SnapStart ist eine infrastrukturbasierte Lösung, die die Startleistung für Java-Funktionen verbessert. Wenn Sie eine neue Version einer Funktion veröffentlichen, SnapStart initialisiert Lambda sie und erstellt einen unveränderlichen, verschlüsselten Snapshot des Speicher- und Festplattenzustands. SnapStart speichert dann den Snapshot zur Wiederverwendung im Cache.

Um alle Vorteile beim Start voll auszuschöpfen SnapStart, verwenden Sie die SdkWarmUp API, um alle Ihre SDK-Clients aufzuwärmen, bevor Lambda den Snapshot erstellt. Der Snapshot erfasst dann die erwärmten Clients, sodass jede wiederhergestellte Funktion damit beginnt, dass sie bereit sind. Weitere Informationen finden Sie unter Erwägen Sie das Aufwärmen der SDK-Clients mit SdkWarmUp.

Erwägen Sie das Aufwärmen der SDK-Clients mit SdkWarmUp

Die SdkWarmUp API in der AWS SDK for Java 2.x wärmt Ihre SDK-Clients während der Anwendungsinitialisierung auf. Infolgedessen ist Ihr erster Service-API-Aufruf schneller. Beim Aufwärmen wird ein Client erstellt und eine Operation aufgerufen, um den SDK-Anforderungspfad auszuführen. Dies geschieht, bevor Ihre Anwendung den tatsächlichen Datenverkehr verarbeitet. Mit einem einzigen Aufruf können Sie alle SDK-Clients in Ihrem Classpath oder nur die spezifischen Clients, die Ihre Anwendung verwendet, warmlaufen lassen.

Sie können die SdkWarmUp API mit Lambda-Funktionen verwenden, die Kaltstarts reduzieren, wie SnapStart Lambda und Provisioned Concurrency. Weitere Informationen zur Konfiguration und Verwendung finden Sie unter. SdkWarmUp Wärmen Sie die SDK-Clients in der AWS SDK for Java 2.x

Änderungen in Version 2.x, die sich auf die Startzeit auswirken

Zusätzlich zu den Änderungen, die Sie an Ihrem Code vornehmen, enthält Version 2.x des SDK für Java drei Hauptänderungen, die die Startzeit verkürzen:

• Verwendung von jackson-jr, einer Serialisierungsbibliothek, die die Initialisierungszeit verbessert

• Verwendung der https://docs.oracle.com/javase/8/docs/api/index.html?java/time.html java.time-Bibliotheken für Datums- und Uhrzeitobjekte, die Teil des JDK sind

• Verwendung von https://www.slf4j.org/ SLF4j für eine Holzfassade

Weitere Ressourcen

Das AWS Lambda Entwicklerhandbuch enthält einen Abschnitt mit bewährten Methoden für die Entwicklung von Lambda-Funktionen, der nicht Java-spezifisch ist.

Ein Beispiel für die Erstellung einer Cloud-nativen Anwendung in Java, die Folgendes verwendet AWS Lambda, finden Sie in diesem Workshop-Inhalt. Im Workshop werden Leistungsoptimierung und andere bewährte Verfahren erörtert.

Sie können erwägen, statische Images zu verwenden, die im Voraus kompiliert wurden, um die Startlatenz zu reduzieren. Sie können beispielsweise das SDK für Java 2.x und Maven verwenden, um ein natives GraalVM-Image zu erstellen.