Bagaimana Roblox Mengembangkan Platform Kafka-nya hingga Mampu Mengolah Lebih dari 18 Triliun Pesan per Hari

Dalam dua tahun terakhir, kami telah meningkatkan kapasitas platform antrian pesan internal kami lebih dari 2,5 kali lipat setiap tahunnya hingga mencapai lebih dari 18 triliun pesan per hari. Saat ini, kami memproses lebih dari 300 juta pesan per detik sambil mempertahankan ketersediaan sebesar 99,995%. Platform antrian pesan ini, yang dibangun di atas Apache Kafka, telah menjadi bagian penting dari cara kami memindahkan data di seluruh perusahaan. Platform ini mendukung beban kerja seperti peristiwa analitik, saluran moderasi, sistem pencocokan, dan banyak lagi. Angka-angka ini memang mengesankan, tetapi hal yang lebih penting adalah bagaimana kami bisa mencapainya. 

Dampak Optimalisasi Ujung ke Ujung 

Kesalahpahaman umum tentang sistem berskala besar adalah bahwa kapasitas sebagian besar merupakan masalah perangkat keras. Berdasarkan pengalaman kami, peningkatan yang paling berdampak dicapai dengan memperlakukan skalabilitas sebagai masalah rekayasa end-to-end.

Tim-tim di seluruh Roblox telah membangun berbagai platform di atas antrian pesan, termasuk jalur pelatihan AI, abstraksi pemrosesan aliran, dan sistem telemetri. Bekerja sama dengan pemilik platform-platform ini memungkinkan kami membantu memastikan kepatuhan terhadap praktik terbaik, seperti mengaktifkan pengelompokan dan kompresi. Hal ini menghasilkan sistem yang efisien tanpa melibatkan pengguna akhir dalam pengaturan konfigurasi yang rumit.

Selaras dengan tim yang menggunakan platform ini dalam hal prioritas bisnis, pengukuran, dan kriteria keberhasilan sangatlah penting dan membantu mendorong kolaborasi lintas tim. Metrik utama bervariasi di antara lapisan-lapisan sistem: Meskipun kami mungkin mengoptimalkan server Kafka untuk menangani volume data besar secara efisien dengan lebih sedikit mesin, pengguna akhir mungkin ingin mengoptimalkan latensi ujung ke ujung hingga tingkat milidetik, atau waktu total yang dibutuhkan pekerjaan batch mereka untuk menyelesaikan penulisan data. 

Tidak Semua Lalu Lintas Sama

Salah satu pelajaran penting yang kami pelajari adalah bahwa platform berskala besar lebih andal jika tidak memperlakukan semua lalu lintas secara sama. Beberapa beban kerja memerlukan latensi sangat rendah dan perlindungan yang kuat selama lonjakan, seperti sistem pencocokan kami, yang beroperasi dengan latensi end-to-end di bawah 10 milidetik. Sebagian lainnya memiliki volume yang sangat tinggi namun lebih toleran terhadap penundaan, seperti pipa pengumpulan peristiwa analitik kami, yang dapat berjalan lancar bahkan dengan latensi ujung ke ujung hingga beberapa detik. Jika keduanya ditangani secara identik, lalu lintas dengan volume tertinggi dapat menggeser lalu lintas yang lebih kritis bagi bisnis, terutama selama beban puncak.

Untuk mengatasi masalah ini, kami mengelompokkan lalu lintas berdasarkan persyaratan kasus penggunaan guna memastikan bahwa masing-masing didukung dengan baik. Kompromi antara latensi ujung ke ujung dan throughput di Kafka merupakan salah satu pertimbangan utama saat menyiapkan kasus penggunaan baru. Hal ini berlaku di sepanjang jalur data dari produser ke server hingga konsumen: Masing-masing memiliki konfigurasi yang dapat disesuaikan untuk mengoptimalkan throughput atau latensi. Konfigurasi sisi klien dapat disesuaikan untuk kasus penggunaan individual, tetapi konfigurasi sisi server kurang fleksibel, karena tidak mungkin mempertahankan kluster khusus untuk setiap kasus penggunaan yang berbeda. 

Kami menerapkan pendekatan ini, yaitu mengoptimalkan setiap kluster untuk kasus penggunaan yang dilayaninya, hingga ke lapisan perangkat keras. 

Perangkat Keras Tetap Penting

Kami memulai dengan menjalankan Kafka pada mesin HDD RAID10. Seiring meningkatnya volume lalu lintas, kapasitas I/O disk pada mesin kami menjadi hambatan utama yang membatasi throughput Kafka per server. Untuk mengatasi hal ini, kami melakukan dua optimasi. Kami mengonversi broker agar menggunakan SSD sebanyak mungkin, sehingga memindahkan titik leher botol dari kapasitas I/O disk ke throughput jaringan atau ruang disk (karena SSD yang kami peroleh memiliki ruang disk yang lebih sedikit). Hal ini meningkatkan throughput I/O disk sebesar 10 kali lipat. Kami juga mulai mengonversi HDD yang tersisa dari RAID10 ke RAID0. Langkah ini kira-kira menggandakan kapasitas I/O disk, karena setiap penulisan dengan RAID0 hanya memerlukan satu penulisan ke disk, bukan dua. 

Komprominya adalah, karena setiap replika pesan ditulis ke satu disk per broker alih-alih dua, peralihan dari RAID10 ke RAID0 dapat menimbulkan risiko keandalan. Untuk menjaga keandalan, kami mengutamakan kasus penggunaan penting dengan meningkatkan konfirmasi (acks) dan replikasi data, termasuk replikasi ke beberapa wilayah.

