Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Migrieren Sie von KCL 2.x zu KCL 3.x

Dieses Thema enthält schrittweise Anweisungen zur Migration Ihres Consumer von KCL 2.x zu KCL 3.x. Wir empfehlen, auf KCL 3.5 oder höher zu migrieren, um das Einzeltabellenformat zu verwenden. KCL 3.x unterstützt die direkte Migration von KCL 2.x-Verbrauchern. Sie können die Daten aus Ihrem Kinesis-Datenstrom weiterhin nutzen und gleichzeitig Ihre Mitarbeiter fortlaufend migrieren.

Schritt 1: Voraussetzungen

Bevor Sie mit der Verwendung von KCL 3.x beginnen, stellen Sie sicher, dass Sie über Folgendes verfügen:

Schritt 2: Abhängigkeiten hinzufügen

Wenn Sie Maven verwenden, fügen Sie Ihrer pom.xml Datei die folgende Abhängigkeit hinzu. Stellen Sie sicher, dass Sie 3.x.x durch die neueste KCL-Version ersetzt haben.

<dependency>
    <groupId>software.amazon.kinesis</groupId>
    <artifactId>amazon-kinesis-client</artifactId>
    <version>3.x.x</version> <!-- Use the latest version -->
</dependency>

Wenn Sie Gradle verwenden, fügen Sie Ihrer Datei Folgendes hinzu. build.gradle Stellen Sie sicher, dass Sie 3.x.x durch die neueste KCL-Version ersetzt haben.

implementation 'software.amazon.kinesis:amazon-kinesis-client:3.x.x'

Sie können im Maven Central Repository nach der neuesten Version der KCL suchen. https://search.maven.org/artifact/software.amazon.kinesis/amazon-kinesis-client

Schritt 3: Richten Sie die migrationsbezogene Konfiguration ein

Um von KCL 2.x zu KCL 3.x zu migrieren, müssen Sie den folgenden Konfigurationsparameter festlegen:

configsBuilder.coordinatorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1)

In dieser Phase bleibt Ihre Anwendung mit KCL 2.x kompatibel und die Migration beginnt nicht, sodass Sie die KCL 3.x-Bibliothek sicher in Ihrer gesamten Flotte bereitstellen können.

Nachdem alle Worker damit arbeitenCLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1, stellen Sie diese Konfiguration auf ein, um die Migration CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X zu starten. Um diese Konfiguration festzulegen, fügen Sie beim Erstellen Ihres Scheduler-Objekts die folgende Zeile hinzu:

configsBuilder.coordinatorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X)

Im Folgenden finden Sie ein Beispiel dafür, wie Sie die CoordinatorConfig.clientVersionConfig für die Migration von KCL 2.x nach 3.x einrichten. Sie können andere Konfigurationen je nach Bedarf an Ihre spezifischen Anforderungen anpassen:

Scheduler scheduler = new Scheduler(
    configsBuilder.checkpointConfig(),
    configsBuilder.coordinatorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X),
    configsBuilder.leaseManagementConfig(),
    configsBuilder.lifecycleConfig(),
    configsBuilder.metricsConfig(),
    configsBuilder.processorConfig(),
    configsBuilder.retrievalConfig()
);

Es ist wichtig, dass alle Worker in Ihrer Consumer-Anwendung zu einem bestimmten Zeitpunkt denselben Load Balancing-Algorithmus verwenden, da KCL 2.x und 3.x unterschiedliche Load-Balancing-Algorithmen verwenden. Wenn Workers mit unterschiedlichen Load-Balancing-Algorithmen betrieben werden, kann dies zu einer suboptimalen Lastverteilung führen, da die beiden Algorithmen unabhängig voneinander arbeiten.

Diese KCL 2.x-Kompatibilitätseinstellung ermöglicht es Ihrer KCL 3.x-Anwendung, in einem mit KCL 2.x kompatiblen Modus zu laufen und den Load Balancing-Algorithmus für KCL 2.x zu verwenden, bis alle Worker in Ihrer Consumer-Anwendung auf KCL 3.x aktualisiert wurden. Wenn die Migration abgeschlossen ist, wechselt KCL automatisch in den vollen KCL 3.x-Funktionsmodus und beginnt, einen neuen KCL 3.x-Load-Balancing-Algorithmus für alle laufenden Worker zu verwenden.

Schritt 4: Folgen Sie den bewährten Methoden für die Implementierung der shutdownRequested () -Methode

KCL 3.x führt eine Funktion namens Graceful Lease Handoff ein, um die erneute Verarbeitung von Daten zu minimieren, wenn ein Mietvertrag im Rahmen der Neuzuweisung eines Mietvertrags an einen anderen Mitarbeiter übergeben wird. Dies wird erreicht, indem die zuletzt verarbeitete Sequenznummer in der Leasing-Tabelle vor der Leasingübergabe überprüft wird. Um sicherzustellen, dass das Graceful Lease Handoff ordnungsgemäß funktioniert, müssen Sie sicherstellen, dass Sie das checkpointer Objekt innerhalb der shutdownRequested Methode in Ihrer Klasse aufrufen. RecordProcessor Wenn Sie das checkpointer Objekt nicht innerhalb der shutdownRequested Methode aufrufen, können Sie es wie im folgenden Beispiel veranschaulicht implementieren.

