Instagram memiliki salah satu basis data Apache Cassandra terbesar di dunia. Proyek ini mulai menggunakan Cassandra pada 2012 untuk menggantikan Redis dan mendukung penerapan fitur aplikasi seperti sistem pengenalan penipuan, Tape dan Direct. Pada awalnya, cluster Cassandra bekerja di AWS, tetapi kemudian insinyur memigrasikannya ke infrastruktur Facebook bersama dengan semua sistem Instagram lainnya. Cassandra tampil sangat baik dalam hal keandalan dan toleransi kesalahan. Pada saat yang sama, metrik latensi saat membaca data jelas dapat ditingkatkan.
Tahun lalu, tim pendukung Instagram Cassandra mulai mengerjakan proyek yang bertujuan mengurangi latensi dalam membaca data secara signifikan di Cassandra, yang disebut oleh para insinyur bernama Rocksandra. Dalam artikel ini, penulis menceritakan apa yang mendorong tim untuk mengimplementasikan proyek ini, kesulitan yang harus diatasi, dan metrik kinerja yang digunakan insinyur di lingkungan cloud internal dan eksternal.
Alasan untuk Transisi
Instagram aktif dan banyak menggunakan Apache Cassandra sebagai layanan penyimpanan nilai kunci. Sebagian besar permintaan Instagram terjadi secara online, oleh karena itu, untuk memberikan pengalaman pengguna yang andal dan menyenangkan bagi ratusan juta pengguna Instagram, SLA sangat menuntut kinerja sistem.
Instagram mematuhi peringkat keandalan lima-sembilan. Ini berarti bahwa jumlah kegagalan pada waktu tertentu tidak dapat melebihi 0,001%. Untuk meningkatkan kinerja, para insinyur secara aktif memantau bandwidth dan latensi dari berbagai kelompok Cassandra, dan memastikan bahwa 99% dari semua permintaan masuk ke dalam indikator tertentu (penundaan P99).
Di bawah ini adalah grafik yang menunjukkan penundaan sisi klien dari satu untuk satu kelompok tempur Cassandra. Biru menunjukkan kecepatan baca rata-rata (5 ms), dan oranye menunjukkan kecepatan baca untuk 99%, mulai dari 25-60 ms. Perubahannya sangat tergantung pada lalu lintas klien.
Studi ini menemukan bahwa ledakan keterlambatan yang tajam sebagian besar disebabkan oleh pekerjaan pengumpul sampah JVM. Insinyur memperkenalkan metrik yang disebut "persentase pemberhentian CM" untuk mengukur persentase waktu yang dihabiskan untuk "menghentikan dunia" oleh server Cassandra, dan disertai dengan penolakan permintaan pelanggan. Berikut adalah grafik di atas yang menunjukkan jumlah waktu (dalam persen) yang pergi ke SM berhenti menggunakan contoh dari salah satu server tempur Cassandra. Indikator berkisar dari 1,25% pada saat lalu lintas terkecil hingga 2,5% pada saat beban puncak.
Grafik menunjukkan bahwa instance server Cassandra ini dapat menghabiskan 2,5% waktunya mengumpulkan sampah daripada melayani permintaan klien. Operasi pencegahan kolektor jelas memiliki dampak signifikan pada keterlambatan P99, dan karenanya menjadi jelas bahwa jika kita dapat mengurangi laju penghentian CM, maka para insinyur dapat secara signifikan mengurangi laju keterlambatan P99.
Solusi
Apache Cassandra adalah database terdistribusi berbasis Java dengan mesin penyimpan datanya sendiri berdasarkan pada pohon-pohon LSM. Insinyur menemukan bahwa komponen mesin seperti tabel memori, alat kompresi, jalur baca / tulis, dan beberapa lainnya menciptakan banyak objek dalam memori dinamis Java, yang menyebabkan JVM harus melakukan banyak operasi overhead tambahan. Untuk mengurangi dampak dari mekanisme penyimpanan pada pekerjaan pengumpul sampah, tim dukungan mempertimbangkan berbagai pendekatan dan akhirnya memutuskan untuk mengembangkan mesin C ++ dan menggantikan yang sudah ada dengannya.
Insinyur tidak ingin melakukan semuanya dari awal, dan karena itu memutuskan untuk mengambil RocksDB sebagai dasar.
RocksDB adalah database tertanam open-source berkinerja tinggi untuk penyimpanan nilai kunci. Ini ditulis dalam C ++, dan API-nya memiliki binding bahasa resmi untuk C ++, C, dan Java. RocksDB dioptimalkan untuk kinerja tinggi, terutama pada drive cepat seperti SSD. Ini banyak digunakan dalam industri sebagai mesin penyimpanan untuk MySQL, mongoDB, dan database populer lainnya.
Kesulitan
Dalam proses penerapan mesin penyimpanan baru di RocksDB, para insinyur menghadapi tiga tugas sulit dan menyelesaikannya.
Kesulitan pertama adalah bahwa Cassandra masih kekurangan arsitektur yang memungkinkan prosesor data pihak ketiga untuk dihubungkan. Ini berarti bahwa pekerjaan mesin yang ada agak berhubungan erat dengan komponen basis data lainnya. Untuk menemukan keseimbangan antara refactoring skala besar dan iterasi cepat, para insinyur mendefinisikan API mesin baru, termasuk antarmuka baca, tulis, dan streaming yang paling umum. Dengan demikian, tim dukungan dapat menerapkan mekanisme pemrosesan data baru untuk API dan memasukkannya ke jalur eksekusi kode yang sesuai di dalam Cassandra.
Kesulitan kedua adalah bahwa Cassandra mendukung tipe data terstruktur dan skema tabel, sementara RocksDB hanya menyediakan antarmuka kunci-nilai. Para insinyur dengan cermat mendefinisikan algoritma pengodean dan pengodean ulang untuk mendukung model data Cassandra dalam struktur data RocksDB dan memastikan kesinambungan semantik dari pertanyaan serupa di antara kedua basis data.
Kesulitan ketiga dikaitkan dengan komponen penting untuk setiap komponen basis data terdistribusi saat bekerja dengan aliran data. Setiap kali sebuah node ditambahkan atau dihapus dari cluster Cassandra, perlu untuk mendistribusikan data dengan benar antara node yang berbeda untuk menyeimbangkan beban dalam cluster. Implementasi yang ada dari mekanisme ini didasarkan pada memperoleh data terperinci dari mesin database yang ada. Oleh karena itu, para insinyur harus memisahkan mereka satu sama lain, membuat lapisan abstraksi dan menerapkan opsi baru untuk memproses aliran menggunakan API RocksDB. Untuk mendapatkan aliran arus yang tinggi, tim dukungan sekarang pertama-tama mendistribusikan data ke file sst sementara, dan kemudian menggunakan API RocksDB khusus untuk "menelan" file, memungkinkan mereka untuk dimuat secara bersamaan ke dalam instance RocksDB.
Indikator kinerja
Setelah hampir satu tahun pengembangan dan pengujian, para insinyur menyelesaikan versi pertama implementasi dan berhasil "meluncurkannya" di beberapa cluster Instagram Instagram Cassandra. Pada salah satu cluster tempur, penundaan P99 turun dari 60 ms menjadi 20 ms. Pengamatan juga menunjukkan bahwa perhentian SM di kluster ini turun dari 2,5% menjadi 0,3%, yaitu hampir 10 kali lipat!
Para insinyur juga ingin memeriksa apakah Rocksandra dapat bekerja dengan baik di lingkungan cloud publik. Tim dukungan menyiapkan cluster Cassandra di AWS menggunakan tiga instance EC3 i3.8 xlarge, masing-masing dengan prosesor 32-core, 244 GB RAM, dan nol serangan dari empat flash drive NVMe.
Untuk pengujian komparatif, kami menggunakan
NDBench , dan skema tabel default untuk framework.
TABLE emp ( emp_uname text PRIMARY KEY, emp_dept text, emp_first text, emp_last text )
Insinyur telah melakukan pra-muat 250 juta 6 baris masing-masing 6 KB (sekitar 500 GB data disimpan di setiap server). Selanjutnya, atur 128 pembaca dan penulis di NDBench.
Tim dukungan menguji berbagai muatan dan mengukur latensi baca dan tulis / P99 / P999 rata-rata. Grafik di bawah ini menunjukkan bahwa Rocksandra menunjukkan latensi baca dan tulis yang jauh lebih rendah dan lebih stabil.
Insinyur juga memeriksa beban dalam mode baca tanpa menulis dan menemukan bahwa dengan penundaan baca P99 yang sama (2 ms), Rocksandra mampu memberikan lebih dari 10 kali lipat dalam kecepatan membaca informasi (300 K / d untuk Rocksandra dibandingkan 30 K / d untuk C * 3.0).
Rencana masa depan
Tim dukungan Instagram telah membuka kode dan
kerangka kerja Rocksandra untuk mengevaluasi kinerja . Anda dapat mengunduhnya dari Github dan mencoba di lingkungan Anda sendiri. Pastikan untuk memberi tahu kami apa yang terjadi!
Sebagai langkah selanjutnya, tim secara aktif bekerja untuk menambahkan dukungan yang lebih luas untuk fungsionalitas C *, seperti indeks sekunder, perbaikan, dan banyak lagi. Dan selain itu, para insinyur sedang mengembangkan
arsitektur mesin basis data plug-in di C * untuk lebih lanjut mentransfer perkembangan ini ke komunitas Apache Cassandra.
