Praktik terbaik

Topik ini menguraikan beberapa praktik terbaik untuk diikuti saat menggunakan AmazonMSK. Untuk informasi tentang praktik terbaik Amazon MSK Replicator, lihatPraktik terbaik untuk menggunakan MSK Replicator.

Ukuran kluster Anda dengan benar: Jumlah partisi per broker

Tabel berikut menunjukkan jumlah partisi yang disarankan (termasuk replika pemimpin dan pengikut) per broker.

Ukuran broker	Jumlah partisi yang disarankan (termasuk replika pemimpin dan pengikut) per broker
kafka.t3.small	300
kafka.m5.large atau kafka.m5.xlarge	1000
kafka.m5.2xlarge	2000
kafka.m5.4xlarge,kafka.m5.8xlarge,kafka.m5.12xlarge,kafka.m5.16xlarge, atau kafka.m5.24xlarge	4000
kafka.m7g.large atau kafka.m7g.xlarge	1000
kafka.m7g.2xlarge	2000
kafka.m7g.4xlarge,kafka.m7g.8xlarge,kafka.m7g.12xlarge, atau kafka.m7g.16xlarge	4000

Jika jumlah partisi per broker melebihi nilai yang disarankan dan klaster Anda menjadi kelebihan beban, Anda mungkin dicegah melakukan operasi berikut:

• Perbarui konfigurasi cluster

• Perbarui cluster ke ukuran broker yang lebih kecil

• Mengasosiasikan sebuah AWS Secrets Manager rahasia dengan cluster yang SASL SCRAM memiliki/otentikasi

Jumlah partisi yang tinggi juga dapat mengakibatkan metrik Kafka yang hilang pada dan CloudWatch pada pengikisan Prometheus.

Untuk panduan memilih jumlah partisi, lihat Apache Kafka Mendukung 200K Partisi Per Cluster. Kami juga menyarankan Anda melakukan pengujian sendiri untuk menentukan ukuran yang tepat untuk broker Anda. Untuk informasi lebih lanjut tentang ukuran broker yang berbeda, lihatUkuran broker.

Ukuran kluster Anda dengan benar: Jumlah broker per cluster

Untuk menentukan jumlah broker yang tepat untuk MSK klaster Anda dan memahami biaya, lihat MSKspreadsheet Ukuran dan Harga. Spreadsheet ini memberikan perkiraan untuk ukuran MSK cluster dan biaya terkait Amazon MSK dibandingkan dengan cluster Apache Kafka EC2 berbasis mandiri yang serupa. Untuk informasi lebih lanjut tentang parameter input di spreadsheet, arahkan kursor ke deskripsi parameter. Perkiraan yang diberikan oleh lembar ini bersifat konservatif dan memberikan titik awal untuk cluster baru. Kinerja klaster, ukuran, dan biaya tergantung pada kasus penggunaan Anda dan kami sarankan Anda memverifikasi mereka dengan pengujian yang sebenarnya.

Untuk memahami bagaimana infrastruktur yang mendasari memengaruhi kinerja Apache Kafka, lihat Praktik terbaik untuk mengukur kluster Apache Kafka Anda dengan benar untuk mengoptimalkan kinerja dan biaya di AWS Blog Data Besar. Posting blog memberikan informasi tentang cara mengukur cluster Anda untuk memenuhi persyaratan throughput, ketersediaan, dan latensi Anda. Ini juga memberikan jawaban atas pertanyaan seperti kapan Anda harus meningkatkan versus skala keluar, dan panduan tentang cara terus memverifikasi ukuran kluster produksi Anda.

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 dengan menyetel konfigurasi num.io.threads dan num.network.threads.

Num.io.Threads adalah jumlah utas yang digunakan broker untuk memproses permintaan. Menambahkan lebih banyak thread, hingga jumlah CPU core yang didukung untuk ukuran instans, dapat membantu meningkatkan throughput cluster.

Num.network.Threads adalah jumlah thread yang digunakan broker 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 CPU core yang didukung untuk ukuran instans memungkinkan penggunaan penuh ukuran instance baru.

penting

Jangan menambah num.network.threads tanpa terlebih dahulu meningkatkan num.io.threads karena ini dapat menyebabkan kemacetan terkait saturasi antrian.

Pengaturan yang disarankan
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 --zookeeper untuk menambah atau menetapkan kembali partisi topik untuk cluster 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 2.4.x.

Untuk mencegah ketidakcocokan ID topik, gunakan klien Kafka versi 2.8.0 atau lebih tinggi untuk operasi admin Kafka. Atau, klien 2.5 dan yang lebih tinggi dapat menggunakan --bootstrap-servers bendera alih-alih --zookeeper bendera.

