View a markdown version of this page

Praktik terbaik untuk broker Standar - Amazon Managed Streaming untuk Apache Kafka
Client-side pertimbanganServer-side pertimbangan

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

Praktik terbaik untuk broker Standar

Topik ini menguraikan beberapa praktik terbaik yang harus diikuti saat menggunakan Amazon MSK. Untuk informasi tentang praktik terbaik Amazon MSK Replicator, lihat. Praktik terbaik

Client-side pertimbangan

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 mempertahankan infrastruktur perpesanan yang andal dan toleran terhadap kesalahan. Broker akan offline untuk acara yang direncanakan dan tidak direncanakan, misalnya peningkatan, tambalan, kegagalan perangkat keras, dan masalah jaringan. Cluster Kafka toleran terhadap broker offline, oleh karena itu klien Kafka juga harus menangani fail-over broker dengan anggun. Lihat detail lengkapnya diPraktik terbaik untuk klien Apache Kafka.

  • Pastikan string koneksi klien menyertakan setidaknya satu broker dari setiap zona ketersediaan. Memiliki beberapa broker dalam string koneksi klien memungkinkan failover ketika broker tertentu offline untuk pembaruan. Untuk informasi tentang cara mendapatkan string koneksi dengan beberapa broker, lihatDapatkan broker bootstrap untuk cluster Amazon MSK.

  • Jalankan pengujian kinerja untuk memverifikasi bahwa konfigurasi klien memungkinkan Anda memenuhi tujuan kinerja Anda.

Server-side pertimbangan

Right-size cluster Anda: Jumlah partisi per broker Standar

Tabel berikut menunjukkan jumlah partisi yang direkomendasikan (termasuk replika pemimpin dan pengikut) per broker Standar. Jumlah partisi yang disarankan tidak diterapkan dan merupakan praktik terbaik untuk skenario di mana Anda mengirim lalu lintas ke 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 kasus penggunaan partisi tinggi dan throughput rendah di mana Anda memiliki jumlah partisi yang lebih tinggi, tetapi Anda tidak mengirim lalu lintas ke 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

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

Jumlah partisi yang tinggi juga dapat mengakibatkan hilangnya metrik Kafka pada CloudWatch dan pada pengikisan Prometheus. Efek ini diperparah oleh sejumlah besar kelompok konsumen karena setiap kombinasi kelompok konsumen, topik, dan partisi menghasilkan entri offset yang dilacak. Kelompok konsumen kosong (kelompok tanpa konsumen aktif) juga berkontribusi terhadap overhead ini. Apache Kafka mempertahankan offset untuk grup ini sampai periode retensi yang ditentukan oleh offsets.retention.minutes berakhir, atau sampai Anda menghapus grup secara eksplisit. Untuk mengurangi ini, pantau jumlah total grup konsumen Anda dan hapus grup konsumen yang tidak digunakan.

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, lihatJenis broker Amazon MSK.

Right-size cluster Anda: Jumlah broker Standar per cluster

Untuk menentukan jumlah broker Standar yang tepat untuk cluster MSK Provisioned Anda dan memahami biaya, lihat spreadsheet Ukuran dan Harga MSK. Spreadsheet ini memberikan perkiraan ukuran cluster MSK Provisioned dan biaya terkait Amazon MSK dibandingkan dengan cluster Apache Kafka yang serupa yang dikelola sendiri. EC2-based Untuk informasi lebih lanjut tentang parameter input dalam spreadsheet, arahkan kursor ke deskripsi parameter. Perkiraan yang disediakan oleh lembar ini bersifat konservatif dan memberikan titik awal untuk cluster MSK Provisioned baru. Kinerja, ukuran, dan biaya cluster tergantung pada kasus penggunaan Anda dan kami sarankan Anda memverifikasinya dengan pengujian aktual.

Untuk memahami bagaimana infrastruktur yang mendasarinya memengaruhi kinerja Apache Kafka, lihat Prakti k terbaik untuk menyesuaikan ukuran cluster Apache Kafka Anda dengan tepat untuk mengoptimalkan kinerja dan biaya di Blog Big Data. AWS 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 meningkatkan skala, dan panduan tentang cara terus memverifikasi ukuran cluster produksi Anda. Untuk informasi tentang cluster berbasis penyimpanan berjenjang, lihat Praktik terbaik untuk menjalankan beban kerja produksi menggunakan penyimpanan berjenjang Amazon MSK.