Memanfaatkan kapasitas penyimpanan dan throughput setiap mesin secara maksimal memerlukan upaya tambahan. Kami mengoptimalkan alokasi memori dan konfigurasi pengelolaan cache halaman agar Kafka dapat menyimpan pesan dalam buffer dan melayani pembacaan atau data terbaru dari memori, hanya mengakses disk dan mengonsumsi IOPS yang berharga saat diperlukan, seperti saat membaca data historis. 

Kami juga menjalankan uji kinerja untuk memahami batasan perangkat keras dan menentukan batasan tingkat perangkat lunak apa yang perlu kami tetapkan. Dalam praktiknya, ini berarti menetapkan pembatasan baca dan tulis broker Kafka, yang bervariasi berdasarkan perangkat keras tempat kluster berjalan. Mesin SSD kami dapat menangani throughput yang lebih tinggi per broker, sedangkan mesin HDD kami lebih cocok untuk kasus penggunaan yang memerlukan penyimpanan data historis dalam jangka panjang. 

Membangun untuk Keandalan

Platform antrian merupakan komponen kritis dari infrastruktur Roblox, dan menjaga keandalan sangatlah penting. Pengujian prapeluncuran serta pengujian skenario kegagalan yang berkelanjutan (kadang-kadang disebut latihan hari pertandingan) telah berperan penting dalam memvalidasi bahwa infrastruktur kami tangguh terhadap mode kegagalan seperti kegagalan satu host, kegagalan rak, masalah jaringan, dan banyak lainnya. Platform pengujian kekacauan internal tim keandalan kami telah memfasilitasi dan memperlancar proses simulasi berbagai skenario kegagalan. Pengujian ini membantu mengidentifikasi perbaikan sistem atau kemunduran, serta membangun keunggulan operasional dengan secara rutin memvalidasi peringatan dan memastikan bahwa operator terbiasa dengan langkah-langkah untuk menangani berbagai masalah—bahkan yang jarang terjadi.

Kami juga telah merancang dan menerapkan proses failover yang dapat dengan cepat memulihkan fungsionalitas antrian untuk kasus penggunaan yang bergantung padanya. Bahkan jika terjadi kegagalan total pada satu kluster, kami dapat mengalihkan klien ke kluster yang sehat dengan kapasitas yang memadai. Untuk memastikan ketersediaan kapasitas yang cukup, kami memelihara kluster Kafka siaga. Hal ini membantu menghilangkan risiko masalah “noisy neighbor” saat mengalihkan lalu lintas antar kluster yang aktif.

Diagram di bawah ini menunjukkan langkah-langkah umum untuk menjalankan failover. Pertama, seorang operator mengidentifikasi cakupan failover. Kemudian, topik dan daftar kontrol akses (ACL) dibuat di kluster siaga melalui operasi massal otomatis. Terakhir, operator memperbarui konfigurasi layanan control plane kami, yang dipantau oleh klien untuk menentukan apakah diperlukan koneksi ulang. Ilustrasi di bawah ini ditujukan untuk kasus penggunaan real-time umum. Kami memiliki strategi dan alat tambahan untuk kasus penggunaan dan skenario lain, termasuk pencerminan topik menggunakan Mirror Maker 2, alat pengisian data (backfill), dan lainnya.

Roblox memiliki persyaratan keamanan yang ketat, yang juga merupakan bagian penting dari keandalan. Kami telah menerapkan fitur keamanan standar seperti enkripsi saat transmisi (dengan mTLS), enkripsi saat penyimpanan (dengan disk terenkripsi), persyaratan masa retensi data, serta otentikasi/otorisasi menggunakan prinsipal Kafka dan ACL. Kami juga secara otomatis merotasi kredensial pengguna kami untuk lebih meningkatkan keamanan.

Selain itu, kami membangun penanganan khusus di bidang kontrol kami untuk memfasilitasi penambalan OS dan pengosongan rak yang cepat. Selama penambalan OS, kami menyimpan data di disk sehingga mesin yang telah ditambal dapat dengan cepat kembali berfungsi dengan baik setelah bergabung kembali dengan klaster Kafka. Dengan cara ini, kami dapat menambal seluruh armada kami dalam waktu 30 hari, bahkan saat armada tersebut terus bertambah. Dengan alat seperti Cruise Control, kami mereplikasi data kami dengan mempertimbangkan rak, sehingga seluruh rak dapat dimatikan untuk pemeliharaan dan penerapan patch jaringan tanpa memengaruhi ketersediaan data.

Langkah ke Depan

Bab berikutnya bagi platform antrian kami adalah membuat platform ini semakin sederhana bagi para pengembang sambil terus meningkatkan elastisitas dan isolasi. Kami berinvestasi dalam abstraksi baru, termasuk proxy produser dan konsumen serta konektor yang sepenuhnya dikelola. Sistem-sistem ini akan semakin memisahkan tim aplikasi dari kerumitan infrastruktur dan membuat platform kami lebih mudah diadopsi serta dikelola dalam skala besar. Misalnya, proxy konsumen akan memfasilitasi pola “competing consumer”, sehingga platform dapat mendukung rentang kasus penggunaan yang lebih luas dan memisahkan penskalaan prosesor dari penskalaan partisi Kafka. Hal ini sangat berguna untuk kasus penggunaan seperti pemrosesan lonjakan notifikasi massal, yang tidak memerlukan urutan tertentu dan dapat memanfaatkan peningkatan sementara jumlah prosesor tanpa harus terikat pada target pengiriman end-to-end yang harus tercapai.

Penskalaan Kafka bukan hanya soal meningkatkan jumlah dan ukuran kluster. Ini tentang membangun disiplin teknik, abstraksi, dan model operasional yang memungkinkan Roblox terus melanjutkan perjalanan kami untuk menghubungkan satu miliar orang setiap hari dengan optimisme dan kesopanan.