Pernahkah kamu merasa Kafka mulai terasa berat dan lambat, seperti WiFi di jam sibuk? LinkedIn juga merasakan hal yang sama, dan mereka melakukan sesuatu tentang itu. Perkenalkan Northguard dan Xinfra, dua inovasi yang dirancang untuk menangani skala data raksasa LinkedIn. Bayangkan, dari 32 triliun record per hari, hingga 17 Petabyte data setiap hari, sudah pasti butuh solusi yang lebih dari sekadar oke.
Northguard: Kafka Naik Level
Kafka, meskipun populer, memiliki keterbatasan terutama dalam hal penskalaan dan pengelolaan pada skala besar. Northguard hadir sebagai solusi untuk masalah ini. Arsitektur Northguard yang terdiri dari data dan metadata yang di-shard, koordinasi terdesentralisasi, dan state global minimal, menghilangkan keterbatasan single-controller dan berbasis partisi pada Kafka.
Northguard itu seperti Kafka yang sudah diet ketat, rajin nge-gym, dan belajar manajemen keuangan. Data diorganisasikan ke dalam records, segments, ranges, dan topics.
- Records: Elemen dasar data (key, value, headers).
- Segments: Unit replikasi yang immutable (tidak bisa diubah).
- Ranges: Irisan keyspace yang berdekatan, mendukung dynamic splitting dan merging untuk penskalaan dan pengurutan.
- Topics: Kumpulan ranges yang mencakup seluruh keyspace, dengan kebijakan penyimpanan yang fleksibel untuk replikasi dan retensi.
Struktur yang mendetail ini memungkinkan keseimbangan beban, ketersediaan tinggi, dan penskalaan yang mulus. Broker secara alami melakukan self-balancing saat producers menghasilkan segments baru, sehingga menghilangkan kebutuhan rebalancing atau pergerakan data yang mahal saat brokers ditambahkan atau gagal. Ini seperti membersihkan kamar secara otomatis setiap hari, jadi tidak perlu lagi spring cleaning yang bikin frustrasi.
Arsitektur Cerdas: Data, Metadata, dan Semua yang Ada di Antaranya
Model metadata Northguard menggunakan replicated state machines (DS-RSM) yang didukung oleh Raft, di-shard di seluruh vnode. Setiap vnode mengelola metadata untuk topics, ranges, dan segments – melacak perubahan state (misalnya, pemisahan, penggabungan, sealing), set replika, dan kebijakan retensi.
Dengan melakukan sharding metadata melalui consistent hashing dan menggunakan koordinasi terdesentralisasi, Northguard menghindari bottleneck controller Kafka dan mendukung jutaan replika dengan konsistensi yang kuat dan ketersediaan tinggi. Jadi, alih-alih satu orang yang mengatur semuanya, ada tim yang bekerja bersama, memastikan tidak ada yang kewalahan.
LinkedIn juga mengoptimalkan protokol Northguard untuk performa dan daya tahan. Operasi metadata seperti membuat, menghapus, dan menanyakan menggunakan panggilan request/response unary yang diarahkan ke leaders vnode. Alur produce, consume, dan replikasi adalah protokol streaming yang disesuaikan dengan pipelining dan windowing untuk memaksimalkan throughput dan meminimalkan latensi.
Producers menulis ke segment leaders aktif, menerima acknowledgments hanya setelah fsync di semua replika, memastikan daya tahan yang kuat. Konsumen menggunakan model streaming serupa dengan flow yang dikendalikan oleh client, mendukung pembacaan high-throughput yang efisien. Replikasi segment aktif dan replikasi segment yang disegel menggunakan arsitektur streaming yang efisien yang sama, menghasilkan kinerja tinggi dan kemampuan self-healing Northguard.
Xinfra: Jembatan Antara Dunia Lama dan Baru
Migrasi dari Kafka ke Northguard pada skala LinkedIn membutuhkan transisi yang mulus dan tanpa downtime untuk ribuan aplikasi penting. Untuk mendukung ini, LinkedIn membangun Xinfra, lapisan Pub/Sub yang divirtualisasikan yang mengabstraksi physical clusters.
Xinfra memungkinkan topics untuk mencakup Kafka dan Northguard melalui mekanisme dual-write, memungkinkan migrasi live tanpa perubahan client. Ini seperti membangun jembatan baru di samping jembatan lama yang masih berfungsi, memungkinkan lalu lintas untuk terus mengalir tanpa gangguan.
Penyimpanan segment di Northguard bersifat pluggable, dengan implementasi "fps-store" default yang dioptimalkan untuk daya tahan dan latensi. Ia menggunakan write-ahead log (WAL), membuat satu file per segment, menerapkan Direct I/O untuk melewati buffering OS, dan memelihara indeks sparse di RocksDB.
Batches records di-flush dan di-fsync di seluruh replika dalam milidetik, memastikan daya tahan bahkan dalam skenario kegagalan. Desain ini menghindari inkonsistensi cache, mendukung pembacaan efisien dari segments lama, dan memungkinkan kinerja yang dapat diprediksi seiring pertumbuhan clusters.
Pengujian Tanpa Henti: Menjamin Keandalan Skala
Untuk memastikan keandalan pada skala, Northguard menjalani pengujian ketat di bawah simulasi deterministik. Seluruh clusters dan clients berjalan dalam lingkungan single-threaded yang terkontrol di mana kesalahan – seperti penutupan broker, partisi jaringan, kesalahan disk, dan peningkatan rolling – disuntikkan dan diputar ulang.
Metode ini memungkinkan LinkedIn untuk mensimulasikan aktivitas bertahun-tahun setiap hari, menangkap edge cases lebih awal, dan terus memvalidasi kebenaran dalam skenario kegagalan yang kompleks. Ini seperti memiliki crash test dummy untuk sistem datamu, memastikan semuanya aman sebelum diluncurkan ke dunia nyata.
Insinyur LinkedIn menyatakan bahwa mereka "telah berhasil memigrasikan ribuan topics dari Kafka ke Northguard, yang mencakup triliunan records per hari" dan bahwa lebih dari 90% aplikasi di LinkedIn sudah menjalankan clients Xinfra. Angka-angka berbicara sendiri.
LinkedIn sedang fokus untuk menyelesaikan implementasi Northguard dan Xinfra dalam sistem internal mereka, dan ketika mereka terus membangun, belajar, dan mengulangi tools ini, mereka akan mengeksplorasi kemungkinan open-sourcing. Jadi, pantau terus!
Intinya? Northguard dan Xinfra adalah bukti bahwa inovasi terus berjalan, bahkan di dunia data yang tampaknya tak terbatas. LinkedIn telah mengatasi masalah skala Kafka, dan menciptakan solusi yang menjanjikan masa depan yang lebih lancar dan efisien.
