Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik terbaik untuk broker Express
Topik ini menguraikan beberapa praktik terbaik untuk diikuti saat menggunakan broker Express. Broker ekspres datang pra-konfigurasi untuk ketersediaan dan daya tahan tinggi. Data Anda didistribusikan di tiga zona ketersediaan secara default, replikasi selalu disetel ke 3 dan replika sinkronisasi minimum selalu disetel ke 2. Namun, masih ada beberapa faktor yang perlu dipertimbangkan untuk mengoptimalkan keandalan dan kinerja cluster Anda.
## 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 lengkap dalam rekomendasi praktik [ terbaik untuk klien ](bestpractices-kafka-client.md) Apache Kafka.
+ Jalankan tes kinerja untuk memverifikasi bahwa konfigurasi klien Anda memungkinkan Anda memenuhi tujuan kinerja Anda bahkan ketika kami memulai kembali broker di bawah beban puncak. Anda dapat me-reboot broker di cluster Anda dari konsol MSK atau menggunakan API MSK.
## Server-side pertimbangan
**Topics**
+ [Right-size cluster Anda: Jumlah broker per cluster](#brokers-per-express-cluster)
+ [Memantau penggunaan CPU](#bestpractices-monitor-cpu-express)
+ [Right-size cluster Anda: Jumlah partisi per broker Express](#partitions-per-express-broker)
+ [Pantau jumlah koneksi](#monitor-connection-count)
+ [Tetapkan kembali partisi](#bestpractices-express-reassign-partitions)
### Right-size cluster Anda: Jumlah broker per cluster
Memilih jumlah broker untuk Express-based cluster Anda mudah. Setiap broker Express dilengkapi dengan kapasitas throughput yang ditentukan untuk masuk dan keluar. Anda harus menggunakan kapasitas throughput ini sebagai sarana utama untuk mengukur ukuran cluster Anda (dan kemudian mempertimbangkan faktor-faktor lain seperti partisi dan jumlah koneksi, dibahas di bawah).
Misalnya, jika aplikasi streaming Anda membutuhkan kapasitas input data (write) 45 MBps dan keluaran data 90 MBps (baca), Anda cukup menggunakan 3 broker express.m7g.large untuk memenuhi kebutuhan throughput Anda. Setiap broker express.m7g.large akan menangani 15 MBps masuk dan 30 MBps keluar. Lihat tabel berikut untuk batas throughput yang kami rekomendasikan untuk setiap ukuran broker Express. Jika throughput Anda melebihi batas yang disarankan, Anda mungkin mengalami penurunan kinerja dan Anda harus mengurangi lalu lintas atau menskalakan cluster Anda. Jika throughput Anda melebihi batas yang disarankan dan mencapai kuota per broker, MSK akan membatasi lalu lintas klien Anda untuk mencegah kelebihan beban lebih lanjut.
Anda juga dapat menggunakan [ spreadsheet lihat Ukuran dan ](https://view.officeapps.live.com/op/view.aspx?src=https%3A%2F%2Fdy7oqpxkwhskb.cloudfront.net%2FMSK_Sizing_Pricing.xlsx&wdOrigin=BROWSELINK) Harga MSK kami untuk mengevaluasi beberapa skenario dan mempertimbangkan faktor-faktor lain, seperti jumlah partisi.
Tabel berikut mencantumkan throughput maksimum yang direkomendasikan per broker untuk setiap ukuran instans.
| Ukuran instans | Masuk (MBps) | Keluar (MBps) |
| --- | --- | --- |
| `express.m7g.large` | 15.6 | 31.2 |
| `express.m7g.xlarge` | 31.2 | 62.5 |
| `express.m7g.2xlarge` | 62.5 | 125.0 |
| `express.m7g.4xlarge` | 124.9 | 249.8 |
| `express.m7g.8xlarge` | 250.0 | 500.0 |
| `express.m7g.12xlarge` | 375.0 | 750.0 |
| `express.m7g.16xlarge` | 500.0 | 1000.0 |
### Memantau penggunaan CPU
Kami menyarankan agar Anda mempertahankan total pemanfaatan CPU untuk broker Anda (didefinisikan sebagai Pengguna CPU\+Sistem CPU) 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. Ini mungkin diperlukan karena acara yang direncanakan atau tidak direncanakan. Contoh acara yang direncanakan adalah peningkatan versi cluster di mana MSK memperbarui broker dalam cluster dengan memulai ulang mereka satu per satu. Contoh peristiwa yang tidak direncanakan adalah kegagalan perangkat keras di broker atau, dalam kasus terburuk, kegagalan AZ di mana semua broker di AZ terpengaruh. Ketika broker dengan replika lead partisi 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 headroom CPU yang cukup di cluster Anda untuk mentolerir peristiwa operasional seperti ini.
Anda dapat menggunakan [ Menggunakan ekspresi matematika dengan CloudWatch metrik ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) di Panduan CloudWatch Pengguna * Amazon * untuk membuat metrik gabungan yaitu Pengguna CPU \+ Sistem CPU. 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: Per [ barui ukuran broker Anda ](msk-update-broker-type.md) ke ukuran yang lebih besar berikutnya. 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.
+ Opsi 2: Per [ luas cluster Anda dengan menambahkan broker](msk-update-broker-count.md), lalu tetapkan kembali partisi yang ada menggunakan alat penugasan ulang partisi bernama. `kafka-reassign-partitions.sh`
**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 ](cruise-control.md) 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, disarankan agar Anda 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.
### Right-size cluster Anda: Jumlah partisi per broker Express
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
Cluster yang kelebihan beban dengan 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. ](https://blogs.apache.org/kafka/entry/apache-kafka-supports-more-partitions) Kami juga menyarankan Anda melakukan pengujian sendiri untuk menentukan ukuran yang tepat untuk broker Anda. Untuk informasi lebih lanjut tentang ukuran broker yang berbeda, lihat[Ukuran broker Amazon MSK](broker-instance-sizes.md).
Untuk informasi tentang jumlah partisi yang disarankan (termasuk replika pemimpin dan pengikut) untuk setiap broker Express, lihat[Kuota partisi broker ekspres](limits.md#msk-express-broker-partition-quota). Jumlah partisi yang disarankan tidak diterapkan dan merupakan praktik terbaik untuk skenario di mana Anda mengirim lalu lintas ke semua partisi topik yang disediakan.
### Pantau jumlah koneksi
Koneksi klien ke broker Anda menghabiskan sumber daya sistem seperti memori dan CPU. Tergantung pada mekanisme otentikasi Anda, Anda harus memantau untuk memastikan Anda berada dalam batas yang berlaku. Untuk menangani percobaan ulang pada koneksi yang gagal, Anda dapat mengatur parameter `reconnect.backoff.ms` konfigurasi di sisi klien. Misalnya, jika Anda ingin klien mencoba kembali koneksi setelah 1 detik, setel `reconnect.backoff.ms` ke`1000`. Untuk informasi selengkapnya tentang mengkonfigurasi percobaan ulang, lihat dokumentasi [ Apache Kafka. ](bestpractices-kafka-client.md#bestpractices-kafka-client-client-availability)
| Dimensi | Kuota |
| --- | --- |
| Koneksi TCP maksimum per broker (kontrol akses [ IAM) ](iam-access-control.md) | 3000 |
| Koneksi TCP maksimum per broker (IAM) | 100 per detik |
| Koneksi TCP maksimum per broker (non-IAM) | MSK tidak memberlakukan batas koneksi untuk autentikasi non-IAM. Namun Anda harus memantau metrik lain seperti penggunaan CPU dan memori untuk memastikan Anda tidak membebani cluster Anda karena koneksi yang berlebihan. |
### 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 20 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](msk-update-broker-count.md) Untuk informasi tentang cara menghapus broker dari cluster MSK Provisioned, lihat. [Menghapus Broker dari Klaster Amazon MSK](msk-remove-broker.md) Untuk informasi tentang alat penugasan ulang partisi, lihat [ Memperluas cluster Anda ](https://kafka.apache.org/documentation/#basic_ops_cluster_expansion) di dokumentasi Apache Kafka.