Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Migre de KCL 2.x a KCL 3.x

En este tema se proporcionan step-by-step instrucciones para migrar a su consumidor de KCL 2.x a KCL 3.x. KCL 3.x permite la migración local de los consumidores de KCL 2.x. Puede seguir consumiendo los datos de su flujo de datos de Kinesis y, al mismo tiempo, migrar a sus procesos de trabajo de forma continua.

Paso 1: requisitos previos

Antes de comenzar con KCL 3.x, asegúrese de que dispone de lo siguiente:

Paso 2: agregar dependencias

Si está utilizando Maven, agregue la siguiente dependencia a su archivo pom.xml. Asegúrese de reemplazar la versión 3.x.x por la versión más reciente de KCL.

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

Si está utilizando Gradle, agregue lo siguiente a su archivo build.gradle. Asegúrese de reemplazar la versión 3.x.x por la versión más reciente de KCL.

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

Puede buscar la versión más reciente del KCL en el Repositorio central de Maven.

Paso 3: configurar la configuración relacionada con la migración

Para migrar de KCL 2.x a KCL 3.x, debe establecer el siguiente parámetro de configuración:

configsBuilder.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_WITH_2X)

El siguiente es un ejemplo de cómo configurar CoordinatorConfig.clientVersionConfig para la migración de KCL 2.x a 3.x. Puede ajustar otras configuraciones según sea necesario según los requisitos específicos:

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

Es importante que todos los procesos de trabajo de la aplicación de consumo utilicen el mismo algoritmo de equilibrio de carga en un momento dado, ya que KCL 2.x y 3.x utilizan diferentes algoritmos de equilibrio de carga. Si los procesos de trabajo utilizan diferentes algoritmos de equilibrio de carga, es posible que la distribución de la carga no sea óptima, ya que los dos algoritmos funcionan de forma independiente.

Esta configuración de compatibilidad con KCL 2.x permite que la aplicación KCL 3.x se ejecute en un modo compatible con KCL 2.x y utilice el algoritmo de equilibrio de carga para KCL 2.x hasta que todos los procesos de trabajo de la aplicación de consumo se hayan actualizado a KCL 3.x. Cuando se complete la migración, KCL cambiará automáticamente al modo de funcionalidad completa de KCL 3.x y empezará a utilizar un nuevo algoritmo de equilibrio de carga de KCL 3.x para todos los procesos de trabajo en ejecución.

Paso 4: seguir las prácticas recomendadas para la implementación del método shutdownRequested()

KCL 3.x presenta una característica denominada transferencia ágil de arrendamientos para minimizar el reprocesamiento de datos cuando se entrega un arrendamiento a otro proceso de trabajo como parte del proceso de reasignación del arrendamiento. Ello se logra mediante el registro de puntos de control en el último número de secuencia procesado en la tabla de arrendamiento antes de la transferencia del arrendamiento. Para garantizar que el traspaso del arrendamiento se realiza correcto, debe asegurarse de invocar el objeto checkpointer según el método shutdownRequested en su clase RecordProcessor. Si no está invocando el objeto checkpointer dentro del método shutdownRequested, puede implementarlo como se ilustra en el siguiente ejemplo.

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

Paso 5: revisar los requisitos previos de la KCL 3.x para recopilar las métricas de los procesos de trabajo.

KCL 3.x recopila métricas de uso de la CPU, como el uso de la CPU por parte de los procesos de trabajo, para equilibrar la carga entre los procesos de trabajo de manera uniforme. Los trabajadores de aplicaciones de consumo pueden ejecutar en Amazon EC2, Amazon ECS, Amazon EKS oAWS Fargate. KCL 3.x puede recopilar métricas de uso de la CPU de los procesos de trabajo únicamente cuando se cumplan los siguientes requisitos previos:

Amazon Elastic Compute Cloud(Amazon EC2)

Amazon Elastic Container Service (Amazon ECS) en Amazon EC2

Amazon ECS en AWS Fargate

Amazon Elastic Kubernetes Service (Amazon EKS) en Amazon EC2

Amazon EKS en AWS Fargate

Paso 6: actualizar los permisos de IAM para KCL 3.x

Debe agregar los siguientes permisos al rol o la política de IAM asociada a su aplicación de consumo de KCL 3.x. Esto implica actualizar la política de IAM existente que utiliza la aplicación KCL. Para obtener más información, consulte Permisos de IAM necesarios para las aplicaciones de consumo de KCL.

Paso 7: implementar el código KCL 3.x para sus procesos de trabajo

Tras haber establecido la configuración necesaria para la migración y haber completado todas las listas de verificación anteriores, podrá crear e implementar el código para sus procesos de trabajo.

Paso 8: completar la migración

Durante la implementación del código KCL 3.x, KCL sigue utilizando el algoritmo de asignación de arrendamientos de KCL 2.x. Cuando haya implementado correctamente el código KCL 3.x en todos sus procesos de trabajo, KCL lo detectará automáticamente y pasará al nuevo algoritmo de asignación de arrendamientos según la utilización de los recursos de los procesos de trabajo. Para obtener más información sobre el nuevo algoritmo de asignación de arrendamiento, consulte Cómo KCL asigna los arrendamientos a los procesos de trabajo y equilibra la carga.

Durante la implementación, puede supervisar el proceso de migración con las siguientes métricas emitidas a CloudWatch. Puede supervisar las métricas de la operación Migration. Todas las métricas son per-KCL-application métricas y se configuran en el nivel de SUMMARY métrica. Si la estadística Sum de la métrica CurrentState:3xWorker coincide con el número total de procesos de trabajo de su aplicación de KCL, indica que la migración a KCL 3.x se ha completado correctamente.

El KCL ofrece la capacidad de reversión al modo compatible con la versión 2.x durante la migración. Si la migración a KCL 3.x se realiza correctamente, recomendamos eliminar la configuración CoordinatorConfig.clientVersionConfig de CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X si la reversión ya no es necesaria. Al eliminar esta configuración, se detiene la emisión de métricas relacionadas con la migración desde la aplicación KCL.