Menjelajahi batas bandwidth Kafka di Dropbox

Meluasnya penggunaan teknologi Apache-stack adalah tren yang jelas. Dan Kafka berada di garis depan popularitas: hari ini, orang-orang yang tahu broker pesan seperti itu, mungkin melebihi jumlah mereka yang terbiasa melihat kata Franz di sebelah kata Kafka.

Kami sendiri secara aktif menggunakan teknologi ini dalam proyek kami. Tapi itu selalu menarik, tetapi bagaimana cara kerjanya untuk orang lain? Dan ini sangat menarik jika ini bukan hanya contoh dari praktik seseorang, tetapi juga pengujian teknologi yang terfokus. Karenanya, kami telah menerjemahkan artikel terbaru yang membahas tentang bagaimana Dropbox secara empiris mencari batas peluang dan daya tahan di Kafka. Dan menemukan apa yang diinginkannya.

Menjelajahi batas bandwidth Kafka di Dropbox
Apache Kafka adalah solusi populer untuk streaming terdistribusi dan pemrosesan berurutan sejumlah besar data. Ini banyak digunakan di industri teknologi tinggi, dan tidak terkecuali Dropbox. Kafka memainkan peran penting dalam struktur data dari banyak sistem terdistribusi kritis kami - analisis data, pembelajaran mesin, pemantauan, pengambilan, dan pemrosesan aliran (Cape) (dan ini hanya beberapa).

Di Dropbox, cluster Kafka dikelola oleh tim Jetstream, yang tanggung jawab utamanya adalah menyediakan layanan berkualitas tinggi terkait dengan Kafka. Memahami batas bandwidth Kafka dalam infrastruktur Dropbox sangat penting untuk membuat keputusan yang tepat tentang bagaimana mengalokasikan sumber daya dalam berbagai kasus penggunaan, dan ini adalah salah satu tujuan prioritas tim. Kami baru-baru ini menciptakan platform pengujian otomatis untuk mencapai hal ini. Dan dalam publikasi ini kami ingin membagikan metode dan temuan kami.

Platform uji

Gambar di atas menunjukkan parameter platform pengujian kami untuk penelitian ini. Kami menggunakan Spark untuk melayani pelanggan Kafka, yang memungkinkan kami untuk menghasilkan dan menggunakan lalu lintas dalam volume yang sewenang-wenang. Kami membuat tiga cluster Kafka dengan ukuran yang berbeda, sehingga menyetel ukuran cluster secara harfiah dikurangi untuk mengarahkan lalu lintas ke titik lain. Kafka menciptakan topik untuk produksi dan konsumsi uji lalu lintas. Untuk mempermudah, kami telah mendistribusikan lalu lintas di semua broker secara merata. Untuk melakukan ini, kami membuat topik pengujian dengan jumlah bagian sepuluh kali jumlah broker. Setiap broker memimpin tepat 10 bagian. Karena menulis ke bagian adalah berurutan, terlalu sedikit partisi yang dialokasikan untuk satu broker dapat menyebabkan penulisan yang kompetitif, yang membatasi bandwidth. Percobaan kami menunjukkan bahwa 10 adalah angka yang baik untuk menghilangkan kesulitan bottleneck yang terkait dengan rekaman kompetitif.

Karena sifat terdistribusi dari infrastruktur kami, pelanggan kami berlokasi di berbagai wilayah di Amerika Serikat. Menimbang bahwa lalu lintas pengujian kami secara signifikan lebih rendah dari batas saluran saluran Dropbox, kami dapat dengan yakin mengasumsikan bahwa batas lalu lintas antar-wilayah ini juga berlaku untuk lalu lintas lokal.

Apa yang memengaruhi beban?

Ada banyak faktor yang dapat mempengaruhi beban cluster Kafka: jumlah produsen, jumlah kelompok konsumen, offset awal konsumen, jumlah pesan per detik, ukuran setiap pesan, jumlah topik dan bagian yang terlibat. Dan ini hanya beberapa di antaranya. Tingkat kebebasan dalam menetapkan parameter tinggi. Jadi, kita perlu menemukan faktor dominan untuk mengurangi kompleksitas pengujian ke tingkat yang dapat diterima.

