Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Migra da KCL 2.x a KCL 3.x

Questo argomento fornisce istruzioni dettagliate per migrare il consumatore da KCL 2.x a KCL 3.x. Ti consigliamo di migrare a KCL 3.5 o versioni successive per utilizzare il formato a tabella singola. KCL 3.x supporta la migrazione sul posto dei consumatori di KCL 2.x. Puoi continuare a consumare i dati del tuo flusso di dati Kinesis mentre migri i tuoi lavoratori in modo continuativo.

Fase 1: prerequisiti

Prima di iniziare a usare KCL 3.x, assicurati di avere quanto segue:

Fase 2: Aggiungere dipendenze

Se stai usando Maven, aggiungi la seguente dipendenza al tuo file. pom.xml Assicurati di aver sostituito 3.x.x con l'ultima versione di KCL.

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

Se stai usando Gradle, aggiungi quanto segue al tuo file. build.gradle Assicurati di aver sostituito 3.x.x con l'ultima versione di KCL.

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

Puoi controllare l'ultima versione di KCL nel Maven Central Repository. https://search.maven.org/artifact/software.amazon.kinesis/amazon-kinesis-client

Fase 3: Imposta la configurazione relativa alla migrazione

Per migrare da KCL 2.x a KCL 3.x, devi impostare il seguente parametro di configurazione:

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

In questa fase, la tua applicazione rimane compatibile con KCL 2.x e la migrazione non viene avviata, il che ti consente di implementare in sicurezza la libreria KCL 3.x in tutta la tua flotta.

Dopo che tutti i lavoratori hanno eseguito conCLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1, imposta questa configurazione su per CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X avviare la migrazione. Per impostare questa configurazione, aggiungi la riga seguente durante la creazione dell'oggetto di pianificazione:

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

Quello che segue è un esempio di come impostare la CoordinatorConfig.clientVersionConfig migrazione da KCL 2.x a 3.x. Puoi regolare altre configurazioni secondo necessità in base ai tuoi requisiti specifici:

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

È importante che tutti i lavoratori dell'applicazione consumer utilizzino lo stesso algoritmo di bilanciamento del carico in un dato momento perché KCL 2.x e 3.x utilizzano algoritmi di bilanciamento del carico diversi. L'esecuzione di lavoratori con algoritmi di bilanciamento del carico diversi può causare una distribuzione del carico non ottimale poiché i due algoritmi funzionano in modo indipendente.

Questa impostazione di compatibilità con KCL 2.x consente all'applicazione KCL 3.x di funzionare in una modalità compatibile con KCL 2.x e di utilizzare l'algoritmo di bilanciamento del carico per KCL 2.x fino a quando tutti i worker dell'applicazione consumer non saranno aggiornati a KCL 3.x. Al termine della migrazione, KCL passerà automaticamente alla modalità con funzionalità complete di KCL 3.x e inizierà a utilizzare un nuovo algoritmo di bilanciamento del carico KCL 3.x per tutti i lavoratori in esecuzione.

Fase 4: Segui le migliori pratiche per l'implementazione del metodo shutdownRequested ()

KCL 3.x introduce una funzionalità chiamata graceful lease handoff per ridurre al minimo la rielaborazione dei dati quando un contratto di locazione viene consegnato a un altro lavoratore come parte del processo di riassegnazione del leasing. Ciò si ottiene inserendo l'ultimo numero di sequenza elaborato nella tabella del leasing prima della cessione del contratto di leasing. Per assicurarvi che il grazioso trasferimento del lease funzioni correttamente, dovete assicurarvi di richiamare l'oggetto all'interno del metodo della classe. checkpointer shutdownRequested RecordProcessor Se non state richiamando l'checkpointeroggetto all'interno del shutdownRequested metodo, potete implementarlo come illustrato nell'esempio seguente.

/**
 * 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);
    } 
}

Fase 5: Verifica i prerequisiti di KCL 3.x per la raccolta delle metriche relative ai lavoratori

KCL 3.x raccoglie le metriche di utilizzo della CPU, come l'utilizzo della CPU dai lavoratori, per bilanciare il carico tra i lavoratori in modo uniforme. Gli applicativi consumer possono essere eseguiti su Amazon EC2, Amazon ECS, Amazon EKS o. AWS Fargate KCL 3.x può raccogliere i parametri di utilizzo della CPU dai lavoratori solo quando sono soddisfatti i seguenti prerequisiti:

Amazon Elastic Compute Cloud(Amazon EC2)

Amazon Elastic Container Service (Amazon ECS) su Amazon EC2

Amazon ECS attivo AWS Fargate

Amazon Elastic Kubernetes Service (Amazon EKS) su Amazon EC2

Amazon EKS su AWS Fargate

Passaggio 6: aggiornamento delle autorizzazioni IAM per KCL 3.x

Devi aggiungere le seguenti autorizzazioni al ruolo o alla policy IAM associata alla tua applicazione consumer KCL 3.x. Ciò comporta l'aggiornamento della politica IAM esistente utilizzata dall'applicazione KCL. Per ulteriori informazioni, consulta Autorizzazioni IAM richieste per le applicazioni consumer KCL.

Passaggio 7: distribuisci il codice KCL 3.x ai tuoi dipendenti

Dopo aver impostato la configurazione richiesta per la migrazione e completato tutte le checklist precedenti per la migrazione, puoi creare e distribuire il codice ai tuoi lavoratori.

Fase 8: Completare la migrazione

Durante l'implementazione del codice KCL 3.x, KCL continua a utilizzare l'algoritmo di assegnazione del leasing di KCL 2.x. Quando hai distribuito con successo il codice KCL 3.x a tutti i tuoi lavoratori, KCL lo rileva automaticamente e passa al nuovo algoritmo di assegnazione del leasing basato sull'utilizzo delle risorse da parte dei lavoratori. Per maggiori dettagli sul nuovo algoritmo di assegnazione del leasing, vedi. In che modo KCL assegna i contratti di locazione ai lavoratori e bilancia il carico

Durante la distribuzione, è possibile monitorare il processo di migrazione con le seguenti metriche emesse a. CloudWatch È possibile monitorare le metriche nell'ambito dell'operazione. Migration Tutte le metriche sono KCL-application permetriche e impostate a livello di metrica. SUMMARY Se la Sum statistica della CurrentState:3xWorker metrica corrisponde al numero totale di lavoratori nella tua applicazione KCL, indica che la migrazione a KCL 3.x è stata completata con successo.

KCL fornisce la funzionalità di rollback alla modalità compatibile 2.x durante la migrazione. Una volta completata la migrazione a KCL 3.x, ti consigliamo di rimuovere l'CoordinatorConfig.clientVersionConfigimpostazione CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X se il rollback non è più necessario. La rimozione di questa configurazione interrompe l'emissione di metriche relative alla migrazione dall'applicazione KCL.