Membangun cluster yang sangat tersedia

Gunakan rekomendasi berikut sehingga MSK klaster 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) setidaknya 3. Perhatikan bahwa RF 1 dapat menyebabkan partisi offline selama pembaruan bergulir; dan RF 2 dapat menyebabkan hilangnya data.

• Tetapkan replika sinkronisasi minimum (minISR) ke paling banyak RF - 1. Min ISR yang sama dengan RF dapat mencegah produksi ke cluster selama pembaruan bergulir. Minit ISR 2 memungkinkan topik yang direplikasi tiga arah tersedia saat satu replika sedang offline.

• 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, lihatMendapatkan broker bootstrap untuk MSK cluster Amazon.

Pantau CPU penggunaan

Amazon MSK sangat menyarankan agar Anda mempertahankan total CPU pemanfaatan untuk broker Anda (didefinisikan sebagaiCPU User + CPU System) di bawah 60%. Ketika Anda memiliki setidaknya 40% dari total cluster Anda yang CPU tersedia, Apache Kafka dapat mendistribusikan kembali CPU beban 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 CPU ruang kepala 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 CPU pemanfaatan 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 inikafka.m5.large, perbarui cluster yang akan digunakankafka.m5.xlarge. Ingatlah bahwa ketika Anda memperbarui ukuran broker di cluster, Amazon MSK membuat broker offline secara bergulir dan untuk 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 --describe untuk 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 CPU beban secara signifikan melebihi 60% karena bentuk penskalaan ini biasanya tidak menghasilkan peningkatan beban pada broker yang ada.

• Opsi 3: Perluas cluster Anda dengan menambahkan broker, lalu tetapkan kembali partisi yang ada dengan menggunakan alat penugasan partisi bernama. kafka-reassign-partitions.sh Namun, 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 CPU pemanfaatan di atas 70% karena replikasi menyebabkan CPU beban tambahan dan lalu lintas jaringan. Amazon MSK hanya merekomendasikan penggunaan opsi ini jika dua opsi sebelumnya tidak layak.

Rekomendasi lainnya:

• Pantau total CPU pemanfaatan per broker sebagai proxy untuk distribusi beban. Jika broker memiliki CPU pemanfaatan yang tidak merata secara konsisten, itu mungkin merupakan tanda bahwa beban tidak didistribusikan secara merata di dalam cluster. Amazon MSK merekomendasikan penggunaan Cruise Control untuk terus mengelola distribusi beban melalui penetapan partisi.

• Pantau produksi dan konsumsi latensi. Menghasilkan dan mengkonsumsi latensi dapat meningkat secara linier dengan CPU pemanfaatan.

• JMXinterval scrape: Jika Anda mengaktifkan pemantauan terbuka dengan fitur Prometheus, Anda disarankan untuk menggunakan interval scrape 60 detik atau lebih tinggi (scrape_interval: 60s) untuk konfigurasi host Prometheus Anda (prometheus.yl). Menurunkan interval scrape dapat menyebabkan CPU penggunaan 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. Anda juga dapat meningkatkan penyimpanan broker secara manual seperti yang dijelaskan dalamPenskalaan manual.

• 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 MSK metrik Amazon, lihatMemantau MSK klaster Amazon.

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 MSKKonfigurasi 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-name TopicName --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-name TopicName --add-config retention.bytes=DesiredRetentionLogSize

Parameter retensi yang Anda tentukan pada tingkat topik lebih diutamakan daripada parameter tingkat kluster.

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 CPU core.

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 non MSK broker

Untuk cluster ZooKeeper berbasis, jika Anda menggunakan ZooKeeper perintah Apache untuk menambahkan broker, broker ini tidak ditambahkan ke MSK cluster Anda, dan Apache Anda ZooKeeper akan berisi informasi yang salah tentang cluster. Hal ini dapat mengakibatkan hilangnya data. Untuk operasi klaster yang didukung, lihatAmazonMSK: Cara kerjanya.

Aktifkan enkripsi dalam transit

Untuk informasi tentang enkripsi dalam perjalanan dan cara mengaktifkannya, lihatEnkripsi bergerak.

Tetapkan kembali partisi

Untuk memindahkan partisi ke broker yang berbeda pada cluster yang sama, Anda dapat menggunakan alat penugasan partisi bernama. kafka-reassign-partitions.sh 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 cluster, lihatMemperluas MSK cluster Amazon. Untuk informasi tentang cara menghapus broker dari klaster, lihatHapus broker dari MSK kluster Amazon. Untuk informasi tentang alat penugasan kembali partisi, lihat Memperluas cluster Anda di dokumentasi Apache Kafka.