Kami memeriksa berbagai kombinasi parameter yang kami temukan cocok. Kami sampai pada kesimpulan yang tidak mengejutkan bahwa faktor dominan yang harus diperhitungkan adalah komponen utama dari beban: jumlah pesan yang dihasilkan per detik (s / s) dan jumlah byte per pesan (b / s).

Model lalu lintas

Kami mengambil pendekatan formal untuk memahami keterbatasan Kafka. Ada ruang lalu lintas terkait untuk kluster Kafka tertentu. Setiap titik dalam ruang multidimensi ini sesuai dengan keadaan lalu lintas unik yang berlaku untuk Kafka dan disajikan sebagai vektor parameter: <s / s, b / s, # produsen, # grup konsumen, # topik, ...>. Semua status lalu lintas yang tidak menghasilkan kemacetan KafKa membentuk subruang tertutup yang permukaannya akan membatasi kluster Kafka.

Untuk pengujian pertama kami, kami memilih s / s dan b / s sebagai parameter utama dan mengurangi ruang lalu lintas menjadi bidang dua dimensi. Batas-batas lalu lintas yang diizinkan membentuk area pelacakan yang jelas. Deteksi batas Kafka dalam kasus kami setara dengan menentukan nilai batas area ini.

Otomasi Tes

Untuk mengatur batas dengan akurasi yang cukup, diperlukan untuk melakukan ratusan tes dengan berbagai parameter - yang akan sangat tidak rasional untuk dilakukan secara manual. Karena itu, kami telah mengembangkan algoritma yang memungkinkan Anda untuk melakukan semua percobaan tanpa campur tangan manusia.

Tingkat kemacetan

Sangat penting untuk menemukan serangkaian indikator yang memungkinkan Anda mengevaluasi status Kafka secara terprogram. Kami memeriksa berbagai indikator yang mungkin dan menetapkan sampel kecil berikut:

• aliran I / O sederhana di bawah 20%: ini berarti kumpulan alur kerja yang digunakan oleh Kafka untuk memproses permintaan klien terlalu sibuk dan tidak dapat menangani tugas yang masuk.
• perubahan dalam set replika sinkronisasi (ISR) lebih dari 50%: ini berarti bahwa ketika menggunakan lalu lintas untuk 50% dari waktu yang diamati, setidaknya satu broker tidak punya waktu untuk menggandakan data yang diterima dari pemimpinnya.

Indikator yang sama digunakan di Jetstream untuk memantau status Kafka dan berfungsi sebagai sinyal alarm pertama kelebihan beban kluster.

Temukan batas

Untuk menentukan satu nilai batas, kami memperbaiki b / s dan kemudian mengubah s / s untuk membuat Kafka kelebihan beban. Dimungkinkan untuk menentukan nilai batas s / s ketika kita mengetahui nilai safe s / s dan dekat dengannya, tetapi sudah menyebabkan kelebihan. Dari keduanya, nilai safe s / s diambil sebagai nilai batas. Seperti yang ditunjukkan di bawah ini, garis nilai batas dibentuk menurut hasil pengujian serupa dengan indikator berbeda b / s:



Perlu dicatat bahwa alih-alih langsung mengatur s / s, kami bereksperimen dengan sejumlah pabrikan yang memiliki kecepatan produksi yang sama, dilambangkan dengan np. Masalahnya adalah bahwa pemrosesan batch pesan mempersulit kontrol atas kecepatan produksi satu pabrikan. Sebaliknya, perubahan jumlah pabrikan memungkinkan Anda mengubah lalu lintas secara linear. Menurut penelitian awal kami, peningkatan sederhana dalam jumlah pabrikan tidak akan membuat perbedaan yang nyata pada beban pada Kafka.

