Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Topik ini menguraikan beberapa praktik terbaik untuk diikuti saat menggunakan Amazon MSK. Untuk informasi tentang praktik terbaik Amazon MSK Replicator, lihat. Praktik terbaik untuk menggunakan MSK Replicator
Pertimbangan sisi klien
Ketersediaan dan kinerja aplikasi Anda tidak hanya bergantung pada pengaturan sisi server tetapi juga pada pengaturan klien.
-
Konfigurasikan klien Anda untuk ketersediaan tinggi. Dalam sistem terdistribusi seperti Apache Kafka, memastikan ketersediaan tinggi sangat penting untuk menjaga infrastruktur pesan yang andal dan toleran terhadap kesalahan. Broker akan offline untuk acara yang direncanakan dan tidak direncanakan, misalnya peningkatan, penambalan, kegagalan perangkat keras, dan masalah jaringan. Cluster Kafka toleran terhadap broker offline, oleh karena itu klien Kafka juga harus menangani kegagalan broker dengan anggun. Lihat detail lengkapnya diPraktik terbaik untuk klien Apache Kafka.
-
Pastikan string koneksi klien mencakup setidaknya satu broker dari setiap zona ketersediaan. Memiliki beberapa broker dalam string koneksi klien memungkinkan untuk failover ketika broker tertentu offline untuk pembaruan. Untuk informasi tentang cara mendapatkan string koneksi dengan beberapa broker, lihatDapatkan broker bootstrap untuk cluster MSK Amazon.
-
Jalankan tes kinerja untuk memverifikasi bahwa konfigurasi klien Anda memungkinkan Anda untuk memenuhi tujuan kinerja Anda.
Pertimbangan sisi server
Ukuran kluster Anda dengan benar: Jumlah partisi per pialang Standar
Tabel berikut menunjukkan jumlah partisi yang disarankan (termasuk replika pemimpin dan pengikut) per broker Standar. Jumlah partisi yang disarankan tidak diberlakukan dan merupakan praktik terbaik untuk skenario di mana Anda mengirim lalu lintas di semua partisi topik yang disediakan.
| Ukuran broker | Jumlah partisi yang disarankan (termasuk replika pemimpin dan pengikut) per broker | Jumlah maksimum partisi yang mendukung operasi pembaruan |
|---|---|---|
kafka.t3.small |
300 | 300 |
kafka.m5.large atau kafka.m5.xlarge |
1000 | 1500 |
kafka.m5.2xlarge |
2000 | 3000 |
kafka.m5.4xlarge,kafka.m5.8xlarge,kafka.m5.12xlarge,kafka.m5.16xlarge, atau kafka.m5.24xlarge |
4000 | 6000 |
kafka.m7g.large atau kafka.m7g.xlarge |
1000 | 1500 |
kafka.m7g.2xlarge |
2000 | 3000 |
kafka.m7g.4xlarge,kafka.m7g.8xlarge,kafka.m7g.12xlarge, atau kafka.m7g.16xlarge |
4000 | 6000 |
Jika Anda memiliki partisi tinggi, kasus penggunaan throughput rendah di mana Anda memiliki jumlah partisi yang lebih tinggi, tetapi Anda tidak mengirim lalu lintas di semua partisi, Anda dapat mengemas lebih banyak partisi per broker, selama Anda telah melakukan pengujian dan pengujian kinerja yang memadai untuk memvalidasi bahwa cluster Anda tetap sehat dengan jumlah partisi yang lebih tinggi. Jika jumlah partisi per broker melebihi nilai maksimum yang diizinkan dan cluster Anda menjadi kelebihan beban, Anda akan dicegah melakukan operasi berikut:
-
Perbarui konfigurasi cluster
-
Perbarui cluster ke ukuran broker yang lebih kecil
-
Kaitkan AWS Secrets Manager rahasia dengan cluster yang memiliki otentikasi SASL/SCRAM
Sejumlah besar partisi juga dapat mengakibatkan metrik Kafka yang hilang pada dan CloudWatch pada pengikisan Prometheus.
Untuk panduan memilih jumlah partisi, lihat Apache Kafka Mendukung 200K
Ukuran kluster Anda dengan benar: Jumlah pialang Standar per klaster
Untuk menentukan jumlah pialang Standar yang tepat untuk klaster MSK Provisioned Anda dan memahami biaya, lihat spreadsheet Ukuran dan Harga MSK
Untuk memahami bagaimana infrastruktur yang mendasarinya memengaruhi kinerja Apache Kafka, lihat Praktik terbaik untuk mengukur kluster Apache Kafka Anda dengan benar untuk mengoptimalkan kinerja dan
Optimalkan throughput cluster untuk instans m5.4xl, m7g.4xl, atau yang lebih besar
Saat menggunakan m5.4xl, m7g.4xl, atau instance yang lebih besar, Anda dapat mengoptimalkan throughput cluster MSK Provisioned dengan menyetel konfigurasi num.io.threads dan num.network.threads.
Num.io.Threads adalah jumlah utas yang digunakan broker Standar untuk memproses permintaan. Menambahkan lebih banyak thread, hingga jumlah core CPU yang didukung untuk ukuran instans, dapat membantu meningkatkan throughput cluster.
Num.network.Threads adalah jumlah utas yang digunakan broker Standar untuk menerima semua permintaan masuk dan mengembalikan tanggapan. Thread jaringan menempatkan permintaan masuk pada antrian permintaan untuk diproses oleh io.threads. Menyetel num.network.threads ke setengah jumlah inti CPU yang didukung untuk ukuran instans memungkinkan penggunaan penuh ukuran instans baru.
penting
Jangan menambah num.network.threads tanpa terlebih dahulu meningkatkan num.io.threads karena ini dapat menyebabkan kemacetan terkait saturasi antrian.
| Ukuran instans | Nilai yang disarankan untuk num.io.threads | Nilai yang disarankan untuk num.network.threads |
|---|---|---|
|
m5.4xl |
16 |
8 |
|
m5.8xl |
32 |
16 |
|
m5.12xl |
48 |
24 |
|
m5.16xl |
64 |
32 |
|
m5.24xl |
96 |
48 |
|
m7g.4xlarge |
16 |
8 |
|
m7g.8xlarge |
32 |
16 |
|
m7g.12xlarge |
48 |
24 |
|
m7g.16xlarge |
64 |
32 |
Gunakan Kafka terbaru AdminClient untuk menghindari masalah ketidakcocokan ID topik
ID topik hilang (Kesalahan: tidak cocok dengan Id topik untuk partisi) saat Anda menggunakan AdminClient versi Kafka yang lebih rendah dari 2.8.0 dengan bendera untuk menambah atau menetapkan kembali partisi topik --zookeeper untuk klaster MSK Provisioned menggunakan Kafka versi 2.8.0 atau lebih tinggi. Perhatikan bahwa --zookeeper bendera tidak digunakan lagi di Kafka 2.5 dan dihapus dimulai dengan Kafka 3.0. Lihat Memutakhirkan ke 2.5.0 dari versi 0.8.x apa pun hingga
Untuk mencegah ketidakcocokan ID topik, gunakan klien Kafka versi 2.8.0 atau lebih tinggi untuk operasi admin Kafka. Atau, klien 2.5 dan lebih tinggi dapat menggunakan --bootstrap-servers bendera alih-alih --zookeeper bendera.
Bangun cluster yang sangat tersedia
Gunakan rekomendasi berikut sehingga kluster MSK Provisioned Anda dapat sangat tersedia selama pembaruan (seperti ketika Anda memperbarui ukuran broker atau versi Apache Kafka, misalnya) atau ketika Amazon MSK mengganti broker.
-
Siapkan cluster tiga-AZ.
-
Pastikan faktor replikasi (RF) minimal 3. Perhatikan bahwa RF 1 dapat menyebabkan partisi offline selama pembaruan bergulir; dan RF 2 dapat menyebabkan hilangnya data.
-
Setel replika in-sync minimum (miniSR) ke paling banyak RF - 1. MiniSR yang sama dengan RF dapat mencegah produksi ke cluster selama pembaruan bergulir. MiniSR 2 memungkinkan topik yang direplikasi tiga arah tersedia saat satu replika sedang offline.
Pantau penggunaan CPU
Amazon MSK sangat menyarankan agar Anda mempertahankan total pemanfaatan CPU untuk broker Anda (didefinisikan sebagaiCPU User + CPU System) di bawah 60%. Ketika Anda memiliki setidaknya 40% dari total CPU cluster Anda yang tersedia, Apache Kafka dapat mendistribusikan kembali beban CPU di seluruh broker di cluster bila diperlukan. Salah satu contoh kapan ini diperlukan adalah ketika Amazon MSK mendeteksi dan pulih dari kesalahan broker; dalam hal ini, Amazon MSK melakukan pemeliharaan otomatis, seperti menambal. Contoh lain adalah ketika pengguna meminta perubahan ukuran broker atau peningkatan versi; dalam dua kasus ini, Amazon MSK menyebarkan alur kerja bergulir yang membuat satu broker offline pada satu waktu. Ketika broker dengan partisi prospek offline, Apache Kafka menugaskan kembali kepemimpinan partisi untuk mendistribusikan kembali pekerjaan ke broker lain di cluster. Dengan mengikuti praktik terbaik ini, Anda dapat memastikan Anda memiliki ruang kepala CPU yang cukup di cluster Anda untuk mentolerir peristiwa operasional seperti ini.
Anda dapat menggunakan matematika CloudWatch metrik Amazon untuk membuat metrik kompositCPU User + CPU System. Atur alarm yang dipicu ketika metrik komposit mencapai pemanfaatan CPU rata-rata 60%. Saat alarm ini dipicu, skala cluster menggunakan salah satu opsi berikut:
-
Opsi 1 (disarankan): Perbarui ukuran broker Anda ke ukuran yang lebih besar berikutnya. Misalnya, jika ukuran saat ini
kafka.m5.large, perbarui cluster yang akan digunakankafka.m5.xlarge. Perlu diingat bahwa ketika Anda memperbarui ukuran broker di cluster, Amazon MSK membawa broker offline secara bergulir dan sementara menugaskan kembali kepemimpinan partisi ke broker lain. Pembaruan ukuran biasanya memakan waktu 10-15 menit per broker. -
Opsi 2: Jika ada topik dengan semua pesan yang dicerna dari produsen yang menggunakan penulisan round-robin (dengan kata lain, pesan tidak dikunci dan pemesanan tidak penting bagi konsumen), perluas cluster Anda dengan menambahkan broker. Tambahkan juga partisi ke topik yang ada dengan throughput tertinggi. Selanjutnya, gunakan
kafka-topics.sh --describeuntuk memastikan bahwa partisi yang baru ditambahkan ditugaskan ke broker baru. Manfaat utama dari opsi ini dibandingkan dengan yang sebelumnya adalah Anda dapat mengelola sumber daya dan biaya lebih terperinci. Selain itu, Anda dapat menggunakan opsi ini jika beban CPU secara signifikan melebihi 60% karena bentuk penskalaan ini biasanya tidak menghasilkan peningkatan beban pada broker yang ada. -
Opsi 3: Perluas kluster MSK Provisioned Anda dengan menambahkan broker, lalu tetapkan kembali partisi yang ada dengan menggunakan alat penugasan partisi bernama.
kafka-reassign-partitions.shNamun, jika Anda menggunakan opsi ini, cluster perlu menghabiskan sumber daya untuk mereplikasi data dari broker ke broker setelah partisi dipindahkan. Dibandingkan dengan dua opsi sebelumnya, ini dapat secara signifikan meningkatkan beban pada cluster pada awalnya. Akibatnya, Amazon MSK tidak merekomendasikan penggunaan opsi ini ketika pemanfaatan CPU di atas 70% karena replikasi menyebabkan beban CPU tambahan dan lalu lintas jaringan. Amazon MSK hanya merekomendasikan penggunaan opsi ini jika dua opsi sebelumnya tidak layak.
Rekomendasi lainnya:
-
Pantau total pemanfaatan CPU per broker sebagai proxy untuk distribusi beban. Jika broker memiliki penggunaan CPU yang tidak merata secara konsisten, itu mungkin merupakan tanda bahwa beban tidak didistribusikan secara merata di dalam cluster. Kami merekomendasikan penggunaan Cruise Control untuk terus mengelola distribusi beban melalui penugasan partisi.
-
Pantau produksi dan konsumsi latensi. Menghasilkan dan mengkonsumsi latensi dapat meningkat secara linier dengan pemanfaatan CPU.
-
Interval pengikisan JMX: Jika Anda mengaktifkan pemantauan terbuka dengan fitur Prometheus, Anda disarankan untuk menggunakan interval gesekan 60 detik atau lebih tinggi (scrape_interval: 60s) untuk konfigurasi host Prometheus Anda (prometheus.yl). Menurunkan interval scrape dapat menyebabkan penggunaan CPU yang tinggi pada cluster Anda.
Memantau ruang disk
Untuk menghindari kehabisan ruang disk untuk pesan, buat CloudWatch alarm yang mengawasi KafkaDataLogsDiskUsed metrik. Ketika nilai metrik ini mencapai atau melebihi 85%, lakukan satu atau lebih tindakan berikut:
-
Gunakan Penskalaan otomatis untuk kluster MSK Amazon. Anda juga dapat meningkatkan penyimpanan broker secara manual seperti yang dijelaskan dalamPenskalaan manual untuk pialang Standar.
-
Kurangi periode penyimpanan pesan atau ukuran log. Untuk informasi tentang cara melakukannya, lihatSesuaikan parameter retensi data.
-
Hapus topik yang tidak digunakan.
Untuk informasi tentang cara mengatur dan menggunakan alarm, lihat Menggunakan CloudWatch Alarm Amazon. Untuk daftar lengkap metrik MSK Amazon, lihat. Memantau klaster Amazon MSK Provisioned
Sesuaikan parameter retensi data
Mengkonsumsi pesan tidak menghapusnya dari log. Untuk mengosongkan ruang disk secara teratur, Anda dapat secara eksplisit menentukan periode waktu penyimpanan, yaitu berapa lama pesan tetap berada di log. Anda juga dapat menentukan ukuran log retensi. Ketika periode waktu retensi atau ukuran log retensi tercapai, Apache Kafka mulai menghapus segmen yang tidak aktif dari log.
Untuk menentukan kebijakan retensi di tingkat klaster, tetapkan satu atau beberapa parameter berikut:log.retention.hours,log.retention.minutes,log.retention.ms, ataulog.retention.bytes. Untuk informasi selengkapnya, lihat Konfigurasi MSK Amazon kustom.
Anda juga dapat menentukan parameter retensi di tingkat topik:
-
Untuk menentukan periode waktu retensi per topik, gunakan perintah berikut.
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.ms=DesiredRetentionTimePeriod -
Untuk menentukan ukuran log retensi per topik, gunakan perintah berikut.
kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-nameTopicName--add-config retention.bytes=DesiredRetentionLogSize
Parameter retensi yang Anda tentukan pada tingkat topik lebih diutamakan daripada parameter tingkat cluster.
Mempercepat pemulihan log setelah shutdown yang tidak bersih
Setelah shutdown yang tidak bersih, broker dapat mengambil beberapa saat untuk memulai kembali seperti halnya pemulihan log. Secara default, Kafka hanya menggunakan satu utas per direktori log untuk melakukan pemulihan ini. Misalnya, jika Anda memiliki ribuan partisi, pemulihan log dapat memakan waktu berjam-jam untuk diselesaikan. Untuk mempercepat pemulihan log, disarankan untuk menambah jumlah thread menggunakan properti konfigurasi num.recovery.threads.per.data.dir. Anda dapat mengaturnya ke jumlah core CPU.
Memantau memori Apache Kafka
Kami menyarankan Anda memantau memori yang digunakan Apache Kafka. Jika tidak, cluster mungkin menjadi tidak tersedia.
Untuk menentukan berapa banyak memori yang digunakan Apache Kafka, Anda dapat memantau metrik. HeapMemoryAfterGC HeapMemoryAfterGCadalah persentase dari total memori heap yang digunakan setelah pengumpulan sampah. Kami menyarankan Anda membuat CloudWatch alarm yang mengambil tindakan ketika HeapMemoryAfterGC meningkat di atas 60%.
Langkah-langkah yang dapat Anda ambil untuk mengurangi penggunaan memori bervariasi. Mereka bergantung pada cara Anda mengkonfigurasi Apache Kafka. Misalnya, jika Anda menggunakan pengiriman pesan transaksional, Anda dapat mengurangi transactional.id.expiration.ms nilai dalam konfigurasi Apache Kafka Anda dari 604800000 ms ke 86400000 ms (dari 7 hari menjadi 1 hari). Ini mengurangi jejak memori setiap transaksi.
Jangan tambahkan broker non-MSK
Untuk cluster MSK Provisioned ZooKeeper berbasis, jika Anda menggunakan ZooKeeper perintah Apache untuk menambahkan broker, broker ini tidak ditambahkan ke cluster MSK Provisioned Anda, dan ZooKeeper Apache Anda akan berisi informasi yang salah tentang cluster. Hal ini dapat mengakibatkan hilangnya data. Untuk operasi klaster MSK Provisioned yang didukung, lihat. Fitur dan konsep utama MSK Amazon
Aktifkan enkripsi dalam transit
Untuk informasi tentang enkripsi dalam perjalanan dan cara mengaktifkannya, lihatEnkripsi MSK Amazon dalam perjalanan.
Tetapkan kembali partisi
Untuk memindahkan partisi ke broker yang berbeda pada cluster MSK Provisioned yang sama, Anda dapat menggunakan alat penugasan kembali partisi bernama. kafka-reassign-partitions.sh Kami menyarankan Anda untuk tidak menetapkan kembali lebih dari 10 partisi dalam satu kafka-reassign-partitions panggilan untuk operasi yang aman. Misalnya, setelah Anda menambahkan broker baru untuk memperluas cluster atau memindahkan partisi untuk menghapus broker, Anda dapat menyeimbangkan kembali cluster itu dengan menugaskan kembali partisi ke broker baru. Untuk informasi tentang cara menambahkan broker ke klaster MSK Provisioned, lihat. Perluas jumlah broker di cluster MSK Amazon Untuk informasi tentang cara menghapus broker dari klaster MSK Provisioned, lihat. Hapus broker dari cluster MSK Amazon Untuk informasi tentang alat penugasan kembali partisi, lihat Memperluas cluster Anda
