Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Bermigrasi dari KCL 2.x ke KCL 3.x

Topik ini memberikan petunjuk langkah demi langkah untuk memigrasikan konsumen Anda dari KCL 2.x ke KCL 3.x. Sebaiknya migrasi ke KCL 3.5 atau yang lebih baru untuk menggunakan format tabel tunggal. KCL 3.x mendukung migrasi konsumen KCL 2.x di tempat. Anda dapat terus menggunakan data dari aliran data Kinesis Anda sambil memigrasikan pekerja Anda secara bergulir.

Langkah 1: Prasyarat

Sebelum Anda mulai menggunakan KCL 3.x, pastikan Anda memiliki yang berikut:

Langkah 2: Tambahkan dependensi

Jika Anda menggunakan Maven, tambahkan dependensi berikut ke pom.xml file Anda. Pastikan Anda mengganti 3.x.x ke versi KCL terbaru.

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

Jika Anda menggunakan Gradle, tambahkan yang berikut ini ke build.gradle file Anda. Pastikan Anda mengganti 3.x.x ke versi KCL terbaru.

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

Anda dapat memeriksa versi terbaru KCL di Maven Central Repository.

Langkah 3: Siapkan konfigurasi terkait migrasi

Untuk bermigrasi dari KCL 2.x ke KCL 3.x, Anda harus mengatur parameter konfigurasi berikut:

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

Pada fase ini, aplikasi Anda tetap kompatibel dengan KCL 2.x dan migrasi tidak dimulai, yang memungkinkan Anda meluncurkan pustaka KCL 3.x dengan aman di seluruh armada Anda.

Setelah semua pekerja berjalan denganCLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X_PHASE1, atur konfigurasi ini CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X untuk memulai migrasi. Untuk mengatur konfigurasi ini, tambahkan baris berikut saat membuat objek penjadwal Anda:

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

Berikut ini adalah contoh cara mengatur CoordinatorConfig.clientVersionConfig untuk bermigrasi dari KCL 2.x ke 3.x. Anda dapat menyesuaikan konfigurasi lain sesuai kebutuhan berdasarkan kebutuhan spesifik Anda:

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

Penting bahwa semua pekerja di aplikasi konsumen Anda menggunakan algoritma penyeimbangan beban yang sama pada waktu tertentu karena KCL 2.x dan 3.x menggunakan algoritma load balancing yang berbeda. Menjalankan pekerja dengan algoritma penyeimbangan beban yang berbeda dapat menyebabkan distribusi beban kurang optimal karena kedua algoritma beroperasi secara independen.

Pengaturan kompatibilitas KCL 2.x ini memungkinkan aplikasi KCL 3.x Anda berjalan dalam mode yang kompatibel dengan KCL 2.x dan menggunakan algoritma penyeimbangan beban untuk KCL 2.x hingga semua pekerja di aplikasi konsumen Anda telah ditingkatkan ke KCL 3.x. Ketika migrasi selesai, KCL akan secara otomatis beralih ke mode fungsionalitas KCL 3.x penuh dan mulai menggunakan algoritma load balancing KCL 3.x baru untuk semua pekerja yang sedang berjalan.

Langkah 4: Ikuti praktik terbaik untuk implementasi metode shutdownRequested ()

KCL 3.x memperkenalkan fitur yang disebut serah terima sewa yang anggun untuk meminimalkan pemrosesan ulang data ketika sewa diserahkan kepada pekerja lain sebagai bagian dari proses penugasan ulang sewa. Ini dicapai dengan memeriksa nomor urut terakhir yang diproses di tabel sewa sebelum serah terima sewa. Untuk memastikan serah terima sewa yang anggun berfungsi dengan baik, Anda harus memastikan bahwa Anda memanggil checkpointer objek dalam shutdownRequested metode di kelas Anda. RecordProcessor Jika Anda tidak memanggil checkpointer objek dalam shutdownRequested metode, Anda dapat mengimplementasikannya seperti yang diilustrasikan dalam contoh berikut.

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

Langkah 5: Periksa prasyarat KCL 3.x untuk mengumpulkan metrik pekerja

KCL 3.x mengumpulkan metrik pemanfaatan CPU seperti pemanfaatan CPU dari pekerja untuk menyeimbangkan beban di seluruh pekerja secara merata. Pekerja aplikasi konsumen dapat berjalan di Amazon EC2, Amazon ECS, Amazon EKS, atau. AWS Fargate KCL 3.x dapat mengumpulkan metrik pemanfaatan CPU dari pekerja hanya jika prasyarat berikut terpenuhi:

Amazon Elastic Compute Cloud(Amazon EC2)

Layanan Kontainer Elastis Amazon (Amazon ECS) di Amazon EC2

Amazon ECS aktif AWS Fargate

Layanan Kubernetes Elastis Amazon (Amazon EKS) di Amazon EC2

Amazon EKS pada AWS Fargate

Langkah 6: Perbarui izin IAM untuk KCL 3.x

Anda harus menambahkan izin berikut ke peran atau kebijakan IAM yang terkait dengan aplikasi konsumen KCL 3.x Anda. Ini melibatkan pembaruan kebijakan IAM yang ada yang digunakan oleh aplikasi KCL. Untuk informasi selengkapnya, lihat Izin IAM diperlukan untuk aplikasi konsumen KCL.

Langkah 7: Terapkan kode KCL 3.x ke pekerja Anda

Setelah Anda menetapkan konfigurasi yang diperlukan untuk migrasi dan menyelesaikan semua daftar periksa migrasi sebelumnya, Anda dapat membuat dan menerapkan kode Anda ke pekerja Anda.

Langkah 8: Selesaikan migrasi

Selama penerapan kode KCL 3.x, KCL terus menggunakan algoritma penugasan sewa dari KCL 2.x. Ketika Anda berhasil menerapkan kode KCL 3.x ke semua pekerja Anda, KCL secara otomatis mendeteksi ini dan beralih ke algoritma penetapan sewa baru berdasarkan pemanfaatan sumber daya pekerja. Untuk detail selengkapnya tentang algoritma penugasan sewa baru, lihatBagaimana KCL memberikan sewa kepada pekerja dan menyeimbangkan beban.

Selama penerapan, Anda dapat memantau proses migrasi dengan metrik berikut yang dipancarkan ke CloudWatch. Anda dapat memantau metrik di bawah Migration operasi. Semua metrik adalah per- KCL-application metrik dan diatur ke tingkat SUMMARY metrik. Jika Sum statistik CurrentState:3xWorker metrik cocok dengan jumlah total pekerja di aplikasi KCL Anda, ini menunjukkan bahwa migrasi ke KCL 3.x telah berhasil diselesaikan.

KCL menyediakan kemampuan rollback ke mode kompatibel 2.x selama migrasi. Setelah migrasi berhasil ke KCL 3.x berhasil, kami sarankan Anda menghapus CoordinatorConfig.clientVersionConfig pengaturan CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X jika rollback tidak lagi diperlukan. Menghapus konfigurasi ini menghentikan emisi metrik terkait migrasi dari aplikasi KCL.