Untuk mulai dengan, kami menemukan nilai batas yang terpisah menggunakan pencarian biner. Pencarian dimulai dengan rentang yang sangat besar np [0, maks], di mana maks adalah nilai yang akan menyebabkan kelebihan beban. Di setiap iterasi, nilai rata-rata dipilih untuk membuat lalu lintas. Jika Kafka kelebihan beban dengan nilai ini, maka nilai rata-rata ini menjadi batas atas baru; jika tidak, itu menjadi batas bawah baru. Proses pencarian berhenti ketika kisaran cukup sempit. Kemudian kami mempertimbangkan indikator s / s, yang terkait dengan batas bawah yang ditetapkan dari nilai batas.

Hasil



Seperti yang Anda lihat pada diagram di atas, kami menetapkan nilai batas untuk Kafka dengan berbagai ukuran. Berdasarkan hasil, kami sampai pada kesimpulan bahwa throughput maksimum yang mungkin dari infrastruktur Dropbox adalah 60 Mb / s per broker.

Harus ditekankan bahwa ini adalah batas konservatif, karena konten pesan pengujian kami adalah acak mungkin untuk mengurangi efek kompresi pesan internal di Kafka. Ketika lalu lintas mencapai batasnya, drive dan jaringan sepenuhnya digunakan. Dalam skrip yang berfungsi, pesan Kafka biasanya sesuai dengan pola tertentu, karena mereka sering dibentuk oleh algoritma yang sama. Ini memberikan peluang signifikan untuk mengoptimalkan kompresi pesan. Kami menguji skenario ekstrem, ketika pesan terdiri dari satu karakter, dan mencatat throughput yang jauh lebih tinggi, karena disk dan jaringan tidak lagi menjadi hambatan.

Selain itu, indikator throughput ini benar jika setidaknya ada 5 kelompok konsumen yang berlangganan topik yang diuji. Dengan kata lain, bandwidth rekaman yang ditunjukkan tercapai ketika bandwidth membaca 5 kali lebih besar. Ketika jumlah kelompok konsumen melebihi 5, bandwidth rekaman mulai menurun ketika jaringan menjadi hambatan. Karena rasio lalu lintas baca dan tulis jauh lebih kecil dari 5 dalam kasus di mana kluster produksi Dropbox digunakan, bandwidth yang diperoleh meluas ke semua kluster produksi.

Hasil ini akan membantu Anda merencanakan sumber daya yang lebih baik untuk Kafka di masa depan. Misalnya, jika kami ingin mengizinkan hingga 20% dari semua broker bekerja offline, maka bandwidth aman maksimum dari satu broker adalah 60 MB / s * 0,8 ~ = 50 Mb / s. Angka ini selanjutnya dapat digunakan untuk menentukan ukuran cluster, tergantung pada throughput yang direncanakan kasus penggunaan masa depan.

Alat untuk pekerjaan di masa depan

Platform dan penguji otomatis akan menjadi alat yang berharga untuk tim Jetstream dalam pekerjaan mereka di masa depan. Ketika kita pindah ke perangkat keras baru, mengubah konfigurasi jaringan atau memperbarui versi Kafka, kita dapat menjalankan kembali tes ini dan mendapatkan data baru pada batas yang diizinkan dari konfigurasi baru. Kita dapat menerapkan metodologi yang sama untuk mempelajari faktor-faktor lain yang dapat mempengaruhi kinerja Kafka dengan berbagai cara. Akhirnya, platform dapat bertindak sebagai teststream Jetstream untuk mensimulasikan opsi lalu lintas baru atau untuk mereproduksi masalah di lingkungan yang terisolasi.

Untuk meringkas

Dalam artikel ini, kami memperkenalkan pendekatan sistematis kami untuk memahami keterbatasan Kafka. Penting untuk dicatat bahwa kami telah mencapai hasil ini berdasarkan infrastruktur Dropbox, sehingga angka kami mungkin tidak berlaku untuk instalasi Kafka lainnya karena perbedaan dalam perangkat keras, perangkat lunak, dan kondisi jaringan. Kami berharap metodologi yang disajikan di sini dapat membantu pembaca memahami sistem mereka sendiri.