/**
 * Invoked when either Scheduler has been requested to gracefully shutdown
 * or lease ownership is being transferred gracefully so the current owner
 * gets one last chance to checkpoint.
 *
 * Checkpoints and logs the data a final time.
 *
 * @param shutdownRequestedInput Provides access to a checkpointer, allowing a record processor to checkpoint
 *                               before the shutdown is completed.
 */
public void shutdownRequested(ShutdownRequestedInput shutdownRequestedInput) {
    try {
       // Ensure that all delivered records are processed 
       // and has been successfully flushed to the downstream before calling 
       // checkpoint
       // If you are performing any asynchronous processing or flushing to
       // downstream, you must wait for its completion before invoking
       // the below checkpoint method.
        log.info("Scheduler is shutting down, checkpointing.");
        shutdownRequestedInput.checkpointer().checkpoint();
    } catch (ShutdownException | InvalidStateException e) {
        log.error("Exception while checkpointing at requested shutdown. Giving up.", e);
    } 
}

Schritt 5: Prüfen Sie die KCL 3.x-Voraussetzungen für die Erfassung von Personalkennzahlen

KCL 3.x erfasst Kennzahlen zur CPU-Auslastung, wie z. B. die CPU-Auslastung der Mitarbeiter, um die Auslastung der Mitarbeiter gleichmäßig zu verteilen. Consumer-Anwendungen können Worker auf Amazon EC2, Amazon ECS, Amazon EKS oder ausführen. AWS Fargate KCL 3.x kann CPU-Auslastungsmetriken von Workern nur dann erfassen, wenn die folgenden Voraussetzungen erfüllt sind:

Amazon Elastic Compute Cloud(Amazon EC2)

Amazon Elastic Container Service (Amazon ECS) auf Amazon EC2

Amazon ECS aktiviert AWS Fargate

Amazon Elastic Kubernetes Service (Amazon EKS) auf Amazon EC2

Amazon EKS an AWS Fargate

Schritt 6: Aktualisieren Sie die IAM-Berechtigungen für KCL 3.x

Sie müssen der IAM-Rolle oder -Richtlinie, die Ihrer KCL 3.x-Verbraucheranwendung zugeordnet ist, die folgenden Berechtigungen hinzufügen. Dazu gehört die Aktualisierung der vorhandenen IAM-Richtlinie, die von der KCL-Anwendung verwendet wird. Weitere Informationen finden Sie unter Für KCL-Verbraucheranwendungen sind IAM-Berechtigungen erforderlich.

Schritt 7: Stellen Sie Ihren Mitarbeitern den KCL 3.x-Code zur Verfügung

Nachdem Sie die für die Migration erforderliche Konfiguration festgelegt und alle vorherigen Migrationschecklisten abgeschlossen haben, können Sie Ihren Code erstellen und für Ihre Mitarbeiter bereitstellen.

Schritt 8: Schließen Sie die Migration ab

Während der Bereitstellung von KCL 3.x-Code verwendet KCL weiterhin den Lease-Zuweisungsalgorithmus von KCL 2.x. Wenn Sie den KCL 3.x-Code erfolgreich für alle Ihre Mitarbeiter bereitgestellt haben, erkennt KCL dies automatisch und wechselt auf den neuen Algorithmus für die Leasingzuweisung, der auf der Ressourcenauslastung der Mitarbeiter basiert. Weitere Informationen zum neuen Algorithmus für die Vertragszuweisung finden Sie unter. Wie KCL den Arbeitern Leasingverträge zuweist und die Last ausgleicht

Während der Bereitstellung können Sie den Migrationsprozess anhand der folgenden Metriken überwachen, die an gesendet CloudWatch werden. Sie können die Metriken im Rahmen des Migration Vorgangs überwachen. Alle Metriken sind pro KCL-application SUMMARY Metrik und auf Metrikebene festgelegt. Wenn die Sum Statistik der CurrentState:3xWorker Metrik mit der Gesamtzahl der Worker in Ihrer KCL-Anwendung übereinstimmt, bedeutet dies, dass die Migration zu KCL 3.x erfolgreich abgeschlossen wurde.

KCL bietet während der Migration die Möglichkeit, in den 2.x-kompatiblen Modus zurückzukehren. Nach erfolgreicher Migration zu KCL 3.x empfehlen wir Ihnen, die CoordinatorConfig.clientVersionConfig Einstellung zu entfernen, CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X falls ein Rollback nicht mehr erforderlich ist. Wenn Sie diese Konfiguration entfernen, werden keine migrationsbezogenen Metriken mehr aus der KCL-Anwendung ausgegeben.