Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Fitur dan konsep utama MSK Amazon
Amazon MSK Provisioned cluster menawarkan berbagai fitur dan kemampuan untuk membantu Anda mengoptimalkan kinerja cluster Anda dan memenuhi kebutuhan streaming Anda. Topik di bawah ini menjelaskan fungsionalitas ini secara rinci.
+ Sebuah [Konsol Manajemen AWS](https://console.aws.amazon.com/msk)
+ Referensi [API MSK Amazon](https://docs.aws.amazon.com/msk/1.0/apireference)
+ Referensi [Perintah Amazon MSK CLI](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Jenis broker Amazon MSK](broker-instance-types.md)
+ [Ukuran broker Amazon MSK](broker-instance-sizes.md)
+ [Manajemen penyimpanan untuk pialang Standar](msk-storage-management.md)
+ [Konfigurasi Amazon MSK yang disediakan](msk-configuration.md)
+ [Penyeimbangan kembali cerdas untuk cluster](intelligent-rebalancing.md)
+ [Penambalan pada kluster MSK Provisioned](patching-impact.md)
+ [Broker offline dan failover klien](troubleshooting-offlinebroker-clientfailover.md)
+ [Keamanan di Amazon MSK](security.md)
+ [Pencatatan MSK Amazon](msk-logging.md)
+ [Manajemen metadata](metadata-management.md)
+ [Topik Operasi](msk-topic-operations-information.md)
+ [Sumber daya MSK Amazon](resources.md)
+ [Versi Apache Kafka](kafka-versions.md)
+ [Memecahkan masalah klaster MSK Amazon Anda](troubleshooting.md)
# Jenis broker Amazon MSK
MSK Provisioned menawarkan dua jenis broker - Standar dan Ekspres. Pialang standar memberi Anda fleksibilitas paling besar untuk mengonfigurasi cluster Anda, sementara broker Express menawarkan lebih banyak elastisitas, throughput, ketahanan, dan ease-of-use untuk menjalankan aplikasi streaming berkinerja tinggi.
Lihat topik berikut untuk detail lebih lanjut tentang setiap penawaran. Tabel berikut juga menyoroti perbandingan fitur utama antara pialang Standard dan Express.
| Fitur | Pialang standar | Pialang ekspres |
| --- | --- | --- |
| [Manajemen Penyimpanan](msk-storage-management.md) | Dikelola pelanggan (Fitur termasuk penyimpanan EBS, Penyimpanan berjenjang, throughput penyimpanan yang disediakan, Penskalaan otomatis, peringatan kapasitas penyimpanan) | Sepenuhnya MSK dikelola |
| [Contoh yang didukung](broker-instance-sizes.md) | T3, M5, M7g | M7g |
| [Pertimbangan ukuran dan penskalaan](bestpractices-intro.md) | Throughput, koneksi, partisi, penyimpanan | Throughput, koneksi, partisi |
| [Penskalaan broker](msk-update-broker-count.md) | Penskalaan vertikal dan horizontal | Penskalaan vertikal dan horizontal |
| [Versi Kafka](kafka-versions.md) | Lihat [Versi Apache Kafka](kafka-versions.md) | Dimulai pada versi 3.6 |
| [Konfigurasi Apache Kafka](msk-configuration.md) | Lebih dapat dikonfigurasi | Sebagian besar MSK dikelola untuk ketahanan yang lebih tinggi |
| [Keamanan](security.md) | Enkripsi, Private/Public akses, Otentikasi & Otorisasi - IAM, SASL/SCRAM, mTLS, plaintext, Kafka ACLs | Enkripsi, Private/Public akses, Otentikasi & Otorisasi - IAM, SASL/SCRAM, mTLS, plaintext, Kafka ACLs |
| [Pemantauan](monitoring.md) | CloudWatch, Pemantauan Terbuka | CloudWatch, Pemantauan Terbuka |
**catatan**
Anda tidak dapat mengubah klaster MSK Provisioned dari tipe broker Standar ke tipe broker Express dengan mengganti jenis broker menggunakan MSK API. Anda harus membuat cluster baru dengan jenis broker yang diinginkan (Standard atau Express).
**Topics**
+ [Pialang Standar MSK Amazon](msk-broker-types-standard.md)
+ [Pialang Amazon MSK Express](msk-broker-types-express.md)
# Pialang Standar MSK Amazon
Pialang standar untuk MSK Provisioned menawarkan fleksibilitas paling besar untuk mengonfigurasi kinerja klaster Anda. Anda dapat memilih dari berbagai konfigurasi cluster untuk mencapai ketersediaan, daya tahan, throughput, dan karakteristik latensi yang diperlukan untuk aplikasi Anda. Anda juga dapat menyediakan kapasitas penyimpanan dan meningkatkannya sesuai kebutuhan. Amazon MSK menangani pemeliharaan perangkat keras pialang Standar dan sumber daya penyimpanan yang terpasang, secara otomatis memperbaiki masalah perangkat keras yang mungkin timbul. Anda dapat menemukan detail lebih lanjut dalam dokumen ini tentang berbagai topik yang terkait dengan pialang Standar, termasuk topik tentang [manajemen penyimpanan](msk-storage-management.md), [konfigurasi](msk-configuration-standard.md), dan [pemeliharaan](patching-impact.md#patching-standard-brokers).
# Pialang Amazon MSK Express
Broker ekspres untuk MSK Provisioned membuat Apache Kafka lebih mudah dikelola, lebih hemat biaya untuk dijalankan dalam skala besar, dan lebih elastis dengan latensi rendah yang Anda harapkan. Broker menyertakan pay-as-you-go penyimpanan yang menskalakan secara otomatis dan tidak memerlukan ukuran, penyediaan, atau pemantauan proaktif. Bergantung pada ukuran instans yang dipilih, setiap node broker dapat memberikan throughput hingga 3x lebih banyak per broker, skala hingga 20x lebih cepat, dan memulihkan 90% lebih cepat dibandingkan dengan broker Apache Kafka standar. Broker ekspres datang pra-konfigurasi dengan default praktik terbaik Amazon MSK dan menegakkan kuota throughput klien untuk meminimalkan perselisihan sumber daya antara klien dan operasi latar belakang Kafka.
Berikut adalah beberapa faktor kunci dan kemampuan untuk dipertimbangkan saat menggunakan broker Express.
+ **Tidak ada manajemen penyimpanan**: Broker ekspres menghilangkan kebutuhan untuk [menyediakan atau mengelola sumber daya penyimpanan apa pun](msk-storage-management.md). Anda mendapatkan penyimpanan yang elastis, hampir tidak terbatas pay-as-you-go, dan terkelola sepenuhnya. Untuk kasus penggunaan throughput tinggi, Anda tidak perlu beralasan tentang interaksi antara instance komputasi dan volume penyimpanan, dan kemacetan throughput terkait. Kemampuan ini menyederhanakan manajemen cluster dan menghilangkan overhead operasional manajemen penyimpanan.
+ **Penskalaan lebih cepat**: Broker ekspres memungkinkan Anda untuk menskalakan cluster Anda dan memindahkan partisi hingga 20x lebih cepat daripada broker Standar. Kemampuan ini sangat penting ketika Anda perlu menskalakan klaster Anda untuk menangani lonjakan beban atau skala yang akan datang di cluster Anda untuk mengurangi biaya. Lihat bagian tentang [memperluas klaster Anda](msk-update-broker-count.md), [menghapus broker](msk-remove-broker.md), [menetapkan kembali partisi](msk-update-broker-type.md), dan [menyiapkan LinkedIn Cruise Control untuk penyeimbangan kembali untuk](cruise-control.md) detail selengkapnya tentang penskalaan klaster Anda.
+ **Throughput yang lebih tinggi**: Broker ekspres menawarkan throughput per broker hingga 3x lebih banyak daripada pialang Standar. Misalnya, Anda dapat dengan aman menulis data hingga 500 MBps dengan masing-masing broker Express berukuran besar m7g.16x dibandingkan dengan 153,8 MBps pada broker Standar yang setara (kedua angka mengasumsikan alokasi bandwidth yang cukup untuk operasi latar belakang, seperti replikasi dan penyeimbangan kembali).
+ **Dikonfigurasi untuk ketahanan tinggi**: Broker ekspres secara otomatis menawarkan berbagai praktik terbaik untuk meningkatkan ketahanan klaster Anda. Ini termasuk pagar pembatas pada konfigurasi Apache Kafka yang kritis, kuota throughput, dan pemesanan kapasitas untuk operasi latar belakang dan perbaikan yang tidak direncanakan. Kemampuan ini membuatnya lebih aman dan mudah untuk menjalankan aplikasi Apache Kafka skala besar. Lihat bagian di [Konfigurasi broker ekspres](msk-configuration-express.md) dan [Kuota broker Amazon MSK Express](limits.md#msk-express-quota) untuk lebih jelasnya.
+ **Tidak ada jendela Pemeliharaan**: Tidak ada jendela pemeliharaan untuk broker Express. Amazon MSK secara otomatis memperbarui perangkat keras cluster Anda secara berkelanjutan. Lihat [Patching for Express broker](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers) untuk detail selengkapnya.
## Informasi tambahan tentang broker Express
+ Broker ekspres bekerja dengan Apache Kafka APIs, tetapi belum sepenuhnya mendukung KStreams API.
+ Broker ekspres hanya tersedia dalam AZs konfigurasi 3.
+ Broker ekspres hanya tersedia pada ukuran instans tertentu. Lihat [harga MSK Amazon](https://aws.amazon.com/msk/pricing/) untuk daftar yang diperbarui.
+ Broker ekspres didukung pada versi Apache Kafka berikut: 3.6, 3.8, dan 3.9.
+ Broker ekspres dapat dibuat dengan KRaft mode dari Apache Kafka versi 3.9 dan seterusnya.
**Lihat blog ini**
Untuk informasi lebih lanjut tentang broker MSK Express dan untuk melihat contoh dunia nyata dari broker Express yang digunakan, baca blog berikut:
[Memperkenalkan broker Express untuk Amazon MSK untuk memberikan throughput tinggi dan penskalaan yang lebih cepat untuk cluster Kafka Anda](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Broker ekspres untuk Amazon MSK: Penskalaan Kafka bermuatan turbo dengan kinerja hingga 20 kali lebih cepat](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
Blog ini menunjukkan bagaimana broker Express:
Memberikan throughput yang lebih cepat, penskalaan yang cepat, dan waktu pemulihan yang lebih baik dari kegagalan
Hilangkan kompleksitas manajemen penyimpanan
# Ukuran broker Amazon MSK
Saat Anda membuat klaster Amazon MSK Provisioned, Anda menentukan ukuran broker yang Anda inginkan. Tergantung pada [jenis broker](broker-instance-types.md), Amazon MSK mendukung ukuran broker berikut.
**Ukuran pialang standar**
+ kafka.t3.small
+ kafka.m5.large, kafka.m5.xlarge, kafka.m5.2xlarge, kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge, kafka.m5.24xlarge
+ kafka.m7g.large, kafka.m7g.xlarge, kafka.m7g.2xlarge, kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge, kafka.m7g.16xlarge
**Ukuran broker ekspres**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.16xlarge
**catatan**
Beberapa ukuran broker mungkin tidak tersedia di AWS Wilayah Certian. Lihat Tabel Harga Instance Broker yang diperbarui di [halaman harga MSK Amazon](https://aws.amazon.com/msk/pricing/) untuk daftar terbaru instans yang tersedia menurut Wilayah.
## Catatan lain tentang ukuran broker
+ Broker M7g menggunakan prosesor AWS Graviton (prosesor berbasis ARM khusus yang dibuat oleh Amazon Web Services). Broker M7g menawarkan peningkatan kinerja harga relatif terhadap instance M5 yang sebanding. Pialang m7g mengkonsumsi daya lebih sedikit daripada instans M5 yang sebanding.
+ Amazon MSK mendukung broker M7g di kluster MSK Provisioned yang menjalankan versi 2.8.2 dan 3.3.2 dan Kafka yang lebih tinggi.
+ Broker M7g dan M5 memiliki kinerja throughput baseline yang lebih tinggi daripada broker T3 dan direkomendasikan untuk beban kerja produksi. Broker M7g dan M5 juga dapat memiliki lebih banyak partisi per broker daripada broker T3. Gunakan broker M7G atau M5 jika Anda menjalankan beban kerja tingkat produksi yang lebih besar atau memerlukan lebih banyak partisi. Untuk mempelajari lebih lanjut tentang ukuran instans M7g dan M5, lihat Instans Tujuan [ EC2 Umum Amazon](https://aws.amazon.com/ec2/instance-types/).
+ Broker T3 memiliki kemampuan untuk menggunakan kredit CPU untuk meningkatkan kinerja sementara. Gunakan broker T3 untuk pengembangan berbiaya rendah, jika Anda menguji beban kerja streaming kecil hingga menengah, atau jika Anda memiliki beban kerja streaming throughput rendah yang mengalami lonjakan sementara dalam throughput. Kami menyarankan Anda menjalankan proof-of-concept tes untuk menentukan apakah broker T3 cukup untuk produksi atau beban kerja kritis. Untuk mempelajari lebih lanjut tentang ukuran broker T3, lihat Instans [Amazon EC2 T3](https://aws.amazon.com/ec2/instance-types/t3/).
Untuk informasi lebih lanjut tentang cara memilih ukuran broker, lihat[Praktik terbaik untuk pialang Standar dan Ekspres](bestpractices-intro.md).
# Manajemen penyimpanan untuk pialang Standar
Amazon MSK menyediakan fitur untuk membantu Anda dengan manajemen penyimpanan di kluster MSK Anda.
**catatan**
Dengan [broker Express](msk-broker-types-express.md), Anda tidak perlu menyediakan atau mengelola sumber penyimpanan apa pun yang digunakan untuk data Anda. Ini menyederhanakan manajemen cluster dan menghilangkan salah satu penyebab umum masalah operasional dengan cluster Apache Kafka. Anda juga menghabiskan lebih sedikit karena Anda tidak perlu menyediakan kapasitas penyimpanan idle dan Anda hanya membayar untuk apa yang Anda gunakan.
**Jenis pialang standar**
Dengan [pialang Standar](msk-broker-types-standard.md) Anda dapat memilih dari berbagai opsi dan kemampuan penyimpanan. Amazon MSK menyediakan fitur untuk membantu Anda dengan manajemen penyimpanan di kluster MSK Anda.
Untuk informasi tentang mengelola throughput, lihat[Penyediaan throughput penyimpanan untuk pialang Standar di cluster MSK Amazon](msk-provision-throughput.md).
**Topics**
+ [Penyimpanan berjenjang untuk pialang Standar](msk-tiered-storage.md)
+ [Tingkatkan penyimpanan broker Amazon MSK Standard](msk-update-storage.md)
+ [Kelola throughput penyimpanan untuk pialang Standar di klaster MSK Amazon](msk-provision-throughput-management.md)
# Penyimpanan berjenjang untuk pialang Standar
Penyimpanan berjenjang adalah tingkat penyimpanan berbiaya rendah untuk MSK Amazon yang diskalakan ke penyimpanan yang hampir tidak terbatas, sehingga hemat biaya untuk membangun aplikasi data streaming.
Anda dapat membuat kluster MSK Amazon yang dikonfigurasi dengan penyimpanan berjenjang yang menyeimbangkan kinerja dan biaya. Amazon MSK menyimpan data streaming dalam tingkat penyimpanan utama yang dioptimalkan kinerja hingga mencapai batas retensi topik Apache Kafka. Kemudian, Amazon MSK secara otomatis memindahkan data ke tingkat penyimpanan berbiaya rendah yang baru.
Saat aplikasi Anda mulai membaca data dari penyimpanan berjenjang, Anda dapat mengharapkan peningkatan latensi baca untuk beberapa byte pertama. Saat Anda mulai membaca data yang tersisa secara berurutan dari tingkat berbiaya rendah, Anda dapat mengharapkan latensi yang mirip dengan tingkat penyimpanan utama. Anda tidak perlu menyediakan penyimpanan apa pun untuk penyimpanan berjenjang berbiaya rendah atau mengelola infrastruktur. Anda dapat menyimpan sejumlah data dan hanya membayar untuk apa yang Anda gunakan. Fitur ini kompatibel dengan yang APIs diperkenalkan di [KIP-405: Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Tiered Storage.
Untuk informasi tentang ukuran, pemantauan, dan pengoptimalan kluster penyimpanan berjenjang MSK, lihat [Praktik terbaik untuk menjalankan beban kerja produksi menggunakan penyimpanan berjenjang MSK Amazon](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/).
Berikut adalah beberapa fitur penyimpanan berjenjang:
+ Anda dapat menskalakan ke penyimpanan yang hampir tidak terbatas. Anda tidak perlu menebak bagaimana menskalakan infrastruktur Apache Kafka Anda.
+ Anda dapat menyimpan data lebih lama di topik Apache Kafka Anda, atau meningkatkan penyimpanan topik Anda, tanpa perlu menambah jumlah broker.
+ Ini menyediakan buffer keamanan durasi yang lebih lama untuk menangani penundaan pemrosesan yang tidak terduga.
+ Anda dapat memproses ulang data lama dalam urutan produksi yang tepat dengan kode pemrosesan aliran yang ada dan Kafka APIs.
+ Partisi menyeimbangkan kembali lebih cepat karena data pada penyimpanan sekunder tidak memerlukan replikasi di seluruh disk broker.
+ Data antara broker dan penyimpanan berjenjang bergerak di dalam VPC dan tidak melakukan perjalanan melalui internet.
+ Mesin klien dapat menggunakan proses yang sama untuk terhubung ke cluster baru dengan penyimpanan berjenjang diaktifkan seperti halnya untuk terhubung ke cluster tanpa penyimpanan berjenjang diaktifkan. Lihat [Membuat mesin klien](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
## Persyaratan penyimpanan berjenjang untuk cluster MSK Amazon
+ Anda harus menggunakan klien Apache Kafka versi 3.0.0 atau lebih tinggi untuk membuat topik baru dengan penyimpanan berjenjang diaktifkan. Untuk mentransisikan topik yang ada ke penyimpanan berjenjang, Anda dapat mengonfigurasi ulang mesin klien yang menggunakan versi klien Kafka yang lebih rendah dari 3.0.0 (versi Apache Kafka minimum yang didukung adalah 2.8.2.tiered) untuk mengaktifkan penyimpanan berjenjang. Lihat [Langkah 4: Buat topik di cluster MSK Amazon](create-topic.md).
+ Cluster MSK Amazon dengan penyimpanan berjenjang yang diaktifkan harus menggunakan versi 3.6.0 atau lebih tinggi, atau 2.8.2.tiered.
## Kendala dan batasan penyimpanan berjenjang untuk cluster MSK Amazon
Penyimpanan berjenjang memiliki kendala dan batasan berikut:
+ Pastikan klien tidak dikonfigurasi `read_committed` saat membaca dari remote\$1tier di MSK Amazon, kecuali aplikasi secara aktif menggunakan fitur transaksi.
+ Penyimpanan berjenjang tidak tersedia di wilayah AWS GovCloud (AS).
+ Penyimpanan berjenjang hanya berlaku untuk cluster mode yang disediakan.
+ Penyimpanan berjenjang tidak mendukung ukuran broker t3.small.
+ Periode retensi minimum dalam penyimpanan berbiaya rendah adalah 3 hari. Tidak ada periode retensi minimum untuk penyimpanan primer.
+ Penyimpanan berjenjang tidak mendukung direktori Multiple Log pada broker (fitur terkait JBOD).
+ Penyimpanan berjenjang tidak mendukung topik yang dipadatkan. Pastikan bahwa semua topik yang telah mengaktifkan penyimpanan berjenjang memiliki cleanup.policy yang dikonfigurasi menjadi 'HAPUS' saja.
+ Cluster penyimpanan berjenjang tidak mendukung perubahan kebijakan log.cleanup.policy untuk topik setelah dibuat.
+ Penyimpanan berjenjang dapat dinonaktifkan untuk topik individual tetapi tidak untuk seluruh cluster. Setelah dinonaktifkan, penyimpanan berjenjang tidak dapat diaktifkan kembali untuk suatu topik.
+ Jika Anda menggunakan Amazon MSK versi 2.8.2.tiered, Anda hanya dapat bermigrasi ke versi Apache Kafka yang didukung penyimpanan berjenjang lainnya. Jika Anda tidak ingin terus menggunakan versi yang didukung penyimpanan berjenjang, buat klaster MSK baru dan migrasi data Anda ke sana.
+ kafka-log-dirsAlat ini tidak dapat melaporkan ukuran data penyimpanan berjenjang. Alat ini hanya melaporkan ukuran segmen log di penyimpanan primer.
Untuk informasi tentang pengaturan dan batasan default yang harus Anda perhatikan saat mengonfigurasi penyimpanan berjenjang di tingkat topik, lihat. [Pedoman untuk konfigurasi tingkat topik penyimpanan berjenjang MSK Amazon](msk-guidelines-tiered-storage-topic-level-config.md)
# Bagaimana segmen log disalin ke penyimpanan berjenjang untuk topik MSK Amazon
Saat Anda mengaktifkan penyimpanan berjenjang untuk topik baru atau yang sudah ada, Apache Kafka menyalin segmen log tertutup dari penyimpanan utama ke penyimpanan berjenjang.
+ Apache Kafka hanya menyalin segmen log tertutup. Ini menyalin semua pesan dalam segmen log ke penyimpanan berjenjang.
+ Segmen aktif tidak memenuhi syarat untuk tiering. Ukuran segmen log (segment.bytes) atau waktu roll segmen (segment.ms) mengontrol tingkat penutupan segmen, dan tingkat Apache Kafka kemudian menyalinnya ke penyimpanan berjenjang.
Pengaturan retensi untuk topik dengan penyimpanan berjenjang diaktifkan berbeda dari pengaturan untuk topik tanpa penyimpanan berjenjang diaktifkan. Aturan berikut mengontrol penyimpanan pesan dalam topik dengan penyimpanan berjenjang diaktifkan:
+ Anda menentukan retensi di Apache Kafka dengan dua pengaturan: log.retention.ms (waktu) dan log.retention.bytes (ukuran). Pengaturan ini menentukan total durasi dan ukuran data yang dipertahankan Apache Kafka di cluster. Apakah Anda mengaktifkan mode penyimpanan berjenjang atau tidak, Anda mengatur konfigurasi ini di tingkat cluster. Anda dapat mengganti pengaturan di tingkat topik dengan konfigurasi topik.
+ Saat Anda mengaktifkan penyimpanan berjenjang, Anda juga dapat menentukan berapa lama tingkat penyimpanan berkinerja tinggi utama menyimpan data. Misalnya, jika topik memiliki pengaturan retensi keseluruhan (log.retention.ms) 7 hari dan retensi lokal (local.retention.ms) 12 jam, maka penyimpanan utama klaster menyimpan data hanya selama 12 jam pertama. Tingkat penyimpanan berbiaya rendah mempertahankan data selama 7 hari penuh.
+ Pengaturan retensi yang biasa berlaku untuk log lengkap. Ini termasuk bagian berjenjang dan utamanya.
+ Setelan local.retention.ms atau local.retention.bytes mengontrol retensi pesan di penyimpanan utama. Apache Kafka menyalin segmen log tertutup ke penyimpanan berjenjang segera setelah ditutup (berdasarkan segment.bytes atau segment.ms), terlepas dari pengaturan retensi lokal. Setelah segmen disalin ke penyimpanan berjenjang, mereka tetap berada di penyimpanan utama hingga ambang batas local.retention.ms atau local.retention.bytes tercapai. Pada saat itu, data dihapus dari penyimpanan primer tetapi tetap tersedia dalam penyimpanan berjenjang. Ini memungkinkan Anda menyimpan data terbaru pada penyimpanan primer berkinerja tinggi untuk akses cepat sementara data lama disajikan dari penyimpanan berjenjang berbiaya rendah.
+ Ketika Apache Kafka menyalin pesan di segmen log ke penyimpanan berjenjang, itu akan menghapus pesan dari cluster berdasarkan pengaturan retention.ms atau retention.bytes.
## Contoh skenario penyimpanan berjenjang MSK Amazon
Skenario ini menggambarkan bagaimana topik yang ada yang memiliki pesan di penyimpanan utama berperilaku saat penyimpanan berjenjang diaktifkan. Anda mengaktifkan penyimpanan berjenjang pada topik ini saat Anda menyetel remote.storage.enable ke. `true` Dalam contoh ini, retention.ms diatur ke 5 hari dan local.retention.ms diatur ke 2 hari. Berikut ini adalah urutan peristiwa ketika segmen kedaluwarsa.
**Time T0 - Sebelum Anda mengaktifkan penyimpanan berjenjang.**
Sebelum Anda mengaktifkan penyimpanan berjenjang untuk topik ini, ada dua segmen log. Salah satu segmen aktif untuk partisi topik yang ada 0.
![\[Time T0 - Sebelum Anda mengaktifkan penyimpanan berjenjang.\]](http://docs.aws.amazon.com/id_id/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Waktu T1 (< 2 hari) - Penyimpanan berjenjang diaktifkan. Segmen 0 disalin ke penyimpanan berjenjang.**
Setelah Anda mengaktifkan penyimpanan berjenjang untuk topik ini, Apache Kafka menyalin segmen log tertutup 0 ke penyimpanan berjenjang segera setelah ditutup. Segmen ditutup berdasarkan setelan segment.bytes atau segment.ms, bukan berdasarkan pengaturan retensi. Apache Kafka menyimpan salinannya di penyimpanan utama juga. Segmen aktif 1 belum memenuhi syarat untuk menyalin ke penyimpanan berjenjang karena masih aktif dan belum ditutup. Dalam timeline ini, Amazon MSK belum menerapkan pengaturan retensi apa pun untuk pesan apa pun di segmen 0 dan segmen 1. (local.retention. bytes/ms, retention.ms/bytes)
![\[Waktu T1 (< 2 hari) - Penyimpanan berjenjang diaktifkan. Segmen 0 disalin ke penyimpanan berjenjang.\]](http://docs.aws.amazon.com/id_id/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Waktu T2 - Retensi lokal berlaku.**
Setelah 2 hari, ambang retensi lokal tercapai untuk segmen 0. Pengaturan local.retention.ms sebagai 2 hari menentukan ini. Segmen 0 sekarang dihapus dari penyimpanan utama, tetapi tetap tersedia dalam penyimpanan berjenjang. Perhatikan bahwa segmen 0 telah disalin ke penyimpanan berjenjang di Time T1 saat ditutup, bukan pada Time T2 saat retensi lokal kedaluwarsa. Segmen aktif 1 belum memenuhi syarat untuk dihapus atau memenuhi syarat untuk menyalin ke penyimpanan berjenjang karena masih aktif.
![\[Waktu T2 - Retensi lokal berlaku.\]](http://docs.aws.amazon.com/id_id/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Waktu T3 - Retensi keseluruhan berlaku.**
Setelah 5 hari, pengaturan retensi mulai berlaku, dan Kafka menghapus segmen log 0 dan pesan terkait dari penyimpanan berjenjang. Segmen 1 belum memenuhi syarat untuk kedaluwarsa atau memenuhi syarat untuk menyalin ke penyimpanan berjenjang karena aktif. Segmen 1 belum ditutup, sehingga tidak memenuhi syarat untuk roll segmen.
![\[Waktu T3 - Retensi keseluruhan berlaku.\]](http://docs.aws.amazon.com/id_id/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# Buat cluster MSK Amazon dengan penyimpanan berjenjang dengan Konsol Manajemen AWS
Proses ini menjelaskan cara membuat cluster MSK Amazon penyimpanan berjenjang menggunakan. Konsol Manajemen AWS
1. Buka konsol MSK Amazon di[https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Pilih **Buat klaster**.
1. Pilih **Custom create** untuk penyimpanan berjenjang.
1. Tentukan nama untuk cluster.
1. Pada **tipe Cluster**, pilih **Provisioned**.
1. Pilih versi Amazon Kafka yang mendukung penyimpanan berjenjang untuk Amazon MSK untuk digunakan untuk membuat cluster.
1. Tentukan ukuran broker selain **kafka.t3.small**.
1. Pilih jumlah broker yang ingin Anda buat Amazon MSK di setiap Availability Zone. Minimal adalah satu broker per Availability Zone, dan maksimum adalah 30 broker per cluster.
1. Tentukan jumlah zona yang didistribusikan oleh broker.
1. Tentukan jumlah broker Apache Kafka yang digunakan per zona.
1. Pilih **opsi Penyimpanan**. Ini termasuk **penyimpanan berjenjang dan penyimpanan EBS untuk mengaktifkan mode penyimpanan** berjenjang.
1. Ikuti langkah-langkah yang tersisa di wizard pembuatan cluster. Saat selesai, **Penyimpanan berjenjang dan penyimpanan EBS** muncul sebagai mode penyimpanan cluster dalam tampilan **Review and create**.
1. Pilih **Buat klaster**.
# Buat cluster MSK Amazon dengan penyimpanan berjenjang dengan AWS CLI
Untuk mengaktifkan penyimpanan berjenjang pada cluster, buat cluster dengan versi Apache Kafka yang benar dan atribut untuk penyimpanan berjenjang. Ikuti contoh kode di bawah ini. Juga, selesaikan langkah-langkah di bagian selanjutnya untuk[Buat topik Kafka dengan penyimpanan berjenjang diaktifkan dengan AWS CLI](#msk-create-topic-tiered-storage-cli).
Lihat [create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html) untuk daftar lengkap atribut yang didukung untuk pembuatan klaster.
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## Buat topik Kafka dengan penyimpanan berjenjang diaktifkan dengan AWS CLI
Untuk menyelesaikan proses yang Anda mulai saat membuat klaster dengan penyimpanan berjenjang diaktifkan, buat juga topik dengan penyimpanan berjenjang yang diaktifkan dengan atribut dalam contoh kode selanjutnya. Atribut khusus untuk penyimpanan berjenjang adalah sebagai berikut:
+ `local.retention.ms`(misalnya, 10 menit) untuk pengaturan retensi berbasis waktu atau `local.retention.bytes` untuk batas ukuran segmen log.
+ `remote.storage.enable`disetel ke `true` untuk mengaktifkan penyimpanan berjenjang.
Konfigurasi berikut menggunakan local.retention.ms, tetapi Anda dapat mengganti atribut ini dengan local.retention.bytes. Atribut ini mengontrol jumlah waktu yang dapat dilewati atau jumlah byte yang dapat disalin Apache Kafka sebelum Apache Kafka menyalin data dari penyimpanan primer ke penyimpanan berjenjang. Lihat [Konfigurasi tingkat topik untuk detail selengkapnya tentang atribut konfigurasi](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) yang didukung.
**catatan**
Anda harus menggunakan klien Apache Kafka versi 3.0.0 dan di atasnya. Versi ini mendukung pengaturan yang disebut `remote.storage.enable` hanya dalam versi klien tersebut`kafka-topics.sh`. Untuk mengaktifkan penyimpanan berjenjang pada topik yang ada yang menggunakan versi Apache Kafka sebelumnya, lihat bagian. [Mengaktifkan penyimpanan berjenjang pada topik MSK Amazon yang ada](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli)
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# Mengaktifkan dan menonaktifkan penyimpanan berjenjang pada topik MSK Amazon yang ada
Bagian ini mencakup cara mengaktifkan dan menonaktifkan penyimpanan berjenjang pada topik yang telah Anda buat. Untuk membuat klaster dan topik baru dengan penyimpanan berjenjang diaktifkan, lihat [Membuat klaster dengan penyimpanan berjenjang menggunakan](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console). Konsol Manajemen AWS
## Mengaktifkan penyimpanan berjenjang pada topik MSK Amazon yang ada
Untuk mengaktifkan penyimpanan berjenjang pada topik yang ada, gunakan sintaks `alter` perintah dalam contoh berikut. Saat Anda mengaktifkan penyimpanan berjenjang pada topik yang sudah ada, Anda tidak dibatasi pada versi klien Apache Kafka tertentu.
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## Nonaktifkan penyimpanan berjenjang pada topik MSK Amazon yang ada
Untuk menonaktifkan penyimpanan berjenjang pada topik yang ada, gunakan sintaks `alter` perintah dalam urutan yang sama seperti saat Anda mengaktifkan penyimpanan berjenjang.
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**catatan**
Saat Anda menonaktifkan penyimpanan berjenjang, Anda sepenuhnya menghapus data topik di penyimpanan berjenjang. Apache Kafka mempertahankan data penyimpanan primer, tetapi masih menerapkan aturan retensi primer berdasarkan. `local.retention.ms` Setelah menonaktifkan penyimpanan berjenjang pada suatu topik, Anda tidak dapat mengaktifkannya kembali. Jika Anda ingin menonaktifkan penyimpanan berjenjang pada topik yang ada, Anda tidak dibatasi untuk versi klien Apache Kafka tertentu.
# Aktifkan penyimpanan berjenjang pada kluster MSK Amazon yang ada menggunakan CLI AWS
**catatan**
Anda dapat mengaktifkan penyimpanan berjenjang hanya jika log.cleanup.policy klaster Anda disetel`delete`, karena topik yang dipadatkan tidak didukung pada penyimpanan berjenjang. Kemudian, Anda dapat mengonfigurasi log.cleanup.policy masing-masing topik menjadi `compact` jika penyimpanan berjenjang tidak diaktifkan pada topik tertentu. Lihat [Konfigurasi tingkat topik untuk detail selengkapnya tentang atribut konfigurasi](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) yang didukung.
1. **Perbarui versi Kafka - Versi** cluster bukan bilangan bulat sederhana. Untuk menemukan versi cluster saat ini, gunakan `DescribeCluster` operasi atau perintah `describe-cluster` AWS CLI. Contoh versi adalah`KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. Edit mode penyimpanan cluster. Contoh kode berikut menunjukkan pengeditan mode penyimpanan cluster untuk `TIERED` menggunakan [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html)API.
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# Perbarui penyimpanan berjenjang pada kluster MSK Amazon yang ada menggunakan konsol
Proses ini menjelaskan cara memperbarui penyimpanan berjenjang Amazon MSK cluster menggunakan. Konsol Manajemen AWS
Pastikan versi Apache Kafka saat ini dari cluster MSK Anda adalah 2.8.2.tier. Lihat [memperbarui versi Apache Kafka jika Anda perlu meng-upgrade cluster MSK Anda ke versi](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html) 2.8.2.tiered.
**catatan**
Anda dapat mengaktifkan penyimpanan berjenjang hanya jika log.cleanup.policy klaster Anda disetel`delete`, karena topik yang dipadatkan tidak didukung pada penyimpanan berjenjang. Kemudian, Anda dapat mengonfigurasi log.cleanup.policy masing-masing topik menjadi `compact` jika penyimpanan berjenjang tidak diaktifkan pada topik tertentu. Lihat [Konfigurasi tingkat topik untuk detail selengkapnya tentang atribut konfigurasi](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) yang didukung.
1. Buka konsol MSK Amazon di[https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Buka halaman ringkasan cluster dan pilih **Properties**.
1. Buka bagian **Penyimpanan** dan pilih **Edit mode penyimpanan cluster**.
1. Pilih **Penyimpanan berjenjang dan penyimpanan EBS** dan **Simpan** perubahan.
# Tingkatkan penyimpanan broker Amazon MSK Standard
Anda dapat meningkatkan jumlah penyimpanan EBS per broker. Anda tidak dapat mengurangi penyimpanan.
Volume penyimpanan tetap tersedia selama operasi penskalaan ini.
**penting**
Saat penyimpanan diskalakan untuk cluster MSK, penyimpanan tambahan segera tersedia. Namun, cluster memerlukan periode pendinginan setelah setiap peristiwa penskalaan penyimpanan. Amazon MSK menggunakan periode pendinginan ini untuk mengoptimalkan cluster sebelum dapat diskalakan lagi. Periode ini dapat berkisar dari minimal 6 jam hingga lebih dari 24 jam, tergantung pada ukuran penyimpanan dan pemanfaatan cluster dan lalu lintas. Ini berlaku untuk acara penskalaan otomatis dan penskalaan manual menggunakan operasi. [UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage) Untuk informasi tentang ukuran penyimpanan yang tepat, lihat. [Praktik terbaik untuk pialang Standar](bestpractices.md)
Anda dapat menggunakan penyimpanan berjenjang untuk meningkatkan jumlah penyimpanan yang tidak terbatas untuk broker Anda. Lihat, [Penyimpanan berjenjang untuk pialang Standar](msk-tiered-storage.md).
**Topics**
+ [Penskalaan otomatis untuk cluster MSK Amazon](msk-autoexpand.md)
+ [Penskalaan manual untuk pialang Standar](manually-expand-storage.md)
# Penskalaan otomatis untuk cluster MSK Amazon
Untuk memperluas penyimpanan klaster secara otomatis sebagai respons terhadap peningkatan penggunaan, Anda dapat mengonfigurasi kebijakan Penskalaan Otomatis Aplikasi untuk Amazon MSK. Dalam kebijakan auto-scaling, Anda menetapkan pemanfaatan disk target dan kapasitas penskalaan maksimum.
Sebelum Anda menggunakan penskalaan otomatis untuk Amazon MSK, Anda harus mempertimbangkan hal berikut:
+
**penting**
Tindakan penskalaan penyimpanan hanya dapat terjadi setiap enam jam sekali.
Kami menyarankan Anda memulai dengan volume penyimpanan berukuran tepat untuk kebutuhan penyimpanan Anda. Untuk panduan tentang ukuran kanan klaster Anda, lihat. [Ukuran kluster Anda dengan benar: Jumlah pialang Standar per klaster](bestpractices.md#brokers-per-cluster)
+ Amazon MSK tidak mengurangi penyimpanan cluster sebagai respons terhadap pengurangan penggunaan. Amazon MSK tidak mendukung penurunan ukuran volume penyimpanan. Jika Anda perlu mengurangi ukuran penyimpanan klaster, Anda harus memigrasikan klaster yang ada ke klaster dengan penyimpanan yang lebih kecil. Untuk informasi tentang migrasi klaster, lihat[Migrasi ke MSK cluster](migration.md).
+ Amazon MSK tidak mendukung penskalaan otomatis di Wilayah Asia Pasifik (Osaka), Afrika (Cape Town), dan Asia Pasifik (Malaysia).
+ Saat Anda mengaitkan kebijakan auto-scaling dengan klaster, Amazon EC2 Auto Scaling secara otomatis membuat alarm Amazon untuk pelacakan target. CloudWatch Jika Anda menghapus klaster dengan kebijakan auto-scaling, CloudWatch alarm ini tetap ada. Untuk menghapus CloudWatch alarm, Anda harus menghapus kebijakan auto-scaling dari klaster sebelum menghapus klaster. Untuk mempelajari selengkapnya tentang pelacakan target, lihat [Kebijakan penskalaan pelacakan target untuk Penskalaan Otomatis Amazon EC2 Auto](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) Scaling di Panduan Pengguna Amazon EC2 *Auto Scaling*.
**Topics**
+ [Detail kebijakan penskalaan otomatis untuk Amazon MSK](msk-autoexpand-details.md)
+ [Siapkan penskalaan otomatis untuk kluster MSK Amazon Anda](msk-autoexpand-setup.md)
# Detail kebijakan penskalaan otomatis untuk Amazon MSK
Kebijakan auto-scaling menentukan parameter berikut untuk klaster Anda:
+ **Target Pemanfaatan Penyimpanan**: Ambang batas pemanfaatan penyimpanan yang digunakan Amazon MSK untuk memicu operasi auto-scaling. Anda dapat menetapkan target pemanfaatan antara 10% dan 80% dari kapasitas penyimpanan saat ini. Kami menyarankan Anda menetapkan Target Pemanfaatan Penyimpanan antara 50% dan 60%.
+ **Kapasitas Penyimpanan Maksimum**: Batas penskalaan maksimum yang dapat ditetapkan MSK Amazon untuk penyimpanan broker Anda. Anda dapat mengatur kapasitas penyimpanan maksimum hingga 16 TiB per broker. Untuk informasi selengkapnya, lihat [Kuota MSK Amazon](limits.md).
Ketika Amazon MSK mendeteksi bahwa `Maximum Disk Utilization` metrik Anda sama dengan atau lebih besar dari `Storage Utilization Target` pengaturan, itu meningkatkan kapasitas penyimpanan Anda dengan jumlah yang sama dengan yang lebih besar dari dua angka: 10 GiB atau 10% dari penyimpanan saat ini. Misalnya, jika Anda memiliki 1000 GiB, jumlah itu adalah 100 GiB. Layanan ini memeriksa penggunaan penyimpanan Anda setiap menit. Operasi penskalaan lebih lanjut terus meningkatkan penyimpanan dengan jumlah yang sama dengan yang lebih besar dari dua angka: 10 GiB atau 10% dari penyimpanan saat ini.
Untuk menentukan apakah operasi auto-scaling telah terjadi, gunakan operasi. [ ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations)
# Siapkan penskalaan otomatis untuk kluster MSK Amazon Anda
Anda dapat menggunakan konsol MSK Amazon, Amazon MSK API, atau CloudFormation untuk menerapkan penskalaan otomatis untuk penyimpanan. CloudFormation Dukungan tersedia melalui [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html).
**catatan**
Anda tidak dapat menerapkan penskalaan otomatis saat membuat klaster. Anda harus terlebih dahulu membuat klaster, lalu membuat dan mengaktifkan kebijakan auto-scaling untuknya. Namun, Anda dapat membuat kebijakan saat layanan Amazon MSK membuat klaster Anda.
**Topics**
+ [Siapkan penskalaan otomatis menggunakan MSK Amazon Konsol Manajemen AWS](msk-autoexpand-setup-console.md)
+ [Siapkan penskalaan otomatis menggunakan CLI](msk-autoexpand-setup-cli.md)
+ [Menyiapkan penskalaan otomatis untuk Amazon MSK menggunakan API](msk-autoexpand-setup-api.md)
# Siapkan penskalaan otomatis menggunakan MSK Amazon Konsol Manajemen AWS
Proses ini menjelaskan cara menggunakan konsol MSK Amazon untuk menerapkan penskalaan otomatis untuk penyimpanan.
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih cluster Anda. Ini membawa Anda ke halaman yang mencantumkan detail tentang cluster.
1. Di bagian **Penskalaan otomatis untuk penyimpanan**, pilih **Konfigurasi**.
1. Buat dan beri nama kebijakan auto-scaling. Tentukan target pemanfaatan penyimpanan, kapasitas penyimpanan maksimum, dan metrik target.
1. Pilih `Save changes`.
Saat Anda menyimpan dan mengaktifkan kebijakan baru, kebijakan menjadi aktif untuk klaster. Amazon MSK kemudian memperluas penyimpanan cluster ketika target pemanfaatan penyimpanan tercapai.
# Siapkan penskalaan otomatis menggunakan CLI
Proses ini menjelaskan cara menggunakan Amazon MSK CLI untuk menerapkan penskalaan otomatis untuk penyimpanan.
1. Gunakan [ RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)perintah untuk mendaftarkan target pemanfaatan penyimpanan.
1. Gunakan [ PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)perintah untuk membuat kebijakan ekspansi otomatis.
# Menyiapkan penskalaan otomatis untuk Amazon MSK menggunakan API
Proses ini menjelaskan cara menggunakan Amazon MSK API untuk menerapkan penskalaan otomatis untuk penyimpanan.
1. Gunakan [ RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html)API untuk mendaftarkan target pemanfaatan penyimpanan.
1. Gunakan [ PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)API untuk membuat kebijakan ekspansi otomatis.
# Penskalaan manual untuk pialang Standar
Untuk meningkatkan penyimpanan, tunggu cluster berada dalam `ACTIVE` status. Penskalaan penyimpanan memiliki periode pendinginan setidaknya enam jam di antara acara. Meskipun operasi membuat penyimpanan tambahan segera tersedia, layanan melakukan pengoptimalan pada cluster Anda yang dapat memakan waktu hingga 24 jam atau lebih. Durasi pengoptimalan ini sebanding dengan ukuran penyimpanan Anda.
## Meningkatkan penyimpanan broker menggunakan Konsol Manajemen AWS
1. Buka konsol MSK Amazon di[https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Pilih cluster MSK yang ingin Anda perbarui penyimpanan broker.
1. Di bagian **Penyimpanan**, pilih **Edit**.
1. Tentukan volume penyimpanan yang Anda inginkan. Anda hanya dapat menambah jumlah penyimpanan, Anda tidak dapat menguranginya.
1. Pilih **Simpan perubahan**.
## Meningkatkan penyimpanan broker menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) yang Anda peroleh saat membuat cluster Anda. Jika Anda tidak memiliki ARN untuk cluster Anda, Anda dapat menemukannya dengan mencantumkan semua cluster. Untuk informasi selengkapnya, lihat [Daftar kluster MSK Amazon](msk-list-clusters.md).
Ganti *Current-Cluster-Version* dengan versi cluster saat ini.
**penting**
Versi cluster bukan bilangan bulat sederhana. Untuk menemukan versi cluster saat ini, gunakan [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operasi atau [perintah AWS CLI deskripsi-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Contoh versi adalah`KTVPDKIKX0DER`.
*Target-Volume-in-GiB*Parameter tersebut mewakili jumlah penyimpanan yang Anda inginkan untuk dimiliki setiap broker. Hanya mungkin untuk memperbarui penyimpanan untuk semua broker. Anda tidak dapat menentukan broker individu untuk memperbarui penyimpanan. Nilai yang Anda tentukan *Target-Volume-in-GiB* harus berupa bilangan bulat yang lebih besar dari 100 GiB. Penyimpanan per broker setelah operasi pembaruan tidak dapat melebihi 16384 GiB.
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## Meningkatkan penyimpanan broker menggunakan API
Untuk memperbarui penyimpanan broker menggunakan API, lihat [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage).
# Kelola throughput penyimpanan untuk pialang Standar di klaster MSK Amazon
Untuk informasi tentang cara menyediakan throughput menggunakan konsol Amazon MSK, CLI, dan API, lihat. [Penyediaan throughput penyimpanan untuk pialang Standar di cluster MSK Amazon](msk-provision-throughput.md)
**Topics**
+ [Kemacetan throughput broker MSK Amazon dan pengaturan throughput maksimum](#throughput-bottlenecks)
+ [Ukur throughput penyimpanan kluster MSK Amazon](#throughput-metrics)
+ [Nilai pembaruan konfigurasi untuk penyimpanan yang disediakan di kluster MSK Amazon](#provisioned-throughput-config)
+ [Penyediaan throughput penyimpanan untuk pialang Standar di cluster MSK Amazon](msk-provision-throughput.md)
## Kemacetan throughput broker MSK Amazon dan pengaturan throughput maksimum
Ada beberapa penyebab kemacetan dalam throughput broker: throughput volume, throughput jaringan Amazon EC2 ke Amazon EBS, dan throughput keluar Amazon EC2. Anda dapat mengaktifkan throughput penyimpanan yang disediakan untuk menyesuaikan throughput volume. Namun, keterbatasan throughput broker dapat disebabkan oleh throughput jaringan Amazon EC2 ke Amazon EBS dan throughput keluar Amazon EC2.
Throughput keluar Amazon EC2 dipengaruhi oleh jumlah kelompok konsumen dan konsumen per kelompok konsumen. Selain itu, throughput jaringan Amazon EC2 hingga Amazon EBS dan throughput keluar Amazon EC2 lebih tinggi untuk ukuran broker yang lebih besar.
Untuk ukuran volume 10 GiB atau lebih besar, Anda dapat menyediakan throughput penyimpanan 250 MiB per detik atau lebih besar. 250 MiB per detik adalah default. Untuk menyediakan throughput penyimpanan, Anda harus memilih ukuran broker kafka.m5.4xlarge atau lebih besar (atau kafka.m7g.2xlarge atau lebih besar), dan Anda dapat menentukan throughput maksimum seperti yang ditunjukkan pada tabel berikut.
****
| ukuran broker | Throughput penyimpanan maksimum (MIB/detik) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1000 |
| kafka.m5.16xlarge | 1000 |
| kafka.m5.24xlarge | 1000 |
| kafka.m7g.2xlarge | 312,5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1000 |
| kafka.m7g.12xlarge | 1000 |
| kafka.m7g.16xlarge | 1000 |
## Ukur throughput penyimpanan kluster MSK Amazon
Anda dapat menggunakan `VolumeWriteBytes` metrik `VolumeReadBytes` dan untuk mengukur throughput penyimpanan rata-rata sebuah cluster. Jumlah kedua metrik ini memberikan throughput penyimpanan rata-rata dalam byte. Untuk mendapatkan throughput penyimpanan rata-rata untuk sebuah cluster, atur kedua metrik ini ke SUM dan periode menjadi 1 menit, lalu gunakan rumus berikut.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
Untuk informasi tentang `VolumeReadBytes` dan `VolumeWriteBytes` metrik, lihat[`PER_BROKER`Pemantauan tingkat](metrics-details.md#broker-metrics).
## Nilai pembaruan konfigurasi untuk penyimpanan yang disediakan di kluster MSK Amazon
Anda dapat memperbarui konfigurasi MSK Amazon sebelum atau setelah Anda mengaktifkan throughput yang disediakan. Namun, Anda tidak akan melihat throughput yang diinginkan hingga Anda melakukan kedua tindakan: perbarui parameter `num.replica.fetchers` konfigurasi dan aktifkan throughput yang disediakan.
Dalam konfigurasi MSK Amazon default, `num.replica.fetchers` memiliki nilai 2. Untuk memperbarui`num.replica.fetchers`, Anda dapat menggunakan nilai yang disarankan dari tabel berikut. Nilai-nilai ini untuk tujuan panduan. Kami menyarankan Anda menyesuaikan nilai-nilai ini berdasarkan kasus penggunaan Anda.
****
| ukuran broker | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
Konfigurasi Anda yang diperbarui mungkin tidak berlaku hingga 24 jam, dan mungkin memakan waktu lebih lama ketika volume sumber tidak sepenuhnya digunakan. Namun, kinerja volume transisi setidaknya sama dengan kinerja volume penyimpanan sumber selama periode migrasi. Volume 1 TiB yang sepenuhnya digunakan biasanya membutuhkan waktu sekitar enam jam untuk bermigrasi ke konfigurasi yang diperbarui.
# Penyediaan throughput penyimpanan untuk pialang Standar di cluster MSK Amazon
Broker MSK Amazon mempertahankan data tentang volume penyimpanan. Penyimpanan I/O dikonsumsi ketika produsen menulis ke cluster, ketika data direplikasi antara broker, dan ketika konsumen membaca data yang tidak ada dalam memori. Throughput penyimpanan volume adalah tingkat di mana data dapat ditulis dan dibaca dari volume penyimpanan. Throughput penyimpanan yang disediakan adalah kemampuan untuk menentukan tarif tersebut untuk broker di cluster Anda.
Anda dapat menentukan tingkat throughput yang disediakan dalam MiB per detik untuk cluster yang brokernya berukuran `kafka.m5.4xlarge` atau lebih besar dan jika volume penyimpanan 10 GiB atau lebih besar. Dimungkinkan untuk menentukan throughput yang disediakan selama pembuatan cluster. Anda juga dapat mengaktifkan atau menonaktifkan throughput yang disediakan untuk klaster yang berada dalam status. `ACTIVE`
Untuk informasi tentang mengelola throughput, lihat[Kelola throughput penyimpanan untuk pialang Standar di klaster MSK Amazon](msk-provision-throughput-management.md).
**Topics**
+ [Menyediakan throughput penyimpanan cluster MSK Amazon menggunakan Konsol Manajemen AWS](#provisioned-throughput-console)
+ [Menyediakan throughput penyimpanan cluster MSK Amazon menggunakan AWS CLI](#provisioned-throughput-cli)
+ [Menyediakan throughput penyimpanan saat membuat klaster MSK Amazon menggunakan API](#provisioned-throughput-api)
## Menyediakan throughput penyimpanan cluster MSK Amazon menggunakan Konsol Manajemen AWS
Proses ini menunjukkan contoh bagaimana Anda dapat menggunakan Konsol Manajemen AWS untuk membuat klaster MSK Amazon dengan throughput yang disediakan diaktifkan.
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Pilih **Buat klaster**.
1. Pilih **Custom create**.
1. Tentukan nama untuk cluster.
1. Di bagian **Penyimpanan**, pilih **Aktifkan**.
1. Pilih nilai untuk throughput penyimpanan per broker.
1. Pilih VPC, zona dan subnet, dan grup keamanan.
1. Pilih **Berikutnya**.
1. Di bagian bawah langkah **Keamanan**, pilih **Berikutnya**.
1. Di bagian bawah langkah **Pemantauan dan tag**, pilih **Berikutnya**.
1. Tinjau pengaturan cluster, lalu pilih **Buat cluster**.
## Menyediakan throughput penyimpanan cluster MSK Amazon menggunakan AWS CLI
Proses ini menunjukkan contoh bagaimana Anda dapat menggunakan AWS CLI untuk membuat klaster dengan throughput yang disediakan diaktifkan.
1. Salin JSON berikut dan tempel ke dalam file. Ganti placeholder ID subnet IDs dan grup keamanan dengan nilai dari akun Anda. Beri nama file `cluster-creation.json` dan simpan.
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. Jalankan AWS CLI perintah berikut dari direktori tempat Anda menyimpan file JSON di langkah sebelumnya.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## Menyediakan throughput penyimpanan saat membuat klaster MSK Amazon menggunakan API
[Untuk mengonfigurasi throughput penyimpanan yang disediakan saat membuat cluster, gunakan V2. CreateCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)
# Konfigurasi Amazon MSK yang disediakan
Amazon MSK menyediakan konfigurasi default untuk broker, topik, dan node metadata. Anda juga dapat membuat konfigurasi kustom dan menggunakannya untuk membuat cluster MSK baru atau untuk memperbarui cluster yang ada. Konfigurasi MSK terdiri dari satu set properti dan nilai yang sesuai. Bergantung pada jenis broker yang Anda gunakan di cluster Anda, ada serangkaian default konfigurasi yang berbeda dan serangkaian konfigurasi berbeda yang dapat Anda modifikasi. Lihat bagian di bawah ini untuk detail lebih lanjut tentang cara mengkonfigurasi pialang Standar dan Ekspres Anda.
**Topics**
+ [Konfigurasi pialang standar](msk-configuration-standard.md)
+ [Konfigurasi broker ekspres](msk-configuration-express.md)
+ [Operasi konfigurasi broker](msk-configuration-operations.md)
# Konfigurasi pialang standar
Bagian ini menjelaskan properti konfigurasi untuk pialang Standar.
**Topics**
+ [Konfigurasi MSK Amazon kustom](msk-configuration-properties.md)
+ [Konfigurasi MSK Amazon default](msk-default-configuration.md)
+ [Pedoman untuk konfigurasi tingkat topik penyimpanan berjenjang MSK Amazon](msk-guidelines-tiered-storage-topic-level-config.md)
# Konfigurasi MSK Amazon kustom
Anda dapat menggunakan Amazon MSK untuk membuat konfigurasi MSK kustom di mana Anda mengatur properti konfigurasi Apache Kafka berikut. Properti yang tidak Anda tetapkan secara eksplisit mendapatkan nilai yang mereka miliki. [Konfigurasi MSK Amazon default](msk-default-configuration.md) Untuk informasi selengkapnya tentang properti konfigurasi, lihat Konfigurasi [Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nama | Deskripsi |
| --- | --- |
| allow.everyone.if.no.acl.found | Jika Anda ingin mengatur properti inifalse, pertama-tama pastikan Anda mendefinisikan Apache Kafka ACLs untuk cluster Anda. Jika Anda mengatur properti ini false dan Anda tidak mendefinisikan Apache Kafka terlebih dahulu ACLs, Anda kehilangan akses ke cluster. Jika itu terjadi, Anda dapat memperbarui konfigurasi lagi dan mengatur properti ini true untuk mendapatkan kembali akses ke cluster. |
| auto.create.topics.enable | Mengaktifkan pembuatan otomatis topik di server. |
| kompresi.type | Jenis kompresi akhir untuk topik tertentu. Anda dapat mengatur properti ini ke codec kompresi standar (gzip,, snappylz4, danzstd). Ini juga menerima. uncompressed Nilai ini setara dengan tidak ada kompresi. Jika Anda menetapkan nilainyaproducer, itu berarti mempertahankan codec kompresi asli yang ditetapkan oleh produsen. |
| koneksi.max.idle.ms | Batas waktu koneksi idle dalam milidetik. Thread prosesor soket server menutup koneksi yang menganggur lebih dari nilai yang Anda tetapkan untuk properti ini. |
| default.replication.factor | Faktor replikasi default untuk topik yang dibuat secara otomatis. |
| delete.topic.enable | Mengaktifkan operasi menghapus topik. Jika Anda mematikan setelan ini, Anda tidak dapat menghapus topik melalui alat admin. |
| group.initial.rebalance.delay.ms | Jumlah waktu koordinator grup menunggu lebih banyak konsumen data untuk bergabung dengan grup baru sebelum koordinator grup melakukan penyeimbangan ulang pertama. Penundaan yang lebih lama berarti berpotensi lebih sedikit penyeimbangan kembali, tetapi ini meningkatkan waktu sampai pemrosesan dimulai. |
| group.max.session.timeout.ms | Batas waktu sesi maksimum untuk konsumen terdaftar. Batas waktu yang lebih lama memberi konsumen lebih banyak waktu untuk memproses pesan di antara detak jantung dengan mengorbankan waktu yang lebih lama untuk mendeteksi kegagalan. |
| group.min.session.timeout.ms | Batas waktu sesi minimum untuk konsumen terdaftar. Batas waktu yang lebih pendek menghasilkan deteksi kegagalan yang lebih cepat dengan mengorbankan detak jantung konsumen yang lebih sering. Ini dapat membanjiri sumber daya broker. |
| leader.imbalance.per.broker.percentage | Rasio ketidakseimbangan pemimpin diperbolehkan per broker. Pengontrol memicu saldo pemimpin jika melebihi nilai ini per broker. Nilai ini ditentukan dalam persentase. |
| log.cleaner.delete.retention.ms | Jumlah waktu yang Anda inginkan Apache Kafka untuk menyimpan catatan yang dihapus. Nilai minimum adalah 0. |
| log.cleaner.min.cleanable.ratio | Properti konfigurasi ini dapat memiliki nilai antara 0 dan 1. Nilai ini menentukan seberapa sering pemadat log mencoba membersihkan log (jika pemadatan log diaktifkan). Secara default, Apache Kafka menghindari pembersihan log jika lebih dari 50% log telah dipadatkan. Rasio ini membatasi ruang maksimum yang terbuang log dengan duplikat (pada 50%, ini berarti paling banyak 50% dari log dapat berupa duplikat). Rasio yang lebih tinggi berarti pembersihan yang lebih sedikit dan lebih efisien, tetapi lebih banyak ruang yang terbuang di log. |
| log.cleanup.policy | Kebijakan pembersihan default untuk segmen di luar jendela retensi. Daftar kebijakan valid yang dipisahkan koma. Kebijakan yang valid adalah delete dancompact. Untuk klaster berkemampuan Penyimpanan Berjenjang, kebijakan yang valid hanya berlaku. delete |
| log.flush.interval.messages | Jumlah pesan yang terakumulasi pada partisi log sebelum pesan dibuang ke disk. |
| log.flush.interval.ms | Waktu maksimum dalam milidetik bahwa pesan dalam topik apa pun tetap dalam memori sebelum dibuang ke disk. Jika Anda tidak menetapkan nilai ini, nilai di log.flush.scheduler.interval.ms akan digunakan. Nilai minimum adalah 0. |
| log.message.timestamp.difference.max.ms | Konfigurasi ini tidak digunakan lagi di Kafka 3.6.0. Dua konfigurasi, log.message.timestamp.before.max.ms danlog.message.timestamp.after.max.ms, telah ditambahkan. Perbedaan waktu maksimum antara stempel waktu ketika broker menerima pesan dan stempel waktu yang ditentukan dalam pesan. Jika log.message.timestamp.type=CreateTime, pesan ditolak jika perbedaan stempel waktu melebihi ambang batas ini. Konfigurasi ini diabaikan jika log.message.timestamp.type=. LogAppendTime |
| log.message.timestamp.type | Menentukan apakah stempel waktu dalam pesan adalah waktu pembuatan pesan atau log menambahkan waktu. Nilai yang diizinkan adalah CreateTime danLogAppendTime. |
| log.retention.bytes | Ukuran maksimum log sebelum menghapusnya. |
| log.retention.hours | Jumlah jam untuk menyimpan file log sebelum menghapusnya, tersier ke properti log.retention.ms. |
| log.retention.minutes | Jumlah menit untuk menyimpan file log sebelum menghapusnya, sekunder ke properti log.retention.ms. Jika Anda tidak menetapkan nilai ini, nilai dalam log.retention.hours akan digunakan. |
| log.retention.ms | Jumlah milidetik untuk menyimpan file log sebelum menghapusnya (dalam milidetik), Jika tidak disetel, nilai dalam log.retention.minutes digunakan. |
| log.roll.ms | Waktu maksimum sebelum segmen log baru diluncurkan (dalam milidetik). Jika Anda tidak menyetel properti ini, nilai di log.roll.hours digunakan. Nilai minimum yang mungkin untuk properti ini adalah 1. |
| log.segment.bytes | Ukuran maksimum dari satu file log. |
| max.incremental.fetch.session.cache.slots | Jumlah maksimum sesi pengambilan inkremental yang dipertahankan. |
| message.max.bytes | Ukuran batch rekor terbesar yang diizinkan Kafka. Jika Anda meningkatkan nilai ini dan ada konsumen yang lebih tua dari 0.10.2, Anda juga harus meningkatkan ukuran pengambilan konsumen sehingga mereka dapat mengambil batch rekaman sebesar ini. Versi format pesan terbaru selalu mengelompokkan pesan ke dalam batch untuk efisiensi. Versi format pesan sebelumnya tidak mengelompokkan catatan yang tidak terkompresi ke dalam batch, dan dalam kasus seperti itu, batas ini hanya berlaku untuk satu rekaman. Anda dapat mengatur nilai ini per topik dengan konfigurasi max.message.bytes level topik. |
| min.insync.replika | Ketika produser menetapkan acks ke `"all"` (or`"-1"`), nilai dalam min.insync.replicas menentukan jumlah minimum replika yang harus mengakui penulisan agar penulisan dianggap berhasil. Jika minimum ini tidak dapat dipenuhi, produsen menimbulkan pengecualian (salah satu NotEnoughReplicas atau NotEnoughReplicasAfterAppend). Anda dapat menggunakan nilai di min.insync.replicas dan acks untuk menerapkan jaminan daya tahan yang lebih besar. Misalnya, Anda dapat membuat topik dengan faktor replikasi 3, mengatur min.insync.replicas ke 2, dan menghasilkan dengan acks of. `"all"` Ini memastikan bahwa produser memunculkan pengecualian jika sebagian besar replika tidak menerima penulisan. |
| num.io.thread | Jumlah thread yang digunakan server untuk memproses permintaan, yang mungkin termasuk disk I/O. |
| num.network.threads | Jumlah thread yang digunakan server untuk menerima permintaan dari jaringan dan mengirim tanggapan ke sana. |
| num.partisi | Jumlah default partisi log per topik. |
| num.recovery.threads.per.data.dir | Jumlah thread per direktori data yang akan digunakan untuk memulihkan log saat startup dan dan untuk flush mereka saat shutdown. |
| num.replica.fetchers | Jumlah utas fetcher yang digunakan untuk mereplikasi pesan dari broker sumber. Jika Anda meningkatkan nilai ini, Anda dapat meningkatkan tingkat I/O paralelisme di broker pengikut. |
| offsets.retention.minutes | Setelah kelompok konsumen kehilangan semua konsumennya (yaitu, menjadi kosong) offsetnya disimpan untuk periode retensi ini sebelum dibuang. Untuk konsumen mandiri (yaitu, mereka yang menggunakan penugasan manual), offset kedaluwarsa setelah waktu komit terakhir ditambah periode retensi ini. |
| offsets.topic.replication.factor | Faktor replikasi untuk topik offset. Tetapkan nilai ini lebih tinggi untuk memastikan ketersediaan. Pembuatan topik internal gagal hingga ukuran cluster memenuhi persyaratan faktor replikasi ini. |
| replica.fetch.max.bytes | Jumlah byte pesan untuk mencoba untuk mengambil untuk setiap partisi. Ini bukan maksimum absolut. Jika kumpulan rekaman pertama di partisi pengambilan yang tidak kosong pertama lebih besar dari nilai ini, kumpulan rekaman dikembalikan untuk memastikan kemajuan. Message.max.bytes (konfigurasi broker) atau max.message.bytes (konfigurasi topik) mendefinisikan ukuran batch rekaman maksimum yang diterima broker. |
| replica.fetch.response.max.bytes | Jumlah maksimum byte yang diharapkan untuk seluruh respons pengambilan. Rekaman diambil dalam batch, dan jika kumpulan rekaman pertama di partisi pengambilan yang tidak kosong pertama lebih besar dari nilai ini, kumpulan rekaman akan tetap dikembalikan untuk memastikan kemajuan. Ini bukan maksimum absolut. Properti message.max.bytes (broker config) atau max.message.bytes (topic config) menentukan ukuran batch record maksimum yang diterima broker. |
| replica.lag.time.max.ms | Jika pengikut belum mengirim permintaan pengambilan atau belum menghabiskan hingga offset akhir log pemimpin setidaknya dalam jumlah milidetik ini, pemimpin akan menghapus pengikut dari ISR.MinValue: 10000MaxValue = 30000 |
| replica.selector.class | Nama kelas yang sepenuhnya memenuhi syarat yang mengimplementasikan. ReplicaSelector Broker menggunakan nilai ini untuk menemukan replika baca yang disukai. Jika Anda menggunakan Apache Kafka versi 2.4.1 atau lebih tinggi, dan ingin mengizinkan konsumen mengambil dari replika terdekat, atur properti ini ke. org.apache.kafka.common.replica.RackAwareReplicaSelector Untuk informasi selengkapnya, lihat [Apache Kafka versi 2.4.1 (gunakan 2.4.1.1 sebagai gantinya)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | Soket menerima buffer untuk permintaan jaringan. |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dari soket server soket. Nilai minimum yang dapat Anda atur untuk properti ini adalah -1. Jika nilainya -1, Amazon MSK menggunakan default OS. |
| socket.request.max.bytes | Jumlah maksimum byte dalam permintaan soket. |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dari soket server soket. Nilai minimum yang dapat Anda atur untuk properti ini adalah -1. Jika nilainya -1, Amazon MSK menggunakan default OS. |
| transaksi.max.timeout.ms | Batas waktu maksimum untuk transaksi. Jika waktu transaksi yang diminta dari klien melebihi nilai ini, broker mengembalikan kesalahan InitProducerIdRequest. Ini mencegah klien dari batas waktu yang terlalu besar, dan ini dapat menghambat konsumen yang membaca dari topik yang termasuk dalam transaksi. |
| transaction.state.log.min.isr | Mengganti konfigurasi min.insync.replicas untuk topik transaksi. |
| transaction.state.log.replication.factor | Faktor replikasi untuk topik transaksi. Tetapkan properti ini ke nilai yang lebih tinggi untuk meningkatkan ketersediaan. Pembuatan topik internal gagal hingga ukuran cluster memenuhi persyaratan faktor replikasi ini. |
| transactional.id.expiration.ms | Waktu dalam milidetik koordinator transaksi menunggu untuk menerima pembaruan status transaksi untuk transaksi saat ini sebelum koordinator kedaluwarsa ID transaksionalnya. Pengaturan ini juga memengaruhi kedaluwarsa ID produsen karena menyebabkan produser IDs kedaluwarsa ketika waktu ini berlalu setelah penulisan terakhir dengan ID produser yang diberikan. Produser IDs mungkin kedaluwarsa lebih cepat jika penulisan terakhir dari ID produsen dihapus karena pengaturan retensi untuk topik tersebut. Nilai minimum untuk properti ini adalah 1 milidetik. |
| unclean.leader.election.enable | Menunjukkan jika replika yang tidak ada dalam set ISR harus berfungsi sebagai pemimpin sebagai upaya terakhir, meskipun ini dapat mengakibatkan hilangnya data. |
| zookeeper.connection.timeout.ms | ZooKeeper kluster mode. Waktu maksimum yang ditunggu klien untuk membuat koneksi. ZooKeeper Jika Anda tidak menyetel nilai ini, nilai di zookeeper.session.timeout.ms digunakan. MinValue = 6000 MaxValue (inklusif) = 18000 Kami menyarankan Anda menetapkan nilai ini ke 10.000 di T3.small untuk menghindari downtime cluster. |
| zookeeper.session.timeout.ms | ZooKeeper kluster mode. Batas waktu ZooKeeper sesi Apache dalam milidetik. MinValue = 6000 MaxValue (inklusif) = 18000 |
Untuk mempelajari cara membuat konfigurasi MSK kustom, daftar semua konfigurasi, atau jelaskan, lihat. [Operasi konfigurasi broker](msk-configuration-operations.md) Untuk membuat klaster MSK dengan konfigurasi MSK kustom, atau untuk memperbarui cluster dengan konfigurasi kustom baru, lihat. [Fitur dan konsep utama MSK Amazon](operations.md)
Saat Anda memperbarui klaster MSK yang ada dengan konfigurasi MSK khusus, Amazon MSK melakukan rolling restart bila diperlukan, dan menggunakan praktik terbaik untuk meminimalkan waktu henti pelanggan. Misalnya, setelah Amazon MSK memulai ulang setiap broker, Amazon MSK mencoba membiarkan broker menangkap data yang mungkin terlewatkan oleh broker selama pembaruan konfigurasi sebelum pindah ke broker berikutnya.
## Konfigurasi MSK Amazon dinamis
Selain properti konfigurasi yang disediakan Amazon MSK, Anda dapat secara dinamis mengatur properti konfigurasi tingkat klaster dan tingkat broker yang tidak memerlukan restart broker. Anda dapat secara dinamis mengatur beberapa properti konfigurasi. Ini adalah properti yang tidak ditandai sebagai hanya-baca dalam tabel di bawah [Konfigurasi Broker](https://kafka.apache.org/documentation/#brokerconfigs) dalam dokumentasi Apache Kafka. Untuk informasi tentang konfigurasi dinamis dan perintah contoh, lihat [Memperbarui Konfigurasi Broker dalam dokumentasi](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) Apache Kafka.
**catatan**
Anda dapat mengatur `advertised.listeners` properti, tetapi bukan `listeners` properti.
## Konfigurasi MSK Amazon tingkat topik
Anda dapat menggunakan perintah Apache Kafka untuk mengatur atau memodifikasi properti konfigurasi tingkat topik untuk topik baru dan yang sudah ada. Untuk informasi selengkapnya tentang properti konfigurasi tingkat topik dan contoh tentang cara mengaturnya, lihat [Konfigurasi Tingkat Topik dalam dokumentasi Apache Kafka](https://kafka.apache.org/documentation/#topicconfigs).
# Konfigurasi MSK Amazon default
Bila Anda membuat kluster MSK dan tidak menentukan konfigurasi MSK kustom, Amazon MSK membuat dan menggunakan konfigurasi default dengan nilai yang ditunjukkan dalam tabel berikut. Untuk properti yang tidak ada dalam tabel ini, Amazon MSK menggunakan default yang terkait dengan versi Apache Kafka Anda. Untuk daftar nilai default ini, lihat Konfigurasi [Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Nama | Deskripsi | Nilai default untuk cluster penyimpanan tidak berjenjang | Nilai default untuk cluster berkemampuan penyimpanan berjenjang |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Jika tidak ada pola sumber daya yang cocok dengan sumber daya tertentu, sumber daya tidak terkait ACLs. Dalam hal ini, jika Anda menyetel properti initrue, semua pengguna dapat mengakses sumber daya, bukan hanya pengguna super. | true | true |
| auto.create.topics.enable | Mengaktifkan pembuatan otomatis topik di server. | false | false |
| auto.leader.rebalance.enable | Memungkinkan penyeimbangan pemimpin otomatis. Benang latar belakang memeriksa dan memulai keseimbangan pemimpin secara berkala, jika perlu. | true | true |
| default.replication.factor | Faktor replikasi default untuk topik yang dibuat secara otomatis. | 3 untuk cluster di 3 Availability Zone, dan 2 untuk cluster di 2 Availability Zone. | 3 untuk cluster di 3 Availability Zone, dan 2 untuk cluster di 2 Availability Zone. |
| local.retention.bytes | Ukuran maksimum segmen log lokal untuk partisi sebelum menghapus segmen lama. Jika Anda tidak menetapkan nilai ini, nilai dalam log.retention.bytes digunakan. Nilai efektif harus selalu kurang dari atau sama dengan nilai log.retention.bytes. Nilai default -2 menunjukkan bahwa tidak ada batasan retensi lokal. Ini sesuai dengan pengaturan retensi.ms/bytes -1. Properti local.retention.ms dan local.retention.bytes mirip dengan log.retention karena digunakan untuk menentukan berapa lama segmen log harus tetap berada di penyimpanan lokal. Konfigurasi log.retention.\$1 yang ada adalah konfigurasi retensi untuk partisi topik. Ini termasuk penyimpanan lokal dan jarak jauh. Nilai yang valid: bilangan bulat di [-2; \$1Inf] | -2 untuk tak terbatas | -2 untuk tak terbatas |
| local.retention.ms | Jumlah milidetik untuk mempertahankan segmen log lokal sebelum penghapusan. Jika Anda tidak menetapkan nilai ini, Amazon MSK menggunakan nilai di log.retention.ms. Nilai efektif harus selalu kurang dari atau sama dengan nilai log.retention.bytes. Nilai default -2 menunjukkan bahwa tidak ada batasan retensi lokal. Ini sesuai dengan pengaturan retensi.ms/bytes -1.Nilai local.retention.ms dan local.retention.bytes mirip dengan log.retention. MSK menggunakan konfigurasi ini untuk menentukan berapa lama segmen log harus tetap berada di penyimpanan lokal. Konfigurasi log.retention.\$1 yang ada adalah konfigurasi retensi untuk partisi topik. Ini termasuk penyimpanan lokal dan jarak jauh. Nilai yang valid adalah bilangan bulat yang lebih besar dari 0. | -2 untuk tak terbatas | -2 untuk tak terbatas |
| log.message.timestamp.difference.max.ms | Konfigurasi ini tidak digunakan lagi di Kafka 3.6.0. Dua konfigurasi, log.message.timestamp.before.max.ms danlog.message.timestamp.after.max.ms, telah ditambahkan. Perbedaan maksimum yang diperbolehkan antara stempel waktu ketika broker menerima pesan dan stempel waktu yang ditentukan dalam pesan. Jika log.message.timestamp.type=CreateTime, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas ini. Konfigurasi ini diabaikan jika log.message.timestamp.type=. LogAppendTime Perbedaan stempel waktu maksimum yang diizinkan tidak boleh lebih besar dari log.retention.ms untuk menghindari penggulungan log yang tidak perlu sering. | 9223372036854775807 | 86400000 untuk Kafka 2.8.2.tiered dan Kafka 3.7.x berjenjang. |
| log.segment.bytes | Ukuran maksimum dari satu file log. | 1073741824 | 134217728 |
| min.insync.replika | Ketika produsen menetapkan nilai acks (produser pengakuan mendapat dari broker Kafka) ke `"all"` (atau`"-1"`), nilai dalam min.insync.replicas menentukan jumlah minimum replika yang harus mengakui penulisan agar penulisan dianggap berhasil. Jika nilai ini tidak memenuhi minimum ini, produsen memunculkan pengecualian (salah satu NotEnoughReplicas atau NotEnoughReplicasAfterAppend). Saat Anda menggunakan nilai di min.insync.replicas dan acks bersama-sama, Anda dapat menerapkan jaminan daya tahan yang lebih besar. Misalnya, Anda dapat membuat topik dengan faktor replikasi 3, mengatur min.insync.replicas ke 2, dan menghasilkan dengan acks of. `"all"` Ini memastikan bahwa produser memunculkan pengecualian jika sebagian besar replika tidak menerima penulisan. | 2 untuk cluster di 3 Availability Zone, dan 1 untuk cluster di 2 Availability Zone. | 2 untuk cluster di 3 Availability Zone, dan 1 untuk cluster di 2 Availability Zone. |
| num.io.thread | Jumlah thread yang digunakan server untuk menghasilkan permintaan, yang mungkin termasuk disk I/O. | 8 | max (8, vCPUs) dimana v CPUs tergantung pada ukuran instance broker |
| num.network.threads | Jumlah thread yang digunakan server untuk menerima permintaan dari jaringan dan mengirim tanggapan ke jaringan. | 5 | max (5, CPUs v/ 2) dimana v CPUs tergantung pada ukuran instance broker |
| num.partisi | Jumlah default partisi log per topik. | 1 | 1 |
| num.replica.fetchers | Jumlah utas fetcher yang digunakan untuk mereplikasi pesan dari broker sumber.Jika Anda meningkatkan nilai ini, Anda dapat meningkatkan tingkat I/O paralelisme di broker pengikut. | 2 | max (2, CPUs v/ 4) dimana v CPUs tergantung pada ukuran instance broker |
| remote.log.msk.disable.policy | Digunakan dengan remote.storage.enable untuk menonaktifkan penyimpanan berjenjang. Setel kebijakan ini ke Hapus, untuk menunjukkan bahwa data dalam penyimpanan berjenjang dihapus saat Anda menyetel remote.storage.enable ke false. | N/A | Tidak ada |
| remote.log.reader.threads | Ukuran kumpulan utas pembaca log jarak jauh, yang digunakan dalam tugas penjadwalan untuk mengambil data dari penyimpanan jarak jauh. | N/A | max (10, v CPUs \$1 0.67) dimana v CPUs tergantung pada ukuran instance broker |
| remote.storage.enable | Mengaktifkan penyimpanan berjenjang (jarak jauh) untuk topik jika disetel ke true. Menonaktifkan penyimpanan berjenjang tingkat topik jika disetel ke false dan remote.log.msk.disable.policy disetel ke Hapus. Saat Anda menonaktifkan penyimpanan berjenjang, Anda menghapus data dari penyimpanan jarak jauh. Saat Anda menonaktifkan penyimpanan berjenjang untuk suatu topik, Anda tidak dapat mengaktifkannya lagi. | false | false |
| replica.lag.time.max.ms | Jika pengikut belum mengirim permintaan pengambilan atau belum menghabiskan hingga offset akhir log pemimpin setidaknya dalam jumlah milidetik ini, pemimpin akan menghapus pengikut dari ISR. | 30000 | 30000 |
| retensi.ms | Bidang wajib. Waktu minimum adalah 3 hari. Tidak ada default karena pengaturannya wajib. Amazon MSK menggunakan nilai retention.ms dengan local.retention.ms untuk menentukan kapan data berpindah dari penyimpanan lokal ke penyimpanan berjenjang. Nilai local.retention.ms menentukan kapan harus memindahkan data dari penyimpanan lokal ke berjenjang. Nilai retention.ms menentukan kapan harus menghapus data dari penyimpanan berjenjang (yaitu, dihapus dari cluster). Nilai yang valid: bilangan bulat di [-1; \$1Inf] | Minimum 259.200.000 milidetik (3 hari). -1 untuk retensi tak terbatas. | Minimum 259.200.000 milidetik (3 hari). -1 untuk retensi tak terbatas. |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dari soket pemutus soket. Jika nilainya -1, default OS digunakan. | 102400 | 102400 |
| socket.request.max.bytes | Jumlah maksimum byte dalam permintaan soket. | 104857600 | 104857600 |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dari soket pemutus soket. Jika nilainya -1, default OS digunakan. | 102400 | 102400 |
| unclean.leader.election.enable | Menunjukkan jika Anda ingin replika yang tidak ada dalam set ISR untuk berfungsi sebagai pemimpin sebagai upaya terakhir, meskipun ini dapat mengakibatkan kehilangan data. | true | SALAH |
| zookeeper.session.timeout.ms | Batas waktu ZooKeeper sesi Apache dalam milidetik. | 18000 | 18000 |
| zookeeper.set.acl | Klien yang ditetapkan untuk menggunakan aman ACLs. | false | false |
Untuk informasi tentang cara menentukan nilai konfigurasi kustom, lihat[Konfigurasi MSK Amazon kustom](msk-configuration-properties.md).
# Pedoman untuk konfigurasi tingkat topik penyimpanan berjenjang MSK Amazon
Berikut ini adalah pengaturan dan batasan default saat Anda mengonfigurasi penyimpanan berjenjang di tingkat topik.
+ Amazon MSK tidak mendukung ukuran segmen log yang lebih kecil untuk topik dengan penyimpanan berjenjang diaktifkan. Jika Anda ingin membuat segmen, ada ukuran segmen log minimum 48 MiB, atau waktu roll segmen minimum 10 menit. Nilai-nilai ini dipetakan ke properti segment.bytes dan segment.ms.
+ Nilai local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Ini adalah pengaturan retensi penyimpanan berjenjang.
+ Nilai default untuk untuk local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. Dalam hal ini, data tetap berada di penyimpanan lokal dan penyimpanan berjenjang (masing-masing satu salinan), dan semuanya kedaluwarsa bersama. Untuk opsi ini, salinan data lokal disimpan ke penyimpanan jarak jauh. Dalam hal ini, data yang dibaca dari lalu lintas konsumsi berasal dari penyimpanan lokal.
+ Nilai default untuk retention.ms adalah 7 hari. Tidak ada batasan ukuran default untuk retention.bytes.
+ Nilai minimum untuk retention.ms/bytes adalah -1. Ini berarti retensi tak terbatas.
+ Nilai minimum untuk local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytespengaturan sebagai -1.
+ Retensi konfigurasi tingkat topik.ms wajib untuk topik dengan penyimpanan berjenjang diaktifkan. Retensi minimum.ms adalah 3 hari.
Untuk informasi lebih lanjut tentang batasan penyimpanan berjenjang, lihat. [Kendala dan batasan penyimpanan berjenjang untuk cluster MSK Amazon](msk-tiered-storage.md#msk-tiered-storage-constraints)
# Konfigurasi broker ekspres
Apache Kafka memiliki ratusan konfigurasi broker yang dapat Anda gunakan untuk menyesuaikan kinerja cluster MSK Provisioned Anda. Menetapkan nilai yang salah atau sub-optimal dapat memengaruhi keandalan dan kinerja cluster. Broker ekspres meningkatkan ketersediaan dan daya tahan klaster MSK Provisioned Anda dengan menetapkan nilai optimal untuk konfigurasi kritis dan melindunginya dari kesalahan konfigurasi umum. Ada tiga kategori konfigurasi berdasarkan akses baca dan tulis: [baca/tulis (dapat diedit)](msk-configuration-express-read-write.md), [hanya baca, dan konfigurasi non-baca/tulis](msk-configuration-express-read-only.md). Beberapa konfigurasi masih menggunakan nilai default Apache Kafka untuk versi Apache Kafka yang sedang dijalankan cluster. Kami menandainya sebagai Apache Kafka Default.
**Topics**
+ [Konfigurasi broker MSK Express kustom (Akses Baca/Tulis)](msk-configuration-express-read-write.md)
+ [Konfigurasi hanya-baca broker ekspres](msk-configuration-express-read-only.md)
# Konfigurasi broker MSK Express kustom (Akses Baca/Tulis)
Anda dapat memperbarui konfigurasi read/write broker baik dengan menggunakan [fitur konfigurasi pembaruan](msk-update-cluster-config.md) Amazon MSK atau menggunakan API Apache Kafka. AlterConfig Konfigurasi broker Apache Kafka bersifat statis atau dinamis. Konfigurasi statis memerlukan broker restart untuk konfigurasi yang akan diterapkan, sementara konfigurasi dinamis tidak memerlukan broker restart. Untuk informasi selengkapnya tentang properti konfigurasi dan mode pembaruan, lihat [Memperbarui konfigurasi broker](https://kafka.apache.org/documentation/#dynamicbrokerconfigs).
**Topics**
+ [Konfigurasi statis pada broker MSK Express](#msk-configuration-express-static-configuration)
+ [Konfigurasi dinamis pada Broker Ekspres](#msk-configuration-express-dynamic-configuration)
+ [Konfigurasi tingkat topik pada Broker Ekspres](#msk-configuration-express-topic-configuration)
## Konfigurasi statis pada broker MSK Express
Anda dapat menggunakan Amazon MSK untuk membuat file konfigurasi MSK kustom untuk mengatur properti statis berikut. Amazon MSK menetapkan dan mengelola semua properti lain yang tidak Anda atur. Anda dapat membuat dan memperbarui file konfigurasi statis dari konsol MSK atau menggunakan perintah [konfigurasi.](msk-configuration-operations-create.md)
| Properti | Deskripsi | nilai default |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | Jika Anda ingin mengatur properti ini ke false, pertama-tama pastikan Anda mendefinisikan Apache Kafka ACLs untuk cluster Anda. Jika Anda menyetel properti ini ke false dan Anda tidak mendefinisikan Apache Kafka terlebih dahulu ACLs, Anda kehilangan akses ke cluster. Jika itu terjadi, Anda dapat memperbarui konfigurasi lagi dan mengatur properti ini ke true untuk mendapatkan kembali akses ke cluster. | true |
| auto.create.topics.enable | Mengaktifkan pembuatan otomatis topik di server. | false |
| kompresi.type | Tentukan jenis kompresi akhir untuk topik tertentu. Konfigurasi ini menerima codec kompresi standar: gzip, snappy, lz4, zstd. Konfigurasi ini juga menerima`uncompressed`, yang setara dengan tidak ada kompresi; dan`producer`, yang berarti mempertahankan codec kompresi asli yang ditetapkan oleh produsen. | Apache Kafka Standar |
| koneksi.max.idle.ms | Batas waktu koneksi idle dalam milidetik. Thread prosesor soket server menutup koneksi yang menganggur lebih dari nilai yang Anda tetapkan untuk properti ini. | Apache Kafka Standar |
| delete.topic.enable | Mengaktifkan operasi menghapus topik. Jika Anda mematikan setelan ini, Anda tidak dapat menghapus topik melalui alat admin. | Apache Kafka Standar |
| group.initial.rebalance.delay.ms | Jumlah waktu koordinator grup menunggu lebih banyak konsumen data untuk bergabung dengan grup baru sebelum koordinator grup melakukan penyeimbangan ulang pertama. Penundaan yang lebih lama berarti berpotensi lebih sedikit penyeimbangan kembali, tetapi ini meningkatkan waktu sampai pemrosesan dimulai. | Apache Kafka Standar |
| group.max.session.timeout.ms | Batas waktu sesi maksimum untuk konsumen terdaftar. Batas waktu yang lebih lama memberi konsumen lebih banyak waktu untuk memproses pesan di antara detak jantung dengan mengorbankan waktu yang lebih lama untuk mendeteksi kegagalan. | Apache Kafka Standar |
| leader.imbalance.per.broker.percentage | Rasio ketidakseimbangan pemimpin diperbolehkan per broker. Pengontrol memicu saldo pemimpin jika melebihi nilai ini per broker. Nilai ini ditentukan dalam persentase. | Apache Kafka Standar |
| log.cleanup.policy | Kebijakan pembersihan default untuk segmen di luar jendela retensi. Daftar kebijakan valid yang dipisahkan koma. Kebijakan yang valid adalah delete dancompact. Untuk klaster berkemampuan penyimpanan berjenjang, kebijakan yang valid hanya berlaku. delete | Apache Kafka Standar |
| log.message.timestamp.after.max.ms | Perbedaan stempel waktu yang diijinkan antara stempel waktu pesan dan stempel waktu broker. Stempel waktu pesan bisa lebih lambat atau sama dengan stempel waktu broker, dengan selisih maksimum yang diijinkan ditentukan oleh nilai yang ditetapkan dalam konfigurasi ini. Jika`log.message.timestamp.type=CreateTime`, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas yang ditentukan ini. Konfigurasi ini diabaikan jika`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, yaitu, 1 hari) |
| log.message.timestamp.before.max.ms | Perbedaan stempel waktu yang diijinkan antara stempel waktu broker dan stempel waktu pesan. Stempel waktu pesan dapat lebih awal dari atau sama dengan stempel waktu broker, dengan perbedaan maksimum yang diijinkan ditentukan oleh nilai yang ditetapkan dalam konfigurasi ini. Jika`log.message.timestamp.type=CreateTime`, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas yang ditentukan ini. Konfigurasi ini diabaikan jika`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, yaitu, 1 hari) |
| log.message.timestamp.type | Menentukan apakah stempel waktu dalam pesan adalah waktu pembuatan pesan atau log menambahkan waktu. Nilai yang diizinkan adalah CreateTime danLogAppendTime. | Apache Kafka Standar |
| log.retention.bytes | Ukuran maksimum log sebelum menghapusnya. | Apache Kafka Standar |
| log.retention.ms | Jumlah milidetik untuk menyimpan file log sebelum menghapusnya. | Apache Kafka Standar |
| max.connections.per.ip | Jumlah maksimum koneksi yang diizinkan dari setiap alamat IP. Ini dapat diatur ke 0 jika ada penggantian yang dikonfigurasi menggunakan properti. max.connections.per.ip.overrides Koneksi baru dari alamat IP dijatuhkan jika batas tercapai. | Apache Kafka Standar |
| max.incremental.fetch.session.cache.slots | Jumlah maksimum sesi pengambilan inkremental yang dipertahankan. | Apache Kafka Standar |
| message.max.bytes | Ukuran batch rekor terbesar yang diizinkan Kafka. Jika Anda meningkatkan nilai ini dan ada konsumen yang lebih tua dari 0.10.2, Anda juga harus meningkatkan ukuran pengambilan konsumen sehingga mereka dapat mengambil batch rekaman sebesar ini. Versi format pesan terbaru selalu mengelompokkan pesan ke dalam batch untuk efisiensi. Versi format pesan sebelumnya tidak mengelompokkan catatan yang tidak terkompresi ke dalam batch, dan dalam kasus seperti itu, batas ini hanya berlaku untuk satu rekaman. Anda dapat mengatur nilai ini per topik dengan `max.message.bytes` konfigurasi tingkat topik. | Apache Kafka Standar |
| num.partisi | Jumlah partisi default per topik. | 1 |
| offsets.retention.minutes | Setelah kelompok konsumen kehilangan semua konsumennya (yaitu, menjadi kosong) offsetnya disimpan untuk periode retensi ini sebelum dibuang. Untuk konsumen mandiri (yaitu, mereka yang menggunakan penugasan manual), offset kedaluwarsa setelah waktu komit terakhir ditambah periode retensi ini. | Apache Kafka Standar |
| replica.fetch.max.bytes | Jumlah byte pesan untuk mencoba untuk mengambil untuk setiap partisi. Ini bukan maksimum absolut. Jika kumpulan rekaman pertama di partisi pengambilan yang tidak kosong pertama lebih besar dari nilai ini, kumpulan rekaman dikembalikan untuk memastikan kemajuan. Message.max.bytes (konfigurasi broker) atau max.message.bytes (konfigurasi topik) mendefinisikan ukuran batch rekaman maksimum yang diterima broker. | Apache Kafka Standar |
| replica.selector.class | Nama kelas yang sepenuhnya memenuhi syarat yang mengimplementasikan. ReplicaSelector Broker menggunakan nilai ini untuk menemukan replika baca yang disukai. Jika Anda ingin mengizinkan konsumen mengambil dari replika terdekat, setel properti ini ke. `org.apache.kafka.common.replica.RackAwareReplicaSelector` | Apache Kafka Standar |
| socket.receive.buffer.bytes | Buffer SO\$1RCVBUF dari soket pemutus soket. Jika nilainya -1, default OS digunakan. | 102400 |
| socket.request.max.bytes | Jumlah maksimum byte dalam permintaan soket. | 104857600 |
| socket.send.buffer.bytes | Buffer SO\$1SNDBUF dari soket pemutus soket. Jika nilainya -1, default OS digunakan. | 102400 |
| transaksi.max.timeout.ms | Batas waktu maksimum untuk transaksi. Jika waktu transaksi yang diminta dari klien melebihi nilai ini, broker mengembalikan kesalahan InitProducerIdRequest. Ini mencegah klien dari batas waktu yang terlalu besar, dan ini dapat menghambat konsumen yang membaca dari topik yang termasuk dalam transaksi. | Apache Kafka Standar |
| transactional.id.expiration.ms | Waktu dalam milidetik koordinator transaksi menunggu untuk menerima pembaruan status transaksi untuk transaksi saat ini sebelum koordinator kedaluwarsa ID transaksionalnya. Pengaturan ini juga memengaruhi kedaluwarsa ID produsen karena menyebabkan produser IDs kedaluwarsa ketika waktu ini berlalu setelah penulisan terakhir dengan ID produser yang diberikan. Produser IDs mungkin kedaluwarsa lebih cepat jika penulisan terakhir dari ID produsen dihapus karena pengaturan retensi untuk topik tersebut. Nilai minimum untuk properti ini adalah 1 milidetik. | Apache Kafka Standar |
## Konfigurasi dinamis pada Broker Ekspres
Anda dapat menggunakan Apache Kafka AlterConfig API atau alat Kafka-configs.sh untuk mengedit konfigurasi dinamis berikut. Amazon MSK menetapkan dan mengelola semua properti lain yang tidak Anda atur. Anda dapat secara dinamis mengatur properti konfigurasi tingkat klaster dan tingkat broker yang tidak memerlukan restart broker.
| Properti | Deskripsi | Nilai default |
| --- | --- | --- |
| advertised.listeners | Listener untuk mempublikasikan untuk digunakan klien, jika berbeda dari properti `listeners` config. Di lingkungan IaaS, ini mungkin perlu berbeda dari antarmuka yang diikat broker. Jika ini tidak disetel, nilai untuk pendengar akan digunakan. Tidak seperti pendengar, tidak valid untuk mengiklankan alamat meta 0.0.0.0. Juga tidak seperti`listeners`, mungkin ada port duplikat di properti ini, sehingga satu pendengar dapat dikonfigurasi untuk mengiklankan alamat pendengar lain. Ini dapat berguna dalam beberapa kasus di mana penyeimbang beban eksternal digunakan. Properti ini ditetapkan pada tingkat per-broker. | null |
| kompresi.type | Jenis kompresi akhir untuk topik tertentu. Anda dapat mengatur properti ini ke codec kompresi standar (`gzip`,, `snappy``lz4`, dan`zstd`). Ini juga menerima. `uncompressed` Nilai ini setara dengan tidak ada kompresi. Jika Anda menetapkan nilainya`producer`, itu berarti mempertahankan codec kompresi asli yang ditetapkan oleh produsen. | Apache Kafka Standar |
| log.cleaner.delete.retention.ms | Jumlah waktu untuk mempertahankan penanda batu nisan hapus untuk topik log yang dipadatkan. Pengaturan ini juga memberikan batas pada waktu di mana konsumen harus menyelesaikan pembacaan jika mereka mulai dari offset 0 untuk memastikan bahwa mereka mendapatkan snapshot yang valid dari tahap akhir. Jika tidak, hapus batu nisan mungkin dikumpulkan sebelum mereka menyelesaikan pemindaian mereka. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, yaitu, 1 hari), Apache Kafka Default |
| log.cleaner.min.compaction.lag.ms | Waktu minimum pesan akan tetap tidak dipadatkan di log. Pengaturan ini hanya berlaku untuk log yang sedang dipadatkan. | 0, Apache Kafka Standar |
| log.cleaner.max.compaction.lag.ms | Waktu maksimum pesan akan tetap tidak memenuhi syarat untuk pemadatan di log. Pengaturan ini hanya berlaku untuk log yang sedang dipadatkan. Konfigurasi ini akan dibatasi dalam kisaran [7 hari, Long.Max]. | 9223372036854775807, Apache Kafka Standar |
| log.cleanup.policy | Kebijakan pembersihan default untuk segmen di luar jendela retensi. Daftar kebijakan valid yang dipisahkan koma. Kebijakan yang valid adalah `delete` dan`compact`. Untuk klaster berkemampuan penyimpanan berjenjang, kebijakan yang valid hanya berlaku. `delete` | Apache Kafka Standar |
| log.message.timestamp.after.max.ms | Perbedaan stempel waktu yang diijinkan antara stempel waktu pesan dan stempel waktu broker. Stempel waktu pesan bisa lebih lambat atau sama dengan stempel waktu broker, dengan selisih maksimum yang diijinkan ditentukan oleh nilai yang ditetapkan dalam konfigurasi ini. Jika`log.message.timestamp.type=CreateTime`, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas yang ditentukan ini. Konfigurasi ini diabaikan jika`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, yaitu, 1 hari) |
| log.message.timestamp.before.max.ms | Perbedaan stempel waktu yang diijinkan antara stempel waktu broker dan stempel waktu pesan. Stempel waktu pesan dapat lebih awal dari atau sama dengan stempel waktu broker, dengan perbedaan maksimum yang diijinkan ditentukan oleh nilai yang ditetapkan dalam konfigurasi ini. Jika`log.message.timestamp.type=CreateTime`, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas yang ditentukan ini. Konfigurasi ini diabaikan jika`log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, yaitu, 1 hari) |
| log.message.timestamp.type | Menentukan apakah stempel waktu dalam pesan adalah waktu pembuatan pesan atau log menambahkan waktu. Nilai yang diizinkan adalah `CreateTime` dan`LogAppendTime`. | Apache Kafka Standar |
| log.retention.bytes | Ukuran maksimum log sebelum menghapusnya. | Apache Kafka Standar |
| log.retention.ms | Jumlah milidetik untuk menyimpan file log sebelum menghapusnya. | Apache Kafka Standar |
| max.connection.creation.rate | Tingkat pembuatan koneksi maksimum yang diizinkan di broker kapan saja. | Apache Kafka Standar |
| max.koneksi | Jumlah maksimum koneksi yang diizinkan di broker kapan saja. Batas ini diterapkan selain batas per-ip yang dikonfigurasi menggunakan. `max.connections.per.ip` | Apache Kafka Standar |
| max.connections.per.ip | Jumlah maksimum koneksi yang diizinkan dari setiap alamat ip. Ini dapat diatur ke `0` jika ada penggantian yang dikonfigurasi menggunakan properti max.connections.per.ip.overrides. Koneksi baru dari alamat ip dijatuhkan jika batas tercapai. | Apache Kafka Standar |
| max.connections.per.ip.overrides | Daftar per-ip atau nama host yang dipisahkan koma menggantikan jumlah koneksi maksimum default. Contoh nilai adalah `hostName:100,127.0.0.1:200` | Apache Kafka Standar |
| message.max.bytes | Ukuran batch rekor terbesar yang diizinkan Kafka. Jika Anda meningkatkan nilai ini dan ada konsumen yang lebih tua dari 0.10.2, Anda juga harus meningkatkan ukuran pengambilan konsumen sehingga mereka dapat mengambil batch rekaman sebesar ini. Versi format pesan terbaru selalu mengelompokkan pesan ke dalam batch untuk efisiensi. Versi format pesan sebelumnya tidak mengelompokkan catatan yang tidak terkompresi ke dalam batch, dan dalam kasus seperti itu, batas ini hanya berlaku untuk satu rekaman. Anda dapat mengatur nilai ini per topik dengan `max.message.bytes` konfigurasi tingkat topik. | Apache Kafka Standar |
| producer.id.expiration.ms | Waktu di ms bahwa pemimpin partisi topik akan menunggu sebelum produser IDs kedaluwarsa. Produser tidak IDs akan kedaluwarsa saat transaksi yang terkait dengannya masih berlangsung. Perhatikan bahwa produser IDs dapat kedaluwarsa lebih cepat jika penulisan terakhir dari ID produsen dihapus karena pengaturan retensi topik. Menyetel nilai ini sama atau lebih tinggi dari `delivery.timeout.ms` dapat membantu mencegah kedaluwarsa selama percobaan ulang dan melindungi terhadap duplikasi pesan, tetapi default harus masuk akal untuk sebagian besar kasus penggunaan. | Apache Kafka Standar |
## Konfigurasi tingkat topik pada Broker Ekspres
Anda dapat menggunakan perintah Apache Kafka untuk mengatur atau memodifikasi properti konfigurasi tingkat topik untuk topik baru dan yang sudah ada. Jika Anda tidak dapat memberikan konfigurasi tingkat topik apa pun, Amazon MSK menggunakan broker default. Seperti konfigurasi tingkat broker, Amazon MSK melindungi beberapa properti konfigurasi tingkat topik dari perubahan. Contohnya termasuk faktor replikasi, `min.insync.replicas` dan`unclean.leader.election.enable`. Jika Anda mencoba membuat topik dengan nilai faktor replikasi selain`3`, Amazon MSK akan membuat topik dengan faktor replikasi secara default. `3` Untuk informasi selengkapnya tentang properti konfigurasi tingkat topik dan contoh tentang cara mengaturnya, lihat [Konfigurasi Tingkat Topik dalam dokumentasi Apache Kafka](https://kafka.apache.org/documentation/#topicconfigs).
| Properti | Deskripsi |
| --- | --- |
| cleanup.policy | Konfigurasi ini menetapkan kebijakan retensi yang akan digunakan pada segmen log. Kebijakan “hapus” (yang merupakan default) akan membuang segmen lama ketika waktu penyimpanan atau batas ukurannya telah tercapai. Kebijakan “kompak” akan mengaktifkan pemadatan log, yang mempertahankan nilai terbaru untuk setiap kunci. Dimungkinkan juga untuk menentukan kedua kebijakan dalam daftar yang dipisahkan koma (misalnya, “hapus, kompak”). Dalam hal ini, segmen lama akan dibuang sesuai waktu retensi dan konfigurasi ukuran, sementara segmen yang dipertahankan akan dipadatkan. Pemadatan pada broker Express dipicu setelah data dalam partisi mencapai 256 MB. |
| kompresi.type | Tentukan jenis kompresi akhir untuk topik tertentu. Konfigurasi ini menerima codec kompresi standar (`gzip`,,`snappy`,`lz4`). `zstd` Ini juga menerima `uncompressed` yang setara dengan tidak ada kompresi; dan `producer` yang berarti mempertahankan codec kompresi asli yang ditetapkan oleh produsen. |
| hapus.retention.ms | Jumlah waktu untuk mempertahankan penanda batu nisan hapus untuk topik log yang dipadatkan. Pengaturan ini juga memberikan batas pada waktu di mana konsumen harus menyelesaikan pembacaan jika mereka mulai dari offset 0 untuk memastikan bahwa mereka mendapatkan snapshot yang valid dari tahap akhir. Jika tidak, hapus batu nisan mungkin dikumpulkan sebelum mereka menyelesaikan pemindaian mereka. Nilai default untuk pengaturan ini adalah 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, yaitu, 1 hari), Apache Kafka Default |
| max.message.bytes | Ukuran batch rekaman terbesar yang diizinkan oleh Kafka (setelah kompresi, jika kompresi diaktifkan). Jika ini meningkat dan ada konsumen yang lebih tua dari`0.10.2`, ukuran pengambilan konsumen juga harus ditingkatkan sehingga mereka dapat mengambil batch rekaman sebesar ini. Dalam versi format pesan terbaru, catatan selalu dikelompokkan ke dalam batch untuk efisiensi. Dalam versi format pesan sebelumnya, catatan yang tidak dikompresi tidak dikelompokkan ke dalam batch dan batas ini hanya berlaku untuk satu catatan dalam kasus itu. Ini dapat diatur per topik dengan tingkat topik`max.message.bytes config`. |
| message.timestamp.after.max.ms | Konfigurasi ini menetapkan perbedaan stempel waktu yang diizinkan antara stempel waktu pesan dan stempel waktu broker. Stempel waktu pesan bisa lebih lambat atau sama dengan stempel waktu broker, dengan selisih maksimum yang diijinkan ditentukan oleh nilai yang ditetapkan dalam konfigurasi ini. Jika`message.timestamp.type=CreateTime`, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas yang ditentukan ini. Konfigurasi ini diabaikan jika`message.timestamp.type=LogAppendTime`. |
| message.timestamp.before.max.ms | Konfigurasi ini menetapkan perbedaan stempel waktu yang diizinkan antara stempel waktu broker dan stempel waktu pesan. Stempel waktu pesan dapat lebih awal dari atau sama dengan stempel waktu broker, dengan perbedaan maksimum yang diijinkan ditentukan oleh nilai yang ditetapkan dalam konfigurasi ini. Jika`message.timestamp.type=CreateTime`, pesan akan ditolak jika perbedaan stempel waktu melebihi ambang batas yang ditentukan ini. Konfigurasi ini diabaikan jika`message.timestamp.type=LogAppendTime`. |
| message.timestamp.type | Tentukan apakah stempel waktu dalam pesan adalah waktu buat pesan atau waktu penambahan log. Nilai harus salah satu `CreateTime` atau `LogAppendTime` |
| min.compaction.lag.ms | Waktu minimum pesan akan tetap tidak dipadatkan di log. Pengaturan ini hanya berlaku untuk log yang sedang dipadatkan. Nilai default untuk pengaturan ini adalah 0, Apache Kafka Default |
| max.compaction.lag.ms | Waktu maksimum pesan akan tetap tidak memenuhi syarat untuk pemadatan di log. Pengaturan ini hanya berlaku untuk log yang sedang dipadatkan. Konfigurasi ini akan dibatasi dalam kisaran [7 hari, Long.Max]. Nilai default untuk pengaturan ini adalah 9223372036854775807, Apache Kafka Default. |
| retensi.bytes | Konfigurasi ini mengontrol ukuran maksimum partisi (yang terdiri dari segmen log) dapat tumbuh sebelum kita membuang segmen log lama untuk mengosongkan ruang jika kita menggunakan kebijakan retensi “hapus”. Secara default tidak ada batas ukuran hanya batas waktu. Karena batas ini diberlakukan pada tingkat partisi, kalikan dengan jumlah partisi untuk menghitung retensi topik dalam byte. Selain itu, `retention.bytes configuration` beroperasi secara independen `segment.ms` dan `segment.bytes` konfigurasi. Selain itu, memicu bergulir segmen baru jika `retention.bytes` dikonfigurasi ke nol. |
| retensi.ms | Konfigurasi ini mengontrol waktu maksimum kami akan menyimpan log sebelum kami membuang segmen log lama untuk mengosongkan ruang jika kami menggunakan kebijakan retensi “hapus”. Ini mewakili SLA tentang seberapa cepat konsumen harus membaca data mereka. Jika diatur ke`-1`, tidak ada batas waktu yang diterapkan. Selain itu, `retention.ms` konfigurasi beroperasi secara independen `segment.ms` dan `segment.bytes` konfigurasi. Selain itu, memicu bergulir segmen baru jika `retention.ms` kondisinya terpenuhi. |
# Konfigurasi hanya-baca broker ekspres
Amazon MSK menetapkan nilai untuk konfigurasi ini dan melindunginya dari perubahan yang dapat memengaruhi ketersediaan klaster Anda. Nilai-nilai ini dapat berubah tergantung pada versi Apache Kafka yang berjalan di cluster, jadi ingatlah untuk memeriksa nilai dari cluster spesifik Anda.
Tabel berikut mencantumkan konfigurasi read-only untuk broker Express.
| Properti | Deskripsi | Nilai Broker Ekspres |
| --- | --- | --- |
| broker.id | Id broker untuk server ini. | 1,2,3... |
| broker.rack | Rak broker. Ini akan digunakan dalam penugasan replikasi sadar rak untuk toleransi kesalahan. Contoh: `RACK1`, `us-timur-1d` | ID AZ atau ID Subnet |
| default.replication.factor | Faktor replikasi default untuk semua topik. | 3 |
| fetch.max.bytes | Jumlah maksimum byte yang akan kami kembalikan untuk permintaan pengambilan. | Apache Kafka Standar |
| group.max.size | Jumlah maksimum konsumen yang dapat ditampung oleh satu kelompok konsumen. | Apache Kafka Standar |
| inter.broker.listener.name | Nama pendengar yang digunakan untuk komunikasi antar broker. | REPLICATION\$1SECURE atau REPLIKASI |
| inter.broker.protocol.version | Menentukan versi protokol antar-broker yang digunakan. | Apache Kafka Standar |
| pendengar | Listener List - Daftar dipisahkan koma dari URIs kita akan mendengarkan dan nama pendengar. Anda dapat mengaturadvertised.listeners property, tetapi bukan listeners properti. | MSK yang dihasilkan |
| log.message.format.version | Tentukan versi format pesan yang akan digunakan broker untuk menambahkan pesan ke log. | Apache Kafka Standar |
| min.insync.replika | Ketika produser menetapkan acks ke `all` (atau`-1`), nilai dalam `min.insync.replicas` menentukan jumlah minimum replika yang harus mengakui penulisan agar penulisan dianggap berhasil. Jika minimum ini tidak dapat dipenuhi, produsen menimbulkan pengecualian (salah satu `NotEnoughReplicas` atau`NotEnoughReplicasAfterAppend`). Anda dapat menggunakan nilai acks dari produsen Anda untuk menegakkan jaminan daya tahan yang lebih besar. Dengan mengatur acks ke “semua”. Ini memastikan bahwa produser memunculkan pengecualian jika sebagian besar replika tidak menerima penulisan. | 2 |
| num.io.thread | Jumlah thread yang digunakan server untuk menghasilkan permintaan, yang mungkin termasuk disk I/O. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | Berdasarkan jenis instance. =Matematika.maks (8, 2 \$1 v) CPUs |
| num.network.threads | Jumlah thread yang digunakan server untuk menerima permintaan dari jaringan dan mengirim tanggapan ke jaringan. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | Berdasarkan jenis instance. =Math.max (8, v) CPUs |
| replica.fetch.response.max.bytes | Jumlah maksimum byte yang diharapkan untuk seluruh respons pengambilan. Rekaman diambil dalam batch, dan jika kumpulan rekaman pertama di partisi pengambilan yang tidak kosong pertama lebih besar dari nilai ini, kumpulan rekaman akan tetap dikembalikan untuk memastikan kemajuan. Ini bukan maksimum absolut. Properti message.max.bytes (konfigurasi broker) atau max.message.bytes (konfigurasi topik) menentukan ukuran batch catatan maksimum yang diterima broker. | Apache Kafka Standar |
| request.timeout.ms | Konfigurasi mengontrol jumlah waktu maksimum klien akan menunggu respons permintaan. Jika tanggapan tidak diterima sebelum batas waktu berlalu, klien akan mengirim ulang permintaan jika perlu atau gagal permintaan jika percobaan ulang habis. | Apache Kafka Standar |
| transaction.state.log.min.isr | min.insync.replicasKonfigurasi yang diganti untuk topik transaksi. | 2 |
| transaction.state.log.replication.factor | Faktor replikasi untuk topik transaksi. | Apache Kafka Standar |
| unclean.leader.election.enable | Mengizinkan replika yang tidak ada dalam set ISR untuk berfungsi sebagai pemimpin sebagai upaya terakhir, meskipun ini dapat mengakibatkan hilangnya data. | SALAH |
# Operasi konfigurasi broker
Konfigurasi broker Apache Kafka bersifat statis atau dinamis. Konfigurasi statis memerlukan broker restart untuk konfigurasi yang akan diterapkan. Konfigurasi dinamis tidak memerlukan broker restart untuk konfigurasi yang akan diperbarui. Untuk informasi selengkapnya tentang properti konfigurasi dan mode pembaruan, lihat Konfigurasi Apache Kafka.
Topik ini menjelaskan cara membuat konfigurasi MSK khusus dan cara melakukan operasi pada mereka. Untuk informasi tentang cara menggunakan konfigurasi MSK untuk membuat atau memperbarui cluster, lihat. [Fitur dan konsep utama MSK Amazon](operations.md)
**Topics**
+ [Buat konfigurasi](msk-configuration-operations-create.md)
+ [Perbarui konfigurasi](msk-configuration-operations-update.md)
+ [Hapus konfigurasi](msk-configuration-operations-delete.md)
+ [Dapatkan metadata konfigurasi](msk-configuration-operations-describe.md)
+ [Dapatkan detail tentang revisi konfigurasi](msk-configuration-operations-describe-revision.md)
+ [Konfigurasi daftar di akun Anda untuk Wilayah saat ini](msk-configuration-operations-list.md)
+ [Status konfigurasi MSK Amazon](msk-configuration-states.md)
# Buat konfigurasi
Proses ini menjelaskan cara membuat konfigurasi MSK Amazon khusus dan cara melakukan operasi di atasnya.
1. Buat file tempat Anda menentukan properti konfigurasi yang ingin Anda atur dan nilai yang ingin Anda tetapkan padanya. Berikut ini adalah isi dari contoh file konfigurasi.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Jalankan AWS CLI perintah berikut, dan ganti *config-file-path* dengan path ke file tempat Anda menyimpan konfigurasi di langkah sebelumnya.
**catatan**
Nama yang Anda pilih untuk konfigurasi Anda harus cocok dengan regex berikut: “^ [0-9A-za-Z] [0-9A-za-Z-] \$10,\$1 \$1”.
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
Berikut ini adalah contoh respons yang berhasil setelah Anda menjalankan perintah ini.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. Perintah sebelumnya mengembalikan Amazon Resource Name (ARN) untuk konfigurasi baru Anda. Simpan ARN ini karena Anda membutuhkannya untuk merujuk ke konfigurasi ini di perintah lain. Jika Anda kehilangan konfigurasi ARN, Anda dapat membuat daftar semua konfigurasi di akun Anda untuk menemukannya lagi.
# Perbarui konfigurasi
Proses ini menjelaskan cara memperbarui konfigurasi MSK Amazon khusus.
1. Buat file tempat Anda menentukan properti konfigurasi yang ingin Anda perbarui dan nilai yang ingin Anda tetapkan padanya. Berikut ini adalah isi dari contoh file konfigurasi.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Jalankan AWS CLI perintah berikut, dan ganti *config-file-path* dengan path ke file tempat Anda menyimpan konfigurasi di langkah sebelumnya.
Ganti *configuration-arn* dengan ARN yang Anda peroleh saat membuat konfigurasi. Jika Anda tidak menyimpan ARN saat membuat konfigurasi, Anda dapat menggunakan `list-configurations` perintah untuk mencantumkan semua konfigurasi di akun Anda. Konfigurasi yang Anda inginkan dalam daftar muncul di respons. ARN konfigurasi juga muncul dalam daftar itu.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Berikut ini adalah contoh respons yang berhasil setelah Anda menjalankan perintah ini.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# Hapus konfigurasi
Prosedur berikut menunjukkan cara menghapus konfigurasi yang tidak dilampirkan ke cluster. Anda tidak dapat menghapus konfigurasi yang dilampirkan ke klaster.
1. Untuk menjalankan contoh ini, ganti *configuration-arn* dengan ARN yang Anda peroleh saat Anda membuat konfigurasi. Jika Anda tidak menyimpan ARN saat membuat konfigurasi, Anda dapat menggunakan `list-configurations` perintah untuk mencantumkan semua konfigurasi di akun Anda. Konfigurasi yang Anda inginkan dalam daftar muncul di respons. ARN konfigurasi juga muncul dalam daftar itu.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Berikut ini adalah contoh respons yang berhasil setelah Anda menjalankan perintah ini.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Dapatkan metadata konfigurasi
Prosedur berikut menunjukkan cara mendeskripsikan konfigurasi MSK Amazon untuk mendapatkan metadata tentang konfigurasi.
1. Perintah berikut mengembalikan metadata tentang konfigurasi. Untuk mendapatkan deskripsi terperinci tentang konfigurasi, jalankan file`describe-configuration-revision`.
Untuk menjalankan contoh ini, ganti *configuration-arn* dengan ARN yang Anda peroleh saat Anda membuat konfigurasi. Jika Anda tidak menyimpan ARN saat membuat konfigurasi, Anda dapat menggunakan `list-configurations` perintah untuk mencantumkan semua konfigurasi di akun Anda. Konfigurasi yang Anda inginkan dalam daftar muncul di respons. ARN konfigurasi juga muncul dalam daftar itu.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Berikut ini adalah contoh respons yang berhasil setelah Anda menjalankan perintah ini.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# Dapatkan detail tentang revisi konfigurasi
Proses ini memberi Anda deskripsi rinci tentang revisi konfigurasi MSK Amazon.
Jika Anda menggunakan `describe-configuration` perintah untuk menggambarkan konfigurasi MSK, Anda melihat metadata konfigurasi. Untuk mendapatkan deskripsi konfigurasi, gunakan perintah,`describe-configuration-revision`.
+ Jalankan perintah berikut dan ganti *configuration-arn* dengan ARN yang Anda peroleh saat Anda membuat konfigurasi. Jika Anda tidak menyimpan ARN saat membuat konfigurasi, Anda dapat menggunakan `list-configurations` perintah untuk mencantumkan semua konfigurasi di akun Anda. Konfigurasi yang Anda inginkan dalam daftar yang muncul dalam respons. ARN konfigurasi juga muncul dalam daftar itu.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Berikut ini adalah contoh respons yang berhasil setelah Anda menjalankan perintah ini.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
Nilai `ServerProperties` dikodekan dengan base64. Jika Anda menggunakan decoder base64 (misalnya, https://www.base64decode.org/) untuk memecahkan kode secara manual, Anda mendapatkan konten dari file konfigurasi asli yang Anda gunakan untuk membuat konfigurasi kustom. Dalam hal ini, Anda mendapatkan yang berikut:
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Konfigurasi daftar di akun Anda untuk Wilayah saat ini
Proses ini menjelaskan cara mencantumkan semua konfigurasi MSK Amazon di akun Anda untuk Wilayah saat ini AWS .
+ Jalankan perintah berikut.
```
aws kafka list-configurations
```
Berikut ini adalah contoh respons yang berhasil setelah Anda menjalankan perintah ini.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Status konfigurasi MSK Amazon
Konfigurasi MSK Amazon dapat berada di salah satu negara bagian berikut. Untuk melakukan operasi pada konfigurasi, konfigurasi harus dalam `DELETE_FAILED` keadaan `ACTIVE` atau:
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# Penyeimbangan kembali cerdas untuk cluster
Amazon MSK menyediakan penyeimbangan kembali cerdas untuk semua cluster MSK Provisioned baru dengan broker Express. Fitur ini secara otomatis mengelola distribusi partisi dan operasi penskalaan cluster, menghilangkan kebutuhan akan alat pihak ketiga. Penyeimbangan ulang cerdas secara otomatis menyeimbangkan kembali partisi saat Anda menskalakan cluster ke atas atau ke bawah. Ini juga terus memantau kesehatan klaster Anda untuk ketidakseimbangan sumber daya atau kelebihan beban dan mendistribusikan kembali beban kerja.
Intelligent rebalancing menyediakan operasi penskalaan cepat yang selesai dalam waktu 30 menit dan tidak memengaruhi ketersediaan klaster selama penskalaan. Ini diaktifkan secara default untuk semua cluster Provisioned berbasis MSK Express baru dan bekerja dengan batas partisi maksimum yang disarankan 20.000 partisi per broker. Selain itu, fitur ini tersedia tanpa biaya tambahan dan tidak memerlukan konfigurasi apa pun.
Efektif 20 November 2025, Intelligent Rebalancing tersedia di semua Wilayah di AWS mana broker Amazon MSK Express didukung.
**Topics**
+ [Cara kerja penyeimbangan kembali yang cerdas](#how-intelligent-rebalancing-works)
+ [Memantau metrik penyeimbangan kembali yang cerdas](#intelligent-rebalancing-metrics)
+ [Pertimbangan untuk menggunakan penyeimbangan kembali cerdas](#intelligent-rebalancing-considerations)
+ [Menskalakan cluster MSK Amazon ke atas dan ke bawah dengan satu operasi](intelligent-rebalancing-scaling-clusters.md)
+ [Penyeimbangan kembali kondisi stabil untuk kluster MSK Amazon](intelligent-rebalancing-self-balancing-paritions.md)
## Cara kerja penyeimbangan kembali yang cerdas
Penyeimbangan kembali cerdas diaktifkan secara default untuk semua cluster MSK Provisioned baru dengan broker Express. Ini termasuk dukungan untuk situasi berikut:
+ **Menskalakan naik dan turun**: Memungkinkan Anda menambah atau menghapus broker ke kluster berbasis MSK Express Anda dengan satu klik. Setelah Anda menentukan broker untuk menambah atau menghapus, penyeimbangan ulang cerdas secara otomatis mendistribusikan kembali partisi di seluruh pengaturan cluster baru berdasarkan praktik terbaik internal. AWS
+ **Rebalancing kondisi stabil**: Pada kondisi tunak, fitur ini memantau kesehatan klaster Anda secara terus menerus dan secara otomatis menyeimbangkan kembali partisi saat:
+ Pemanfaatan sumber daya menjadi miring di seluruh broker.
+ Pialang menjadi terlalu banyak disediakan atau kurang dimanfaatkan.
+ Broker baru ditambahkan atau broker yang ada dihapus.
**catatan**
Jika penyeimbangan ulang cerdas diaktifkan, Anda tidak akan dapat menggunakan alat pihak ketiga, seperti Cruise Control, untuk menyeimbangkan kembali partisi. Anda harus terlebih dahulu menjeda penyeimbangan ulang cerdas untuk menggunakan API penugasan ulang partisi yang disediakan oleh alat pihak ketiga ini.
Anda dapat menggunakan fitur ini di konsol MSK Amazon. Anda juga dapat menggunakan fitur ini menggunakan AWS CLI, Amazon MSK APIs atau AWS SDK, dan. AWS CloudFormation Untuk informasi selengkapnya, lihat [Penskalaan kluster MSK Amazon](intelligent-rebalancing-scaling-clusters.md) dan [Penyeimbangan kembali keadaan mantap](intelligent-rebalancing-self-balancing-paritions.md).
## Memantau metrik penyeimbangan kembali yang cerdas
Anda dapat memantau status operasi penyeimbangan ulang cerdas yang sedang berlangsung dan historis menggunakan metrik Amazon CloudWatch berikut:
+ `RebalanceInProgress`: Metrik ini diterbitkan setiap menit dengan nilai 1 saat penyeimbangan kembali sedang berlangsung dan 0 sebaliknya.
+ `UnderProvisioned`: Menunjukkan bahwa klaster saat ini sedang disediakan dan penyeimbangan ulang partisi apa pun tidak dapat dilakukan. Anda juga perlu menambahkan lebih banyak broker atau meningkatkan jenis instans cluster Anda.
Untuk informasi tentang pemantauan klaster MSK Provisioned, lihat dan. [](monitoring.md) [](cloudwatch-metrics.md)
## Pertimbangan untuk menggunakan penyeimbangan kembali cerdas
+ Support for intelligent rebalancing hanya tersedia untuk cluster MSK Provisioned baru dengan broker Express.
+ Untuk penugasan kembali partisi otomatis, dukungan maksimum hingga 20.000 partisi per broker tersedia.
+ Anda tidak dapat menggunakan penugasan ulang partisi APIs atau alat penyeimbangan ulang pihak ketiga saat penyeimbangan ulang cerdas diaktifkan. Untuk menggunakan alat tersebut APIs atau pihak ketiga, Anda harus terlebih dahulu menjeda penyeimbangan ulang cerdas untuk klaster berbasis MSK Express Anda.
# Menskalakan cluster MSK Amazon ke atas dan ke bawah dengan satu operasi
Dengan penyeimbangan ulang yang cerdas, Anda dapat meningkatkan skala cluster Anda ke atas atau ke bawah dengan mengedit jumlah broker di cluster Anda dalam satu tindakan. Anda dapat melakukan ini di konsol MSK Amazon, atau dengan menggunakan AWS CLI, Amazon MSK APIs atau AWS SDK, dan. AWS CloudFormation Saat Anda mengubah jumlah broker, Amazon MSK melakukan hal berikut:
+ Secara otomatis mendistribusikan partisi ke broker baru.
+ Memindahkan partisi dari broker yang dihapus.
Saat Anda menskalakan klaster Anda ke atas dan ke bawah, ketersediaan klaster bagi klien untuk memproduksi dan mengkonsumsi data tetap tidak terpengaruh.
**Topics**
------
#### [ Scaling clusters using Konsol Manajemen AWS ]
1. Buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Pada halaman **Clusters**, pilih cluster berbasis Express yang baru dibuat. Untuk informasi tentang membuat klaster berbasis Express yang disediakan, lihat. [Langkah 1: Buat klaster MSK Provisioned](create-cluster.md)
1. Pada daftar dropdown **Tindakan**, pilih **Edit jumlah broker.**
1. Pada halaman **Edit jumlah broker per zona**, lakukan salah satu hal berikut:
+ Untuk menambahkan lebih banyak broker di klaster Anda, pilih **Tambahkan broker ke setiap Availability Zone**, lalu masukkan jumlah broker yang ingin Anda tambahkan.
+ Untuk menghapus broker dari klaster Anda, pilih **Hapus satu broker dari setiap Availability Zone**.
1. Pilih **Simpan perubahan**.
------
#### [ Scaling clusters using AWS CLI ]
Anda dapat menskalakan cluster Anda ke atas atau ke bawah dengan mengedit jumlah broker mereka. Untuk melakukan ini di AWS CLI, gunakan [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html)perintah, seperti yang ditunjukkan pada contoh berikut. Dalam perintah ini, tentukan jumlah broker yang Anda inginkan di cluster Anda di `target-broker-count` parameter.
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
Anda dapat menskalakan cluster Anda ke atas atau ke bawah dengan mengedit jumlah broker secara terprogram. Untuk melakukan ini menggunakan AWS SDK, gunakan [UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)API, seperti yang ditunjukkan pada contoh berikut. Untuk `TargetNumberOfBrokerNodes` parameternya, tentukan jumlah broker yang Anda inginkan di cluster Anda.
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Penyeimbangan kembali kondisi stabil untuk kluster MSK Amazon
Penyeimbangan kembali keadaan stabil adalah bagian dari fitur penyeimbangan kembali cerdas, yang diaktifkan secara default untuk semua cluster MSK Provisioned baru dengan broker Express. Saat Anda menskalakan cluster Anda naik atau turun, Amazon MSK secara otomatis menangani manajemen partisi dengan mendistribusikan partisi ke broker baru dan memindahkan partisi dari broker yang akan dihapus. Untuk memastikan distribusi beban kerja yang optimal di seluruh broker, penyeimbangan ulang cerdas menggunakan praktik terbaik MSK Amazon untuk menentukan ambang batas untuk memulai penyeimbangan kembali secara otomatis untuk broker Anda.
Anda dapat menjeda dan melanjutkan penyeimbangan kembali kondisi tunak saat diperlukan. Penyeimbangan kembali kondisi stabil terus memantau klaster Anda dan melakukan hal berikut:
+ Melacak penggunaan sumber daya broker (CPU, jaringan, penyimpanan).
+ Menyesuaikan penempatan partisi secara otomatis tanpa berdampak pada ketersediaan data.
+ Menyelesaikan operasi penyeimbangan kembali hingga 180x lebih cepat untuk broker Express dibandingkan dengan pialang Standar.
+ Mempertahankan kinerja cluster.
**Topics**
------
#### [ Pause and resume steady state rebalancing in Konsol Manajemen AWS ]
1. Buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Pada halaman **Clusters**, pilih cluster berbasis Express. Untuk informasi tentang membuat klaster berbasis Express yang disediakan, lihat. [Langkah 1: Buat klaster MSK Provisioned](create-cluster.md)
1. **Pada halaman detail Cluster, verifikasi bahwa status **penyeimbangan kembali Cerdas** adalah Aktif.** Jika Intelligent rebalancing tidak tersedia atau statusnya **Dijeda**, buat klaster berbasis Express baru.
1. Pada daftar dropdown **Actions**, pilih **Edit intelligent** rebalancing.
1. Pada halaman **Edit intelligent rebalancing**, lakukan hal berikut:
1. Pilih **Dijeda**.
1. Pilih **Simpan perubahan**.
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
Untuk mengatur status rebalancing cluster untuk **ACTIVE** menggunakan AWS CLI, gunakan perintah [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html), seperti yang ditunjukkan pada contoh berikut. Dalam perintah ini, tentukan status dengan `rebalancing` parameter.
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
Anda juga dapat mengatur status rebalancing cluster menggunakan [UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing)API untuk memodifikasi jumlah broker secara terprogram. Contoh berikut menunjukkan cara mengatur status penyeimbangan kembali ke **ACTIVE** dan. **PAUSED**
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# Penambalan pada kluster MSK Provisioned
Secara berkala, Amazon MSK memperbarui perangkat lunak pada broker di cluster Anda. Pemeliharaan mencakup pembaruan yang direncanakan atau perbaikan yang tidak direncanakan. Pemeliharaan terencana mencakup pembaruan sistem operasi, pembaruan keamanan, dan pembaruan perangkat lunak lain yang diperlukan untuk menjaga kesehatan, keamanan, dan kinerja klaster Anda. Kami melakukan pemeliharaan yang tidak direncanakan untuk menyelesaikan degradasi infrastruktur yang tiba-tiba. Kami melakukan pemeliharaan pada pialang Standar dan Ekspres, tetapi pengalamannya berbeda.
## Penambalan untuk pialang Standar
Pembaruan pada pialang Standar Anda tidak berdampak pada penulisan dan pembacaan aplikasi Anda jika Anda mengikuti praktik [terbaik](bestpractices.md).
Amazon MSK menggunakan pembaruan bergulir untuk perangkat lunak untuk menjaga ketersediaan klaster Anda yang tinggi. Selama proses ini, broker di-reboot satu per satu, dan Kafka secara otomatis memindahkan kepemimpinan ke broker online lain. Ketika Anda melihat operasi klaster di Konsol Manajemen AWS atau melalui `DescribeClusterOperation` dan `ListClusterOperations` APIs, operasi pemeliharaan ini muncul dengan jenis operasi`SECURITY_PATCHING`. Klien Kafka memiliki mekanisme bawaan untuk secara otomatis mendeteksi perubahan kepemimpinan untuk partisi dan terus menulis dan membaca data ke dalam cluster MSK. Ikuti [Praktik terbaik untuk klien Apache Kafka](bestpractices-kafka-client.md) untuk kelancaran pengoperasian cluster Anda setiap saat, termasuk selama penambalan.
Setelah broker offline, adalah normal untuk melihat kesalahan pemutusan sementara pada klien Anda. Anda juga akan mengamati untuk jendela singkat (hingga 2 menit, biasanya kurang) beberapa lonjakan di p99 membaca dan menulis latensi (biasanya milidetik tinggi, hingga \$1 2 detik). Lonjakan ini diharapkan dan disebabkan oleh klien yang terhubung kembali ke broker pemimpin baru; itu tidak memengaruhi produk atau konsumsi Anda dan akan menyelesaikan setelah terhubung kembali. Untuk informasi selengkapnya, lihat [Broker offline dan failover klien](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html).
Anda juga akan mengamati peningkatan metrik`UnderReplicatedPartitions`, yang diharapkan karena partisi pada broker yang ditutup tidak lagi mereplikasi data. Ini tidak berdampak pada penulisan dan pembacaan aplikasi sebagai replika untuk partisi ini yang di-host di broker lain sekarang melayani permintaan.
Setelah pembaruan perangkat lunak, ketika broker kembali online, ia perlu “mengejar” pesan yang dihasilkan saat offline. Selama catch up, Anda juga dapat mengamati peningkatan penggunaan volume throughput dan CPU. Ini seharusnya tidak berdampak pada penulisan dan pembacaan ke dalam cluster jika Anda memiliki cukup sumber daya CPU, memori, jaringan, dan volume pada broker Anda.
## Penambalan untuk broker Express
Tidak ada jendela pemeliharaan untuk broker Express. Amazon MSK secara otomatis memperbarui klaster Anda secara berkelanjutan dalam waktu yang didistribusikan, yang berarti Anda dapat mengharapkan reboot broker sesekali dan tunggal sepanjang bulan. Ini memastikan Anda tidak perlu membuat rencana atau akomodasi apa pun di sekitar jendela pemeliharaan satu kali di seluruh cluster. Seperti biasa, lalu lintas akan tetap tidak terganggu selama reboot broker karena kepemimpinan akan berubah ke broker lain yang akan terus melayani permintaan. Ketika Anda melihat operasi klaster di Konsol Manajemen AWS atau melalui `DescribeClusterOperation` dan `ListClusterOperations` APIs, operasi pemeliharaan ini muncul dengan jenis operasi`BROKER_UPDATE`.
Broker ekspres dilengkapi dengan pengaturan praktik terbaik dan pagar pembatas yang membuat klaster Anda tahan terhadap perubahan beban yang mungkin terjadi selama pemeliharaan. Amazon MSK menetapkan kuota throughput pada broker Express Anda untuk mengurangi dampak kelebihan beban klaster Anda yang dapat menyebabkan masalah selama restart broker. Perbaikan ini menghilangkan kebutuhan akan pemberitahuan sebelumnya, perencanaan, dan jendela pemeliharaan saat Anda menggunakan broker Express.
Broker ekspres selalu mereplikasi data Anda dengan tiga cara sehingga klien Anda secara otomatis gagal selama reboot. Anda tidak perlu khawatir topik menjadi tidak tersedia karena faktor replikasi disetel ke 1 atau 2. Selain itu, catch up untuk broker Express yang dimulai ulang lebih cepat daripada broker Standar. Kecepatan patching yang lebih cepat pada broker Express berarti bahwa akan ada gangguan perencanaan minimal untuk setiap aktivitas pesawat kontrol yang mungkin telah Anda jadwalkan untuk cluster Anda.
Seperti semua aplikasi Apache Kafka, masih ada kontrak client-server bersama untuk klien yang terhubung ke broker Express. Masih penting untuk mengonfigurasi klien Anda untuk menangani kegagalan kepemimpinan antar broker. Ikuti [Praktik terbaik untuk klien Apache Kafka](bestpractices-kafka-client.md) untuk kelancaran operasi cluster Anda setiap saat, termasuk saat menambal. Setelah broker memulai kembali, adalah normal untuk melihat [kesalahan pemutusan sementara pada](troubleshooting-offlinebroker-clientfailover.md) klien Anda. Ini tidak akan mempengaruhi produk dan konsumsi Anda karena broker pengikut akan mengambil alih kepemimpinan partisi. Klien Apache Kafka Anda akan secara otomatis gagal dan mulai mengirim permintaan ke broker pemimpin baru.
# Broker offline dan failover klien
Kafka memungkinkan broker offline; broker offline tunggal dalam cluster yang sehat dan seimbang mengikuti praktik terbaik tidak akan melihat dampak atau menyebabkan kegagalan untuk memproduksi atau mengkonsumsi. Ini karena broker lain akan mengambil alih kepemimpinan partisi dan karena lib klien Kafka akan secara otomatis gagal dan mulai mengirim permintaan ke broker pemimpin baru.
**Kontrak server klien**
Ini menghasilkan kontrak bersama antara pustaka klien dan perilaku sisi server; server harus berhasil menetapkan satu atau lebih pemimpin baru dan klien harus mengubah broker untuk mengirim permintaan kepada pemimpin baru pada waktu yang tepat.
Kafka menggunakan pengecualian untuk mengontrol aliran ini:
**Contoh prosedur**
1. Broker A memasuki keadaan offline.
1. Klien Kafka menerima pengecualian (biasanya pemutusan jaringan atau not\$1leader\$1for\$1partition).
1. Pengecualian ini memicu klien Kafka untuk memperbarui metadatanya sehingga mengetahui tentang pemimpin terbaru.
1. Klien Kafka melanjutkan pengiriman permintaan ke pemimpin partisi baru di broker lain.
Proses ini biasanya memakan waktu kurang dari 2 detik dengan klien Java vended dan konfigurasi default. Kesalahan sisi klien bertele-tele dan berulang tetapi tidak menimbulkan kekhawatiran, seperti yang dilambangkan dengan level “WARN”.
**Contoh: Pengecualian 1**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2`
**Contoh: Pengecualian 2**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"`
Klien Kafka akan secara otomatis menyelesaikan kesalahan ini biasanya dalam 1 detik dan paling lama 3 detik. Ini muncul sebagai produce/consume latensi pada p99 dalam metrik sisi klien (biasanya milidetik tinggi di tahun 100-an). Lebih lama dari ini biasanya menunjukkan masalah dengan konfigurasi klien atau beban pengontrol sisi server. Silakan lihat bagian pemecahan masalah.
Kegagalan yang berhasil dapat diverifikasi dengan memeriksa peningkatan `LeaderCount` metrik `BytesInPerSec` dan pada broker lain yang membuktikan bahwa lalu lintas dan kepemimpinan bergerak seperti yang diharapkan. Anda juga akan mengamati peningkatan `UnderReplicatedPartitions` metrik, yang diharapkan ketika replika offline dengan broker shutdown.
**Pemecahan masalah**
Aliran di atas dapat terganggu dengan melanggar kontrak client-server. Alasan paling umum untuk masalah meliputi:
+ Kesalahan konfigurasi atau penggunaan lib klien Kafka yang salah.
+ Perilaku dan bug default yang tidak terduga dengan lib klien pihak ke-3.
+ Pengontrol kelebihan beban menghasilkan penugasan pemimpin partisi yang lebih lambat.
+ Pengontrol baru dipilih sehingga penugasan pemimpin partisi lebih lambat.
Untuk memastikan perilaku yang benar untuk menangani kegagalan kepemimpinan, kami merekomendasikan:
+ [Praktik terbaik](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html) sisi server harus diikuti untuk memastikan bahwa broker pengontrol diskalakan dengan tepat untuk menghindari penugasan kepemimpinan yang lambat.
+ Pustaka klien harus mengaktifkan percobaan ulang untuk memastikan bahwa klien menangani failover.
+ Pustaka klien harus memiliki retry.backoff.ms yang dikonfigurasi (default 100) untuk menghindari badai. connection/request
+ Pustaka klien harus menyetel request.timeout.ms dan delivery.timeout.ms ke nilai yang sejalan dengan SLA aplikasi. Nilai yang lebih tinggi akan menghasilkan fail-over yang lebih lambat untuk jenis kegagalan tertentu.
+ Pustaka klien harus memastikan bahwa bootstrap.servers berisi setidaknya 3 broker acak untuk menghindari dampak ketersediaan pada penemuan awal.
+ Beberapa pustaka klien memiliki level yang lebih rendah daripada yang lain dan mengharapkan pengembang aplikasi untuk mengimplementasikan logika coba ulang dan penanganan pengecualian itu sendiri. Silakan merujuk ke dokumentasi khusus lib klien misalnya penggunaan, dan pastikan bahwa reconnect/retry logika yang benar diikuti.
+ Kami merekomendasikan pemantauan latensi sisi klien untuk produksi, jumlah permintaan yang berhasil, dan jumlah kesalahan untuk kesalahan yang tidak dapat dicoba ulang.
+ Kami telah mengamati bahwa pustaka golang dan ruby pihak ke-3 yang lebih tua tetap bertele-tele selama seluruh periode waktu offline broker meskipun permintaan produksi dan konsumsi tidak terpengaruh. Kami menyarankan Anda untuk selalu memantau metrik tingkat bisnis Anda selain metrik permintaan untuk keberhasilan dan kesalahan untuk menentukan apakah ada dampak nyata vs kebisingan di log Anda.
+ Pelanggan tidak boleh alarm tentang pengecualian sementara untuk jaringan/not\$1leader karena mereka normal, tidak berdampak, dan diharapkan sebagai bagian dari protokol kafka.
+ Pelanggan tidak boleh alarm UnderReplicatedPartitions karena mereka normal, tidak berdampak, dan diharapkan selama satu broker offline.
# Keamanan di Amazon MSK
Keamanan cloud di AWS adalah prioritas tertinggi. Sebagai AWS pelanggan, Anda mendapat manfaat dari pusat data dan arsitektur jaringan yang dibangun untuk memenuhi persyaratan organisasi yang paling sensitif terhadap keamanan.
Keamanan adalah tanggung jawab bersama antara Anda AWS dan Anda. [Model tanggung jawab bersama](https://aws.amazon.com/compliance/shared-responsibility-model/) menjelaskan hal ini sebagai keamanan *dari* cloud dan keamanan *dalam* cloud:
+ **Keamanan cloud** — AWS bertanggung jawab untuk melindungi infrastruktur yang menjalankan AWS layanan di AWS Cloud. AWS juga memberi Anda layanan yang dapat Anda gunakan dengan aman. Auditor pihak ketiga secara teratur menguji dan memverifikasi efektivitas keamanan kami sebagai bagian dari [Program AWS Kepatuhan Program AWS Kepatuhan](https://aws.amazon.com/compliance/programs/) . Untuk mempelajari tentang program kepatuhan yang berlaku untuk Amazon Managed Streaming for Apache Kafka, lihat Amazon Web Services in Scope by Compliance Program [Amazon Web Services in Scope by Compliance](https://aws.amazon.com/compliance/services-in-scope/) Program by Compliance Program.
+ **Keamanan di cloud** — Tanggung jawab Anda ditentukan oleh AWS layanan yang Anda gunakan. Anda juga bertanggung jawab atas faktor lain, termasuk sensitivitas data Anda, persyaratan perusahaan Anda, serta undang-undang dan peraturan yang berlaku.
Dokumentasi ini membantu Anda memahami cara menerapkan model tanggung jawab bersama saat menggunakan Amazon MSK. Topik berikut menunjukkan cara mengonfigurasi Amazon MSK untuk memenuhi tujuan keamanan dan kepatuhan Anda. Anda juga mempelajari cara menggunakan Amazon Web Services lain yang membantu Anda memantau dan mengamankan sumber daya MSK Amazon Anda.
**Topics**
+ [Perlindungan data di Amazon Managed Streaming for Apache Kafka](data-protection.md)
+ [Otentikasi dan otorisasi untuk Amazon MSK APIs](security-iam.md)
+ [Otentikasi dan otorisasi untuk Apache Kafka APIs](kafka_apis_iam.md)
+ [Mengubah grup keamanan klaster MSK Amazon](change-security-group.md)
+ [Kontrol akses ke ZooKeeper node Apache di kluster MSK Amazon Anda](zookeeper-security.md)
+ [Validasi kepatuhan untuk Amazon Managed Streaming for Apache Kafka](MSK-compliance.md)
+ [Ketahanan di Amazon Managed Streaming untuk Apache Kafka](disaster-recovery-resiliency.md)
+ [Keamanan infrastruktur di Amazon Managed Streaming for Apache Kafka](infrastructure-security.md)
# Perlindungan data di Amazon Managed Streaming for Apache Kafka
[Model tanggung jawab AWS bersama model](https://aws.amazon.com/compliance/shared-responsibility-model/) berlaku untuk perlindungan data di Amazon Managed Streaming for Apache Kafka. Seperti yang dijelaskan dalam model AWS ini, bertanggung jawab untuk melindungi infrastruktur global yang menjalankan semua AWS Cloud. Anda bertanggung jawab untuk mempertahankan kendali atas konten yang di-host pada infrastruktur ini. Anda juga bertanggung jawab atas tugas-tugas konfigurasi dan manajemen keamanan untuk Layanan AWS yang Anda gunakan. Lihat informasi yang lebih lengkap tentang privasi data dalam [Pertanyaan Umum Privasi Data](https://aws.amazon.com/compliance/data-privacy-faq/). Lihat informasi tentang perlindungan data di Eropa di pos blog [Model Tanggung Jawab Bersama dan GDPR AWS](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) di *Blog Keamanan AWS *.
Untuk tujuan perlindungan data, kami menyarankan Anda melindungi Akun AWS kredensyal dan mengatur pengguna individu dengan AWS IAM Identity Center atau AWS Identity and Access Management (IAM). Dengan cara itu, setiap pengguna hanya diberi izin yang diperlukan untuk memenuhi tanggung jawab tugasnya. Kami juga menyarankan supaya Anda mengamankan data dengan cara-cara berikut:
+ Gunakan autentikasi multi-faktor (MFA) pada setiap akun.
+ Gunakan SSL/TLS untuk berkomunikasi dengan AWS sumber daya. Kami mensyaratkan TLS 1.2 dan menganjurkan TLS 1.3.
+ Siapkan API dan pencatatan aktivitas pengguna dengan AWS CloudTrail. Untuk informasi tentang penggunaan CloudTrail jejak untuk menangkap AWS aktivitas, lihat [Bekerja dengan CloudTrail jejak](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) di *AWS CloudTrail Panduan Pengguna*.
+ Gunakan solusi AWS enkripsi, bersama dengan semua kontrol keamanan default di dalamnya Layanan AWS.
+ Gunakan layanan keamanan terkelola tingkat lanjut seperti Amazon Macie, yang membantu menemukan dan mengamankan data sensitif yang disimpan di Amazon S3.
+ Jika Anda memerlukan modul kriptografi tervalidasi FIPS 140-3 saat mengakses AWS melalui antarmuka baris perintah atau API, gunakan titik akhir FIPS. Lihat informasi selengkapnya tentang titik akhir FIPS yang tersedia di [Standar Pemrosesan Informasi Federal (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
Kami sangat merekomendasikan agar Anda tidak pernah memasukkan informasi identifikasi yang sensitif, seperti nomor rekening pelanggan Anda, ke dalam tanda atau bidang isian bebas seperti bidang **Nama**. Ini termasuk ketika Anda bekerja dengan Amazon MSK atau lainnya Layanan AWS menggunakan konsol, API AWS CLI, atau AWS SDKs. Data apa pun yang Anda masukkan ke dalam tanda atau bidang isian bebas yang digunakan untuk nama dapat digunakan untuk log penagihan atau log diagnostik. Saat Anda memberikan URL ke server eksternal, kami sangat menganjurkan supaya Anda tidak menyertakan informasi kredensial di dalam URL untuk memvalidasi permintaan Anda ke server itu.
**Topics**
+ [Enkripsi Amazon MSK](msk-encryption.md)
+ [Memulai enkripsi MSK Amazon](msk-working-with-encryption.md)
+ [Gunakan Amazon MSK APIs dengan Titik Akhir VPC Antarmuka](privatelink-vpc-endpoints.md)
# Enkripsi Amazon MSK
Amazon MSK menyediakan opsi enkripsi data yang dapat Anda gunakan untuk memenuhi persyaratan manajemen data yang ketat. Sertifikat yang digunakan Amazon MSK untuk enkripsi harus diperbarui setiap 13 bulan. Amazon MSK secara otomatis memperbarui sertifikat ini untuk semua cluster. Cluster broker ekspres tetap dalam `ACTIVE` keadaan saat Amazon MSK memulai operasi pembaruan sertifikat. Untuk klaster pialang standar, Amazon MSK menetapkan status cluster `MAINTENANCE` saat memulai operasi pembaruan sertifikat. MSK menyetelnya kembali ke `ACTIVE` saat pembaruan selesai. Saat cluster berada dalam operasi pemutakhiran sertifikat, Anda dapat terus memproduksi dan mengkonsumsi data, tetapi Anda tidak dapat melakukan operasi pembaruan apa pun di dalamnya.
## Enkripsi MSK Amazon saat istirahat
Amazon MSK terintegrasi dengan [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/)(KMS) untuk menawarkan enkripsi sisi server yang transparan. Amazon MSK selalu mengenkripsi data Anda saat istirahat. Saat Anda membuat klaster MSK, Anda dapat menentukan AWS KMS key yang Anda ingin Amazon MSK gunakan untuk mengenkripsi data Anda saat istirahat. Jika Anda tidak menentukan kunci KMS, Amazon MSK membuat [Kunci yang dikelola AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk)untuk Anda dan menggunakannya atas nama Anda. Untuk informasi selengkapnya tentang kunci KMS, lihat [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) di *Panduan Developer AWS Key Management Service *.
## Enkripsi MSK Amazon dalam perjalanan
Amazon MSK menggunakan TLS 1.2. Secara default, ini mengenkripsi data dalam perjalanan antara broker kluster MSK Anda. Anda dapat mengganti default ini pada saat Anda membuat cluster.
Untuk komunikasi antara klien dan broker, Anda harus menentukan salah satu dari tiga pengaturan berikut:
+ Hanya izinkan data terenkripsi TLS. Ini adalah pengaturan default.
+ Izinkan plaintext, serta data terenkripsi TLS.
+ Hanya izinkan data plaintext.
Broker MSK Amazon menggunakan AWS Certificate Manager sertifikat publik. Oleh karena itu, setiap truststore yang mempercayai Amazon Trust Services juga mempercayai sertifikat broker MSK Amazon.
Meskipun kami sangat menyarankan untuk mengaktifkan enkripsi dalam transit, ini dapat menambahkan overhead CPU tambahan dan latensi beberapa milidetik. Namun, sebagian besar kasus penggunaan tidak sensitif terhadap perbedaan ini, dan besarnya dampaknya bergantung pada konfigurasi klaster, klien, dan profil penggunaan Anda.
# Memulai enkripsi MSK Amazon
Saat membuat cluster MSK, Anda dapat menentukan pengaturan enkripsi dalam format JSON. Berikut adalah contohnya.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Untuk`DataVolumeKMSKeyId`, Anda dapat menentukan [kunci yang dikelola pelanggan](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) atau MSK Kunci yang dikelola AWS untuk di akun Anda (`alias/aws/kafka`). Jika Anda tidak menentukan`EncryptionAtRest`, Amazon MSK masih mengenkripsi data Anda saat istirahat di bawah. Kunci yang dikelola AWS Untuk menentukan kunci mana yang digunakan klaster Anda, kirim `GET` permintaan atau panggil operasi `DescribeCluster` API.
Untuk`EncryptionInTransit`, nilai default `InCluster` adalah true, tetapi Anda dapat mengaturnya ke false jika Anda tidak ingin Amazon MSK mengenkripsi data Anda saat melewati antara broker.
Untuk menentukan mode enkripsi untuk data dalam perjalanan antara klien dan broker, atur `ClientBroker` ke salah satu dari tiga nilai:`TLS`,`TLS_PLAINTEXT`, atau`PLAINTEXT`.
**Topics**
+ [Tentukan pengaturan enkripsi saat membuat cluster MSK Amazon](msk-working-with-encryption-cluster-create.md)
+ [Uji enkripsi Amazon MSK TLS](msk-working-with-encryption-test-tls.md)
# Tentukan pengaturan enkripsi saat membuat cluster MSK Amazon
Proses ini menjelaskan cara menentukan pengaturan enkripsi saat membuat cluster MSK Amazon.
**Tentukan pengaturan enkripsi saat membuat cluster**
1. Simpan isi dari contoh sebelumnya dalam file dan berikan file nama apa pun yang Anda inginkan. Misalnya, sebut saja`encryption-settings.json`.
1. Jalankan `create-cluster` perintah dan gunakan `encryption-info` opsi untuk menunjuk ke file tempat Anda menyimpan konfigurasi JSON Anda. Berikut adalah contohnya. Ganti *\$1YOUR MSK VERSION\$1* dengan versi yang cocok dengan versi klien Apache Kafka. Untuk informasi tentang cara menemukan versi klaster MSK Anda, lihat[Menentukan versi klaster MSK Anda](create-topic.md#find-msk-cluster-version). Ketahuilah bahwa menggunakan versi klien Apache Kafka yang tidak sama dengan versi cluster MSK Anda dapat menyebabkan kerusakan, kehilangan, dan waktu henti data Apache Kafka.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
Berikut ini adalah contoh respons yang berhasil setelah menjalankan perintah ini.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Uji enkripsi Amazon MSK TLS
Proses ini menjelaskan cara menguji enkripsi TLS di Amazon MSK.
**Untuk menguji enkripsi TLS**
1. Buat mesin klien mengikuti panduan di[Langkah 3: Buat mesin klien](create-client-machine.md).
1. Instal Apache Kafka di mesin klien.
1. Dalam contoh ini kita menggunakan truststore JVM untuk berbicara dengan cluster MSK. Untuk melakukan ini, pertama buat folder bernama `/tmp` pada mesin klien. Kemudian, buka `bin` folder instalasi Apache Kafka, dan jalankan perintah berikut. (Jalur JVM Anda mungkin berbeda.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Saat masih dalam `bin` folder instalasi Apache Kafka di mesin klien, buat file teks bernama `client.properties` dengan konten berikut.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Jalankan perintah berikut pada mesin yang telah AWS CLI diinstal, ganti *clusterARN* dengan ARN cluster Anda.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Hasil yang sukses terlihat seperti berikut ini. Simpan hasil ini karena Anda membutuhkannya untuk langkah selanjutnya.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. Jalankan perintah berikut, ganti *BootstrapBrokerStringTls* dengan salah satu titik akhir broker yang Anda peroleh pada langkah sebelumnya.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Buka jendela perintah baru dan sambungkan ke mesin klien yang sama. Kemudian, jalankan perintah berikut untuk membuat konsumen konsol.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Di jendela produser, ketik pesan teks diikuti dengan pengembalian, dan cari pesan yang sama di jendela konsumen. Amazon MSK mengenkripsi pesan ini dalam perjalanan.
[Untuk informasi selengkapnya tentang mengonfigurasi klien Apache Kafka agar bekerja dengan data terenkripsi, lihat Mengonfigurasi Klien Kafka.](https://kafka.apache.org/documentation/#security_configclients)
# Gunakan Amazon MSK APIs dengan Titik Akhir VPC Antarmuka
Anda dapat menggunakan Endpoint VPC Antarmuka, yang didukung oleh AWS PrivateLink, untuk mencegah lalu lintas antara VPC Amazon dan MSK APIs Amazon Anda meninggalkan jaringan Amazon. Titik Akhir VPC Antarmuka tidak memerlukan gateway internet, perangkat NAT, koneksi VPN, atau koneksi Direct AWS Connect. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)adalah AWS teknologi yang memungkinkan komunikasi pribadi antar AWS layanan menggunakan elastic network interface dengan private IPs di Amazon VPC Anda. Untuk informasi selengkapnya, lihat [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) dan [Interface VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) ().AWS PrivateLink
Aplikasi Anda dapat terhubung dengan Amazon MSK Provisioned dan MSK Connect menggunakan. APIs AWS PrivateLink Untuk memulai, buat Endpoint VPC Antarmuka untuk API MSK Amazon Anda untuk memulai lalu lintas yang mengalir dari dan ke sumber daya VPC Amazon Anda melalui Titik Akhir VPC Antarmuka. Titik akhir VPC Antarmuka berkemampuan FIPS tersedia untuk Wilayah AS. Untuk informasi selengkapnya, lihat [Membuat Endpoint Antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
Dengan menggunakan fitur ini, klien Apache Kafka Anda dapat secara dinamis mengambil string koneksi untuk terhubung dengan sumber daya MSK Provisioned atau MSK Connect tanpa melintasi internet untuk mengambil string koneksi.
Saat membuat Endpoint VPC Antarmuka, pilih salah satu titik akhir nama layanan berikut:
**Untuk MSK Disediakan:**
+ Titik akhir nama layanan berikut tidak lagi didukung untuk koneksi baru:
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (diaktifkan FIPS)
+ Layanan endpoint dualstack yang mendukung keduanya IPv4 dan IPv6 lalu lintas adalah:
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (FIPS-diaktifkan)
Untuk menyiapkan titik akhir dualstack, Anda harus mengikuti pedoman titik akhir [Dual-stack](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) dan FIPS.
Di mana wilayah adalah nama wilayah Anda. Pilih nama layanan ini untuk bekerja dengan MSK APIs Provisioned-compatible. Untuk informasi selengkapnya, lihat [Operasi](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) di *https://docs.aws.amazon.com/msk/1.0/apireference/*.
**Untuk MSK Connect:**
+ com.amazonaws.region.kafkaconnect
Di mana wilayah adalah nama wilayah Anda. Pilih nama layanan ini untuk bekerja dengan MSK APIs Connect-kompatibel. Untuk informasi selengkapnya, lihat [Tindakan](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) di *Referensi API Amazon MSK Connect*.
*Untuk informasi selengkapnya, termasuk step-by-step petunjuk untuk membuat titik akhir VPC antarmuka, lihat [Membuat titik akhir antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) di Panduan.AWS PrivateLink *
## Kontrol akses ke titik akhir VPC untuk Amazon MSK Provisioned atau MSK Connect APIs
Kebijakan titik akhir VPC memungkinkan Anda mengontrol akses dengan melampirkan kebijakan ke titik akhir VPC atau dengan menggunakan bidang tambahan dalam kebijakan yang dilampirkan ke pengguna, grup, atau peran IAM untuk membatasi akses agar hanya terjadi melalui titik akhir VPC yang ditentukan. Gunakan kebijakan contoh yang sesuai untuk menentukan izin akses untuk layanan MSK Provisioned atau MSK Connect.
Jika Anda tidak melampirkan kebijakan ketika membuat titik akhir, Amazon VPC melampirkan kebijakan default untuk Anda sehingga memungkinkan akses penuh ke layanan. Kebijakan endpoint tidak mengesampingkan atau mengganti kebijakan berbasis identitas IAM atau kebijakan khusus layanan. Ini adalah kebijakan terpisah untuk mengendalikan akses dari titik akhir ke layanan tertentu.
*Untuk informasi selengkapnya, lihat [Mengontrol Akses ke Layanan dengan Titik Akhir VPC di Panduan](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html).AWS PrivateLink *
------
#### [ MSK Provisioned — VPC policy example ]
**Akses hanya-baca**
Kebijakan sampel ini dapat dilampirkan ke titik akhir VPC. (Untuk informasi selengkapnya, lihat Mengontrol Akses ke Sumber Daya VPC Amazon). Ini membatasi tindakan untuk hanya mencantumkan dan menjelaskan operasi melalui titik akhir VPC yang dilampirkan.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned - Contoh kebijakan titik akhir VPC**
Batasi akses ke kluster MSK tertentu
Kebijakan sampel ini dapat dilampirkan ke titik akhir VPC. Ini membatasi akses ke cluster Kafka tertentu melalui titik akhir VPC yang dilampirkan.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Daftar konektor dan buat konektor baru**
Berikut ini adalah contoh kebijakan endpoint untuk MSK Connect. Kebijakan ini memungkinkan peran yang ditentukan untuk mencantumkan konektor dan membuat konektor baru.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect - Contoh kebijakan titik akhir VPC**
Mengizinkan hanya permintaan dari alamat IP tertentu di VPC yang ditentukan
Contoh berikut menunjukkan kebijakan yang hanya memungkinkan permintaan yang berasal dari alamat IP tertentu di VPC tertentu untuk berhasil. Permintaan dari alamat IP lain akan gagal.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Otentikasi dan otorisasi untuk Amazon MSK APIs
AWS Identity and Access Management (IAM) adalah Layanan AWS yang membantu administrator mengontrol akses ke AWS sumber daya dengan aman. Administrator IAM mengontrol siapa yang dapat *diautentikasi* (masuk) dan *diberi wewenang* (memiliki izin) untuk menggunakan sumber daya MSK Amazon. IAM adalah Layanan AWS yang dapat Anda gunakan tanpa biaya tambahan.
**Topics**
+ [Bagaimana Amazon MSK bekerja dengan IAM](security_iam_service-with-iam.md)
+ [Contoh kebijakan berbasis identitas MSK Amazon](security_iam_id-based-policy-examples.md)
+ [Peran terkait layanan untuk Amazon MSK](using-service-linked-roles.md)
+ [AWS kebijakan terkelola untuk Amazon MSK](security-iam-awsmanpol.md)
+ [Memecahkan masalah identitas dan akses MSK Amazon](security_iam_troubleshoot.md)
# Bagaimana Amazon MSK bekerja dengan IAM
Sebelum Anda menggunakan IAM untuk mengelola akses ke Amazon MSK, Anda harus memahami fitur IAM apa yang tersedia untuk digunakan dengan Amazon MSK. *Untuk mendapatkan tampilan tingkat tinggi tentang cara Amazon MSK dan AWS layanan lainnya bekerja dengan IAM, lihat [AWS Layanan yang Bekerja dengan IAM di Panduan Pengguna IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html).*
**Topics**
+ [Kebijakan berbasis identitas MSK Amazon](security_iam_service-with-iam-id-based-policies.md)
+ [Kebijakan berbasis sumber daya Amazon MSK](security_iam_service-with-iam-resource-based-policies.md)
+ [Otorisasi berdasarkan tag MSK Amazon](security_iam_service-with-iam-tags.md)
+ [Peran Amazon MSK IAM](security_iam_service-with-iam-roles.md)
# Kebijakan berbasis identitas MSK Amazon
Dengan kebijakan berbasis identitas IAM, Anda dapat menentukan secara spesifik apakah tindakan dan sumber daya diizinkan atau ditolak, serta kondisi yang menjadi dasar dikabulkan atau ditolaknya tindakan tersebut. Amazon MSK mendukung tindakan, sumber daya, dan kunci kondisi tertentu. Untuk mempelajari semua elemen yang Anda gunakan dalam kebijakan JSON, lihat [Referensi Elemen Kebijakan JSON IAM ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) dalam *Panduan Pengguna IAM*.
## Tindakan untuk kebijakan berbasis identitas MSK Amazon
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, di mana **utama** dapat melakukan **tindakan** pada **sumber daya**, dan dalam **kondisi apa**.
Elemen `Action` dari kebijakan JSON menjelaskan tindakan yang dapat Anda gunakan untuk mengizinkan atau menolak akses dalam sebuah kebijakan. Sertakan tindakan dalam kebijakan untuk memberikan izin untuk melakukan operasi terkait.
Tindakan kebijakan di Amazon MSK menggunakan awalan berikut sebelum tindakan:. `kafka:` Misalnya, untuk memberikan izin kepada seseorang untuk mendeskripsikan klaster MSK dengan operasi Amazon MSK `DescribeCluster` API, Anda menyertakan `kafka:DescribeCluster` tindakan tersebut dalam kebijakan mereka. Pernyataan kebijakan harus memuat elemen `Action` atau `NotAction`. Amazon MSK mendefinisikan serangkaian tindakannya sendiri yang menggambarkan tugas yang dapat Anda lakukan dengan layanan ini.
Harap dicatat, tindakan kebijakan untuk topik MSK APIs menggunakan `kafka-cluster` awalan sebelum tindakan, lihat. [Semantik tindakan dan sumber daya kebijakan otorisasi IAM](kafka-actions.md)
Untuk menetapkan beberapa tindakan dalam satu pernyataan, pisahkan dengan koma seperti berikut:
```
"Action": ["kafka:action1", "kafka:action2"]
```
Anda dapat menentukan beberapa tindakan menggunakan wildcard (\$1). Sebagai contoh, untuk menentukan semua tindakan yang dimulai dengan kata `Describe`, sertakan tindakan berikut:
```
"Action": "kafka:Describe*"
```
*Untuk melihat daftar tindakan MSK Amazon, lihat [Tindakan, sumber daya, dan kunci kondisi untuk Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) Kafka di Panduan Pengguna IAM.*
## Sumber daya untuk kebijakan berbasis identitas MSK Amazon
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, di mana **utama** dapat melakukan **tindakan** pada **sumber daya**, dan dalam **kondisi apa**.
Elemen kebijakan JSON `Resource` menentukan objek yang menjadi target penerapan tindakan. Praktik terbaiknya, tentukan sumber daya menggunakan [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Untuk tindakan yang tidak mendukung izin di tingkat sumber daya, gunakan wildcard (\$1) untuk menunjukkan bahwa pernyataan tersebut berlaku untuk semua sumber daya.
```
"Resource": "*"
```
Sumber daya instans MSK Amazon memiliki ARN berikut:
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Untuk informasi selengkapnya tentang format ARNs, lihat [Amazon Resource Names (ARNs) dan Ruang Nama AWS Layanan](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Misalnya, untuk menentukan instans `CustomerMessages` dalam pernyataan Anda, gunakan ARN berikut:
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Untuk menentukan semua instans milik akun tertentu, gunakan wildcard (\$1):
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Beberapa tindakan MSK Amazon, seperti untuk membuat sumber daya, tidak dapat dilakukan pada sumber daya tertentu. Dalam kasus tersebut, Anda harus menggunakan wildcard (\$1).
```
"Resource": "*"
```
Untuk menentukan beberapa sumber daya dalam satu pernyataan, pisahkan ARNs dengan koma.
```
"Resource": ["resource1", "resource2"]
```
*Untuk melihat daftar jenis sumber daya MSK Amazon dan jenisnya ARNs, lihat Sumber Daya yang [Ditentukan oleh Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) Kafka di Panduan Pengguna IAM.* Untuk mempelajari tindakan mana yang dapat Anda tentukan ARN dari setiap sumber daya, lihat [Tindakan yang Ditentukan oleh Amazon Managed Streaming for](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions) Apache Kafka.
## Kunci kondisi untuk kebijakan berbasis identitas MSK Amazon
Administrator dapat menggunakan kebijakan AWS JSON untuk menentukan siapa yang memiliki akses ke apa. Yaitu, **principal** dapat melakukan **tindakan** pada suatu **sumber daya**, dan dalam suatu **syarat**.
Elemen `Condition` menentukan ketika pernyataan dieksekusi berdasarkan kriteria yang ditetapkan. Anda dapat membuat ekspresi bersyarat yang menggunakan [operator kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), misalnya sama dengan atau kurang dari, untuk mencocokkan kondisi dalam kebijakan dengan nilai-nilai yang diminta. Untuk melihat semua kunci kondisi AWS global, lihat [kunci konteks kondisi AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) di *Panduan Pengguna IAM*.
Amazon MSK mendefinisikan rangkaian kunci kondisinya sendiri dan juga mendukung penggunaan beberapa kunci kondisi global. Untuk melihat semua kunci kondisi AWS global, lihat [Kunci Konteks Kondisi AWS Global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) di *Panduan Pengguna IAM*.
*Untuk melihat daftar kunci kondisi MSK Amazon, lihat Kunci Kondisi [untuk Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) Kafka di Panduan Pengguna IAM.* Untuk mempelajari tindakan dan sumber daya yang dapat Anda gunakan kunci kondisi, lihat [Tindakan yang Ditentukan oleh Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions) Kafka.
## Contoh untuk kebijakan berbasis identitas MSK Amazon
Untuk melihat contoh kebijakan berbasis identitas MSK Amazon, lihat. [Contoh kebijakan berbasis identitas MSK Amazon](security_iam_id-based-policy-examples.md)
# Kebijakan berbasis sumber daya Amazon MSK
Amazon MSK mendukung kebijakan klaster (juga dikenal sebagai kebijakan berbasis sumber daya) untuk digunakan dengan kluster MSK Amazon. Anda dapat menggunakan kebijakan klaster untuk menentukan prinsipal IAM mana yang memiliki izin lintas akun untuk menyiapkan konektivitas pribadi ke kluster MSK Amazon Anda. Saat digunakan dengan otentikasi klien IAM, Anda juga dapat menggunakan kebijakan klaster untuk secara terperinci menentukan izin bidang data Kafka untuk klien yang menghubungkan.
Ukuran maksimum yang didukung untuk kebijakan klaster adalah 20 KB.
Untuk melihat contoh cara mengonfigurasi kebijakan klaster, lihat[Langkah 2: Lampirkan kebijakan klaster ke klaster MSK](mvpc-cluster-owner-action-policy.md).
# Otorisasi berdasarkan tag MSK Amazon
Anda dapat melampirkan tag ke cluster MSK Amazon. Untuk mengendalikan akses berdasarkan tanda, berikan informasi tentang tanda di [elemen kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dari kebijakan menggunakan kunci kondisi `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name`, atau `aws:TagKeys`. Untuk informasi tentang menandai sumber daya MSK Amazon, lihat. [Menandai kluster MSK Amazon](msk-tagging.md)
Anda hanya dapat mengontrol akses cluster dengan bantuan tag. Untuk menandai topik dan grup konsumen, Anda perlu menambahkan pernyataan terpisah dalam kebijakan Anda tanpa tag.
Untuk melihat contoh kebijakan berbasis identitas untuk membatasi akses ke klaster berdasarkan tag pada klaster tersebut, lihat. [Mengakses kluster MSK Amazon berdasarkan tag](security_iam_id-based-policy-examples-view-widget-tags.md)
Anda dapat menggunakan kondisi dalam kebijakan berbasis identitas untuk mengontrol akses ke sumber daya MSK Amazon berdasarkan tag. Contoh berikut menunjukkan kebijakan yang memungkinkan pengguna untuk mendeskripsikan cluster, mendapatkan broker bootstrap, daftar node brokernya, memperbaruinya, dan menghapusnya. Namun, kebijakan ini hanya memberikan izin jika tag klaster `Owner` memiliki nilai pengguna tersebut. `username` Pernyataan kedua dalam kebijakan berikut memungkinkan akses ke topik di cluster. Pernyataan pertama dalam kebijakan ini tidak mengizinkan akses topik apa pun.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Peran Amazon MSK IAM
[IAM role](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) adalah entitas di dalam akun Amazon Web Services Anda yang memiliki izin khusus.
## Menggunakan kredensyal sementara dengan Amazon MSK
Anda dapat menggunakan kredensial sementara untuk masuk dengan gabungan, menjalankan IAM role, atau menjalankan peran lintas akun. Anda memperoleh kredensyal keamanan sementara dengan memanggil operasi AWS STS API seperti [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)atau. [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html)
Amazon MSK mendukung penggunaan kredensyal sementara.
## Peran terkait layanan
[Peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) memungkinkan Amazon Web Services mengakses sumber daya di layanan lain untuk menyelesaikan tindakan atas nama Anda. Peran tertaut layanan muncul di akun IAM Anda dan dimiliki oleh layanan tersebut. Administrator dapat melihat tetapi tidak dapat mengedit izin untuk peran yang terkait dengan layanan.
Amazon MSK mendukung peran terkait layanan. Untuk detail tentang membuat atau mengelola peran terkait layanan MSK Amazon,. [Peran terkait layanan untuk Amazon MSK](using-service-linked-roles.md)
# Contoh kebijakan berbasis identitas MSK Amazon
Secara default, pengguna dan peran IAM tidak memiliki izin untuk menjalankan tindakan Amazon MSK API. Administrator harus membuat kebijakan IAM yang memberikan izin kepada pengguna dan peran untuk melakukan operasi API tertentu pada sumber daya tertentu yang mereka butuhkan. Administrator kemudian harus melampirkan kebijakan tersebut ke pengguna IAM atau grup yang memerlukan izin tersebut.
Untuk mempelajari cara membuat kebijakan berbasis identitas IAM menggunakan contoh dokumen kebijakan JSON ini, lihat [Membuat Kebijakan pada Tab JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) dalam *Panduan Pengguna IAM*.
**Topics**
+ [Praktik terbaik kebijakan](security_iam_service-with-iam-policy-best-practices.md)
+ [Mengizinkan pengguna melihat izin mereka sendiri](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Mengakses satu cluster MSK Amazon](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Mengakses kluster MSK Amazon berdasarkan tag](security_iam_id-based-policy-examples-view-widget-tags.md)
# Praktik terbaik kebijakan
Kebijakan berbasis identitas menentukan apakah seseorang dapat membuat, mengakses, atau menghapus sumber daya MSK Amazon di akun Anda. Tindakan ini membuat Akun AWS Anda dikenai biaya. Ketika Anda membuat atau mengedit kebijakan berbasis identitas, ikuti panduan dan rekomendasi ini:
+ **Mulailah dengan kebijakan AWS terkelola dan beralih ke izin hak istimewa paling sedikit — Untuk mulai memberikan izin** kepada pengguna dan beban kerja Anda, gunakan *kebijakan AWS terkelola* yang memberikan izin untuk banyak kasus penggunaan umum. Mereka tersedia di Anda Akun AWS. Kami menyarankan Anda mengurangi izin lebih lanjut dengan menentukan kebijakan yang dikelola AWS pelanggan yang khusus untuk kasus penggunaan Anda. Untuk informasi selengkapnya, lihat [Kebijakan yang dikelola AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) atau [Kebijakan yang dikelola AWS untuk fungsi tugas](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) dalam *Panduan Pengguna IAM*.
+ **Menerapkan izin dengan hak akses paling rendah** – Ketika Anda menetapkan izin dengan kebijakan IAM, hanya berikan izin yang diperlukan untuk melakukan tugas. Anda melakukannya dengan mendefinisikan tindakan yang dapat diambil pada sumber daya tertentu dalam kondisi tertentu, yang juga dikenal sebagai *izin dengan hak akses paling rendah*. Untuk informasi selengkapnya tentang cara menggunakan IAM untuk mengajukan izin, lihat [Kebijakan dan izin dalam IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) dalam *Panduan Pengguna IAM*.
+ **Gunakan kondisi dalam kebijakan IAM untuk membatasi akses lebih lanjut** – Anda dapat menambahkan suatu kondisi ke kebijakan Anda untuk membatasi akses ke tindakan dan sumber daya. Sebagai contoh, Anda dapat menulis kondisi kebijakan untuk menentukan bahwa semua permintaan harus dikirim menggunakan SSL. Anda juga dapat menggunakan ketentuan untuk memberikan akses ke tindakan layanan jika digunakan melalui yang spesifik Layanan AWS, seperti CloudFormation. Untuk informasi selengkapnya, lihat [Elemen kebijakan JSON IAM: Kondisi](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dalam *Panduan Pengguna IAM*.
+ **Gunakan IAM Access Analyzer untuk memvalidasi kebijakan IAM Anda untuk memastikan izin yang aman dan fungsional** – IAM Access Analyzer memvalidasi kebijakan baru dan yang sudah ada sehingga kebijakan tersebut mematuhi bahasa kebijakan IAM (JSON) dan praktik terbaik IAM. IAM Access Analyzer menyediakan lebih dari 100 pemeriksaan kebijakan dan rekomendasi yang dapat ditindaklanjuti untuk membantu Anda membuat kebijakan yang aman dan fungsional. Untuk informasi selengkapnya, lihat [Validasi kebijakan dengan IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) dalam *Panduan Pengguna IAM*.
+ **Memerlukan otentikasi multi-faktor (MFA)** - Jika Anda memiliki skenario yang mengharuskan pengguna IAM atau pengguna root di Anda, Akun AWS aktifkan MFA untuk keamanan tambahan. Untuk meminta MFA ketika operasi API dipanggil, tambahkan kondisi MFA pada kebijakan Anda. Untuk informasi selengkapnya, lihat [Amankan akses API dengan MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) dalam *Panduan Pengguna IAM*.
Untuk informasi selengkapnya tentang praktik terbaik dalam IAM, lihat [Praktik terbaik keamanan di IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) dalam *Panduan Pengguna IAM*.
# Mengizinkan pengguna melihat izin mereka sendiri
Contoh ini menunjukkan cara membuat kebijakan yang mengizinkan pengguna IAM melihat kebijakan inline dan terkelola yang dilampirkan ke identitas pengguna mereka. Kebijakan ini mencakup izin untuk menyelesaikan tindakan ini di konsol atau menggunakan API atau secara terprogram. AWS CLI AWS
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Mengakses satu cluster MSK Amazon
Dalam contoh ini, Anda ingin memberikan pengguna IAM di akun Amazon Web Services Anda akses ke salah satu cluster Anda. `purchaseQueriesCluster` Kebijakan ini memungkinkan pengguna untuk mendeskripsikan cluster, mendapatkan broker bootstrap, daftar node brokernya, dan memperbaruinya.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# Mengakses kluster MSK Amazon berdasarkan tag
Anda dapat menggunakan kondisi dalam kebijakan berbasis identitas untuk mengontrol akses ke sumber daya MSK Amazon berdasarkan tag. Contoh ini menunjukkan bagaimana Anda dapat membuat kebijakan yang memungkinkan pengguna untuk mendeskripsikan cluster, mendapatkan broker bootstrap, daftar node brokernya, memperbaruinya, dan menghapusnya. Namun, izin diberikan hanya jika tag cluster `Owner` memiliki nilai nama pengguna pengguna tersebut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
Anda dapat melampirkan kebijakan ini ke pengguna IAM di akun Anda. Jika pengguna bernama `richard-roe` mencoba memperbarui kluster MSK, cluster harus diberi tag `Owner=richard-roe` atau. `owner=richard-roe` Jika tidak, aksesnya akan ditolak. Kunci tanda syarat `Owner` sama dengan kedua `Owner` dan `owner` karena nama kunci syarat tidak terpengaruh huruf besar/kecil. Untuk informasi lebih lanjut, lihat [Elemen Kebijakan IAM JSON: Persyaratan](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) dalam *Panduan Pengguna IAM*.
# Peran terkait layanan untuk Amazon MSK
Amazon MSK menggunakan peran terkait [layanan AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Peran terkait layanan adalah jenis peran IAM unik yang ditautkan langsung ke Amazon MSK. Peran terkait layanan telah ditentukan sebelumnya oleh Amazon MSK dan mencakup semua izin yang diperlukan layanan untuk memanggil layanan lain AWS atas nama Anda.
Peran terkait layanan membuat pengaturan Amazon MSK lebih mudah karena Anda tidak perlu menambahkan izin yang diperlukan secara manual. Amazon MSK mendefinisikan izin dari peran terkait layanannya. Kecuali ditentukan lain, hanya Amazon MSK yang dapat mengambil perannya. Izin yang ditentukan mencakup kebijakan kepercayaan dan kebijakan izin, serta bahwa kebijakan izin tidak dapat dilampirkan ke entitas IAM lainnya.
Untuk informasi tentang layanan lain yang mendukung peran terkait layanan, lihat [Amazon Web Services yang Bekerja dengan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html), dan cari layanan yang memiliki **Ya** di kolom Peran Tertaut **Layanan**. Pilih **Ya** dengan sebuah tautan untuk melihat dokumentasi peran terkait layanan untuk layanan tersebut.
**Topics**
+ [Izin peran terkait layanan](slr-permissions.md)
+ [Buat peran tertaut layanan](create-slr.md)
+ [Edit peran tertaut layanan](edit-slr.md)
+ [Wilayah yang didukung untuk peran yang terhubung dengan layanan](slr-regions.md)
# Izin peran terkait layanan untuk Amazon MSK
Amazon MSK menggunakan peran terkait layanan bernama. **AWSServiceRoleForKafka** Amazon MSK menggunakan peran ini untuk mengakses sumber daya Anda dan melakukan operasi seperti:
+ `*NetworkInterface`— membuat dan mengelola antarmuka jaringan di akun pelanggan yang membuat broker cluster dapat diakses oleh klien di VPC pelanggan.
+ `*VpcEndpoints`— mengelola titik akhir VPC di akun pelanggan yang membuat broker klaster dapat diakses oleh klien di VPC pelanggan yang menggunakan. AWS PrivateLink Amazon MSK menggunakan izin untuk`DescribeVpcEndpoints`, `ModifyVpcEndpoint` dan. `DeleteVpcEndpoints`
+ `secretsmanager`— kelola kredensyal klien dengan. AWS Secrets Manager
+ `GetCertificateAuthorityCertificate`— mengambil sertifikat untuk otoritas sertifikat pribadi Anda.
+ `*Ipv6Addresses`— menetapkan dan membatalkan penetapan IPv6 alamat ke antarmuka jaringan di akun pelanggan untuk mengaktifkan IPv6 konektivitas untuk kluster MSK.
+ `ModifyNetworkInterfaceAttribute`— memodifikasi atribut antarmuka jaringan di akun pelanggan untuk mengkonfigurasi IPv6 pengaturan untuk konektivitas cluster MSK.
Peran terkait layanan ini dilampirkan ke kebijakan terkelola berikut ini: `KafkaServiceRolePolicy`. Untuk pembaruan kebijakan ini, lihat [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
Peran tertaut layanan AWSServiceRoleForKafka memercayai layanan berikut untuk mengambil peran tersebut:
+ `kafka.amazonaws.com`
Kebijakan izin peran memungkinkan Amazon MSK menyelesaikan tindakan berikut pada sumber daya.
Anda harus mengonfigurasi izin untuk mengizinkan entitas IAM (seperti pengguna, grup, atau peran) untuk membuat, mengedit, atau menghapus peran terkait layanan. Untuk informasi selengkapnya, silakan lihat [Izin Peran Tertaut Layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) di *Panduan Pengguna IAM*.
# Membuat peran terkait layanan untuk Amazon MSK
Anda tidak perlu membuat peran terkait layanan secara manual. Saat Anda membuat klaster MSK Amazon di Konsol Manajemen AWS, API AWS CLI, atau AWS API, Amazon MSK membuat peran terkait layanan untuk Anda.
Jika Anda menghapus peran terkait layanan ini, dan ingin membuatnya lagi, Anda dapat mengulangi proses yang sama untuk membuat kembali peran tersebut di akun Anda. Saat Anda membuat kluster MSK Amazon, Amazon MSK membuat peran terkait layanan untuk Anda lagi.
# Mengedit peran terkait layanan untuk Amazon MSK
Amazon MSK tidak mengizinkan Anda mengedit peran AWSServiceRoleForKafka terkait layanan. Setelah membuat peran terkait layanan, Anda tidak dapat mengubah nama peran karena berbagai entitas mungkin merujuk peran tersebut. Namun, Anda dapat mengedit penjelasan peran menggunakan IAM. Untuk informasi selengkapnya, lihat [Mengedit Peran Tertaut Layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) dalam *Panduan Pengguna IAM*.
# Wilayah yang Didukung untuk peran terkait layanan MSK Amazon
Amazon MSK mendukung penggunaan peran terkait layanan di semua Wilayah tempat layanan tersedia. Untuk informasi selengkapnya, lihat [AWS Wilayah dan Titik Akhir](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS kebijakan terkelola untuk Amazon MSK
Kebijakan AWS terkelola adalah kebijakan mandiri yang dibuat dan dikelola oleh AWS. AWS Kebijakan terkelola dirancang untuk memberikan izin bagi banyak kasus penggunaan umum sehingga Anda dapat mulai menetapkan izin kepada pengguna, grup, dan peran.
Perlu diingat bahwa kebijakan AWS terkelola mungkin tidak memberikan izin hak istimewa paling sedikit untuk kasus penggunaan spesifik Anda karena tersedia untuk digunakan semua pelanggan. AWS Kami menyarankan Anda untuk mengurangi izin lebih lanjut dengan menentukan [kebijakan yang dikelola pelanggan](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) yang khusus untuk kasus penggunaan Anda.
Anda tidak dapat mengubah izin yang ditentukan dalam kebijakan AWS terkelola. Jika AWS memperbarui izin yang ditentukan dalam kebijakan AWS terkelola, pembaruan akan memengaruhi semua identitas utama (pengguna, grup, dan peran) yang dilampirkan kebijakan tersebut. AWS kemungkinan besar akan memperbarui kebijakan AWS terkelola saat baru Layanan AWS diluncurkan atau operasi API baru tersedia untuk layanan yang ada.
Untuk informasi selengkapnya, lihat [Kebijakan terkelola AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) dalam *Panduan Pengguna IAM*.
# AWS kebijakan terkelola: MSKFull Akses Amazon
Kebijakan ini memberikan izin administratif yang memungkinkan akses penuh utama ke semua tindakan MSK Amazon. Izin dalam kebijakan ini dikelompokkan sebagai berikut:
+ Izin MSK Amazon memungkinkan semua tindakan MSK Amazon.
+ **`Amazon EC2`izin** — dalam kebijakan ini diperlukan untuk memvalidasi sumber daya yang diteruskan dalam permintaan API. Ini untuk memastikan Amazon MSK dapat berhasil menggunakan sumber daya dengan cluster. Izin Amazon EC2 lainnya dalam kebijakan ini memungkinkan Amazon MSK membuat AWS sumber daya yang diperlukan untuk memungkinkan Anda terhubung ke cluster Anda.
+ **`AWS KMS`izin** - digunakan selama panggilan API untuk memvalidasi sumber daya yang diteruskan dalam permintaan. Mereka diperlukan untuk Amazon MSK untuk dapat menggunakan kunci yang diteruskan dengan cluster MSK Amazon.
+ **`CloudWatch Logs, Amazon S3, and Amazon Data Firehose`izin** - diperlukan untuk Amazon MSK untuk dapat memastikan bahwa tujuan pengiriman log dapat dijangkau, dan valid untuk penggunaan log broker.
+ **`IAM`izin** - diperlukan agar Amazon MSK dapat membuat peran terkait layanan di akun Anda dan memungkinkan Anda meneruskan peran eksekusi layanan ke Amazon MSK.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS kebijakan terkelola: Amazon MSKRead OnlyAccess
Kebijakan ini memberikan izin hanya-baca yang memungkinkan pengguna melihat informasi di Amazon MSK. Prinsipal dengan kebijakan ini terlampir tidak dapat membuat pembaruan atau menghapus sumber daya yang keluar, juga tidak dapat membuat sumber daya MSK Amazon baru. Misalnya, prinsipal dengan izin ini dapat melihat daftar cluster dan konfigurasi yang terkait dengan akun mereka, tetapi tidak dapat mengubah konfigurasi atau pengaturan cluster apa pun. Izin dalam kebijakan ini dikelompokkan sebagai berikut:
+ **`Amazon MSK`izin** - memungkinkan Anda mencantumkan sumber daya MSK Amazon, menjelaskannya, dan mendapatkan informasi tentangnya.
+ **`Amazon EC2`izin** - digunakan untuk menggambarkan VPC Amazon, subnet, grup keamanan, ENIs dan yang terkait dengan kluster.
+ **`AWS KMS`izin** — digunakan untuk menggambarkan kunci yang terkait dengan cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS kebijakan terkelola: KafkaServiceRolePolicy
Anda tidak dapat melampirkan KafkaServiceRolePolicy ke entitas IAM Anda. Kebijakan ini dilampirkan ke peran terkait layanan yang memungkinkan Amazon MSK melakukan tindakan seperti mengelola titik akhir (konektor) VPC pada kluster MSK, mengelola antarmuka jaringan, dan mengelola kredensyal klaster. AWS Secrets Manager Untuk informasi selengkapnya, lihat [Peran terkait layanan untuk Amazon MSK](using-service-linked-roles.md).
Tabel berikut menjelaskan pembaruan pada kebijakan KafkaServiceRolePolicy terkelola sejak Amazon MSK mulai melacak perubahan.
| Ubah | Deskripsi | Date |
| --- | --- | --- |
| [IPv6 dukungan konektivitas ditambahkan ke KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — Perbarui ke kebijakan yang ada | Amazon MSK menambahkan izin untuk mengaktifkan IPv6 konektivitas KafkaServiceRolePolicy untuk kluster MSK. Izin ini memungkinkan Amazon MSK untuk menetapkan dan membatalkan penetapan IPv6 alamat ke antarmuka jaringan dan memodifikasi atribut antarmuka jaringan di akun pelanggan. | November 17, 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) – Pembaruan ke kebijakan yang ada | Amazon MSK menambahkan izin untuk mendukung konektivitas pribadi multi-VPC. | 8 Maret 2023 |
| Amazon MSK mulai melacak perubahan | Amazon MSK mulai melacak perubahan untuk kebijakan KafkaServiceRolePolicy terkelola. | 8 Maret 2023 |
# AWS kebijakan terkelola: AWSMSKReplicator ExecutionRole
`AWSMSKReplicatorExecutionRole`Kebijakan ini memberikan izin kepada replikator MSK Amazon untuk mereplikasi data antar kluster MSK. Izin dalam kebijakan ini dikelompokkan sebagai berikut:
+ **`cluster`**— Memberikan izin Amazon MSK Replicator untuk terhubung ke cluster menggunakan otentikasi IAM. Juga memberikan izin untuk mendeskripsikan dan mengubah cluster.
+ **`topic`**— Memberikan izin Amazon MSK Replicator untuk mendeskripsikan, membuat, dan mengubah topik, dan untuk mengubah konfigurasi dinamis topik.
+ **`consumer group`**— Memberikan izin Amazon MSK Replicator untuk mendeskripsikan dan mengubah grup konsumen, membaca dan menulis tanggal dari kluster MSK, dan untuk menghapus topik internal yang dibuat oleh replikator.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# Amazon MSK memperbarui kebijakan AWS terkelola
Lihat detail tentang pembaruan kebijakan AWS terkelola untuk Amazon MSK sejak layanan ini mulai melacak perubahan ini.
| Ubah | Deskripsi | Date |
| --- | --- | --- |
| [WriteDataIdempotently izin ditambahkan ke AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) - Perbarui ke kebijakan yang ada | Amazon MSK menambahkan WriteDataIdempotently izin ke AWSMSKReplicator ExecutionRole kebijakan untuk mendukung replikasi data antara kluster MSK. | Maret 12, 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) – Kebijakan baru | Amazon MSK menambahkan AWSMSKReplicator ExecutionRole kebijakan untuk mendukung Amazon MSK Replicator. | Desember 4, 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) - Perbarui ke kebijakan yang ada | Amazon MSK menambahkan izin untuk mendukung Amazon MSK Replicator. | 28 September 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) – Pembaruan ke kebijakan yang ada | Amazon MSK menambahkan izin untuk mendukung konektivitas pribadi multi-VPC. | 8 Maret 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) - Perbarui ke kebijakan yang ada | Amazon MSK menambahkan izin Amazon EC2 baru untuk memungkinkan untuk terhubung ke cluster. | 30 November 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) - Perbarui ke kebijakan yang ada | Amazon MSK menambahkan izin baru untuk memungkinkannya menggambarkan tabel rute Amazon EC2. | November 19, 2021 |
| Amazon MSK mulai melacak perubahan | Amazon MSK mulai melacak perubahan untuk kebijakan yang AWS dikelola. | November 19, 2021 |
# Memecahkan masalah identitas dan akses MSK Amazon
Gunakan informasi berikut untuk membantu Anda mendiagnosis dan memperbaiki masalah umum yang mungkin Anda temui saat bekerja dengan Amazon MSK dan IAM.
**Topics**
+ [Saya tidak berwenang untuk melakukan tindakan di Amazon MSK](#security_iam_troubleshoot-no-permissions)
## Saya tidak berwenang untuk melakukan tindakan di Amazon MSK
Jika Konsol Manajemen AWS memberitahu Anda bahwa Anda tidak berwenang untuk melakukan tindakan, maka Anda harus menghubungi administrator Anda untuk bantuan. Administrator Anda adalah orang yang memberi Anda kredensial masuk.
Contoh kesalahan berikut terjadi ketika pengguna `mateojackson` IAM mencoba menggunakan konsol untuk menghapus cluster tetapi tidak memiliki `kafka:DeleteCluster` izin.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
Dalam hal ini, Mateo meminta administratornya untuk memperbarui kebijakannya untuk mengizinkan dia mengakses sumber daya `purchaseQueriesCluster` menggunakan tindakan `kafka:DeleteCluster`.
# Otentikasi dan otorisasi untuk Apache Kafka APIs
Anda dapat menggunakan IAM untuk mengautentikasi klien dan mengizinkan atau menolak tindakan Apache Kafka. Atau, Anda dapat menggunakan TLS atau SASL/SCRAM untuk mengautentikasi klien, dan Apache Kafka ACLs untuk mengizinkan atau menolak tindakan.
Untuk informasi tentang cara mengontrol siapa yang dapat melakukan [operasi MSK Amazon](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) di klaster Anda, lihat[Otentikasi dan otorisasi untuk Amazon MSK APIs](security-iam.md).
**Topics**
+ [Kontrol akses IAM](iam-access-control.md)
+ [Otentikasi klien TLS timbal balik untuk Amazon MSK](msk-authentication.md)
+ [Otentikasi kredensyal masuk dengan Secrets Manager AWS](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# Kontrol akses IAM
Kontrol akses IAM untuk Amazon MSK memungkinkan Anda menangani otentikasi dan otorisasi untuk klaster MSK Anda. Ini menghilangkan kebutuhan untuk menggunakan satu mekanisme untuk otentikasi dan satu lagi untuk otorisasi. Misalnya, ketika klien mencoba menulis ke klaster Anda, Amazon MSK menggunakan IAM untuk memeriksa apakah klien tersebut adalah identitas yang diautentikasi dan juga apakah itu berwenang untuk diproduksi ke cluster Anda.
Kontrol akses IAM berfungsi untuk klien Java dan non-Java, termasuk klien Kafka yang ditulis dengan Python, Go, dan .NET. JavaScript Kontrol akses IAM untuk klien non-Java tersedia untuk kluster MSK dengan Kafka versi 2.7.1 atau lebih tinggi.
Untuk memungkinkan kontrol akses IAM, Amazon MSK membuat modifikasi kecil pada kode sumber Apache Kafka. Modifikasi ini tidak akan menyebabkan perbedaan nyata dalam pengalaman Apache Kafka Anda. Amazon MSK mencatat peristiwa akses sehingga Anda dapat mengaudit mereka.
Anda dapat memanggil Apache Kafka ACL APIs untuk cluster MSK yang menggunakan kontrol akses IAM. Namun, Apache Kafka tidak ACLs berpengaruh pada otorisasi untuk identitas IAM. Anda harus menggunakan kebijakan IAM untuk mengontrol akses identitas IAM.
**Pertimbangan penting**
Saat Anda menggunakan kontrol akses IAM dengan kluster MSK Anda, ingatlah pertimbangan penting berikut:
Kontrol akses IAM tidak berlaku untuk node Apache ZooKeeper . Untuk informasi tentang bagaimana Anda dapat mengontrol akses ke node tersebut, lihat[Kontrol akses ke ZooKeeper node Apache di kluster MSK Amazon Anda](zookeeper-security.md).
Pengaturan `allow.everyone.if.no.acl.found` Apache Kafka tidak berpengaruh jika cluster Anda menggunakan kontrol akses IAM.
Anda dapat memanggil Apache Kafka ACL APIs untuk cluster MSK yang menggunakan kontrol akses IAM. Namun, Apache Kafka tidak ACLs berpengaruh pada otorisasi untuk identitas IAM. Anda harus menggunakan kebijakan IAM untuk mengontrol akses identitas IAM.
# Cara kerja kontrol akses IAM untuk Amazon MSK
Untuk menggunakan kontrol akses IAM untuk Amazon MSK, lakukan langkah-langkah berikut, yang dijelaskan secara rinci dalam topik ini:
+ [Buat kluster MSK Amazon yang menggunakan kontrol akses IAM](create-iam-access-control-cluster-in-console.md)
+ [Konfigurasikan klien untuk kontrol akses IAM](configure-clients-for-iam-access-control.md)
+ [Buat kebijakan otorisasi untuk peran IAM](create-iam-access-control-policies.md)
+ [Dapatkan broker bootstrap untuk kontrol akses IAM](get-bootstrap-brokers-for-iam.md)
# Buat kluster MSK Amazon yang menggunakan kontrol akses IAM
Bagian ini menjelaskan bagaimana Anda dapat menggunakan Konsol Manajemen AWS, API, atau AWS CLI untuk membuat klaster MSK Amazon yang menggunakan kontrol akses IAM. Untuk informasi tentang cara mengaktifkan kontrol akses IAM untuk klaster yang ada, lihat[Perbarui pengaturan keamanan kluster MSK Amazon](msk-update-security.md).
**Gunakan Konsol Manajemen AWS untuk membuat cluster yang menggunakan kontrol akses IAM**
1. Buka konsol MSK Amazon di[https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Pilih **Buat klaster**.
1. Pilih **Buat cluster dengan pengaturan khusus**.
1. Di bagian **Otentikasi**, pilih kontrol **akses IAM**.
1. Selesaikan sisa alur kerja untuk membuat cluster.
**Menggunakan API atau AWS CLI untuk membuat klaster yang menggunakan kontrol akses IAM**
+ Untuk membuat cluster dengan kontrol akses IAM diaktifkan, gunakan [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API atau perintah CLI [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html), dan teruskan JSON berikut untuk parameter:. `ClientAuthentication` `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Konfigurasikan klien untuk kontrol akses IAM
Untuk memungkinkan klien berkomunikasi dengan kluster MSK yang menggunakan kontrol akses IAM, Anda dapat menggunakan salah satu dari mekanisme ini:
+ Konfigurasi klien non-Java menggunakan mekanisme SASL\$1OAUTHBEARER
+ Konfigurasi klien Java menggunakan SASL\$1OAUTHBEARER mekanisme atau AWS\$1MSK\$1IAM mekanisme
## Gunakan SASL\$1OAUTHBEARER mekanisme untuk mengkonfigurasi IAM
1. Edit file konfigurasi client.properties Anda menggunakan contoh klien Python Kafka berikut. Perubahan konfigurasi serupa dalam bahasa lain.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. Unduh pustaka pembantu untuk bahasa konfigurasi yang Anda pilih dan ikuti petunjuk di bagian *Memulai* di beranda perpustakaan bahasa tersebut.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js \$1getting -dimulai](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started)
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python \$1get -dimulai](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started)
+ Go: [https://github.com/aws/aws-msk-iam-sasl-signer-go](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started) \$1getting -started
+ .NET: [https://github.com/aws/aws-msk-iam-sasl-signer-net](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started) \$1getting -dimulai
+ JAVA: SASL\$1OAUTHBEARER dukungan untuk Java tersedia melalui file [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)jar
## Gunakan AWS\$1MSK\$1IAM mekanisme kustom MSK untuk mengkonfigurasi IAM
1. Tambahkan yang berikut ini ke `client.properties` file. Ganti ** dengan jalur yang sepenuhnya memenuhi syarat ke file trust store pada klien.
**catatan**
Jika Anda tidak ingin menggunakan sertifikat tertentu, Anda dapat menghapus `ssl.truststore.location=` dari `client.properties` file Anda. Bila Anda tidak menentukan nilai untuk`ssl.truststore.location`, proses Java menggunakan sertifikat default.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
Untuk menggunakan profil bernama yang Anda buat untuk AWS kredensyal, sertakan `awsProfileName="your profile name";` dalam file konfigurasi klien Anda. Untuk informasi tentang profil bernama, lihat [Profil bernama](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) dalam AWS CLI dokumentasi.
1. Unduh file [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR stabil terbaru, dan letakkan di jalur kelas. Jika Anda menggunakan Maven, tambahkan dependensi berikut, sesuaikan nomor versi sesuai kebutuhan:
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
Plugin klien MSK Amazon bersumber terbuka di bawah lisensi Apache 2.0.
# Buat kebijakan otorisasi untuk peran IAM
Lampirkan kebijakan otorisasi ke peran IAM yang sesuai dengan klien. Dalam kebijakan otorisasi, Anda menentukan tindakan mana yang akan diizinkan atau ditolak untuk peran tersebut. Jika klien Anda menggunakan instans Amazon EC2, kaitkan kebijakan otorisasi dengan peran IAM untuk instans Amazon EC2 tersebut. Atau, Anda dapat mengonfigurasi klien Anda untuk menggunakan profil bernama, dan kemudian Anda mengaitkan kebijakan otorisasi dengan peran untuk profil bernama tersebut. [Konfigurasikan klien untuk kontrol akses IAM](configure-clients-for-iam-access-control.md)menjelaskan cara mengkonfigurasi klien untuk menggunakan profil bernama.
Untuk informasi tentang cara membuat kebijakan IAM, lihat [Membuat kebijakan IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Berikut ini adalah contoh kebijakan otorisasi untuk cluster bernama MyTestCluster. Untuk memahami semantik `Action` dan `Resource` elemen, lihat. [Semantik tindakan dan sumber daya kebijakan otorisasi IAM](kafka-actions.md)
**penting**
Perubahan yang Anda buat pada kebijakan IAM tercermin dalam IAM APIs dan segera. AWS CLI Namun, perlu waktu yang nyata agar perubahan kebijakan berlaku. Dalam kebanyakan kasus, perubahan kebijakan berlaku dalam waktu kurang dari satu menit. Kondisi jaringan terkadang dapat meningkatkan penundaan.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
Untuk mempelajari cara membuat kebijakan dengan elemen tindakan yang sesuai dengan kasus penggunaan Apache Kafka yang umum, seperti memproduksi dan mengkonsumsi data, lihat. [Kasus penggunaan umum untuk kebijakan otorisasi klien](iam-access-control-use-cases.md)
[Untuk Kafka versi 2.8.0 dan di atasnya, **WriteDataIdempotently**izin tidak digunakan lagi (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) Secara default, `enable.idempotence = true` diatur. Oleh karena itu, untuk Kafka versi 2.8.0 ke atas, IAM tidak menawarkan fungsionalitas yang sama dengan Kafka. ACLs Tidak mungkin `WriteDataIdempotently` untuk topik dengan hanya menyediakan `WriteData` akses ke topik itu. Ini tidak mempengaruhi kasus ketika `WriteData` disediakan untuk **SEMUA** topik. Dalam hal ini, `WriteDataIdempotently` diperbolehkan. Hal ini disebabkan perbedaan dalam implementasi logika IAM dan bagaimana Kafka ACLs diimplementasikan. Selain itu, menulis ke topik idempotently juga membutuhkan akses ke. `transactional-ids`
Untuk mengatasi hal ini, sebaiknya gunakan kebijakan yang serupa dengan kebijakan berikut.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
Dalam hal ini, `WriteData` memungkinkan menulis ke`TestTopic`, sementara `WriteDataIdempotently` memungkinkan penulisan idempoten ke cluster. Kebijakan ini juga menambahkan akses ke `transactional-id` sumber daya yang akan dibutuhkan.
Karena `WriteDataIdempotently` merupakan izin tingkat cluster, Anda tidak dapat menggunakannya di tingkat topik. Jika `WriteDataIdempotently` dibatasi pada tingkat topik, kebijakan ini tidak akan berfungsi.
# Dapatkan broker bootstrap untuk kontrol akses IAM
Lihat [Dapatkan broker bootstrap untuk cluster MSK Amazon](msk-get-bootstrap-brokers.md).
# Semantik tindakan dan sumber daya kebijakan otorisasi IAM
**catatan**
Untuk cluster yang menjalankan Apache Kafka versi 3.8 atau yang lebih baru, kontrol akses IAM mendukung API untuk mengakhiri transaksi. WriteTxnMarkers Untuk cluster yang menjalankan versi Kafka lebih awal dari 3.8, kontrol akses IAM tidak mendukung tindakan klaster internal termasuk. WriteTxnMarkers Untuk versi sebelumnya, untuk mengakhiri transaksi, gunakan otentikasi SCRAM atau mTLS dengan tepat, ACLs bukan autentikasi IAM.
Bagian ini menjelaskan semantik elemen tindakan dan sumber daya yang dapat Anda gunakan dalam kebijakan otorisasi IAM. Untuk contoh kebijakan, lihat [Buat kebijakan otorisasi untuk peran IAM](create-iam-access-control-policies.md).
## Tindakan kebijakan otorisasi
Tabel berikut mencantumkan tindakan yang dapat Anda sertakan dalam kebijakan otorisasi saat Anda menggunakan kontrol akses IAM untuk Amazon MSK. Bila Anda menyertakan dalam kebijakan otorisasi tindakan dari kolom *Tindakan* tabel, Anda juga harus menyertakan tindakan terkait dari kolom *Tindakan yang diperlukan*.
| Tindakan | Deskripsi | Tindakan yang diperlukan | Sumber daya yang dibutuhkan | Berlaku untuk cluster tanpa server |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Memberikan izin untuk menghubungkan dan mengautentikasi ke cluster. | Tidak ada | cluster | Ya |
| kafka-cluster:DescribeCluster | Memberikan izin untuk mendeskripsikan berbagai aspek cluster, setara dengan DESCRIPTION CLUSTER ACL Apache Kafka. | `kafka-cluster:Connect` | cluster | Ya |
| kafka-cluster:AlterCluster | Memberikan izin untuk mengubah berbagai aspek cluster, setara dengan ALTER CLUSTER ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | klaster | Tidak |
| kafka-cluster:DescribeClusterDynamicConfiguration | Memberikan izin untuk mendeskripsikan konfigurasi dinamis cluster, setara dengan APache Kafka DESCRIBE\$1CONFIGS CLUSTER ACL. | `kafka-cluster:Connect` | klaster | Tidak |
| kafka-cluster:AlterClusterDynamicConfiguration | Memberikan izin untuk mengubah konfigurasi dinamis cluster, setara dengan ALTER\$1CONFIGS CLUSTER ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | klaster | Tidak |
| kafka-cluster:WriteDataIdempotently | Memberikan izin untuk menulis data idempotently pada cluster, setara dengan Apache Kafka IDEMPOTENT\$1WRITE CLUSTER ACL. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | cluster | Ya |
| kafka-cluster:CreateTopic | Memberikan izin untuk membuat topik di cluster, setara dengan CREATE ACL Apache Kafka. CLUSTER/TOPIC | `kafka-cluster:Connect` | topik | Ya |
| kafka-cluster:DescribeTopic | Memberikan izin untuk mendeskripsikan topik di cluster, setara dengan APache Kafka's DESCRIPTE TOPIC ACL. | `kafka-cluster:Connect` | topik | Ya |
| kafka-cluster:AlterTopic | Memberikan izin untuk mengubah topik di klaster, setara dengan ALTER TOPIC ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topik | Ya |
| kafka-cluster:DeleteTopic | Memberikan izin untuk menghapus topik di klaster, setara dengan DELETE TOPIC ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topik | Ya |
| kafka-cluster:DescribeTopicDynamicConfiguration | Memberikan izin untuk mendeskripsikan konfigurasi dinamis topik pada klaster, setara dengan DESCRIBE\$1CONFIGS TOPIC ACL Apache Kafka. | `kafka-cluster:Connect` | topik | Ya |
| kafka-cluster:AlterTopicDynamicConfiguration | Memberikan izin untuk mengubah konfigurasi dinamis topik pada klaster, setara dengan ALTER\$1CONFIGS TOPIC ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | topik | Ya |
| kafka-cluster:ReadData | Memberikan izin untuk membaca data dari topik di cluster, setara dengan READ TOPIC ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | topik | Ya |
| kafka-cluster:WriteData | Memberikan izin untuk menulis data ke topik di cluster, setara dengan WRITE TOPIC ACL Apache Kafka | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | topik | Ya |
| kafka-cluster:DescribeGroup | Memberikan izin untuk mendeskripsikan grup pada sebuah cluster, setara dengan Apache Kafka's DESCRIPTE GROUP ACL. | `kafka-cluster:Connect` | grup | Ya |
| kafka-cluster:AlterGroup | Memberikan izin untuk bergabung dengan grup di cluster, setara dengan READ GROUP ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | grup | Ya |
| kafka-cluster:DeleteGroup | Memberikan izin untuk menghapus grup di cluster, setara dengan DELETE GROUP ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | grup | Ya |
| kafka-cluster:DescribeTransactionalId | Memberikan izin untuk mendeskripsikan transaksional IDs pada klaster, setara dengan DESCRIBE TRANSACTIONAL\$1ID ACL Apache Kafka. | `kafka-cluster:Connect` | transaksional-id | Ya |
| kafka-cluster:AlterTransactionalId | Memberikan izin untuk mengubah transaksional IDs pada cluster, setara dengan WRITE TRANSACTIONAL\$1ID ACL Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transaksional-id | Ya |
Anda dapat menggunakan wildcard asterisk (\$1) beberapa kali dalam tindakan setelah titik dua. Berikut ini adalah beberapa contohnya.
+ `kafka-cluster:*Topic`singkatan dari`kafka-cluster:CreateTopic`,`kafka-cluster:DescribeTopic`,`kafka-cluster:AlterTopic`, dan`kafka-cluster:DeleteTopic`. Itu tidak termasuk `kafka-cluster:DescribeTopicDynamicConfiguration` atau`kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*`singkatan dari semua izin.
## Sumber daya kebijakan otorisasi
Tabel berikut menunjukkan empat jenis sumber daya yang dapat Anda gunakan dalam kebijakan otorisasi saat Anda menggunakan kontrol akses IAM untuk Amazon MSK. Anda bisa mendapatkan klaster Amazon Resource Name (ARN) dari Konsol Manajemen AWS atau dengan menggunakan [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API atau perintah [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Anda kemudian dapat menggunakan ARN cluster untuk membangun topik, grup, dan ID transaksional. ARNs Untuk menentukan sumber daya dalam kebijakan otorisasi, gunakan ARN sumber daya tersebut.
| Sumber daya | Format ARN |
| --- | --- |
| Kluster | arn:aws:kafka: ::cluster//regionaccount-idcluster-namecluster-uuid |
| Topik | arn:aws:kafka: ::topik///regionaccount-idcluster-namecluster-uuidtopic-name |
| Kelompok | arn:aws:kafka: ::grup///regionaccount-idcluster-namecluster-uuidgroup-name |
| ID Transaksional | arn:aws:kafka: ::transactional-id//regionaccount-idcluster-namecluster-uuidtransactional-id |
Anda dapat menggunakan wildcard asterisk (\$1) beberapa kali di mana saja di bagian ARN yang muncul setelah`:cluster/`,,, `:topic/` dan. `:group/` `:transactional-id/` Berikut ini adalah beberapa contoh bagaimana Anda dapat menggunakan wildcard asterisk (\$1) untuk merujuk ke beberapa sumber daya:
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: semua topik di cluster mana pun bernama MyTestCluster, terlepas dari UUID cluster.
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: semua topik yang namanya diakhiri dengan “\$1test” di cluster yang namanya MyTestCluster dan UUIDnya abcd1234-0123-abcd-5678-1234abcd-1.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: semua transaksi yang ID transaksionalnya adalah 5555abcd-1111-abcd-1234-abcd1234-1, di semua inkarnasi klaster yang disebutkan di akun Anda. MyTestCluster Ini berarti bahwa jika Anda membuat klaster bernama MyTestCluster, lalu menghapusnya, dan kemudian membuat cluster lain dengan nama yang sama, Anda dapat menggunakan ARN sumber daya ini untuk mewakili ID transaksi yang sama pada kedua cluster. Namun, cluster yang dihapus tidak dapat diakses.
# Kasus penggunaan umum untuk kebijakan otorisasi klien
Kolom pertama dalam tabel berikut menunjukkan beberapa kasus penggunaan umum. Untuk mengotorisasi klien untuk melaksanakan kasus penggunaan tertentu, sertakan tindakan yang diperlukan untuk kasus penggunaan tersebut dalam kebijakan otorisasi klien, dan atur `Effect` ke. `Allow`
Untuk informasi tentang semua tindakan yang merupakan bagian dari kontrol akses IAM untuk Amazon MSK, lihat. [Semantik tindakan dan sumber daya kebijakan otorisasi IAM](kafka-actions.md)
**catatan**
Tindakan ditolak secara default. Anda harus secara eksplisit mengizinkan setiap tindakan yang ingin Anda berikan otorisasi kepada klien untuk dilakukan.
****
| Kasus penggunaan | Tindakan yang diperlukan |
| --- | --- |
| Admin | `kafka-cluster:*` |
| Buat topik | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Menghasilkan data | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Konsumsi data | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Menghasilkan data secara idempotently | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Menghasilkan data secara transaksional | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Jelaskan konfigurasi cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Perbarui konfigurasi cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Jelaskan konfigurasi suatu topik | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Perbarui konfigurasi topik | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Mengubah topik | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Otentikasi klien TLS timbal balik untuk Amazon MSK
Anda dapat mengaktifkan otentikasi klien dengan TLS untuk koneksi dari aplikasi Anda ke broker MSK Amazon Anda. Untuk menggunakan otentikasi klien, Anda memerlukan file AWS Private CA. AWS Private CA Bisa sama dengan cluster Anda Akun AWS , atau di akun yang berbeda. Untuk informasi tentang AWS Private CA s, lihat [Membuat dan Mengelola a AWS Private CA](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
Amazon MSK tidak mendukung daftar pencabutan sertifikat (). CRLs Untuk mengontrol akses ke topik klaster Anda atau memblokir sertifikat yang disusupi, gunakan Apache Kafka ACLs dan AWS grup keamanan. Untuk informasi tentang menggunakan Apache Kafka ACLs, lihat. [Apache Kafka ACLs](msk-acls.md)
**Topics**
+ [Buat kluster MSK Amazon yang mendukung otentikasi klien](msk-authentication-cluster.md)
+ [Siapkan klien untuk menggunakan otentikasi](msk-authentication-client.md)
+ [Menghasilkan dan mengkonsumsi pesan menggunakan otentikasi](msk-authentication-messages.md)
# Buat kluster MSK Amazon yang mendukung otentikasi klien
Prosedur ini menunjukkan kepada Anda cara mengaktifkan otentikasi klien menggunakan file. AWS Private CA
**catatan**
Kami sangat merekomendasikan penggunaan independen AWS Private CA untuk setiap cluster MSK ketika Anda menggunakan TLS timbal balik untuk mengontrol akses. Melakukannya akan memastikan bahwa sertifikat TLS yang ditandatangani PCAs hanya dengan mengautentikasi dengan satu kluster MSK.
1. Buat file bernama `clientauthinfo.json` dengan isi berikut ini. Ganti *Private-CA-ARN* dengan ARN PCA Anda.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Buat file bernama `brokernodegroupinfo.json` seperti yang dijelaskan dalam[Buat klaster MSK Amazon yang disediakan menggunakan AWS CLI](create-cluster-cli.md).
1. Otentikasi klien mengharuskan Anda juga mengaktifkan enkripsi dalam perjalanan antara klien dan broker. Buat file bernama `encryptioninfo.json` dengan isi berikut ini. Ganti *KMS-Key-ARN* dengan ARN kunci KMS Anda. Anda dapat mengatur `ClientBroker` ke `TLS` atau`TLS_PLAINTEXT`.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Untuk informasi selengkapnya tentang enkripsi, lihat[Enkripsi Amazon MSK](msk-encryption.md).
1. Pada mesin tempat Anda AWS CLI menginstal, jalankan perintah berikut untuk membuat cluster dengan otentikasi dan enkripsi dalam transit diaktifkan. Simpan ARN cluster yang disediakan dalam tanggapan.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# Siapkan klien untuk menggunakan otentikasi
Proses ini menjelaskan cara menyiapkan instans Amazon EC2 untuk digunakan sebagai klien untuk menggunakan otentikasi.
Proses ini menjelaskan cara menghasilkan dan menggunakan pesan menggunakan otentikasi dengan membuat mesin klien, membuat topik, dan mengonfigurasi pengaturan keamanan yang diperlukan.
1. Buat instans Amazon EC2 untuk digunakan sebagai mesin klien. Untuk mempermudah, buat instance ini di VPC yang sama yang Anda gunakan untuk cluster. Lihat [Langkah 3: Buat mesin klien](create-client-machine.md) contoh cara membuat mesin klien seperti itu.
1. Buat topik. Sebagai contoh, lihat instruksi di bawah[Langkah 4: Buat topik di cluster MSK Amazon](create-topic.md).
1. Pada mesin tempat Anda AWS CLI menginstal, jalankan perintah berikut untuk mendapatkan broker bootstrap dari cluster. Ganti *Cluster-ARN* dengan ARN cluster Anda.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Simpan string yang terkait `BootstrapBrokerStringTls` dengan respons.
1. Pada mesin klien Anda, jalankan perintah berikut untuk menggunakan toko kepercayaan JVM untuk membuat toko kepercayaan klien Anda. Jika jalur JVM Anda berbeda, sesuaikan perintahnya.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. Pada mesin klien Anda, jalankan perintah berikut untuk membuat kunci pribadi untuk klien Anda. Ganti *Distinguished-Name**Example-Alias*,*Your-Store-Pass*,, dan *Your-Key-Pass* dengan string pilihan Anda.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. Pada mesin klien Anda, jalankan perintah berikut untuk membuat permintaan sertifikat dengan kunci pribadi yang Anda buat pada langkah sebelumnya.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Buka `client-cert-sign-request` file dan pastikan bahwa itu dimulai dengan `-----BEGIN CERTIFICATE REQUEST-----` dan diakhiri dengan`-----END CERTIFICATE REQUEST-----`. Jika dimulai dengan`-----BEGIN NEW CERTIFICATE REQUEST-----`, hapus kata `NEW` (dan spasi tunggal yang mengikutinya) dari awal dan akhir file.
1. Pada mesin tempat Anda AWS CLI menginstal, jalankan perintah berikut untuk menandatangani permintaan sertifikat Anda. Ganti *Private-CA-ARN* dengan ARN PCA Anda. Anda dapat mengubah nilai validitas jika Anda mau. Di sini kita menggunakan 300 sebagai contoh.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
Simpan sertifikat ARN yang disediakan dalam tanggapan.
**catatan**
Untuk mengambil sertifikat klien Anda, gunakan `acm-pca get-certificate` perintah dan tentukan ARN sertifikat Anda. Untuk informasi selengkapnya, lihat [mendapatkan sertifikat di Referensi AWS CLI](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) *Perintah*.
1. Jalankan perintah berikut untuk mendapatkan sertifikat yang AWS Private CA ditandatangani untuk Anda. Ganti *Certificate-ARN* dengan ARN yang Anda peroleh dari respons ke perintah sebelumnya.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. Dari hasil JSON menjalankan perintah sebelumnya, salin string yang terkait dengan `Certificate` dan. `CertificateChain` Tempel kedua string ini dalam file baru bernama signed-certificate-from-acm. Tempel string yang terkait dengan `Certificate` pertama, diikuti oleh string yang terkait dengan`CertificateChain`. Ganti `\n` karakter dengan baris baru. Berikut ini adalah struktur file setelah Anda menempelkan sertifikat dan rantai sertifikat di dalamnya.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Jalankan perintah berikut pada mesin klien untuk menambahkan sertifikat ini ke keystore Anda sehingga Anda dapat mempresentasikannya ketika Anda berbicara dengan broker MSK.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Buat file bernama `client.properties` dengan isi berikut ini. Sesuaikan lokasi truststore dan keystore ke jalur tempat Anda menyimpan. `kafka.client.truststore.jks` Ganti versi klien Kafka Anda dengan *\$1YOUR KAFKA VERSION\$1* placeholder.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# Menghasilkan dan mengkonsumsi pesan menggunakan otentikasi
Proses ini menjelaskan cara memproduksi dan mengkonsumsi pesan menggunakan otentikasi.
1. Jalankan perintah berikut untuk membuat topik. File bernama `client.properties` adalah yang Anda buat di prosedur sebelumnya.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Jalankan perintah berikut untuk memulai produser konsol. File bernama `client.properties` adalah yang Anda buat di prosedur sebelumnya.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. Di jendela perintah baru di mesin klien Anda, jalankan perintah berikut untuk memulai konsumen konsol.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Ketik pesan di jendela produser dan saksikan mereka muncul di jendela konsumen.
# Otentikasi kredensyal masuk dengan Secrets Manager AWS
Anda dapat mengontrol akses ke kluster MSK Amazon menggunakan kredensyal masuk yang disimpan dan diamankan menggunakan Secrets Manager. AWS Menyimpan kredensyal pengguna di Secrets Manager mengurangi overhead otentikasi klaster seperti mengaudit, memperbarui, dan memutar kredensyal. Secrets Manager juga memungkinkan Anda berbagi kredensyal pengguna di seluruh cluster.
Setelah Anda mengaitkan rahasia dengan kluster MSK, MSK menyinkronkan data kredensi secara berkala.
**Topics**
+ [Cara kerja autentikasi kredensyal masuk](msk-password-howitworks.md)
+ [Menyiapkan SASL/SCRAM otentikasi untuk kluster MSK Amazon](msk-password-tutorial.md)
+ [Bekerja dengan pengguna](msk-password-users.md)
+ [Keterbatasan saat menggunakan rahasia SCRAM](msk-password-limitations.md)
# Cara kerja autentikasi kredensyal masuk
Autentikasi kredensyal masuk untuk Amazon MSK SASL/SCRAM menggunakan otentikasi (Otentikasi Sederhana dan Lapisan Keamanan/Mekanisme Respons Tantangan Asin). Untuk menyiapkan autentikasi kredensyal masuk untuk klaster, Anda membuat sumber daya Rahasia di Secrets [Manager, dan mengaitkan kredensyal masuk dengan AWS rahasia](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) tersebut.
[SASL/SCRAM didefinisikan dalam RFC 5802.](https://tools.ietf.org/html/rfc5802) SCRAM menggunakan algoritma hashing aman, dan tidak mengirimkan kredensyal login plaintext antara klien dan server.
**catatan**
Saat Anda mengatur SASL/SCRAM otentikasi untuk klaster Anda, Amazon MSK mengaktifkan enkripsi TLS untuk semua lalu lintas antara klien dan broker.
# Menyiapkan SASL/SCRAM otentikasi untuk kluster MSK Amazon
Untuk mengatur AWS rahasia di Secrets Manager, ikuti tutorial [Membuat dan Mengambil Rahasia](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) di [Panduan Pengguna AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Perhatikan persyaratan berikut saat membuat rahasia untuk cluster MSK Amazon:
+ Pilih **Jenis rahasia lainnya (misalnya kunci API)** untuk tipe rahasia.
+ Nama rahasia Anda harus dimulai dengan awalan **AmazonMSK\$1**.
+ Anda harus menggunakan AWS KMS kunci kustom yang ada atau membuat AWS KMS kunci khusus baru untuk rahasia Anda. Secrets Manager menggunakan AWS KMS kunci default untuk rahasia secara default.
**penting**
Rahasia yang dibuat dengan AWS KMS kunci default tidak dapat digunakan dengan kluster MSK Amazon.
+ **Data kredensi login Anda harus dalam format berikut untuk memasukkan pasangan nilai kunci menggunakan opsi Plaintext.**
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Catat nilai ARN (Amazon Resource Name) untuk rahasia Anda.
+
**penting**
Anda tidak dapat mengaitkan rahasia Secrets Manager dengan klaster yang melebihi batas yang dijelaskan dalam[Ukuran kluster Anda dengan benar: Jumlah partisi per pialang Standar](bestpractices.md#partitions-per-broker).
+ Jika Anda menggunakan AWS CLI untuk membuat rahasia, tentukan ID kunci atau ARN untuk parameter. `kms-key-id` Jangan tentukan alias.
+ Untuk mengaitkan rahasia dengan cluster Anda, gunakan konsol MSK Amazon, atau [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operasinya.
**penting**
Saat Anda mengaitkan rahasia dengan klaster, Amazon MSK melampirkan kebijakan sumber daya ke rahasia yang memungkinkan klaster Anda mengakses dan membaca nilai rahasia yang Anda tetapkan. Anda tidak boleh mengubah kebijakan sumber daya ini. Melakukannya dapat mencegah cluster Anda mengakses rahasia Anda. Jika Anda membuat perubahan pada kebijakan sumber daya Rahasia dan/atau kunci KMS yang digunakan untuk enkripsi rahasia, pastikan Anda mengaitkan kembali rahasia ke kluster MSK Anda. Ini akan memastikan bahwa cluster Anda dapat terus mengakses rahasia Anda.
Contoh input JSON berikut untuk `BatchAssociateScramSecret` operasi mengaitkan rahasia dengan cluster:
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# Menghubungkan ke klaster Anda dengan kredensyal masuk
Setelah Anda membuat rahasia dan mengaitkannya dengan cluster Anda, Anda dapat menghubungkan klien Anda ke cluster. Prosedur berikut menunjukkan cara menghubungkan klien ke cluster yang menggunakan SASL/SCRAM otentikasi. Ini juga menunjukkan bagaimana memproduksi dan mengkonsumsi dari topik contoh.
**Topics**
+ [Menghubungkan klien ke cluster menggunakan SASL/SCRAM otentikasi](#w2aab9c13c29c17c13c11b9b7)
+ [Memecahkan masalah koneksi](#msk-password-tutorial-connect-troubleshooting)
## Menghubungkan klien ke cluster menggunakan SASL/SCRAM otentikasi
1. Jalankan perintah berikut pada mesin yang telah AWS CLI diinstal. Ganti *clusterARN* dengan ARN cluster Anda.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Dari hasil JSON dari perintah ini, simpan nilai yang terkait dengan string bernama`BootstrapBrokerStringSaslScram`. Anda akan menggunakan nilai ini di langkah selanjutnya.
1. Di mesin klien Anda, buat file konfigurasi JAAS yang berisi kredensyal pengguna yang disimpan dalam rahasia Anda. Misalnya, untuk pengguna **alice**, buat file yang dipanggil `users_jaas.conf` dengan konten berikut.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Gunakan perintah berikut untuk mengekspor file konfigurasi JAAS Anda sebagai parameter `KAFKA_OPTS` lingkungan.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Buat file bernama `kafka.client.truststore.jks` dalam `/tmp` direktori.
1. (Opsional) Gunakan perintah berikut untuk menyalin file penyimpanan kunci JDK dari `cacerts` folder JVM Anda ke `kafka.client.truststore.jks` file yang Anda buat pada langkah sebelumnya. Ganti *JDKFolder* dengan nama folder JDK pada instance Anda. Misalnya, folder JDK Anda mungkin diberi nama. `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Di `bin` direktori instalasi Apache Kafka Anda, buat file properti klien yang disebut `client_sasl.properties` dengan konten berikut. File ini mendefinisikan mekanisme dan protokol SASL.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Untuk membuat contoh topik, jalankan perintah berikut. Ganti *BootstrapBrokerStringSaslScram* dengan string broker bootstrap yang Anda peroleh di langkah 1 topik ini.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Untuk menghasilkan contoh topik yang Anda buat, jalankan perintah berikut di mesin klien Anda. Ganti *BootstrapBrokerStringSaslScram* dengan string broker bootstrap yang Anda ambil di langkah 1 topik ini.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Untuk mengkonsumsi dari topik yang Anda buat, jalankan perintah berikut di mesin klien Anda. Ganti *BootstrapBrokerStringSaslScram* dengan string broker bootstrap yang Anda peroleh di langkah 1 topik ini.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Memecahkan masalah koneksi
Saat menjalankan perintah klien Kafka, Anda mungkin mengalami kesalahan memori heap Java, terutama saat bekerja dengan topik atau kumpulan data besar. Kesalahan ini terjadi karena alat Kafka berjalan sebagai aplikasi Java dengan pengaturan memori default yang mungkin tidak cukup untuk beban kerja Anda.
Untuk mengatasi `Out of Memory Java Heap` kesalahan, Anda dapat meningkatkan ukuran heap Java dengan memodifikasi variabel `KAFKA_OPTS` lingkungan untuk menyertakan pengaturan memori.
Contoh berikut menetapkan ukuran heap maksimum untuk 1GB ()`-Xmx1G`. Anda dapat menyesuaikan nilai ini berdasarkan memori dan persyaratan sistem yang tersedia.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Untuk mengkonsumsi topik besar, pertimbangkan untuk menggunakan parameter berbasis waktu atau berbasis offset alih-alih membatasi penggunaan `--from-beginning` memori:
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Bekerja dengan pengguna
**Membuat pengguna:** Anda membuat pengguna dalam rahasia Anda sebagai pasangan nilai kunci. Saat Anda menggunakan opsi **Plaintext** di konsol Secrets Manager, Anda harus menentukan data kredensi masuk dalam format berikut.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Mencabut akses pengguna:** Untuk mencabut kredensyal pengguna untuk mengakses kluster, sebaiknya Anda menghapus atau menerapkan ACL di klaster terlebih dahulu, lalu memisahkan rahasianya. Ini karena hal-hal berikut:
+ Menghapus pengguna tidak menutup koneksi yang ada.
+ Perubahan pada rahasia Anda membutuhkan waktu hingga 10 menit untuk disebarkan.
Untuk informasi tentang menggunakan ACL dengan Amazon MSK, lihat. [Apache Kafka ACLs](msk-acls.md)
Untuk cluster yang menggunakan ZooKeeper mode, kami menyarankan Anda membatasi akses ke ZooKeeper node Anda untuk mencegah pengguna memodifikasi. ACLs Untuk informasi selengkapnya, lihat [Kontrol akses ke ZooKeeper node Apache di kluster MSK Amazon Anda](zookeeper-security.md).
# Keterbatasan saat menggunakan rahasia SCRAM
Perhatikan batasan berikut saat menggunakan rahasia SCRAM:
+ Amazon MSK hanya mendukung otentikasi SCRAM-SHA-512.
+ Cluster MSK Amazon dapat memiliki hingga 1000 pengguna.
+ Anda harus menggunakan sebuah AWS KMS key dengan Rahasia Anda. Anda tidak dapat menggunakan Rahasia yang menggunakan kunci enkripsi Secrets Manager default dengan Amazon MSK. Untuk informasi tentang membuat kunci KMS, lihat [Membuat kunci KMS enkripsi simetris](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Anda tidak dapat menggunakan kunci KMS asimetris dengan Secrets Manager.
+ Anda dapat mengaitkan hingga 10 rahasia dengan cluster sekaligus menggunakan [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operasi.
+ **Nama rahasia yang terkait dengan cluster MSK Amazon harus memiliki awalan AmazonMSK\$1.**
+ Rahasia yang terkait dengan kluster MSK Amazon harus berada di akun dan AWS wilayah Amazon Web Services yang sama dengan cluster.
# Apache Kafka ACLs
Apache Kafka memiliki otorisasi yang dapat dicolokkan dan dikirimkan dengan implementasi otorisasi. out-of-box Amazon MSK memungkinkan otorisasi ini dalam `server.properties` file di broker.
Apache Kafka ACLs memiliki format “Principal P adalah [Diizinkan/Ditolak] Operasi O Dari Host H pada Resource R apa pun yang cocok dengan RP”. ResourcePattern Jika RP tidak cocok dengan R sumber daya tertentu, maka R tidak terkait ACLs, dan oleh karena itu tidak ada orang lain selain pengguna super yang diizinkan mengakses R. Untuk mengubah perilaku Apache Kafka ini, Anda mengatur properti `allow.everyone.if.no.acl.found` ke true. Amazon MSK menetapkannya ke true secara default. Ini berarti bahwa dengan kluster MSK Amazon, jika Anda tidak secara eksplisit mengatur ACLs sumber daya, semua kepala sekolah dapat mengakses sumber daya ini. Jika Anda ACLs mengaktifkan sumber daya, hanya kepala sekolah yang berwenang yang dapat mengaksesnya. Jika Anda ingin membatasi akses ke topik dan mengotorisasi klien menggunakan otentikasi timbal balik TLS, tambahkan ACLs menggunakan Apache Kafka Authorizer CLI. Untuk informasi selengkapnya tentang menambahkan, menghapus, dan mencantumkan ACLs, lihat Antarmuka [Baris Perintah Otorisasi Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface).
Karena Amazon MSK mengonfigurasi broker sebagai pengguna super, mereka dapat mengakses semua topik. Ini membantu broker untuk mereplikasi pesan dari partisi utama apakah `allow.everyone.if.no.acl.found` properti didefinisikan untuk konfigurasi cluster atau tidak.
**Untuk menambah atau menghapus akses baca dan tulis ke topik**
1. Tambahkan broker Anda ke tabel ACL untuk memungkinkan mereka membaca dari semua topik yang ada ACLs . Untuk memberi broker Anda membaca akses ke topik, jalankan perintah berikut pada mesin klien yang dapat berkomunikasi dengan cluster MSK.
Ganti *Distinguished-Name* dengan DNS dari salah satu broker bootstrap cluster Anda, lalu ganti string sebelum periode pertama dalam nama yang dibedakan ini dengan tanda bintang ()`*`. Misalnya, jika salah satu broker bootstrap cluster Anda memiliki DNS`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, ganti *Distinguished-Name* perintah berikut dengan`*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`. Untuk informasi tentang cara mendapatkan broker bootstrap, lihat[Dapatkan broker bootstrap untuk cluster MSK Amazon](msk-get-bootstrap-brokers.md).
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. Untuk memberikan akses baca aplikasi klien ke topik, jalankan perintah berikut di mesin klien Anda. Jika Anda menggunakan otentikasi TLS timbal balik, gunakan yang sama dengan yang *Distinguished-Name* Anda gunakan saat Anda membuat kunci pribadi.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Untuk menghapus akses baca, Anda dapat menjalankan perintah yang sama, menggantinya `--add` dengan`--remove`.
1. Untuk memberikan akses tulis ke topik, jalankan perintah berikut di mesin klien Anda. Jika Anda menggunakan otentikasi TLS timbal balik, gunakan yang sama dengan yang *Distinguished-Name* Anda gunakan saat Anda membuat kunci pribadi.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Untuk menghapus akses tulis, Anda dapat menjalankan perintah yang sama, menggantinya `--add` dengan`--remove`.
# Mengubah grup keamanan klaster MSK Amazon
Halaman ini menjelaskan cara mengubah grup keamanan klaster MSK yang ada. Anda mungkin perlu mengubah grup keamanan klaster untuk menyediakan akses ke kumpulan pengguna tertentu atau membatasi akses ke klaster. Untuk informasi tentang grup keamanan, lihat [Grup keamanan untuk VPC Anda di panduan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) pengguna Amazon VPC.
1. Gunakan [ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API atau perintah [daftar-node](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) di dalam AWS CLI untuk mendapatkan daftar broker di cluster Anda. Hasil operasi ini termasuk antarmuka jaringan elastis (ENIs) yang terkait dengan broker. IDs
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon EC2 di. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Menggunakan daftar dropdown di dekat sudut kanan atas layar, pilih Wilayah tempat cluster digunakan.
1. Di panel kiri, di bawah **Jaringan & Keamanan**, pilih **Antarmuka Jaringan**.
1. Pilih ENI pertama yang Anda peroleh pada langkah pertama. Pilih menu **Tindakan** di bagian atas layar, lalu pilih **Ubah Grup Keamanan**. Tetapkan grup keamanan baru ke ENI ini. Ulangi langkah ini untuk setiap ENIs yang Anda peroleh pada langkah pertama.
**catatan**
**Perubahan yang Anda buat pada grup keamanan klaster menggunakan konsol Amazon EC2 tidak tercermin di konsol MSK di bawah Pengaturan jaringan.**
1. Konfigurasikan aturan grup keamanan baru untuk memastikan bahwa klien Anda memiliki akses ke broker. Untuk informasi tentang menyetel aturan grup keamanan, lihat [Menambahkan, Menghapus, dan Memperbarui Aturan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) di panduan pengguna Amazon VPC.
**penting**
Jika Anda mengubah grup keamanan yang terkait dengan broker cluster, dan kemudian menambahkan broker baru ke cluster itu, Amazon MSK mengaitkan broker baru dengan grup keamanan asli yang dikaitkan dengan cluster ketika cluster dibuat. Namun, agar cluster berfungsi dengan benar, semua brokernya harus dikaitkan dengan grup keamanan yang sama. Oleh karena itu, jika Anda menambahkan broker baru setelah mengubah grup keamanan, Anda harus mengikuti prosedur sebelumnya lagi dan memperbarui broker baru. ENIs
# Kontrol akses ke ZooKeeper node Apache di kluster MSK Amazon Anda
Untuk alasan keamanan, Anda dapat membatasi akses ke ZooKeeper node Apache yang merupakan bagian dari kluster MSK Amazon Anda. Untuk membatasi akses ke node, Anda dapat menetapkan grup keamanan terpisah untuk mereka. Anda kemudian dapat memutuskan siapa yang mendapat akses ke grup keamanan itu.
**penting**
Bagian ini tidak berlaku untuk cluster yang berjalan dalam KRaft mode. Lihat [KRaft modus](metadata-management.md#kraft-intro).
**Topics**
+ [Untuk menempatkan ZooKeeper node Apache Anda dalam grup keamanan terpisah](zookeeper-security-group.md)
+ [Menggunakan keamanan TLS dengan Apache ZooKeeper](zookeeper-security-tls.md)
# Untuk menempatkan ZooKeeper node Apache Anda dalam grup keamanan terpisah
Untuk membatasi akses ke ZooKeeper node Apache, Anda dapat menetapkan grup keamanan terpisah untuk mereka. Anda dapat memilih siapa yang memiliki akses ke grup keamanan baru ini dengan menetapkan aturan grup keamanan.
1. Dapatkan string ZooKeeper koneksi Apache untuk cluster Anda. Untuk mempelajari caranya, lihat [ZooKeeper modus](metadata-management.md#msk-get-connection-string). String koneksi berisi nama DNS dari node Apache ZooKeeper Anda.
1. Gunakan alat seperti `host` atau `ping` untuk mengonversi nama DNS yang Anda peroleh pada langkah sebelumnya ke alamat IP. Simpan alamat IP ini karena Anda membutuhkannya nanti dalam prosedur ini.
1. Masuk ke Konsol Manajemen AWS dan buka konsol Amazon EC2 di. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Di panel kiri, di bawah **NETWORK & SECURITY**, pilih **Network Interfaces**.
1. Di bidang pencarian di atas tabel antarmuka jaringan, ketikkan nama cluster Anda, lalu ketik return. Ini membatasi jumlah antarmuka jaringan yang muncul dalam tabel ke antarmuka yang terkait dengan cluster Anda.
1. Pilih kotak centang di awal baris yang sesuai dengan antarmuka jaringan pertama dalam daftar.
1. Di panel detail di bagian bawah halaman, cari ** IPv4 IP pribadi Primer**. Jika alamat IP ini cocok dengan salah satu alamat IP yang Anda peroleh pada langkah pertama prosedur ini, ini berarti bahwa antarmuka jaringan ini ditetapkan ke ZooKeeper node Apache yang merupakan bagian dari cluster Anda. Jika tidak, batalkan centang kotak di sebelah antarmuka jaringan ini, dan pilih antarmuka jaringan berikutnya dalam daftar. Urutan di mana Anda memilih antarmuka jaringan tidak masalah. Pada langkah selanjutnya, Anda akan melakukan operasi yang sama pada semua antarmuka jaringan yang ditugaskan ke ZooKeeper node Apache, satu per satu.
1. Saat Anda memilih antarmuka jaringan yang sesuai dengan ZooKeeper node Apache, pilih menu **Tindakan** di bagian atas halaman, lalu pilih **Ubah Grup Keamanan**. Tetapkan grup keamanan baru ke antarmuka jaringan ini. Untuk informasi tentang membuat grup keamanan, lihat [Membuat Grup Keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) di dokumentasi Amazon VPC.
1. Ulangi langkah sebelumnya untuk menetapkan grup keamanan baru yang sama ke semua antarmuka jaringan yang terkait dengan ZooKeeper node Apache cluster Anda.
1. Anda sekarang dapat memilih siapa yang memiliki akses ke grup keamanan baru ini. Untuk informasi tentang menyetel aturan grup keamanan, lihat [Menambahkan, Menghapus, dan Memperbarui Aturan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) di dokumentasi Amazon VPC.
# Menggunakan keamanan TLS dengan Apache ZooKeeper
Anda dapat menggunakan keamanan TLS untuk enkripsi dalam perjalanan antara klien Anda dan node Apache ZooKeeper Anda. Untuk menerapkan keamanan TLS dengan ZooKeeper node Apache Anda, lakukan hal berikut:
+ Cluster harus menggunakan Apache Kafka versi 2.5.1 atau yang lebih baru untuk menggunakan keamanan TLS dengan Apache. ZooKeeper
+ Aktifkan keamanan TLS saat Anda membuat atau mengonfigurasi klaster Anda. Cluster yang dibuat dengan Apache Kafka versi 2.5.1 atau yang lebih baru dengan TLS diaktifkan secara otomatis menggunakan keamanan TLS dengan titik akhir Apache. ZooKeeper Untuk informasi tentang pengaturan keamanan TLS, lihat[Memulai enkripsi MSK Amazon](msk-working-with-encryption.md).
+ Ambil ZooKeeper titik akhir TLS Apache menggunakan operasi. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
+ Buat file ZooKeeper konfigurasi Apache untuk digunakan dengan `kafka-configs.sh` dan [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)alat, atau dengan ZooKeeper shell. Dengan setiap alat, Anda menggunakan `--zk-tls-config-file` parameter untuk menentukan ZooKeeper konfigurasi Apache Anda.
Contoh berikut menunjukkan file ZooKeeper konfigurasi Apache khas:
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ Untuk perintah lain (seperti`kafka-topics`), Anda harus menggunakan variabel `KAFKA_OPTS` lingkungan untuk mengkonfigurasi ZooKeeper parameter Apache. Contoh berikut menunjukkan cara mengkonfigurasi variabel `KAFKA_OPTS` lingkungan untuk meneruskan ZooKeeper parameter Apache ke perintah lain:
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
Setelah Anda mengkonfigurasi variabel `KAFKA_OPTS` lingkungan, Anda dapat menggunakan perintah CLI secara normal. Contoh berikut membuat topik Apache Kafka menggunakan ZooKeeper konfigurasi Apache dari variabel lingkungan: `KAFKA_OPTS`
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**catatan**
Nama-nama parameter yang Anda gunakan dalam file ZooKeeper konfigurasi Apache Anda dan yang Anda gunakan dalam variabel `KAFKA_OPTS` lingkungan Anda tidak konsisten. Perhatikan nama mana yang Anda gunakan dengan parameter mana dalam file konfigurasi dan variabel `KAFKA_OPTS` lingkungan Anda.
Untuk informasi selengkapnya tentang mengakses ZooKeeper node Apache Anda dengan TLS, lihat [KIP-515: Aktifkan klien ZK untuk](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication) menggunakan otentikasi baru yang didukung TLS.
# Validasi kepatuhan untuk Amazon Managed Streaming for Apache Kafka
Auditor pihak ketiga menilai keamanan dan kepatuhan Amazon Managed Streaming for Apache Kafka sebagai bagian dari program kepatuhan. AWS Ini termasuk PCI dan HIPAA BAA.
Untuk daftar AWS layanan dalam lingkup program kepatuhan tertentu, lihat [Layanan Amazon dalam Lingkup menurut Program Kepatuhan](https://aws.amazon.com/compliance/services-in-scope/) . Untuk informasi umum, lihat [Program AWS Kepatuhan Program AWS](https://aws.amazon.com/compliance/programs/) .
Anda dapat mengunduh laporan audit pihak ketiga menggunakan AWS Artifact. Untuk informasi selengkapnya, lihat [Mengunduh Laporan di AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Tanggung jawab kepatuhan Anda saat menggunakan Amazon MSK ditentukan oleh sensitivitas data Anda, tujuan kepatuhan perusahaan Anda, serta undang-undang dan peraturan yang berlaku. AWS menyediakan sumber daya berikut untuk membantu kepatuhan:
+ [Panduan Quick Start Keamanan dan Kepatuhan](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance) – Panduan deployment ini membahas pertimbangan arsitektur dan menyediakan langkah–langkah untuk melakukan deployment terhadap lingkungan dasar di AWS yang menjadi fokus keamanan dan kepatuhan.
+ [Arsitektur untuk Whitepaper Keamanan dan Kepatuhan HIPAA — Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) ini menjelaskan bagaimana perusahaan dapat menggunakan untuk membuat aplikasi yang sesuai dengan HIPAA. AWS
+ [AWS Sumber Daya AWS](https://aws.amazon.com/compliance/resources/) — Kumpulan buku kerja dan panduan ini mungkin berlaku untuk industri dan lokasi Anda.
+ [Mengevaluasi Sumber Daya dengan Aturan](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) dalam *Panduan AWS Config Pengembang* — AWS Config Layanan menilai seberapa baik konfigurasi sumber daya Anda mematuhi praktik internal, pedoman industri, dan peraturan.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— AWS Layanan ini memberikan pandangan komprehensif tentang keadaan keamanan Anda di dalamnya AWS yang membantu Anda memeriksa kepatuhan Anda terhadap standar industri keamanan dan praktik terbaik.
# Ketahanan di Amazon Managed Streaming untuk Apache Kafka
Infrastruktur AWS global dibangun di sekitar AWS Wilayah dan Zona Ketersediaan. AWS Wilayah menyediakan beberapa Availability Zone yang terpisah secara fisik dan terisolasi, yang terhubung dengan latensi rendah, throughput tinggi, dan jaringan yang sangat redundan. Dengan Zona Ketersediaan, Anda dapat merancang serta mengoperasikan aplikasi dan basis data yang secara otomatis melakukan fail over di antara zona tanpa gangguan. Zona Ketersediaan memiliki ketersediaan dan toleransi kesalahan yang lebih baik, dan dapat diskalakan dibandingkan infrastruktur pusat data tunggal atau multi tradisional.
Untuk informasi selengkapnya tentang AWS Wilayah dan Availability Zone, lihat [Infrastruktur AWS Global](https://aws.amazon.com/about-aws/global-infrastructure/).
# Keamanan infrastruktur di Amazon Managed Streaming for Apache Kafka
Sebagai layanan terkelola, Amazon Managed Streaming for Apache Kafka dilindungi oleh prosedur keamanan jaringan global AWS yang dijelaskan dalam whitepaper [Amazon Web Services: Overview of](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) Security Processes.
Anda menggunakan panggilan API yang AWS dipublikasikan untuk mengakses Amazon MSK melalui jaringan. Klien harus mendukung Keamanan Lapisan Pengangkutan (TLS) 1.0 atau versi yang lebih baru. Kami merekomendasikan TLS 1.2 atau versi yang lebih baru. Klien juga harus mendukung suite cipher dengan perfect forward secrecy (PFS) seperti Ephemeral Diffie-Hellman (DHE) atau Elliptic Curve Ephemeral Diffie-Hellman (ECDHE). Sebagian besar sistem modern seperti Java 7 dan sistem yang lebih baru mendukung mode ini.
Selain itu, permintaan harus ditandatangani menggunakan ID kunci akses dan kunci akses rahasia yang terkait dengan principal IAM. Atau Anda dapat menggunakan [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) untuk menghasilkan kredensial keamanan sementara untuk menandatangani permintaan.
# Pencatatan MSK Amazon
Anda dapat mengirimkan log broker Apache Kafka ke satu atau lebih jenis tujuan berikut: Amazon CloudWatch Log, Amazon S3, Amazon Data Firehose. Anda juga dapat mencatat panggilan API MSK Amazon dengan AWS CloudTrail.
**catatan**
Log broker tersedia di broker MSK Standard dan Express.
## Log broker
Log broker memungkinkan Anda untuk memecahkan masalah aplikasi Apache Kafka Anda dan menganalisis komunikasi mereka dengan cluster MSK Anda. Anda dapat mengonfigurasi klaster MSK baru atau yang sudah ada untuk mengirimkan log broker tingkat Info ke satu atau beberapa jenis sumber daya tujuan berikut: grup CloudWatch log, bucket S3, aliran pengiriman Firehose. Melalui Firehose Anda kemudian dapat mengirimkan data log dari aliran pengiriman Anda ke OpenSearch Layanan.
Anda harus membuat sumber daya tujuan sebelum mengonfigurasi klaster Anda untuk mengirimkan log broker ke sana. Amazon MSK tidak membuat sumber daya tujuan ini untuk Anda jika sumber daya tersebut belum ada. Untuk informasi tentang ketiga jenis sumber daya tujuan ini dan cara membuatnya, lihat dokumentasi berikut:
+ [ CloudWatch Log Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### Izin yang diperlukan
Untuk mengonfigurasi tujuan log broker MSK Amazon, identitas IAM yang Anda gunakan untuk tindakan MSK Amazon harus memiliki izin yang dijelaskan dalam kebijakan. [AWS kebijakan terkelola: MSKFull Akses Amazon](security-iam-awsmanpol-AmazonMSKFullAccess.md)
Untuk melakukan streaming log broker ke bucket S3, Anda juga memerlukan `s3:PutBucketPolicy` izin. Untuk informasi tentang kebijakan bucket S3, lihat [Bagaimana Cara Menambahkan Kebijakan Bucket S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) di Panduan Pengguna Amazon S3. Untuk informasi tentang kebijakan IAM secara umum, lihat [Manajemen Akses](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) di Panduan Pengguna IAM.
### Kebijakan kunci KMS yang diperlukan untuk digunakan dengan bucket SSE-KMS
Jika Anda mengaktifkan enkripsi sisi server untuk bucket S3 menggunakan kunci AWS KMS-managed (SSE-KMS) dengan kunci yang dikelola pelanggan, tambahkan berikut ini ke kebijakan kunci untuk kunci KMS Anda sehingga Amazon MSK dapat menulis file broker ke bucket.
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### Konfigurasikan log broker menggunakan Konsol Manajemen AWS
Jika Anda membuat cluster baru, cari judul **pengiriman log Broker** di bagian **Monitoring**. Anda dapat menentukan tujuan yang Anda inginkan Amazon MSK untuk mengirimkan log broker Anda.
Untuk cluster yang ada, pilih cluster dari daftar cluster Anda, lalu pilih tab **Properties**. Gulir ke bawah ke bagian **pengiriman Log** dan kemudian pilih tombol **Edit**. Anda dapat menentukan tujuan yang Anda inginkan Amazon MSK untuk mengirimkan log broker Anda.
### Konfigurasikan log broker menggunakan AWS CLI
Bila Anda menggunakan `create-cluster` atau `update-monitoring` perintah, Anda dapat secara opsional menentukan `logging-info` parameter dan meneruskannya struktur JSON seperti contoh berikut. Dalam JSON ini, ketiga tipe tujuan adalah opsional.
**catatan**
Anda harus menyetel `LogDeliveryEnabled` tag ke `true` aliran Firehose untuk mengatur pengiriman log. Peran terkait layanan yang AWS dibuat untuk CloudWatch log menggunakan tag ini untuk memberikan izin bagi semua aliran pengiriman Firehose. Jika Anda menghapus tag ini, peran yang ditautkan layanan tidak akan dapat mengirimkan log ke aliran Firehose. *Untuk melihat contoh kebijakan IAM yang menunjukkan izin yang disertakan dalam peran terkait layanan, lihat peran [IAM yang digunakan untuk izin sumber daya di](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html) Panduan Pengguna Amazon. CloudWatch *
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### Konfigurasikan log broker menggunakan API
Anda dapat menentukan `loggingInfo` struktur opsional di JSON yang Anda berikan ke [UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring)operasi [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)atau.
**catatan**
Secara default, saat pencatatan broker diaktifkan, Amazon MSK mencatat log `INFO` level ke tujuan yang ditentukan. [Namun untuk pialang Standar, pengguna Apache Kafka 2.4.X dan yang lebih baru dapat secara dinamis mengatur level log broker ke salah satu level log log4j.](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html) Untuk informasi tentang pengaturan level log broker secara dinamis, lihat [KIP-412: Memperluas Admin API untuk mendukung level log aplikasi dinamis](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels). Jika Anda menyetel level log secara dinamis ke `DEBUG` atau`TRACE`, sebaiknya gunakan Amazon S3 atau Firehose sebagai tujuan log. Jika Anda menggunakan CloudWatch Log sebagai tujuan log dan Anda mengaktifkan `DEBUG` atau menaikkan `TRACE` level secara dinamis, MSK Amazon dapat terus mengirimkan sampel log. Ini dapat secara signifikan mempengaruhi kinerja broker dan hanya boleh digunakan ketika level `INFO` log tidak cukup bertele-tele untuk menentukan akar penyebab suatu masalah.
# Log panggilan API dengan AWS CloudTrail
**catatan**
AWS CloudTrail log tersedia untuk Amazon MSK hanya ketika Anda menggunakan[Kontrol akses IAM](iam-access-control.md).
Amazon MSK terintegrasi dengan AWS CloudTrail, layanan yang menyediakan catatan tindakan yang diambil oleh pengguna, peran, atau AWS layanan di Amazon MSK. CloudTrail menangkap panggilan API untuk sebagai acara. Panggilan yang diambil termasuk panggilan dari konsol MSK Amazon dan panggilan kode ke operasi Amazon MSK API. Ini juga menangkap tindakan Apache Kafka seperti membuat dan mengubah topik dan grup.
Jika Anda membuat jejak, Anda dapat mengaktifkan pengiriman CloudTrail acara secara berkelanjutan ke bucket Amazon S3, termasuk acara untuk Amazon MSK. Jika Anda tidak mengonfigurasi jejak, Anda masih dapat melihat peristiwa terbaru di CloudTrail konsol dalam **Riwayat acara**. Dengan menggunakan informasi yang dikumpulkan oleh CloudTrail, Anda dapat menentukan permintaan yang dibuat untuk Amazon MSK atau tindakan Apache Kafka, alamat IP dari mana permintaan dibuat, siapa yang membuat permintaan, kapan dibuat, dan detail tambahan.
Untuk mempelajari selengkapnya CloudTrail, termasuk cara mengonfigurasi dan mengaktifkannya, lihat [Panduan AWS CloudTrail Pengguna](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informasi MSK Amazon di CloudTrail
CloudTrail diaktifkan di akun Amazon Web Services Anda saat Anda membuat akun. Ketika aktivitas acara yang didukung terjadi di klaster MSK, aktivitas tersebut direkam dalam suatu CloudTrail peristiwa bersama dengan peristiwa AWS layanan lainnya dalam **riwayat Acara**. Anda dapat melihat, mencari, dan mengunduh kejadian terbaru di akun Amazon Web Services Anda. Untuk informasi lain, lihat [Melihat Peristiwa dengan Riwayat Peristiwa CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Untuk catatan peristiwa yang sedang berlangsung di akun Amazon Web Services Anda, termasuk acara untuk Amazon MSK, buat jejak. *Jejak* memungkinkan CloudTrail untuk mengirimkan file log ke bucket Amazon S3. Secara default, saat Anda membuat jejak di konsol tersebut, jejak diterapkan ke semua Wilayah . Jejak mencatat peristiwa dari semua Wilayah di partisi AWS dan mengirimkan file log ke bucket Amazon S3 yang Anda tentukan. Selain itu, Anda dapat mengonfigurasi layanan Amazon lainnya untuk menganalisis lebih lanjut dan menindaklanjuti data peristiwa yang dikumpulkan dalam CloudTrail log. Untuk informasi selengkapnya, lihat berikut:
+ [Gambaran Umum untuk Membuat Jejak](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Layanan dan Integrasi yang Didukung](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Mengkonfigurasi Notifikasi Amazon SNS untuk CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Menerima File CloudTrail Log dari Beberapa Wilayah](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) dan [Menerima File CloudTrail Log dari Beberapa Akun](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Amazon MSK mencatat semua [operasi MSK Amazon](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html) sebagai peristiwa dalam file CloudTrail log. Selain itu, ia mencatat tindakan Apache Kafka berikut.
+ kafka-cluster: DescribeClusterDynamicConfiguration
+ kafka-cluster: AlterClusterDynamicConfiguration
+ kafka-cluster: CreateTopic
+ kafka-cluster: DescribeTopicDynamicConfiguration
+ kafka-cluster: AlterTopic
+ kafka-cluster: AlterTopicDynamicConfiguration
+ kafka-cluster: DeleteTopic
Setiap entri peristiwa atau log berisi informasi tentang entitas yang membuat permintaan tersebut. Informasi identitas membantu Anda menentukan hal berikut ini:
+ Apakah permintaan dibuat dengan pengguna root atau kredensyal pengguna AWS Identity and Access Management (IAM).
+ Apakah permintaan tersebut dibuat dengan kredensial keamanan sementara untuk satu peran atau pengguna gabungan.
+ Apakah permintaan itu dibuat oleh AWS layanan lain.
Untuk informasi lain, lihat [Elemen userIdentity CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Contoh: Entri file log Amazon MSK
Trail adalah konfigurasi yang memungkinkan pengiriman peristiwa sebagai file log ke bucket Amazon S3 yang Anda tentukan. CloudTrail file log berisi satu atau lebih entri log. Peristiwa mewakili permintaan tunggal dari sumber manapun dan mencakup informasi tentang tindakan yang diminta, tanggal dan waktu tindakan, parameter permintaan, dan sebagainya. CloudTrail file log bukanlah jejak tumpukan yang diurutkan dari panggilan API publik dan tindakan Apache Kafka, sehingga tidak muncul dalam urutan tertentu.
Contoh berikut menunjukkan entri CloudTrail log yang menunjukkan tindakan MSK `DescribeCluster` dan `DeleteCluster` Amazon.
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
Contoh berikut menunjukkan entri CloudTrail log yang menunjukkan `kafka-cluster:CreateTopic` tindakan.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# Manajemen metadata
Amazon MSK mendukung mode manajemen Apache ZooKeeper atau KRaft metadata.
Dari Apache Kafka versi 3.7.x di Amazon MSK, Anda dapat membuat cluster yang KRaft menggunakan mode alih-alih mode. ZooKeeper KRaftcluster berbasis mengandalkan pengontrol dalam Kafka untuk mengelola metadata.
**Topics**
+ [ZooKeeper modus](#msk-get-connection-string)
+ [KRaft modus](#kraft-intro)
## ZooKeeper modus
[Apache ZooKeeper](https://zookeeper.apache.org/) adalah layanan terpusat untuk memelihara informasi konfigurasi, penamaan, menyediakan sinkronisasi terdistribusi, dan menyediakan layanan grup. Semua jenis layanan ini digunakan dalam beberapa bentuk atau lainnya oleh aplikasi terdistribusi,” termasuk Apache Kafka.
Jika cluster Anda menggunakan ZooKeeper mode, Anda dapat menggunakan langkah-langkah di bawah ini untuk mendapatkan string ZooKeeper koneksi Apache. Namun, kami menyarankan Anda menggunakan `BootstrapServerString` untuk terhubung ke operasi admin cluster dan perfom Anda karena `--zookeeper` bendera telah usang di Kafka 2.5 dan dihapus dari Kafka 3.0.
### Mendapatkan string ZooKeeper koneksi Apache menggunakan Konsol Manajemen AWS
1. Buka konsol MSK Amazon di[https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Tabel menunjukkan semua cluster untuk wilayah saat ini di bawah akun ini. Pilih nama cluster untuk melihat deskripsinya.
1. Pada halaman **ringkasan Cluster**, pilih **Lihat informasi klien**. Ini menunjukkan kepada Anda broker bootstrap, serta string ZooKeeper koneksi Apache.
### Mendapatkan string ZooKeeper koneksi Apache menggunakan AWS CLI
1. Jika Anda tidak mengetahui Nama Sumber Daya Amazon (ARN) klaster Anda, Anda dapat menemukannya dengan mencantumkan semua cluster di akun Anda. Untuk informasi selengkapnya, lihat [Daftar kluster MSK Amazon](msk-list-clusters.md).
1. Untuk mendapatkan string ZooKeeper koneksi Apache, bersama dengan informasi lain tentang cluster Anda, jalankan perintah berikut, ganti *ClusterArn* dengan ARN cluster Anda.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
Output dari `describe-cluster` perintah ini terlihat seperti contoh JSON berikut.
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
Contoh JSON sebelumnya menunjukkan `ZookeeperConnectString` kunci dalam output `describe-cluster` perintah. Salin nilai yang sesuai dengan kunci ini dan simpan untuk saat Anda perlu membuat topik di cluster Anda.
**penting**
Cluster MSK Amazon Anda harus dalam `ACTIVE` keadaan agar Anda dapat memperoleh string ZooKeeper koneksi Apache. Ketika sebuah cluster masih dalam `CREATING` status, output dari `describe-cluster` perintah tidak termasuk`ZookeeperConnectString`. Jika ini masalahnya, tunggu beberapa menit dan kemudian jalankan `describe-cluster` lagi setelah cluster Anda mencapai `ACTIVE` status.
### Mendapatkan string ZooKeeper koneksi Apache menggunakan API
Untuk mendapatkan string ZooKeeper koneksi Apache menggunakan API, lihat [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster).
## KRaft modus
Amazon MSK memperkenalkan dukungan untuk KRaft (Apache Kafka Raft) di Kafka versi 3.7.x. Komunitas Apache Kafka dikembangkan KRaft untuk menggantikan [Apache ZooKeeper untuk manajemen metadata di cluster Apache](#msk-get-connection-string) Kafka. Dalam KRaft mode, metadata cluster disebarkan dalam sekelompok pengendali Kafka, yang merupakan bagian dari cluster Kafka, bukan di seluruh node. ZooKeeper KRaftpengendali disertakan tanpa biaya tambahan untuk Anda, dan tidak memerlukan pengaturan atau manajemen tambahan dari Anda. Lihat [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) untuk informasi lebih lanjut tentang. KRaft
Berikut adalah beberapa poin yang perlu diperhatikan tentang KRaft mode di MSK:
+ KRaft mode hanya tersedia untuk cluster baru. Anda tidak dapat mengganti mode metadata setelah cluster dibuat.
+ Pada konsol MSK, Anda dapat membuat cluster berbasis Kraft dengan memilih Kafka versi 3.7.x dan memilih kotak centang di KRaft jendela pembuatan cluster.
+ Untuk membuat cluster dalam KRaft mode menggunakan MSK API [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)atau [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)operasi, Anda harus menggunakan `3.7.x.kraft` sebagai versi. Gunakan `3.7.x` sebagai versi untuk membuat cluster dalam ZooKeeper mode.
+ Jumlah partisi per broker sama pada KRaft dan ZooKeeper berdasarkan cluster. Namun, KRaft memungkinkan Anda untuk meng-host lebih banyak partisi per cluster dengan menyediakan [lebih banyak broker dalam](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html) sebuah cluster.
+ Tidak ada perubahan API yang diperlukan untuk menggunakan KRaft mode di Amazon MSK. Namun, jika klien Anda masih menggunakan string `--zookeeper` koneksi hari ini, Anda harus memperbarui klien Anda untuk menggunakan string `--bootstrap-server` koneksi untuk terhubung ke cluster Anda. `--zookeeper`Bendera tidak digunakan lagi di Apache Kafka versi 2.5 dan dihapus dimulai dengan Kafka versi 3.0. Oleh karena itu kami menyarankan Anda menggunakan versi klien Apache Kafka terbaru dan string `--bootstrap-server` koneksi untuk semua koneksi ke cluster Anda.
+ ZooKeeper mode terus tersedia untuk semua versi yang dirilis di mana zookeeper juga didukung oleh Apache Kafka. Lihat [Versi Apache Kafka yang didukung](supported-kafka-versions.md) detail tentang akhir dukungan untuk versi Apache Kafka dan pembaruan masa depan.
+ Anda harus memeriksa apakah alat apa pun yang Anda gunakan mampu menggunakan Kafka Admin APIs tanpa ZooKeeper koneksi. Lihat langkah-langkah terbaru [Gunakan Cruise LinkedIn Control untuk Apache Kafka dengan Amazon MSK](cruise-control.md) untuk menghubungkan cluster Anda ke Cruise Control. Cruise Control juga memiliki instruksi untuk [menjalankan Cruise Control tanpa ZooKeeper](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper).
+ Anda tidak perlu mengakses KRaft pengontrol klaster Anda secara langsung untuk tindakan administratif apa pun. Namun, jika Anda menggunakan pemantauan terbuka untuk mengumpulkan metrik, Anda juga memerlukan titik akhir DNS dari pengontrol Anda untuk mengumpulkan beberapa metrik terkait non-pengontrol tentang klaster Anda. Anda bisa mendapatkan endpoint DNS ini dari MSK Console atau menggunakan operasi API. [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes) Lihat langkah-langkah terbaru [Memantau klaster MSK Provisioned dengan Prometheus](open-monitoring.md) untuk menyiapkan pemantauan terbuka untuk cluster KRaft berbasis.
+ Tidak ada [CloudWatch metrik](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html) tambahan yang perlu Anda pantau untuk kluster KRaft mode melalui kluster ZooKeeper mode. MSK mengelola KRaft pengontrol yang digunakan dalam cluster Anda.
+ Anda dapat terus mengelola ACLs menggunakan cluster KRaft mode menggunakan string `--bootstrap-server` koneksi. Anda tidak boleh menggunakan string `--zookeeper` koneksi untuk mengelola ACLs. Lihat [Apache Kafka ACLs](msk-acls.md).
+ Dalam KRaft mode, metadata cluster Anda disimpan pada KRaft pengontrol dalam Kafka dan bukan node eksternal. ZooKeeper Oleh karena itu, Anda tidak perlu mengontrol akses ke node pengontrol secara terpisah [seperti yang Anda lakukan dengan ZooKeeper node](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html).
# Topik Operasi
Anda dapat menggunakan Amazon MSK APIs untuk mengelola topik di klaster MSK Provisioned Anda tanpa perlu mengatur dan memelihara klien admin Kafka. Dengan ini APIs, Anda dapat menentukan atau membaca properti topik seperti faktor replikasi dan jumlah partisi, bersama dengan pengaturan konfigurasi seperti kebijakan retensi dan pembersihan. Anda dapat mengelola topik Kafka secara terprogram menggunakan antarmuka yang Anda kenal termasuk AWS CLI,, dan. AWS SDKs AWS CloudFormation Ini APIs juga terintegrasi ke dalam konsol MSK Amazon, membawa semua operasi topik ke satu tempat. Anda sekarang dapat membuat atau memperbarui topik hanya dengan beberapa klik menggunakan default yang dipandu sambil mendapatkan visibilitas komprehensif ke dalam konfigurasi topik, informasi tingkat partisi, dan metrik.
**penting**
Respons API topik ini mencerminkan data yang diperbarui kira-kira setiap menit. Untuk status topik terbaru setelah membuat perubahan, biarkan sekitar satu menit sebelum melakukan kueri.
## Persyaratan untuk menggunakan topik APIs
+ Cluster Anda harus berupa klaster MSK Provisioned. Ini tidak APIs tersedia untuk kluster MSK Tanpa Server.
+ Cluster Anda harus menjalankan Apache Kafka versi 3.6.0 atau yang lebih baru. Untuk informasi selengkapnya tentang versi yang didukung, lihat[Versi Apache Kafka yang didukung](supported-kafka-versions.md).
+ Cluster Anda harus berada di `ACTIVE` negara bagian. Untuk informasi selengkapnyua tentang status klaster, lihat [Memahami status cluster MSK Provisioned](msk-cluster-states.md).
+ Anda harus memiliki izin IAM yang sesuai. Untuk informasi selengkapnya, lihat [Izin IAM untuk operasi topik APIs](#topic-operations-permissions).
## Izin IAM untuk operasi topik APIs
Untuk memanggil ini APIs, Anda harus memiliki izin IAM yang sesuai. Tabel berikut mencantumkan izin yang diperlukan untuk setiap API.
**Izin yang diperlukan untuk operasi topik APIs**
| API | Izin yang Diperlukan | Sumber daya |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | Kluster ARN, Topik ARN |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | Kluster ARN, Topik ARN |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | Kluster ARN, Topik ARN |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | Kluster ARN, Topik ARN |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | Kluster ARN, Topik ARN |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | Kluster ARN, Topik ARN |
**catatan**
Untuk`kafka-cluster:Connect`, tentukan ARN cluster dalam kebijakan IAM Anda. Untuk semua tindakan lainnya, tentukan topik ARN dalam kebijakan IAM Anda.
**catatan**
Untuk`ListTopics`, Anda dapat menggunakan wildcard (\$1) untuk mencocokkan semua topik di cluster. Sebagai contoh: `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`.
Untuk informasi selengkapnya tentang kontrol akses IAM untuk Amazon MSK, lihat. [Kontrol akses IAM](iam-access-control.md)
**Topics**
+ [Persyaratan untuk menggunakan topik APIs](#topic-operations-requirements)
+ [Izin IAM untuk operasi topik APIs](#topic-operations-permissions)
+ [Daftar topik dalam cluster MSK Amazon](msk-list-topics.md)
+ [Dapatkan informasi rinci tentang suatu topik](msk-describe-topic.md)
+ [Melihat informasi partisi untuk topik](msk-describe-topic-partitions.md)
+ [Buat topik di kluster MSK Amazon](msk-create-topic.md)
+ [Perbarui topik di kluster MSK Amazon](msk-update-topic.md)
+ [Hapus topik di kluster MSK Amazon](msk-delete-topic.md)
# Daftar topik dalam cluster MSK Amazon
Anda dapat mencantumkan semua topik di klaster MSK Provisioned Anda untuk melihat metadata dasar seperti jumlah partisi dan faktor replikasi. Ini berguna untuk memantau topik klaster Anda, melakukan pemeriksaan inventaris, atau mengidentifikasi topik untuk penyelidikan lebih lanjut.
**catatan**
`ListTopics`API menyediakan metadata topik dasar. Untuk mendapatkan informasi terperinci tentang topik tertentu, termasuk status dan konfigurasinya saat ini, gunakan `DescribeTopic` API. Untuk informasi selengkapnya, lihat [Dapatkan informasi rinci tentang suatu topik](msk-describe-topic.md).
**catatan**
Respons API ini mencerminkan data yang diperbarui kira-kira setiap menit. Untuk status topik terbaru setelah membuat perubahan, biarkan sekitar satu menit sebelum melakukan kueri.
**Topics**
+ [Daftar topik menggunakan Konsol Manajemen AWS](list-topics-console.md)
+ [Daftar topik menggunakan AWS CLI](list-topics-cli.md)
+ [Daftar topik menggunakan API](list-topics-api.md)
# Daftar topik menggunakan Konsol Manajemen AWS
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih nama cluster yang ingin Anda daftarkan topiknya.
1. Pada halaman detail cluster, pilih tab **Topik**.
1. Tabel menunjukkan semua topik dalam cluster, termasuk nama topik, jumlah partisi, faktor replikasi, dan jumlah out-of-sync replika.
# Daftar topik menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) cluster Anda. Jika Anda tidak memiliki ARN untuk cluster Anda, Anda dapat menemukannya dengan mencantumkan semua cluster. Untuk informasi selengkapnya, lihat [Daftar kluster MSK Amazon](msk-list-clusters.md).
```
aws kafka list-topics --cluster-arn ClusterArn
```
Output dari perintah ini terlihat seperti contoh JSON berikut.
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## Hasil paginating
Jika klaster Anda memiliki banyak topik, Anda dapat menggunakan pagination untuk mengambil hasil dalam batch yang lebih kecil. Gunakan `--max-results` parameter untuk menentukan jumlah maksimum topik yang akan dikembalikan, dan gunakan `--next-token` parameter untuk mengambil halaman hasil berikutnya.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
Jika ada lebih banyak hasil yang tersedia, responsnya mencakup `nextToken` nilai. Gunakan token ini untuk mengambil halaman hasil berikutnya.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## Memfilter topik berdasarkan nama
Anda dapat memfilter daftar topik dengan menentukan awalan menggunakan parameter. `--topic-name-filter` Ini hanya mengembalikan topik yang namanya dimulai dengan awalan yang ditentukan.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
Perintah ini hanya mengembalikan topik yang namanya dimulai dengan`prod-`, seperti `prod-orders` atau`prod-inventory`.
# Daftar topik menggunakan API
Untuk membuat daftar topik menggunakan API, lihat [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics).
# Dapatkan informasi rinci tentang suatu topik
Anda dapat mengambil informasi terperinci tentang topik tertentu di kluster MSK Provisioned Anda, termasuk statusnya saat ini, jumlah partisi, faktor replikasi, dan konfigurasi. Ini berguna untuk pemecahan masalah, memvalidasi pengaturan topik, atau memantau status topik selama operasi.
**catatan**
Respons API ini mencerminkan data yang diperbarui kira-kira setiap menit. Untuk status topik terbaru setelah membuat perubahan, biarkan sekitar satu menit sebelum melakukan kueri.
**Topics**
+ [Jelaskan topik menggunakan Konsol Manajemen AWS](describe-topic-console.md)
+ [Jelaskan topik menggunakan AWS CLI](describe-topic-cli.md)
+ [Jelaskan topik menggunakan API](describe-topic-api.md)
# Jelaskan topik menggunakan Konsol Manajemen AWS
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih nama cluster yang berisi topik yang ingin Anda gambarkan.
1. Pada halaman detail cluster, pilih tab **Topik**.
1. Dalam daftar topik, pilih nama topik yang ingin Anda lihat.
1. Halaman detail topik menampilkan informasi tentang topik, termasuk statusnya, jumlah partisi, faktor replikasi, dan pengaturan konfigurasi.
# Jelaskan topik menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) cluster Anda dan *TopicName* dengan nama topik yang ingin Anda jelaskan.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
Output dari perintah ini terlihat seperti contoh JSON berikut.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## Memahami status topik
`status`Bidang menunjukkan keadaan topik saat ini. Tabel berikut menjelaskan nilai status yang mungkin.
**Nilai status topik**
| Status | Deskripsi |
| --- | --- |
| CREATING | Topik sedang dibuat. |
| AKTIF | Topiknya aktif dan siap digunakan. |
| UPDATING | Konfigurasi topik sedang diperbarui. |
| DELETING | Topik sedang dihapus. |
## Memahami konfigurasi topik
`configs`Bidang berisi properti konfigurasi Kafka topik, dikodekan dalam format Base64. Untuk melihat konfigurasi dalam format yang dapat dibaca, Anda perlu memecahkan kode string Base64.
Contoh berikut menunjukkan cara memecahkan kode konfigurasi menggunakan `base64` perintah di Linux atau macOS.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
Output yang diterjemahkan menunjukkan properti konfigurasi topik dalam format nilai kunci.
```
compression.type=producer
retention.ms=604800000
```
Untuk informasi selengkapnya tentang properti konfigurasi tingkat topik, lihat. [Konfigurasi MSK Amazon tingkat topik](msk-configuration-properties.md#msk-topic-confinguration)
# Jelaskan topik menggunakan API
Untuk menjelaskan topik menggunakan API, lihat [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic).
# Melihat informasi partisi untuk topik
Anda dapat mengambil informasi rinci tentang partisi topik tertentu di kluster MSK Provisioned Anda. Informasi ini mencakup nomor partisi, broker pemimpin, broker replika, dan replika in-sync (ISR). Ini berguna untuk memantau distribusi partisi, mengidentifikasi partisi yang kurang direplikasi, atau memecahkan masalah replikasi.
**catatan**
Respons API ini mencerminkan data yang diperbarui kira-kira setiap menit. Untuk status topik terbaru setelah membuat perubahan, biarkan sekitar satu menit sebelum melakukan kueri.
**Topics**
+ [Lihat informasi partisi menggunakan Konsol Manajemen AWS](describe-topic-partitions-console.md)
+ [Lihat informasi partisi menggunakan AWS CLI](describe-topic-partitions-cli.md)
+ [Melihat informasi partisi menggunakan API](describe-topic-partitions-api.md)
# Lihat informasi partisi menggunakan Konsol Manajemen AWS
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih nama cluster yang berisi topik.
1. Pada halaman detail cluster, pilih tab **Topik**.
1. Dalam daftar topik, pilih nama topik yang ingin Anda lihat informasi partisi.
1. Pada halaman detail topik, informasi partisi ditampilkan, menunjukkan nomor partisi, broker pemimpin, replika, dan replika sinkronisasi untuk setiap partisi.
# Lihat informasi partisi menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) cluster Anda dan *TopicName* dengan nama topik.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
Output dari perintah ini terlihat seperti contoh JSON berikut.
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## Memahami informasi partisi
Tanggapan tersebut mencakup informasi berikut untuk setiap partisi:
+ **partisi** — Nomor partisi. Partisi diberi nomor mulai dari 0.
+ **leader** — ID broker pemimpin untuk partisi ini. Pemimpin menangani semua permintaan baca dan tulis untuk partisi.
+ **replika** — Daftar broker IDs yang memiliki replika partisi ini. Ini termasuk in-sync dan out-of-sync replika.
+ **isr** — Daftar broker IDs yang merupakan replika sinkron. Replika ini sepenuhnya terjebak dengan pemimpin dan dapat mengambil alih sebagai pemimpin jika diperlukan.
Pada contoh di atas, partisi 2 memiliki out-of-sync replika. `replicas`Daftar ini termasuk broker 2, tetapi `isr` daftarnya tidak. Ini menunjukkan bahwa broker 2 tidak sepenuhnya terjebak dengan pemimpin untuk partisi ini.
## Hasil paginating
Jika topik Anda memiliki banyak partisi, Anda dapat menggunakan pagination untuk mengambil hasil dalam batch yang lebih kecil. Gunakan `--max-results` parameter untuk menentukan jumlah maksimum partisi yang akan dikembalikan, dan gunakan `--next-token` parameter untuk mengambil halaman hasil berikutnya.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
Jika ada lebih banyak hasil yang tersedia, responsnya mencakup `nextToken` nilai. Gunakan token ini untuk mengambil halaman hasil berikutnya.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## Kasus penggunaan umum
Melihat informasi partisi berguna untuk beberapa skenario:
+ **Mengidentifikasi partisi yang kurang direplikasi** — Bandingkan `replicas` dan `isr` daftar untuk mengidentifikasi partisi di mana beberapa replika tidak sinkron. Ini dapat menunjukkan masalah kinerja atau masalah broker.
+ **Memantau distribusi partisi** — Periksa apakah pemimpin partisi didistribusikan secara merata di seluruh broker untuk memastikan beban seimbang.
+ **Memecahkan masalah replikasi — Identifikasi** broker mana yang mengalami kesulitan mengikuti replikasi dengan memeriksa daftar ISR.
+ **Perencanaan penyeimbangan kembali partisi** - Gunakan informasi ini untuk memahami tata letak partisi saat ini sebelum melakukan operasi penyeimbangan kembali.
# Melihat informasi partisi menggunakan API
Untuk melihat informasi partisi menggunakan API, lihat [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions).
# Buat topik di kluster MSK Amazon
Anda dapat membuat topik di klaster MSK Provisioned Anda menggunakan API ini secara langsung tanpa menyiapkan Kafka kustom apa pun. AdminClient Saat membuat topik, Anda menentukan nama topik, jumlah partisi, faktor replikasi, dan konfigurasi topik opsional.
**Topics**
+ [Buat topik menggunakan Konsol Manajemen AWS](create-topic-console.md)
+ [Buat topik menggunakan AWS CLI](create-topic-cli.md)
+ [Buat topik menggunakan API](create-topic-api.md)
# Buat topik menggunakan Konsol Manajemen AWS
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih nama cluster tempat Anda ingin membuat topik.
1. Pada halaman detail cluster, pilih tab **Topik**.
1. Pilih **Buat topik**.
1. Masukkan nama topik, jumlah partisi, dan faktor replikasi. Secara opsional, tambahkan konfigurasi. Anda dapat membuat beberapa topik sekaligus.
1. Pilih **Buat topik**.
# Buat topik menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) cluster Anda. Jika Anda tidak memiliki ARN untuk cluster Anda, Anda dapat menemukannya dengan mencantumkan semua cluster. Untuk informasi selengkapnya, lihat [Daftar kluster MSK Amazon](msk-list-clusters.md).
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
Output dari perintah ini terlihat seperti contoh JSON berikut.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# Buat topik menggunakan API
Untuk membuat topik menggunakan API, lihat [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic).
# Perbarui topik di kluster MSK Amazon
Perbarui jumlah partisi atau konfigurasi tingkat topik untuk topik yang ada. Operasi ini memodifikasi topik tanpa memerlukan rekreasi.
**catatan**
Anda dapat memperbarui jumlah partisi atau konfigurasi topik dalam satu panggilan API, tetapi tidak keduanya secara bersamaan. Untuk memperbarui keduanya, lakukan panggilan API terpisah.
**Topics**
+ [Perbarui topik menggunakan Konsol Manajemen AWS](update-topic-console.md)
+ [Perbarui topik menggunakan AWS CLI](update-topic-cli.md)
+ [Memperbarui topik menggunakan API](update-topic-api.md)
# Perbarui topik menggunakan Konsol Manajemen AWS
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih nama cluster yang berisi topik yang ingin Anda perbarui.
1. Pada halaman detail cluster, pilih tab **Topik**.
1. Pilih topik yang ingin Anda perbarui, lalu pilih **Edit pengaturan partisi** atau **Edit konfigurasi** dari **Tindakan**.
1. Perbarui jumlah partisi atau konfigurasi sesuai kebutuhan.
1. Pilih **Simpan**.
# Perbarui topik menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) cluster Anda dan *TopicName* dengan nama topik yang ingin Anda perbarui.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
Output dari perintah ini terlihat seperti contoh JSON berikut.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# Memperbarui topik menggunakan API
Untuk memperbarui topik menggunakan API, lihat [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic).
# Hapus topik di kluster MSK Amazon
Menghapus topik secara permanen akan menghapus semua data, metadata, dan informasi partisi. Operasi ini tidak dapat dibatalkan.
**Topics**
+ [Hapus topik menggunakan Konsol Manajemen AWS](delete-topic-console.md)
+ [Hapus topik menggunakan AWS CLI](delete-topic-cli.md)
+ [Menghapus topik menggunakan API](delete-topic-api.md)
# Hapus topik menggunakan Konsol Manajemen AWS
1. Masuk ke Konsol Manajemen AWS, dan buka konsol MSK Amazon di [https://console.aws.amazon.com/msk/rumah? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Dalam daftar cluster, pilih nama cluster yang berisi topik yang ingin Anda hapus.
1. Pada halaman detail cluster, pilih tab **Topik**.
1. Pilih topik yang ingin Anda hapus, lalu pilih **Hapus** dari **Tindakan**.
1. **Konfirmasikan penghapusan, lalu pilih Hapus.**
# Hapus topik menggunakan AWS CLI
Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) cluster Anda dan *TopicName* dengan nama topik yang ingin Anda hapus.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
Output dari perintah ini terlihat seperti contoh JSON berikut.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# Menghapus topik menggunakan API
Untuk menghapus topik menggunakan API, lihat [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic).
# Sumber daya MSK Amazon
Istilah *sumber daya* memiliki dua arti di Amazon MSK, tergantung pada konteksnya. Dalam konteks sumber daya APIs adalah struktur di mana Anda dapat menjalankan operasi. Untuk daftar sumber daya ini dan operasi yang dapat Anda panggil padanya, lihat [Sumber Daya](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html) di Referensi API MSK Amazon. Dalam konteks[Kontrol akses IAM](iam-access-control.md), sumber daya adalah entitas yang dapat Anda izinkan atau tolak aksesnya, seperti yang didefinisikan di [Sumber daya kebijakan otorisasi](kafka-actions.md#msk-iam-resources) bagian.
# Versi Apache Kafka
Saat Anda membuat cluster MSK Amazon, Anda menentukan versi Apache Kafka mana yang ingin Anda miliki di dalamnya. Anda juga dapat memperbarui versi Apache Kafka dari cluster yang ada. Topik di bagian ini membantu Anda memahami garis waktu untuk dukungan versi Kafka dan saran untuk praktik terbaik.
**Topics**
+ [Versi Apache Kafka yang didukung](supported-kafka-versions.md)
+ [Dukungan versi Amazon MSK](version-support.md)
# Versi Apache Kafka yang didukung
Amazon Managed Streaming for Apache Kafka (Amazon MSK) mendukung versi Apache Kafka dan Amazon MSK berikut. Komunitas Apache Kafka menyediakan sekitar 12 bulan dukungan untuk versi setelah tanggal rilisnya. Untuk lebih jelasnya, lihat [kebijakan Apache Kafka EOL (akhir hayat](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?)).
Tabel berikut mencantumkan versi Apache Kafka yang didukung Amazon MSK.
| Versi Apache Kafka | Tanggal rilis MSK | Akhir tanggal dukungan |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 2019-07-31 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 2019-12-19 | 2024-06-08 |
| [2.4.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-04-02 | 2024-06-08 |
| [2.4.1.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2.6.0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 2020-10-21 | 2024-09-11 |
| [2.6.1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 2021-01-19 | 2024-09-11 |
| [2.6.2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 2021-04-29 | 2024-09-11 |
| [2.6.3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.7.0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 2020-12-29 | 2024-09-11 |
| [2.7.1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 2021-05-25 | 2024-09-11 |
| [2.7.2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.8.0](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 2021-05-19 | 2024-09-11 |
| [2.8.1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 2022-10-28 | 2024-09-11 |
| [2.8.2 berjenjang](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 2022-10-28 | 2025-01-14 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.3.1](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 2022-10-26 | 2024-09-11 |
| [3.3.2](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | 2023-03-02 | 2024-09-11 |
| [3.4.0](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 2023-05-04 | 2025-08-04 |
| [3.5.1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 2023-09-26 | 2025-10-23 |
| [3.6.0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 2023-11-16 | 2026-06-01 |
| [3.7.x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 2024-05-29 | -- |
| [3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 2025-02-20 | -- |
| [3.9.x (Direkomendasikan](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)) | 2025-04-21 | -- |
| [4.0.x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 2025-05-16 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Untuk informasi selengkapnya tentang kebijakan dukungan versi MSK Amazon, lihat[Kebijakan dukungan versi MSK Amazon](version-support.md#version-support-policy).
## Amazon MSK versi 4.1.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 4.1, yang memperkenalkan Antrian sebagai fitur pratinjau, Protokol Rebalance Streams baru di akses awal, dan Replika Pemimpin yang Memenuhi Syarat (ELR). Seiring dengan fitur-fitur ini, Apache Kafka versi 4.1 mencakup berbagai perbaikan bug dan peningkatan.
Sorotan utama Kafka 4.1 adalah pengenalan Antrian sebagai fitur pratinjau. Anda dapat menggunakan beberapa konsumen untuk memproses pesan dari partisi topik yang sama, meningkatkan paralelisme dan throughput untuk beban kerja yang memerlukan pengiriman pesan. point-to-point Protokol Rebalance Streams yang baru dibangun di atas protokol penyeimbangan kembali konsumen Kafka 4.0, memperluas kemampuan koordinasi broker ke Kafka Streams untuk penugasan tugas dan penyeimbangan kembali yang dioptimalkan. Selain itu, ELR sekarang diaktifkan secara default untuk memperkuat ketersediaan.
Untuk detail selengkapnya dan daftar lengkap perbaikan dan perbaikan bug, lihat [catatan rilis Apache Kafka untuk](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) versi 4.1.
Untuk mulai menggunakan Apache Kafka 4.1 di Amazon MSK, pilih versi 4.1.x saat membuat cluster baru melalui,, atau. Konsol Manajemen AWS AWS CLI AWS SDKs Anda juga dapat memutakhirkan kluster yang disediakan MSK yang ada dengan pembaruan bergulir di tempat. Amazon MSK mengatur ulang broker untuk menjaga ketersediaan dan melindungi data Anda selama peningkatan. Dukungan Kafka versi 4.1 tersedia di semua Wilayah AWS tempat Amazon MSK ditawarkan.
## Amazon MSK versi 4.0.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 4.0. Versi ini membawa kemajuan terbaru dalam manajemen klaster dan kinerja ke MSK Provisioned. Kafka 4.0 memperkenalkan protokol penyeimbangan kembali konsumen baru, yang sekarang tersedia secara umum, yang membantu memastikan penyeimbangan kembali kelompok yang lebih lancar dan lebih cepat. Selain itu, Kafka 4.0 mengharuskan broker dan alat untuk menggunakan Java 17, memberikan peningkatan keamanan dan kinerja, mencakup berbagai perbaikan dan peningkatan bug, dan menghentikan manajemen metadata melalui Apache. ZooKeeper
Untuk detail selengkapnya dan daftar lengkap perbaikan dan perbaikan bug, lihat [catatan rilis Apache Kafka untuk](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) versi 4.0.
## Amazon MSK versi 3.9.x (Disarankan)
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.9. Versi ini meningkatkan fungsionalitas penyimpanan berjenjang dengan memungkinkan Anda menyimpan data berjenjang saat Anda menonaktifkan penyimpanan berjenjang di tingkat topik. Aplikasi konsumen Anda dapat membaca data historis dari remote log start offset (Rx) sambil mempertahankan offset log berkelanjutan di penyimpanan lokal dan jarak jauh.
Versi 3.9 adalah versi terakhir yang mendukung keduanya ZooKeeper dan sistem manajemen KRaft metadata. Amazon MSK akan memberikan dukungan tambahan untuk versi 3.9 selama minimal dua tahun sejak tanggal rilisnya.
Untuk detail selengkapnya dan daftar lengkap perbaikan dan perbaikan bug, lihat [catatan rilis Apache Kafka untuk](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html) versi 3.9.x.
## Amazon MSK versi 3.8.x
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.8. Anda sekarang dapat membuat cluster baru menggunakan versi 3.8 dengan KRAFT atau ZooKeeper mode untuk manajemen metadata atau meningkatkan cluster ZooKeeper berbasis yang ada untuk menggunakan versi 3.8. Apache Kafka versi 3.8 mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Fitur baru utama termasuk dukungan untuk konfigurasi tingkat kompresi. Ini memungkinkan Anda untuk lebih mengoptimalkan kinerja Anda saat menggunakan jenis kompresi seperti lz4, zstd dan gzip, dengan memungkinkan Anda mengubah tingkat kompresi default.
Untuk detail selengkapnya dan daftar lengkap perbaikan dan perbaikan bug, lihat [catatan rilis Apache Kafka untuk](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) versi 3.8.x.
## Apache Kafka versi 3.7.x (dengan penyimpanan berjenjang siap produksi)
Apache Kafka versi 3.7.x di MSK mencakup dukungan untuk Apache Kafka versi 3.7.0. Anda dapat membuat cluster atau meng-upgrade cluster yang ada untuk menggunakan versi 3.7.x yang baru. Dengan perubahan penamaan versi ini, Anda tidak lagi harus mengadopsi versi perbaikan tambalan yang lebih baru seperti 3.7.1 ketika dirilis oleh komunitas Apache Kafka. Amazon MSK akan secara otomatis memperbarui 3.7.x untuk mendukung versi patch future setelah tersedia. Ini memungkinkan Anda untuk mendapatkan keuntungan dari perbaikan keamanan dan bug yang tersedia melalui versi perbaikan tambalan tanpa memicu peningkatan versi. Versi perbaikan tambalan yang dirilis oleh Apache Kafka ini tidak merusak kompatibilitas versi dan Anda dapat memperoleh manfaat dari versi perbaikan tambalan baru tanpa khawatir tentang kesalahan baca atau tulis untuk aplikasi klien Anda. Pastikan alat otomatisasi infrastruktur Anda, seperti CloudFormation, diperbarui untuk memperhitungkan perubahan penamaan versi ini.
Amazon MSK sekarang mendukung KRaft mode (Apache Kafka Raft) di Apache Kafka versi 3.7.x. Di Amazon MSK, seperti halnya dengan ZooKeeper node, KRaft pengontrol disertakan tanpa biaya tambahan untuk Anda, dan tidak memerlukan pengaturan atau manajemen tambahan dari Anda. Anda sekarang dapat membuat cluster dalam KRaft mode atau ZooKeeper mode pada Apache Kafka versi 3.7.x. Dalam mode Kraft, Anda dapat menambahkan hingga 60 broker untuk menampung lebih banyak partisi per cluster, tanpa meminta peningkatan batas, dibandingkan dengan kuota 30-broker pada cluster berbasis Zookeeper. Untuk mempelajari lebih lanjut KRaft tentang MSK, lihat[KRaft modus](metadata-management.md#kraft-intro).
Apache Kafka versi 3.7.x juga mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Perbaikan utama termasuk pengoptimalan penemuan pemimpin untuk klien dan opsi pengoptimalan flush segmen log. [Untuk daftar lengkap perbaikan dan perbaikan bug, lihat catatan rilis Apache Kafka untuk 3.7.0.](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html)
## Apache Kafka versi 3.6.0 (dengan penyimpanan berjenjang siap produksi)
Untuk informasi tentang Apache Kafka versi 3.6.0 (dengan penyimpanan berjenjang siap produksi), lihat catatan [rilisnya](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
Amazon MSK akan terus menggunakan dan mengelola Zookeeper untuk manajemen kuorum dalam rilis ini untuk stabilitas.
## Amazon MSK versi 3.5.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.5.1 untuk cluster baru dan yang sudah ada. Apache Kafka 3.5.1 mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Fitur utama termasuk pengenalan penugasan partisi rack-aware baru untuk konsumen. Amazon MSK akan terus menggunakan dan mengelola Zookeeper untuk manajemen kuorum dalam rilis ini. Untuk daftar lengkap perbaikan dan perbaikan bug, lihat catatan rilis Apache Kafka untuk 3.5.1.
Untuk informasi tentang Apache Kafka versi 3.5.1, lihat [catatan rilisnya](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
## Amazon MSK versi 3.4.0
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.4.0 untuk cluster baru dan yang sudah ada. Apache Kafka 3.4.0 mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Fitur utama termasuk perbaikan untuk meningkatkan stabilitas untuk mengambil dari replika terdekat. Amazon MSK akan terus menggunakan dan mengelola Zookeeper untuk manajemen kuorum dalam rilis ini. Untuk daftar lengkap perbaikan dan perbaikan bug, lihat catatan rilis Apache Kafka untuk 3.4.0.
Untuk informasi tentang Apache Kafka versi 3.4.0, lihat [catatan rilisnya](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
## Amazon MSK versi 3.3.2
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.3.2 untuk cluster baru dan yang sudah ada. Apache Kafka 3.3.2 mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Fitur utama termasuk perbaikan untuk meningkatkan stabilitas untuk mengambil dari replika terdekat. Amazon MSK akan terus menggunakan dan mengelola Zookeeper untuk manajemen kuorum dalam rilis ini. Untuk daftar lengkap perbaikan dan perbaikan bug, lihat catatan rilis Apache Kafka untuk 3.3.2.
Untuk informasi tentang Apache Kafka versi 3.3.2, lihat [catatan rilisnya](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
## Amazon MSK versi 3.3.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.3.1 untuk cluster baru dan yang sudah ada. Apache Kafka 3.3.1 mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Beberapa fitur utama termasuk penyempurnaan metrik dan partisi. Amazon MSK akan terus menggunakan dan mengelola Zookeeper untuk manajemen kuorum dalam rilis ini untuk stabilitas. Untuk daftar lengkap perbaikan dan perbaikan bug, lihat catatan rilis Apache Kafka untuk 3.3.1.
Untuk informasi tentang Apache Kafka versi 3.3.1, lihat [catatan rilisnya](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
## Amazon MSK versi 3.1.1
Amazon Managed Streaming for Apache Kafka (Amazon MSK) sekarang mendukung Apache Kafka versi 3.1.1 dan 3.2.0 untuk cluster baru dan yang sudah ada. Apache Kafka 3.1.1 dan Apache Kafka 3.2.0 mencakup beberapa perbaikan bug dan fitur baru yang meningkatkan kinerja. Beberapa fitur utama termasuk penyempurnaan metrik dan penggunaan topik. IDs MSK akan terus menggunakan dan mengelola Zookeeper untuk manajemen kuorum dalam rilis ini untuk stabilitas. Untuk daftar lengkap perbaikan dan perbaikan bug, lihat catatan rilis Apache Kafka untuk 3.1.1 dan 3.2.0.
Untuk informasi tentang Apache Kafka versi 3.1.1 dan 3.2.0, lihat catatan rilis [3.2.0 dan catatan rilis [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html)](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
## Amazon MSK penyimpanan berjenjang versi 2.8.2.tiered
Rilis ini adalah versi Amazon MSK-only dari Apache Kafka versi 2.8.2, dan kompatibel dengan klien Apache Kafka open source.
[Rilis 2.8.2.tiered berisi fungsionalitas penyimpanan berjenjang yang kompatibel dengan APIs diperkenalkan di KIP-405 untuk Apache Kafka.](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Untuk informasi selengkapnya tentang fitur penyimpanan berjenjang MSK Amazon, lihat. [Penyimpanan berjenjang untuk pialang Standar](msk-tiered-storage.md)
## Apache Kafka versi 2.5.1
Apache Kafka versi 2.5.1 mencakup beberapa perbaikan bug dan fitur baru, termasuk enkripsi dalam perjalanan untuk Apache dan klien administrasi. ZooKeeper Amazon MSK menyediakan ZooKeeper titik akhir TLS, yang dapat Anda kueri dengan operasi. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
Output dari [ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operasi termasuk `ZookeeperConnectStringTls` node, yang mencantumkan titik akhir zookeeper TLS.
Contoh berikut menunjukkan `ZookeeperConnectStringTls` simpul respon untuk `DescribeCluster` operasi:
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
Untuk informasi tentang penggunaan enkripsi TLS dengan zookeeper, lihat. [Menggunakan keamanan TLS dengan Apache ZooKeeper](zookeeper-security-tls.md)
Untuk informasi lebih lanjut tentang Apache Kafka versi 2.5.1, lihat [catatan rilisnya](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
## Amazon MSK perbaikan bug versi 2.4.1.1
Rilis ini adalah versi perbaikan bug khusus Amazon MSK dari Apache Kafka versi 2.4.1. Rilis perbaikan bug ini berisi perbaikan untuk [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752), masalah langka yang menyebabkan kelompok konsumen terus menyeimbangkan kembali dan tetap dalam keadaan. `PreparingRebalance` Masalah ini memengaruhi cluster yang menjalankan Apache Kafka versi 2.3.1 dan 2.4.1. Rilis ini berisi perbaikan yang diproduksi komunitas yang tersedia di Apache Kafka versi 2.5.0.
**catatan**
Cluster MSK Amazon yang menjalankan versi 2.4.1.1 kompatibel dengan klien Apache Kafka yang kompatibel dengan Apache Kafka versi 2.4.1.
Kami menyarankan Anda menggunakan MSK bug-fix versi 2.4.1.1 untuk cluster MSK Amazon baru jika Anda lebih suka menggunakan Apache Kafka 2.4.1. Anda dapat memperbarui cluster yang ada yang menjalankan Apache Kafka versi 2.4.1 ke versi ini untuk menggabungkan perbaikan ini. Untuk informasi tentang memutakhirkan klaster yang ada, lihat[Tingkatkan versi Apache Kafka](version-upgrades.md).
Untuk mengatasi masalah ini tanpa memutakhirkan cluster ke versi 2.4.1.1, lihat [Kelompok konsumen terjebak di `PreparingRebalance` negara bagian](troubleshooting.md#consumer-group-rebalance) bagian panduan. [Memecahkan masalah klaster MSK Amazon Anda](troubleshooting.md)
## Apache Kafka versi 2.4.1 (gunakan 2.4.1.1 sebagai gantinya)
**catatan**
Anda tidak dapat lagi membuat cluster MSK dengan Apache Kafka versi 2.4.1. Sebagai gantinya, Anda dapat menggunakan [Amazon MSK perbaikan bug versi 2.4.1.1](#2.4.1.1) dengan klien yang kompatibel dengan Apache Kafka versi 2.4.1. Dan jika Anda sudah memiliki cluster MSK dengan Apache Kafka versi 2.4.1, kami sarankan Anda memperbaruinya untuk menggunakan Apache Kafka versi 2.4.1.1 sebagai gantinya.
KIP-392 adalah salah satu Proposal Peningkatan Kafka kunci yang termasuk dalam rilis 2.4.1 Apache Kafka. Peningkatan ini memungkinkan konsumen untuk mengambil dari replika terdekat. Untuk menggunakan fitur ini, atur `client.rack` properti konsumen ke ID Availability Zone konsumen. Contoh ID AZ adalah`use1-az1`. Amazon MSK menetapkan `broker.rack` ke IDs Zona Ketersediaan broker. Anda juga harus mengatur properti `replica.selector.class` konfigurasi ke`org.apache.kafka.common.replica.RackAwareReplicaSelector`, yang merupakan implementasi dari kesadaran rak yang disediakan oleh Apache Kafka.
Saat Anda menggunakan versi Apache Kafka ini, metrik di tingkat `PER_TOPIC_PER_BROKER` pemantauan hanya muncul setelah nilainya menjadi bukan nol untuk pertama kalinya. Untuk informasi selengkapnya tentang langkah ini, lihat [`PER_TOPIC_PER_BROKER`Pemantauan tingkat](metrics-details.md#broker-topic-metrics).
Untuk informasi tentang cara menemukan Availability Zone IDs, lihat [AZ IDs untuk Sumber Daya Anda](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) di panduan AWS Resource Access Manager pengguna.
Untuk informasi tentang menyetel properti konfigurasi, lihat[Konfigurasi Amazon MSK yang disediakan](msk-configuration.md).
Untuk informasi selengkapnya tentang KIP-392, lihat [Izinkan Konsumen Mengambil dari Replika Terdekat](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica) di halaman Confluence.
Untuk informasi lebih lanjut tentang Apache Kafka versi 2.4.1, lihat [catatan rilisnya](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) di situs unduhan Apache Kafka.
# Dukungan versi Amazon MSK
Topik ini menjelaskan [Kebijakan dukungan versi MSK Amazon](#version-support-policy) dan prosedur untuk[Tingkatkan versi Apache Kafka](version-upgrades.md). Jika Anda meningkatkan versi Kafka Anda, ikuti praktik terbaik yang diuraikan di. [Praktik terbaik untuk peningkatan versi](version-upgrades-best-practices.md)
**Topics**
+ [Kebijakan dukungan versi MSK Amazon](#version-support-policy)
+ [Tingkatkan versi Apache Kafka](version-upgrades.md)
+ [Praktik terbaik untuk peningkatan versi](version-upgrades-best-practices.md)
## Kebijakan dukungan versi MSK Amazon
Bagian ini menjelaskan kebijakan dukungan untuk Amazon MSK mendukung versi Kafka.
+ Semua versi Kafka didukung hingga mereka mencapai akhir tanggal dukungan mereka. Untuk detail tentang akhir tanggal dukungan, lihat[Versi Apache Kafka yang didukung](supported-kafka-versions.md). Tingkatkan klaster MSK Anda ke versi Kafka yang direkomendasikan atau versi yang lebih tinggi sebelum akhir tanggal dukungan. Untuk detail tentang meningkatkan versi Apache Kafka Anda, lihat. [Tingkatkan versi Apache Kafka](version-upgrades.md) Cluster yang menggunakan versi Kafka setelah akhir tanggal dukungannya ditingkatkan secara otomatis ke versi Kafka yang direkomendasikan. Upgrade otomatis dapat terjadi kapan saja setelah akhir tanggal dukungan. Anda tidak akan menerima pemberitahuan apa pun sebelum peningkatan.
+ MSK akan menghapus dukungan untuk cluster yang baru dibuat yang menggunakan versi Kafka dengan tanggal akhir dukungan yang diterbitkan.
# Tingkatkan versi Apache Kafka
Anda dapat meningkatkan kluster MSK yang ada ke versi Apache Kafka yang lebih baru. Sebelum memutakhirkan versi Kafka cluster Anda, verifikasi bahwa versi perangkat lunak sisi klien Anda mendukung fitur dalam versi Kafka yang baru.
Untuk informasi tentang cara membuat klaster sangat tersedia selama peningkatan, lihat[Bangun cluster yang sangat tersedia](bestpractices.md#ensure-high-availability).
**Tingkatkan versi Apache Kafka menggunakan Konsol Manajemen AWS**
1. Buka konsol MSK Amazon di[https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Di bilah navigasi, pilih Wilayah tempat Anda membuat cluster MSK.
1. Pilih kluster MSK yang ingin Anda tingkatkan.
1. Pada tab **Properties**, pilih **Upgrade** di bagian **versi Apache Kafka**.
1. Di bagian **versi Apache Kafka**, lakukan hal berikut:
1. Dalam daftar dropdown *Pilih versi Apache Kafka*, pilih versi target yang ingin Anda tingkatkan. Misalnya, pilih **3.9.x**.
1. (Opsional) Pilih **Lihat kompatibilitas versi** untuk memverifikasi kompatibilitas antara versi kluster Anda saat ini dan versi pemutakhiran yang tersedia. Kemudian, pilih **Pilih** untuk melanjutkan.
**catatan**
Amazon MSK mendukung peningkatan di tempat ke sebagian besar versi Apache Kafka. Namun, saat memutakhirkan dari versi Kafka ZooKeeper berbasis ke versi KRaft berbasis, Anda harus membuat cluster baru. Kemudian, salin data Anda ke cluster baru, dan alihkan klien ke cluster baru.
1. (Opsional) Pilih kotak centang **Perbarui konfigurasi klaster** untuk menerapkan pembaruan konfigurasi yang kompatibel dengan versi baru. Ini memungkinkan fitur dan peningkatan versi baru.
Anda dapat melewati langkah ini jika Anda perlu mempertahankan konfigurasi kustom yang ada.
**catatan**
Upgrade sisi server tidak secara otomatis memperbarui aplikasi klien.
Untuk menjaga stabilitas klaster, penurunan versi tidak didukung.
1. Pilih **Upgrade** untuk memulai proses.
**Tingkatkan versi Apache Kafka menggunakan AWS CLI**
1. Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) yang Anda peroleh saat membuat cluster Anda. Jika Anda tidak memiliki ARN untuk cluster Anda, Anda dapat menemukannya dengan mencantumkan semua cluster. Untuk informasi selengkapnya, lihat [Daftar kluster MSK Amazon](msk-list-clusters.md).
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
Output dari perintah ini mencakup daftar versi Apache Kafka yang dapat Anda tingkatkan cluster. Sepertinya contoh berikut.
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. Jalankan perintah berikut, ganti *ClusterArn* dengan Amazon Resource Name (ARN) yang Anda peroleh saat membuat cluster Anda. Jika Anda tidak memiliki ARN untuk cluster Anda, Anda dapat menemukannya dengan mencantumkan semua cluster. Untuk informasi selengkapnya, lihat [Daftar kluster MSK Amazon](msk-list-clusters.md).
Ganti *Current-Cluster-Version* dengan versi cluster saat ini. Untuk *TargetVersion* Anda dapat menentukan salah satu versi target dari output dari perintah sebelumnya.
**penting**
Versi cluster bukan bilangan bulat sederhana. Untuk menemukan versi cluster saat ini, gunakan [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operasi atau [perintah AWS CLI deskripsi-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Contoh versi adalah`KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
Output dari perintah sebelumnya terlihat seperti JSON berikut.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Untuk mendapatkan hasil `update-cluster-kafka-version` operasi, jalankan perintah berikut, ganti *ClusterOperationArn* dengan ARN yang Anda peroleh dalam output perintah. `update-cluster-kafka-version`
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
Output dari `describe-cluster-operation` perintah ini terlihat seperti contoh JSON berikut.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
Jika `OperationState` memiliki nilai`UPDATE_IN_PROGRESS`, tunggu sebentar, lalu jalankan `describe-cluster-operation` perintah lagi. Ketika operasi selesai, nilai `OperationState` menjadi`UPDATE_COMPLETE`. Karena waktu yang diperlukan Amazon MSK untuk menyelesaikan operasi bervariasi, Anda mungkin perlu memeriksa berulang kali hingga operasi selesai.
**Tingkatkan versi Apache Kafka menggunakan API**
1. Panggil [GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions)operasi untuk mendapatkan daftar versi Apache Kafka yang dapat Anda tingkatkan cluster.
1. Panggil [UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion)operasi untuk meningkatkan cluster ke salah satu versi Apache Kafka yang kompatibel.
# Praktik terbaik untuk peningkatan versi
Untuk memastikan kontinuitas klien selama pembaruan bergulir yang dilakukan sebagai bagian dari proses peningkatan versi Kafka, tinjau konfigurasi klien Anda dan topik Apache Kafka Anda sebagai berikut:
+ Tetapkan faktor replikasi topik (RF) ke nilai minimum untuk cluster dua-AZ dan nilai minimum `2` untuk cluster tiga-AZ. `3` Nilai RF `2` dapat menyebabkan partisi offline selama penambalan.
+ Tetapkan replika in-sync minimum (miniSR) ke nilai maksimum 1 kurang dari Faktor Replikasi (RF) Anda, yaitu. `miniISR = (RF) - 1` Ini memastikan bahwa set replika partisi dapat mentolerir satu replika yang sedang offline atau kurang direplikasi.
+ Konfigurasikan klien untuk menggunakan beberapa string koneksi broker. Memiliki beberapa broker dalam string koneksi klien memungkinkan untuk failover jika broker tertentu yang mendukung klien I/O mulai ditambal. Untuk informasi tentang cara mendapatkan string koneksi dengan beberapa broker, lihat [Mendapatkan broker bootstrap untuk klaster MSK Amazon](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html).
+ Kami menyarankan Anda meningkatkan menghubungkan klien ke versi yang disarankan atau lebih tinggi untuk mendapatkan manfaat dari fitur yang tersedia di versi baru. Upgrade klien tidak tunduk pada tanggal akhir masa pakai (EOL) versi Kafka klaster MSK Anda, dan tidak perlu diselesaikan pada tanggal EOL. Apache Kafka menyediakan [kebijakan kompatibilitas klien dua arah yang memungkinkan klien](https://kafka.apache.org/protocol#protocol_compatibility) lama bekerja dengan cluster yang lebih baru dan sebaliknya.
+ Klien Kafka yang menggunakan versi 3.xx kemungkinan akan datang dengan default berikut: dan. `acks=all` `enable.idempotence=true` `acks=all`berbeda dari default sebelumnya `acks=1` dan memberikan daya tahan ekstra dengan memastikan bahwa semua replika yang sinkron mengakui permintaan produksi. Demikian pula, default untuk `enable.idempotence` sebelumnya`false`. Perubahan menjadi `enable.idempotence=true` sebagai default menurunkan kemungkinan pesan duplikat. Perubahan ini dianggap sebagai pengaturan praktik terbaik dan dapat memperkenalkan sejumlah kecil latensi tambahan yang berada dalam parameter kinerja normal.
+ Gunakan versi Kafka yang direkomendasikan saat membuat cluster MSK baru. Menggunakan versi Kafka yang direkomendasikan memungkinkan Anda untuk mendapatkan keuntungan dari fitur Kafka dan MSK terbaru.
# Memecahkan masalah klaster MSK Amazon Anda
Informasi berikut dapat membantu Anda memecahkan masalah yang mungkin Anda miliki dengan kluster MSK Amazon Anda. Anda juga dapat memposting masalah Anda ke [AWS re:Post](https://repost.aws/). Untuk memecahkan masalah Amazon MSK Replicator, lihat. [Memecahkan masalah MSK Replicator](msk-replicator-troubleshooting.md)
**Topics**
+ [Penggantian volume menyebabkan saturasi disk karena kelebihan replikasi](#replication-overload-disk-saturation)
+ [Kelompok konsumen terjebak di `PreparingRebalance` negara bagian](#consumer-group-rebalance)
+ [Kesalahan saat mengirimkan log broker ke Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Tidak ada grup keamanan default](#troubleshooting-shared-vpc)
+ [Cluster tampak macet dalam status CREATING](#troubleshooting-cluster-stuck)
+ [Status cluster berubah dari CREATING menjadi FAILED](#troubleshooting-cluster-failed)
+ [Status klaster AKTIF tetapi produsen tidak dapat mengirim data atau konsumen tidak dapat menerima data](#troubleshooting-nodata)
+ [AWS CLI tidak mengenali Amazon MSK](#troubleshooting-nocli)
+ [Partisi offline atau replika tidak sinkron](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [Ruang disk hampir habis](#troubleshooting-lowdiskspace)
+ [Memori hampir habis](#troubleshooting-lowmemory)
+ [Produser mendapat NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Partisi yang kurang direplikasi (URP) lebih besar dari nol](#troubleshooting-urp)
+ [Cluster memiliki topik yang disebut \$1\$1amazon\$1msk\$1canary dan \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [Replikasi partisi gagal](#partition_replication_fails)
+ [Tidak dapat mengakses klaster yang mengaktifkan akses publik](#public-access-issues)
+ [Tidak dapat mengakses cluster melalui IPv6 bootstrap](#dualstack-issues)
+ [Tidak dapat mengakses klaster dari dalam AWS: Masalah jaringan](#networking-trouble)
+ [Otentikasi gagal: Terlalu banyak koneksi](#troubleshoot-too-many-connects)
+ [Otentikasi gagal: Sesi terlalu singkat](#troubleshoot-session-too-short)
+ [MSK Tanpa Server: Pembuatan cluster gagal](#troubleshoot-serverless-create-cluster-failure)
+ [Tidak dapat memperbarui KafkaVersionsList dalam konfigurasi MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## Penggantian volume menyebabkan saturasi disk karena kelebihan replikasi
Selama kegagalan perangkat keras volume yang tidak direncanakan, Amazon MSK dapat mengganti volume dengan instance baru. Kafka mengisi kembali volume baru dengan mereplikasi partisi dari broker lain di cluster. Setelah partisi direplikasi dan ditangkap, mereka memenuhi syarat untuk keanggotaan leadership dan in-sync replica (ISR).
**Masalah**
Dalam broker yang pulih dari penggantian volume, beberapa partisi dengan berbagai ukuran dapat kembali online sebelum yang lain. Ini bisa menjadi masalah karena partisi tersebut dapat melayani lalu lintas dari broker yang sama yang masih mengejar (mereplikasi) partisi lain. Lalu lintas replikasi ini terkadang dapat memenuhi batas throughput volume yang mendasarinya, yaitu 250 MiB per detik dalam kasus default. Ketika saturasi ini terjadi, partisi apa pun yang sudah tertangkap akan terpengaruh, menghasilkan latensi di seluruh cluster untuk setiap broker yang berbagi ISR dengan partisi yang tertangkap (bukan hanya partisi pemimpin karena acks jarak jauh). `acks=all` Masalah ini lebih sering terjadi pada cluster yang lebih besar yang memiliki jumlah partisi yang lebih besar yang ukurannya bervariasi.
**Rekomendasi**
+ Untuk memperbaiki I/O postur replikasi, pastikan [pengaturan utas praktik terbaik](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads) sudah ada.
+ Untuk mengurangi kemungkinan saturasi volume yang mendasarinya, aktifkan penyimpanan yang disediakan dengan throughput yang lebih tinggi. Nilai throughput min 500 MiB/s direkomendasikan untuk kasus replikasi throughput tinggi, tetapi nilai aktual yang dibutuhkan akan bervariasi dengan throughput dan kasus penggunaan. [Penyediaan throughput penyimpanan untuk pialang Standar di cluster MSK Amazon](msk-provision-throughput.md).
+ Untuk meminimalkan tekanan replikasi, turunkan `num.replica.fetchers` ke nilai default. `2`
## Kelompok konsumen terjebak di `PreparingRebalance` negara bagian
Jika satu atau lebih grup konsumen Anda terjebak dalam keadaan penyeimbangan kembali terus-menerus, penyebabnya mungkin masalah Apache Kafka [KAFKA-9752, yang memengaruhi Apache Kafka versi 2.3.1](https://issues.apache.org/jira/browse/KAFKA-9752) dan 2.4.1.
Untuk mengatasi masalah ini, kami sarankan Anda meningkatkan klaster Anda ke[Amazon MSK perbaikan bug versi 2.4.1.1](supported-kafka-versions.md#2.4.1.1), yang berisi perbaikan untuk masalah ini. Untuk informasi tentang memperbarui klaster yang ada ke Amazon MSK bug-fix versi 2.4.1.1, lihat. [Tingkatkan versi Apache Kafka](version-upgrades.md)
Solusi untuk menyelesaikan masalah ini tanpa memutakhirkan cluster ke Amazon MSK bug-fix versi 2.4.1.1 adalah dengan mengatur klien Kafka untuk digunakan[Protokol keanggotaan statis](#consumer-group-rebalance-static), atau ke [Identifikasi dan reboot](#consumer-group-rebalance-reboot) node broker koordinasi dari grup konsumen yang macet.
### Menerapkan protokol keanggotaan statis
Untuk menerapkan Protokol Keanggotaan Statis di klien Anda, lakukan hal berikut:
1. Atur `group.instance.id` properti konfigurasi [Konsumen Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) Anda ke string statis yang mengidentifikasi konsumen dalam grup.
1. Pastikan bahwa contoh lain dari konfigurasi diperbarui untuk menggunakan string statis.
1. Terapkan perubahan ke Konsumen Kafka Anda.
Menggunakan Protokol Keanggotaan Statis lebih efektif jika batas waktu sesi dalam konfigurasi klien diatur ke durasi yang memungkinkan konsumen untuk pulih tanpa memicu penyeimbangan ulang grup konsumen sebelum waktunya. Misalnya, jika aplikasi konsumen Anda dapat mentolerir ketidaktersediaan 5 menit, nilai yang wajar untuk batas waktu sesi adalah 4 menit, bukan nilai default 10 detik.
**catatan**
Menggunakan Protokol Keanggotaan Statis hanya mengurangi kemungkinan menghadapi masalah ini. Anda mungkin masih mengalami masalah ini bahkan saat menggunakan Protokol Keanggotaan Statis.
### Mem-boot ulang node broker koordinasi
Untuk me-reboot node broker koordinator, lakukan hal berikut:
1. Identifikasi koordinator grup menggunakan `kafka-consumer-groups.sh` perintah.
1. Mulai ulang koordinator grup grup konsumen yang macet menggunakan tindakan [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)API.
## Kesalahan saat mengirimkan log broker ke Amazon CloudWatch Logs
Saat Anda mencoba menyiapkan klaster untuk mengirim log broker ke Amazon CloudWatch Logs, Anda mungkin mendapatkan salah satu dari dua pengecualian.
Jika Anda mendapatkan `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded` pengecualian, coba lagi tetapi gunakan grup log yang dimulai dengan`/aws/vendedlogs/`. Untuk informasi selengkapnya, lihat [Mengaktifkan Logging dari Amazon Web Services tertentu](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Jika Anda mendapatkan `InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` pengecualian, pilih kebijakan CloudWatch Log Amazon yang ada di akun Anda, dan tambahkan JSON berikut ke dalamnya.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Jika Anda mencoba menambahkan JSON di atas ke kebijakan yang ada tetapi mendapatkan kesalahan yang mengatakan Anda telah mencapai panjang maksimum untuk kebijakan yang Anda pilih, coba tambahkan JSON ke salah satu kebijakan Amazon Logs Anda yang lain. CloudWatch Setelah Anda menambahkan JSON ke kebijakan yang ada, coba sekali lagi untuk menyiapkan pengiriman broker-log ke Amazon Logs. CloudWatch
## Tidak ada grup keamanan default
Jika Anda mencoba membuat klaster dan mendapatkan kesalahan yang menunjukkan bahwa tidak ada grup keamanan default, itu mungkin karena Anda menggunakan VPC yang dibagikan dengan Anda. Minta administrator Anda untuk memberi Anda izin untuk mendeskripsikan grup keamanan di VPC ini dan coba lagi. Untuk contoh kebijakan yang mengizinkan tindakan ini, lihat [Amazon EC2: Mengizinkan Mengelola Grup Keamanan EC2 yang Terkait Dengan VPC Tertentu, Secara Terprogram,](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html) dan di Konsol.
## Cluster tampak macet dalam status CREATING
Terkadang pembuatan cluster bisa memakan waktu hingga 30 menit. Tunggu selama 30 menit dan periksa status cluster lagi.
## Status cluster berubah dari CREATING menjadi FAILED
Coba buat cluster lagi.
## Status klaster AKTIF tetapi produsen tidak dapat mengirim data atau konsumen tidak dapat menerima data
+ Jika pembuatan klaster berhasil (status klaster`ACTIVE`), tetapi Anda tidak dapat mengirim atau menerima data, pastikan bahwa aplikasi produsen dan konsumen Anda memiliki akses ke klaster. Untuk informasi lebih lanjut, lihat panduan di[Langkah 3: Buat mesin klien](create-client-machine.md).
+ Jika produsen dan konsumen Anda memiliki akses ke cluster tetapi masih mengalami masalah dalam memproduksi dan mengkonsumsi data, penyebabnya mungkin [KAFKA-7697, yang mempengaruhi Apache Kafka](https://issues.apache.org/jira/browse/KAFKA-7697) versi 2.1.0 dan dapat menyebabkan kebuntuan di satu atau lebih broker. Pertimbangkan untuk bermigrasi ke Apache Kafka 2.2.1, yang tidak terpengaruh oleh bug ini. Untuk informasi tentang cara bermigrasi, lihat[Migrasikan beban kerja Kafka ke kluster MSK Amazon](migration.md).
## AWS CLI tidak mengenali Amazon MSK
Jika Anda telah AWS CLI menginstal, tetapi tidak mengenali perintah MSK Amazon, tingkatkan AWS CLI ke versi terbaru. Untuk petunjuk terperinci tentang cara meng-upgrade AWS CLI, lihat [Menginstal AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html). Untuk informasi tentang cara menggunakan perintah AWS CLI untuk menjalankan Amazon MSK, lihat[Fitur dan konsep utama MSK Amazon](operations.md).
## Partisi offline atau replika tidak sinkron
Ini bisa menjadi gejala ruang disk rendah. Lihat [Ruang disk hampir habis](#troubleshooting-lowdiskspace).
## Ruang disk hampir habis
Lihat praktik terbaik berikut untuk mengelola ruang disk: [Memantau ruang disk](bestpractices.md#bestpractices-monitor-disk-space) dan[Sesuaikan parameter retensi data](bestpractices.md#bestpractices-retention-period).
## Memori hampir habis
Jika Anda melihat `MemoryUsed` metrik berjalan tinggi atau `MemoryFree` hampir habis, itu tidak berarti ada masalah. Apache Kafka dirancang untuk menggunakan memori sebanyak mungkin, dan mengelolanya secara optimal.
## Produser mendapat NotLeaderForPartitionException
Ini sering merupakan kesalahan sementara. Tetapkan parameter `retries` konfigurasi produsen ke nilai yang lebih tinggi dari nilai saat ini.
## Partisi yang kurang direplikasi (URP) lebih besar dari nol
`UnderReplicatedPartitions`Metrik adalah salah satu yang penting untuk dipantau. Dalam cluster MSK yang sehat, metrik ini memiliki nilai 0. Jika lebih besar dari nol, itu mungkin karena salah satu alasan berikut.
+ Jika `UnderReplicatedPartitions` runcing, masalahnya mungkin cluster tidak disediakan pada ukuran yang tepat untuk menangani lalu lintas masuk dan keluar. Lihat [Praktik terbaik untuk pialang Standar](bestpractices.md).
+ Jika `UnderReplicatedPartitions` secara konsisten lebih besar dari 0 termasuk selama periode lalu lintas rendah, masalahnya mungkin Anda telah menetapkan pembatasan ACLs yang tidak memberikan akses topik ke broker. Untuk mereplikasi partisi, broker harus diberi wewenang untuk topik BACA dan DESKRIPSI. DESCRIBE diberikan secara default dengan otorisasi BACA. Untuk informasi tentang pengaturan ACLs, lihat [Otorisasi dan ACLs dalam dokumentasi](https://kafka.apache.org/documentation/#security_authz) Apache Kafka.
## Cluster memiliki topik yang disebut \$1\$1amazon\$1msk\$1canary dan \$1\$1amazon\$1msk\$1canary\$1state
Anda mungkin melihat bahwa klaster MSK Anda memiliki topik dengan nama `__amazon_msk_canary` dan satu lagi dengan nama`__amazon_msk_canary_state`. Ini adalah topik internal yang dibuat dan digunakan Amazon MSK untuk kesehatan klaster dan metrik diagnostik. Topik-topik ini dapat diabaikan dalam ukuran dan tidak dapat dihapus.
## Replikasi partisi gagal
Pastikan Anda belum mengatur ACLs CLUSTER\$1ACTIONS.
## Tidak dapat mengakses klaster yang mengaktifkan akses publik
Jika klaster Anda mengaktifkan akses publik, tetapi Anda masih tidak dapat mengaksesnya dari internet, ikuti langkah-langkah berikut:
1. Pastikan aturan masuk grup keamanan klaster memungkinkan alamat IP Anda dan port cluster. Untuk daftar nomor port cluster, lihat[Informasi pelabuhan](port-info.md). Juga pastikan bahwa aturan keluar grup keamanan memungkinkan komunikasi keluar. Untuk informasi selengkapnya tentang grup keamanan serta aturan masuk dan keluarnya, lihat [Grup keamanan untuk VPC Anda di Panduan Pengguna](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) Amazon VPC.
1. Pastikan alamat IP Anda dan port cluster diizinkan dalam aturan masuk ACL jaringan VPC cluster. Tidak seperti kelompok keamanan, jaringan tidak ACLs memiliki kewarganegaraan. Ini berarti Anda harus mengonfigurasi aturan masuk dan keluar. Dalam aturan keluar, izinkan semua lalu lintas (rentang port: 0-65535) ke alamat IP Anda. Untuk informasi selengkapnya, lihat [Menambahkan dan menghapus aturan](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) di Panduan Pengguna Amazon VPC.
1. Pastikan Anda menggunakan string bootstrap-broker akses publik untuk mengakses cluster. Kluster MSK yang memiliki akses publik diaktifkan memiliki dua string bootstrap-broker yang berbeda, satu untuk akses publik, dan satu untuk akses dari dalam. AWS Untuk informasi selengkapnya, lihat [Dapatkan broker bootstrap menggunakan Konsol Manajemen AWS](get-bootstrap-console.md).
## Tidak dapat mengakses cluster melalui IPv6 bootstrap
Jika Anda mengalami masalah saat menghubungkan ke cluster menggunakan string IPv6 bootstrap yang disediakan, ikuti langkah-langkah berikut:
1. Pastikan klien Anda memiliki alamat IPv4 dan IPv6 yang ditetapkan. Aplikasi klien Anda harus berjalan di subnet yang memiliki pengalamatan IPv4 dan IPv6 diaktifkan dan dikonfigurasi dengan benar. Periksa apakah VPC Anda memiliki blok IPv4 CIDR dan blok CIDR IPv6 terkait, konfirmasikan subnet Anda memiliki alamat IPv4 dan IPv6 yang diaktifkan, dan verifikasi instans EC2 atau lingkungan klien Anda memiliki keduanya dan alamat yang ditetapkan. IPv4 IPv6 Untuk informasi selengkapnya, lihat [Pengalamatan IP untuk subnet Anda VPCs dan subnet](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) di Panduan Pengguna Amazon VPC.
1. Pastikan IPv6 port yang relevan ada dalam aturan masuk dan keluar grup keamanan. Tambahkan aturan masuk untuk mengizinkan lalu lintas pada port klaster dari IPv6 alamat Anda dan konfigurasikan aturan keluar untuk mengizinkan IPv6 lalu lintas. Untuk nomor port tertentu, lihat [Informasi port](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) dalam dokumentasi MSK. Ingatlah untuk memperbarui keduanya IPv4 dan IPv6 aturan jika berjalan dalam mode dual-stack. Untuk informasi selengkapnya tentang grup keamanan serta aturan masuk dan keluarnya, lihat [Grup keamanan untuk VPC Anda di Panduan Pengguna](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) Amazon VPC.
1. Pastikan konfigurasi properti JVM benar untuk IPv6 dukungan. Dalam aplikasi klien Anda, atur `java.net.preferIPv6Addresses` ke `true` dan `java.net.preferIPv4Stack` ke`false`. Pengaturan ini dapat dikonfigurasi baik sebagai properti sistem atau argumen JVM. Mulai ulang aplikasi Anda setelah membuat perubahan ini agar diterapkan.
## Tidak dapat mengakses klaster dari dalam AWS: Masalah jaringan
Jika Anda memiliki aplikasi Apache Kafka yang tidak dapat berkomunikasi dengan sukses dengan kluster MSK, mulailah dengan melakukan tes konektivitas berikut.
1. Gunakan salah satu metode yang dijelaskan [Dapatkan broker bootstrap untuk cluster MSK Amazon](msk-get-bootstrap-brokers.md) untuk mendapatkan alamat broker bootstrap.
1. Dalam perintah berikut ganti *bootstrap-broker* dengan salah satu alamat broker yang Anda peroleh pada langkah sebelumnya. Ganti *port-number* dengan 9094 jika cluster diatur untuk menggunakan otentikasi TLS. Jika cluster tidak menggunakan otentikasi TLS, ganti *port-number* dengan 9092. Jalankan perintah dari mesin klien.
```
telnet bootstrap-broker port-number
```
Dimana nomor port adalah:
+ 9094 jika cluster diatur untuk menggunakan otentikasi TLS.
+ 9092 Jika cluster tidak menggunakan otentikasi TLS.
+ Nomor port yang berbeda diperlukan jika akses publik diaktifkan.
Jalankan perintah dari mesin klien.
1. Ulangi perintah sebelumnya untuk semua broker bootstrap.
Jika mesin klien dapat mengakses broker, ini berarti tidak ada masalah konektivitas. Dalam hal ini, jalankan perintah berikut untuk memeriksa apakah klien Apache Kafka Anda sudah diatur dengan benar. Untuk mendapatkan*bootstrap-brokers*, gunakan salah satu metode yang dijelaskan dalam[Dapatkan broker bootstrap untuk cluster MSK Amazon](msk-get-bootstrap-brokers.md). Ganti *topic* dengan nama topik Anda.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Jika perintah sebelumnya berhasil, ini berarti klien Anda diatur dengan benar. Jika Anda masih tidak dapat memproduksi dan mengkonsumsi dari aplikasi, debug masalah di tingkat aplikasi.
Jika mesin klien tidak dapat mengakses broker, lihat subbagian berikut untuk panduan yang didasarkan pada pengaturan mesin klien Anda.
### Klien Amazon EC2 dan cluster MSK di VPC yang sama
Jika mesin klien berada dalam VPC yang sama dengan kluster MSK, pastikan grup keamanan klaster memiliki aturan masuk yang menerima lalu lintas dari grup keamanan mesin klien. Untuk informasi tentang mengatur aturan ini, lihat [Aturan Grup Keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Untuk contoh cara mengakses cluster dari instans Amazon EC2 yang berada di VPC yang sama dengan cluster, lihat. [Mulai menggunakan Amazon MSK](getting-started.md)
### Klien Amazon EC2 dan kluster MSK berbeda VPCs
Jika mesin klien dan cluster berada dalam dua yang berbeda VPCs, pastikan hal berikut:
+ VPCs Keduanya mengintip.
+ Status koneksi peering aktif.
+ Tabel rute keduanya VPCs diatur dengan benar.
Untuk informasi tentang peering VPC, lihat Bekerja [dengan Koneksi Peering VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Klien lokal
Dalam kasus klien lokal yang diatur untuk terhubung ke kluster MSK menggunakan Site-to-Site VPN, pastikan hal berikut:
+ Status koneksi VPN adalah`UP`. Untuk informasi tentang cara memeriksa status koneksi VPN, lihat [Bagaimana cara memeriksa status terowongan VPN saya saat ini?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/) .
+ Tabel rute VPC klaster berisi rute untuk CIDR lokal yang targetnya memiliki format. `Virtual private gateway(vgw-xxxxxxxx)`
+ Grup keamanan klaster MSK memungkinkan lalu lintas pada port 2181, port 9092 (jika klaster Anda menerima lalu lintas teks biasa), dan port 9094 (jika klaster Anda menerima lalu lintas terenkripsi TLS).
Untuk panduan Site-to-Site VPN pemecahan masalah lainnya, lihat [Pemecahan Masalah Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Jika klien menggunakan Direct Connect, lihat [Pemecahan Masalah Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Jika panduan pemecahan masalah sebelumnya tidak menyelesaikan masalah, pastikan tidak ada firewall yang memblokir lalu lintas jaringan. Untuk debugging lebih lanjut, gunakan alat seperti `tcpdump` dan `Wireshark` untuk menganalisis lalu lintas dan untuk memastikan bahwa itu mencapai cluster MSK.
## Otentikasi gagal: Terlalu banyak koneksi
`Failed authentication ... Too many connects`Kesalahan menunjukkan bahwa broker melindungi dirinya sendiri karena satu atau lebih klien IAM mencoba menghubungkannya dengan tingkat yang agresif. Untuk membantu broker menerima tingkat koneksi IAM baru yang lebih tinggi, Anda dapat meningkatkan parameter [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms)konfigurasi.
Untuk mempelajari lebih lanjut tentang batas tarif untuk koneksi baru per broker, lihat [Kuota MSK Amazon](limits.md) halaman.
## Otentikasi gagal: Sesi terlalu singkat
`Failed authentication ... Session too short`Kesalahan terjadi ketika klien Anda mencoba terhubung ke klaster menggunakan kredensyal IAM yang akan kedaluwarsa. Pastikan Anda memeriksa bagaimana kredensyal IAM Anda disegarkan. Kemungkinan besar, kredensyal diganti terlalu dekat dengan kedaluwarsa sesi yang menyebabkan masalah di sisi server, dan kegagalan otentikasi.
## MSK Tanpa Server: Pembuatan cluster gagal
Jika Anda mencoba membuat kluster MSK Tanpa Server dan alur kerja gagal, Anda mungkin tidak memiliki izin untuk membuat titik akhir VPC. Verifikasi bahwa administrator Anda telah memberi Anda izin untuk membuat titik akhir VPC dengan mengizinkan tindakan. `ec2:CreateVpcEndpoint`
Untuk daftar lengkap izin yang diperlukan untuk melakukan semua tindakan MSK Amazon, lihat. [AWS kebijakan terkelola: MSKFull Akses Amazon](security-iam-awsmanpol-AmazonMSKFullAccess.md)
## Tidak dapat memperbarui KafkaVersionsList dalam konfigurasi MSK
Saat Anda memperbarui [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)properti di [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)sumber daya, pembaruan gagal dengan kesalahan berikut.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Saat Anda memperbarui `KafkaVersionsList` properti, AWS CloudFormation membuat ulang konfigurasi baru dengan properti yang diperbarui sebelum menghapus konfigurasi lama. Pembaruan CloudFormation tumpukan gagal karena konfigurasi baru menggunakan nama yang sama dengan konfigurasi yang ada. Pembaruan semacam itu membutuhkan [penggantian sumber daya](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Agar berhasil memperbarui`KafkaVersionsList`, Anda juga harus memperbarui properti [Nama](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) dalam operasi yang sama.
Selain itu, jika konfigurasi Anda dilampirkan dengan cluster apa pun yang dibuat menggunakan Konsol Manajemen AWS or AWS CLI, tambahkan berikut ini ke sumber daya konfigurasi Anda untuk mencegah [upaya penghapusan sumber daya yang gagal](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted).
```
UpdateReplacePolicy: Retain
```
Setelah pembaruan berhasil, buka konsol MSK Amazon dan hapus konfigurasi lama. Untuk informasi tentang konfigurasi MSK, lihat. [Konfigurasi Amazon MSK yang disediakan](msk-configuration.md)