Mengoptimalkan throughput cluster untuk m5.4xl, m7g.4xl, atau instans yang lebih besar

Saat menggunakan m5.4xl, m7g.4xl, atau instans yang lebih besar, Anda dapat mengoptimalkan throughput cluster MSK Provisioned dengan menyetel konfigurasi num.io.thread dan num.network.thread.

Num.io.threads adalah jumlah thread yang digunakan broker Standar untuk memproses permintaan. Menambahkan lebih banyak thread, hingga jumlah inti 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.thread. Menyetel num.network.thread ke setengah jumlah inti CPU yang didukung untuk ukuran instance memungkinkan penggunaan penuh ukuran instance baru.

penting

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

Tabel berikut menjelaskan pengaturan yang disarankan untuk setiap ukuran instans.

Ukuran instans Nilai yang disarankan untuk num.io.thread Nilai yang disarankan untuk num.network.thread

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 tanda untuk menambah atau menetapkan kembali partisi topik untuk cluster MSK Provisioned menggunakan Kafka versi 2.8.0 atau lebih tinggi. --zookeeper Perhatikan bahwa --zookeeper bendera tidak digunakan lagi di Kafka 2.5 dan dihapus dimulai dengan Kafka 3.0. Lihat Up grade ke 2.5.0 dari versi 0.8.x hingga 2.4.x apa pun.

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 flag alih-alih --zookeeper bendera.

Bangun cluster yang sangat tersedia

Gunakan rekomendasi berikut agar cluster MSK Provisioned Anda dapat sangat tersedia selama pembaruan (seperti saat Anda memperbarui ukuran broker atau versi Apache Kafka, misalnya) atau saat 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 offline.

Memantau penggunaan CPU

Amazon MSK sangat menyarankan agar Anda mempertahankan pemanfaatan CPU untuk broker Anda (didefinisikan sebagaiCPU User + CPU System) di bawah 60%. Ini memastikan bahwa cluster Anda mempertahankan headroom CPU yang cukup untuk menangani peristiwa operasional, seperti kegagalan broker, tambalan, dan peningkatan bergulir.

Apache Kafka dapat mendistribusikan kembali beban CPU di seluruh broker di cluster bila diperlukan. Misalnya, ketika Amazon MSK mendeteksi dan pulih dari kesalahan broker, ia melakukan perawatan otomatis, seperti menambal. Demikian pula, ketika pengguna meminta perubahan ukuran broker atau peningkatan versi, Amazon MSK memulai alur kerja bergulir yang membuat satu broker offline pada satu waktu. Ketika broker dengan partisi lead offline, Apache Kafka menugaskan kembali kepemimpinan partisi untuk mendistribusikan kembali pekerjaan ke broker lain di cluster. Dengan mengikuti praktik terbaik ini, Anda memastikan headroom CPU yang cukup untuk mentolerir peristiwa operasional ini.

catatan

Saat memantau pemanfaatan CPU, ketahuilah bahwa total penggunaan CPU mencakup lebih dari CPU User danCPU System. Kategori lain, sepertiiowait,, irqsoftirq, dansteal, juga berkontribusi pada aktivitas CPU secara keseluruhan. Akibatnya, CPU I dle tidak selalu sama dengan100% - CPU User - CPU System.

