Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Migrasi dari KCL 2.x ke 3.x KCL
Topik ini memberikan step-by-step petunjuk untuk memigrasikan konsumen Anda dari KCL 2.x ke KCL 3.x. KCL3.x mendukung migrasi konsumen KCL 2.x di tempat. Anda dapat terus mengkonsumsi data dari aliran data Kinesis Anda sambil memigrasikan pekerja Anda secara bergulir.
penting
KCL3.x mempertahankan antarmuka dan metode yang sama dengan 2.x. KCL Oleh karena itu, Anda tidak perlu memperbarui kode pemrosesan catatan selama migrasi. Namun, Anda harus mengatur konfigurasi yang tepat dan memeriksa langkah-langkah yang diperlukan untuk migrasi. Kami sangat menyarankan Anda mengikuti langkah-langkah migrasi berikut untuk pengalaman migrasi yang lancar.
Langkah 1: Prasyarat
Sebelum Anda mulai menggunakan KCL 3.x, pastikan Anda memiliki yang berikut:
-
Java Development Kit (JDK) 8 atau lebih baru
-
AWS SDK for Java 2.x
-
Maven atau Gradle untuk manajemen ketergantungan
Langkah 2: Tambahkan dependensi
Jika Anda menggunakan Maven, tambahkan dependensi berikut ke file Anda. pom.xml
Pastikan Anda mengganti 3.xx ke versi terbaru. KCL
<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 berikut ini ke build.gradle
file Anda. Pastikan Anda mengganti 3.xx ke versi terbaru. KCL
implementation 'software.amazon.kinesis:amazon-kinesis-client:3.x.x'
Anda dapat memeriksa versi terbaru dari KCL Repositori Pusat Maven
Langkah 3: Siapkan konfigurasi terkait migrasi
Untuk bermigrasi dari KCL 2.x ke KCL 3.x, Anda harus mengatur parameter konfigurasi berikut:
-
CoordinatorConfig. clientVersionConfig: Konfigurasi ini menentukan mode kompatibilitas KCL versi mana aplikasi akan berjalan. Saat bermigrasi dari KCL 2.x ke 3.x, Anda perlu mengatur konfigurasi ini ke.
CLIENT_VERSION_CONFIG_COMPATIBLE_WITH_2X
Untuk mengatur konfigurasi ini, tambahkan baris berikut saat membuat objek scheduler Anda:
configsBuilder.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_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.coordiantorConfig().clientVersionConfig(ClientVersionConfig.CLIENT_VERSION_CONFIG_COMPLATIBLE_WITH_2X), configsBuilder.leaseManagementConfig(), configsBuilder.lifecycleConfig(), configsBuilder.metricsConfig(), configsBuilder.processorConfig(), configsBuilder.retrievalConfig() );
Sangat penting bahwa semua pekerja dalam aplikasi konsumen Anda menggunakan algoritma load balancing yang sama pada waktu tertentu karena KCL 2.x dan 3.x menggunakan algoritma load balancing yang berbeda. Menjalankan pekerja dengan algoritma load balancing yang berbeda dapat menyebabkan distribusi beban suboptimal 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 load balancing untuk KCL 2.x hingga semua pekerja di aplikasi konsumen Anda telah ditingkatkan ke 3.x. KCL Ketika migrasi selesai, secara otomatis KCL akan beralih ke mode fungsionalitas KCL 3.x penuh dan mulai menggunakan algoritma penyeimbangan beban KCL 3.x baru untuk semua pekerja yang sedang berjalan.
penting
Jika Anda tidak menggunakan ConfigsBuilder
tetapi membuat LeaseManagementConfig
objek untuk mengatur konfigurasi, Anda harus menambahkan satu parameter lagi yang disebut applicationName
dalam KCL versi 3.x atau yang lebih baru. Untuk detailnya, lihat Kesalahan kompilasi dengan LeaseManagementConfig konstruktor. Kami merekomendasikan penggunaan ConfigsBuilder
untuk mengatur KCL konfigurasi. ConfigsBuilder
menyediakan cara yang lebih fleksibel dan dapat dipelihara untuk mengkonfigurasi aplikasi AndaKCL.
Langkah 4: Ikuti praktik terbaik untuk implementasi metode shutdownRequested ()
KCL3.x memperkenalkan fitur yang disebut handoff sewa anggun untuk meminimalkan pemrosesan ulang data ketika sewa diserahkan kepada pekerja lain sebagai bagian dari proses penggantian sewa. Ini dicapai dengan memeriksa nomor urut yang diproses terakhir di tabel sewa sebelum serah terima sewa. Untuk memastikan handoff sewa anggun berfungsi dengan baik, Anda harus memastikan bahwa Anda memanggil checkpointer
objek dalam metode di kelas Anda. shutdownRequested
RecordProcessor
Jika Anda tidak memanggil checkpointer
objek dalam shutdownRequested
metode, Anda dapat menerapkannya seperti yang diilustrasikan dalam contoh berikut.
penting
-
Contoh implementasi berikut adalah persyaratan minimal untuk handoff sewa yang anggun. Anda dapat memperluasnya untuk menyertakan logika tambahan yang terkait dengan pos pemeriksaan jika diperlukan. Jika Anda melakukan pemrosesan asinkron, pastikan semua catatan yang dikirim ke hilir diproses sebelum menjalankan pos pemeriksaan.
-
Sementara handoff sewa yang anggun secara signifikan mengurangi kemungkinan pemrosesan ulang data selama transfer sewa, itu tidak sepenuhnya menghilangkan kemungkinan ini. Untuk menjaga integritas dan konsistensi data, rancang aplikasi konsumen hilir Anda menjadi idempoten. Ini berarti mereka harus dapat menangani pemrosesan rekaman duplikat potensial tanpa efek buruk pada keseluruhan sistem.
/** * 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
KCL3.x mengumpulkan metrik CPU pemanfaatan seperti CPU pemanfaatan dari pekerja untuk menyeimbangkan beban di seluruh pekerja secara merata. Pekerja aplikasi konsumen dapat berjalan di AmazonEC2, AmazonECS, AmazonEKS, atau AWS Fargate. KCL3.x dapat mengumpulkan metrik CPU pemanfaatan dari pekerja hanya jika prasyarat berikut terpenuhi:
Amazon Elastic Compute Cloud(AmazonEC2)
-
Sistem operasi Anda harus OS Linux.
-
Anda harus mengaktifkan IMDSv2dalam EC2 contoh Anda.
Layanan Kontainer Elastis Amazon (AmazonECS) di Amazon EC2
-
Sistem operasi Anda harus OS Linux.
-
Anda harus mengaktifkan titik akhir metadata ECS tugas versi 4.
-
Versi agen ECS penampung Amazon Anda harus 1.39.0 atau yang lebih baru.
Amazon ECS di AWS Fargate
-
Anda harus mengaktifkan titik akhir metadata tugas Fargate versi 4. Jika Anda menggunakan platform Fargate versi 1.4.0 atau yang lebih baru, ini diaktifkan secara default.
-
Platform Fargate versi 1.4.0 atau yang lebih baru.
Layanan Amazon Elastic Kubernetes (Amazon) di Amazon EKS EC2
-
Sistem operasi Anda harus OS Linux.
Amazon EKS di AWS Fargate
-
Platform Fargate 1.3.0 atau yang lebih baru.
penting
Jika KCL 3.x tidak dapat mengumpulkan metrik CPU pemanfaatan dari pekerja karena prasyarat tidak terpenuhi, itu akan menyeimbangkan kembali beban tingkat throughput per sewa. Mekanisme penyeimbangan kembali ini akan memastikan semua pekerja akan mendapatkan tingkat throughput total yang sama dari sewa yang diberikan kepada setiap pekerja. Untuk informasi selengkapnya, lihat Bagaimana KCL menugaskan sewa kepada pekerja dan menyeimbangkan beban.
Langkah 6: IAM Perbarui izin untuk 3.x KCL
Anda harus menambahkan izin berikut ke IAM peran atau kebijakan yang terkait dengan aplikasi konsumen KCL 3.x Anda. Ini melibatkan memperbarui IAM kebijakan yang ada yang digunakan oleh KCL aplikasi. Untuk informasi selengkapnya, lihat IAMizin yang diperlukan untuk aplikasi KCL konsumen.
penting
KCLAplikasi Anda yang ada mungkin tidak memiliki IAM tindakan dan sumber daya berikut yang ditambahkan dalam IAM kebijakan karena tidak diperlukan di KCL 2.x. Pastikan Anda telah menambahkannya sebelum menjalankan aplikasi KCL 3.x Anda:
-
Tindakan:
UpdateTable
-
Sumber daya (ARNs):
arn:aws:dynamodb:region:account:table/KCLApplicationName
-
-
Tindakan:
Query
-
Sumber daya (ARNs):
arn:aws:dynamodb:region:account:table/KCLApplicationName/Index/*
-
-
Tindakan:
CreateTable
,DescribeTable
,Scan
,GetItem
,PutItem
,UpdateItem
,DeleteItem
-
Sumber daya (ARNs):
arn:aws:dynamodb:region:account:table/KCLApplicationName-WorkerMetricStats
,arn:aws:dynamodb:region:account:table/KCLApplicationName-CoordinatorState
Ganti “wilayah,” “akun,” dan KCLApplicationName "" di ARNs dengan nama Anda sendiri Wilayah AWS, Akun AWS nomor, dan nama KCL aplikasi masing-masing. Jika Anda menggunakan konfigurasi untuk menyesuaikan nama tabel metadata yang dibuat olehKCL, gunakan nama tabel yang ditentukan tersebut alih-alih nama aplikasi. KCL
-
Langkah 7: Menyebarkan kode KCL 3.x ke pekerja Anda
Setelah Anda mengatur konfigurasi yang diperlukan untuk migrasi dan menyelesaikan semua daftar periksa migrasi sebelumnya, Anda dapat membuat dan menerapkan kode Anda ke pekerja Anda.
catatan
Jika Anda melihat kesalahan kompilasi dengan LeaseManagementConfig
konstruktor, lihat Kesalahan kompilasi dengan LeaseManagementConfig konstruktor untuk informasi pemecahan masalah.
Langkah 8: Selesaikan migrasi
Selama penerapan kode KCL 3.x, KCL terus menggunakan algoritme penetapan sewa dari 2.x. KCL Ketika Anda telah berhasil menerapkan kode KCL 3.x ke semua pekerja Anda, KCL secara otomatis mendeteksi ini dan beralih ke algoritme penetapan sewa baru berdasarkan pemanfaatan sumber daya pekerja. Untuk detail selengkapnya tentang algoritme penetapan sewa baru, lihat. Bagaimana KCL menugaskan sewa kepada pekerja dan menyeimbangkan beban
Selama penerapan, Anda dapat memantau proses migrasi dengan metrik berikut yang dipancarkan. CloudWatch Anda dapat memantau metrik di bawah Migration
operasi. Semua metrik adalah per-KCL-application metrik dan disetel ke tingkat SUMMARY
metrik. Jika Sum
statistik CurrentState:3xWorker
metrik cocok dengan jumlah total pekerja dalam KCL aplikasi Anda, ini menunjukkan bahwa migrasi ke KCL 3.x telah berhasil diselesaikan.
penting
Dibutuhkan setidaknya 10 menit untuk beralih KCL ke algoritme penugasan leasee baru setelah semua pekerja siap menjalankannya.
Metrik | Deskripsi |
---|---|
CurrentState:3xWorker |
Jumlah KCL pekerja yang berhasil bermigrasi ke KCL 3.x dan menjalankan algoritme penetapan sewa baru. Jika
|
CurrentState:2xCompatibleWorker |
Jumlah KCL pekerja yang berjalan dalam mode kompatibel KCL 2.x selama proses migrasi. Nilai bukan nol untuk metrik ini menunjukkan bahwa migrasi masih berlangsung.
|
Fault |
Jumlah pengecualian yang ditemui selama proses migrasi. Sebagian besar pengecualian ini adalah kesalahan sementara, dan KCL 3.x akan secara otomatis mencoba lagi untuk menyelesaikan migrasi. Jika Anda mengamati nilai
|
GsiStatusReady |
Status indeks sekunder global (GSI) penciptaan pada tabel sewa. Metrik ini menunjukkan apakah GSI pada tabel sewa telah dibuat, prasyarat untuk menjalankan 3.x. KCL Nilainya adalah 0 atau 1, dengan 1 menunjukkan penciptaan yang berhasil. Selama keadaan rollback, metrik ini tidak akan dipancarkan. Setelah Anda maju lagi, Anda dapat melanjutkan pemantauan metrik ini.
|
workerMetricsReady |
Status emisi metrik pekerja dari semua pekerja. Metrik menunjukkan apakah semua pekerja memancarkan metrik seperti pemanfaatan. CPU Nilainya adalah 0 atau 1, dengan 1 menunjukkan semua pekerja berhasil memancarkan metrik dan siap untuk algoritme penetapan sewa baru. Selama keadaan rollback, metrik ini tidak akan dipancarkan. Setelah Anda maju lagi, Anda dapat melanjutkan pemantauan metrik ini.
|
KCLmenyediakan 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
catatan
Sebaiknya Anda memantau kinerja dan stabilitas aplikasi selama suatu periode selama migrasi dan setelah menyelesaikan migrasi. Jika Anda mengamati masalah apa pun, Anda dapat mengembalikan pekerja untuk menggunakan fungsionalitas yang kompatibel KCL 2.x menggunakan Alat MigrasiKCL.