Anda dapat menggunakan matematika CloudWatch metrik Amazon untuk membuat metrik komposit (CPU User + CPU System), dan mengatur alarm untuk memicu ketika penggunaan rata-rata melebihi 60%. Saat dipicu, pertimbangkan untuk menskalakan cluster menggunakan salah satu opsi berikut:

  • Opsi 1 (disarankan): Per barui ukuran broker Anda ke ukuran yang lebih besar berikutnya. Misalnya, jika ukuran saat ini adalahkafka.m5.large, perbarui cluster untuk digunakankafka.m5.xlarge. Perlu diingat bahwa ketika Anda memperbarui ukuran broker di cluster, Amazon MSK membuat 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), per luas 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 ditetapkan ke broker baru. Manfaat utama dari opsi ini dibandingkan dengan yang sebelumnya adalah Anda dapat mengelola sumber daya dan biaya secara lebih rinci. 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 cluster MSK Provisioned Anda dengan menambahkan broker, lalu tetapkan kembali partisi yang ada dengan menggunakan alat penugasan ulang 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 ditugaskan kembali. 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 dan lalu lintas jaringan tambahan. 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 secara konsisten memiliki pemanfaatan CPU yang tidak merata, itu mungkin pertanda bahwa beban tidak terdistribusi secara merata di dalam cluster. Sebaiknya gunakan Cruise Control untuk terus mengelola distribusi beban melalui penetapan 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 pengikisan 60 detik atau lebih tinggi (scrape_interval: 60s) untuk konfigurasi host Prometheus Anda (prometheus.yml). Menurunkan interval pengikisan 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:

Untuk informasi tentang cara mengatur dan menggunakan alarm, lihat Menggunakan CloudWatch Alarm Amazon. Untuk daftar lengkap metrik Amazon MSK, lihatMemantau cluster yang disediakan Amazon MSK.

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 tidak aktif dari log.

Untuk menentukan kebijakan retensi di tingkat cluster, tetapkan satu atau beberapa parameter berikut:log.retention.hours,log.retention.minutes,log.retention.ms, ataulog.retention.bytes. Untuk informasi selengkapnya, lihat Konfigurasi Amazon MSK khusus.

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 di tingkat topik lebih diutamakan daripada parameter tingkat cluster.

Mempercepat pemulihan log setelah shutdown yang tidak bersih

Setelah shutdown yang tidak bersih, broker dapat membutuhkan waktu beberapa saat untuk memulai ulang karena melakukan pemulihan log. Secara default, Kafka hanya menggunakan satu thread per direktori log untuk melakukan pemulihan ini. Misalnya, jika Anda memiliki ribuan partisi, pemulihan log dapat memakan waktu berjam-jam untuk menyelesaikannya. Untuk mempercepat pemulihan log, disarankan untuk meningkatkan jumlah thread menggunakan properti konfigurasi num.recovery.threads.per.data.dir. Anda dapat mengaturnya ke jumlah inti CPU.

Memantau memori Apache Kafka

Kami menyarankan Anda memantau memori yang digunakan Apache Kafka. Jika tidak, cluster mungkin tidak tersedia.

Untuk menentukan berapa banyak memori yang digunakan Apache Kafka, Anda dapat memantau HeapMemoryAfterGC metrik. 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 dari setiap transaksi.

Jangan menambahkan broker non-MSK

Untuk cluster ZooKeeper-based MSK Provisioned, jika Anda menggunakan ZooKeeper perintah Apache untuk menambahkan broker, broker ini tidak akan ditambahkan ke cluster MSK Provisioned Anda, dan Apache Anda ZooKeeper akan berisi informasi yang salah tentang cluster. Hal ini dapat mengakibatkan hilangnya data. Untuk operasi cluster MSK Provisioned yang didukung, lihat. Fitur dan konsep utama Amazon MSK

Aktifkan enkripsi dalam transit

Untuk informasi tentang enkripsi saat transit dan cara mengaktifkannya, lihatEnkripsi Amazon MSK saat transit.

Tetapkan kembali partisi

Untuk memindahkan partisi ke broker yang berbeda pada cluster MSK Provisioned yang sama, Anda dapat menggunakan alat penugasan ulang partisi bernama. kafka-reassign-partitions.sh Kami menyarankan agar Anda tidak menetapkan ulang 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 menetapkan kembali partisi ke broker baru. Untuk informasi tentang cara menambahkan broker ke cluster MSK Provisioned, lihat. Perluas jumlah broker di cluster Amazon MSK Untuk informasi tentang cara menghapus broker dari cluster MSK Provisioned, lihat. Menghapus Broker dari Klaster Amazon MSK Untuk informasi tentang alat penugasan ulang partisi, lihat Memperluas cluster Anda di dokumentasi Apache Kafka.