Ulang Tahun ke-1 Valkey: Bagaimana Fork Komunitas Melampaui Redis

• Redis Inc mengguncang kepercayaan komunitas dengan keputusan menutup sumber (beralih ke SSPL), tetapi komunitas pengembang berkumpul di sekitar fork Valkey dan terus mendorong inovasi serta kontribusi yang aktif
• Redis 8.0 kembali menjadi open source, dan pendirinya Antirez ikut kembali berpartisipasi dalam fitur baru serta optimasi, sehingga kedua kubu sama-sama menunjukkan perkembangan yang cepat
• Menurut hasil benchmark terbaru, Valkey 8.1.1 pada lingkungan 8vCPU mencatat performa SET 37% lebih tinggi dibanding Redis 8.0, dengan latensi p99 yang juga lebih rendah (performa GET juga unggul 16%)
• Dengan teknik tuning nyata seperti thread IO dan core pinning, Valkey mencapai peningkatan throughput lebih dari 3x di lingkungan multithreading sekaligus meminimalkan latensi
• Benchmark yang lebih mendekati lingkungan produksi serta praktik tuning juga dibagikan, termasuk hal-hal yang perlu diperhatikan saat menafsirkan hasil benchmark dan cara menerapkannya di lingkungan operasional nyata

---

Penutupan sumber Redis dan kemunculan Valkey

• Setahun lalu, Redis Inc (dahulu Garantia Data) merusak hubungan kepercayaan dengan komunitas melalui perubahan lisensi open source (mengadopsi SSPL)
• Sebagai solusi atas hal ini, fork terbuka Valkey lahir dan menjadi aset teknologi yang digunakan luas untuk sistem terdistribusi, cache, dan pemrosesan data real-time
• Di sisi Redis, upaya pemulihan kepercayaan juga dilakukan melalui kembalinya Antirez (pendiri), penguatan performa/fitur, dan kembalinya Redis 8.0 ke open source

Valkey 8.1 vs Redis 8.0: perbandingan performa

• Benchmark SET dilakukan pada kondisi yang sama: instance AWS c8g.2xl 8vCPU, item 1KB/3M keyspace/500 koneksi
  • Valkey 8.1.1: 999.8K RPS(p99 0.8ms)
  • Redis 8.0: 729.4K RPS(p99 0.99ms)
  • Valkey 37% lebih tinggi pada SET, 16% lebih tinggi pada GET, dan lebih cepat 30% pada SET p99 serta 60% pada GET p99
• Saat memakai 6 thread IO, Valkey meningkat dari 239K → 678K RPS (naik 2,8x), p99 dari 1.68ms → 0.93ms (turun 44%)
• Redis juga naik dengan thread IO dari 235K → 563K RPS, p99 dari 1.35ms → 0.84ms (turun 40%)

Dampak tuning multithreading/core

• Efek thread IO mulai terlihat jelas dari 3 thread ke atas, dan Valkey menunjukkan selisih yang lebih besar dibanding Redis setelah 4 thread
• Jika core IRQ (interrupt) dibatasi ke 2 core lalu Redis/Valkey dipasang tetap (pinning) ke 6 core sisanya, ada tambahan kenaikan performa
  • Valkey: 832K → 999.8K RPS (core/IRQ pinning, pemakaian CPU 80%)
  • Pemisahan core IRQ dan aplikasi meminimalkan tail latency serta meningkatkan efisiensi cache
  • Disediakan juga contoh penggunaan cpuset-cpus, --io-threads, dan lainnya di Docker

Reproduksi benchmark dan tips praktis

• Menggunakan instance AWS Graviton4(c8g.2xlarge) terbaru, serta cluster placement group
• Performa maksimum dicapai lewat core pinning/pemisahan IRQ/penyesuaian jumlah koneksi (sekitar 400~500)
• Ukuran keyspace/item juga perlu dituning; nilai dan keyspace yang lebih kecil meningkatkan hit rate cache L3
• Sangat disarankan memanfaatkan alat benchmark multithread seperti valkey-benchmark atau rpc-perf (tool berbasis Rust yang lebih dekat dengan penggunaan nyata)

  docker run --network="host" --rm --cpuset-cpus="2-7" \  
  valkey/valkey:8.0.1 valkey-benchmark \  
  -h 172.31.4.92 -p 6379 -t SET,GET -n 100000000 -c 256 \  
  -r 3000000 --threads 6 -d 1024  
  

Batasan dan hal yang perlu diperhatikan dalam pengukuran performa

• Hasil benchmark bisa berbeda dari lingkungan produksi nyata

  • Workload nyata melibatkan banyak faktor seperti campuran SET:GET, perubahan beban, target TPS, dan latensi jaringan
  • Saat jumlah koneksi melonjak, juga terlihat latensi antrean meningkat, throughput menurun, dan tail latency bertambah
  • Hasil dapat sangat berbeda tergantung tool/opsi benchmark, topologi jaringan, dan faktor lainnya

Tahapan pertumbuhan utama dan perkembangan komunitas

Proyek Valkey selama setahun terakhir berkembang aktif di berbagai sisi

• Melalui kolaborasi banyak pengembang dan perusahaan di GitHub dan tempat lain, proyek ini menambah fitur, memperbaiki bug, dan meningkatkan keamanan
• Upaya pada dokumentasi dan dukungan pengguna juga diperkuat untuk menurunkan hambatan masuk bagi pengguna baru
• Dalam pengelolaan proyek, pengambilan keputusan yang transparan dan voting komunitas ditekankan

Nilai bagi industri dan sisi teknis

Valkey memiliki keunggulan berikut

• Dapat digunakan siapa saja tanpa batasan lisensi, sehingga menjadi pilihan menarik bagi vendor layanan cloud maupun perusahaan web berskala besar
• Memiliki kompatibilitas tinggi dengan Redis sehingga migrasi juga mudah
• Karena dikembangkan oleh komunitas, beragam kebutuhan bisa lebih cepat diakomodasi lewat update berkelanjutan

Kesimpulan dan implikasi

• Valkey menunjukkan hasil yang melampaui Redis dalam aspek teknologi, performa, dan komunitas hanya dalam satu tahun sejak menjadi fork Redis
• Praktik tuning nyata seperti thread IO, pemisahan core/IRQ, dan pengaturan koneksi menjadi kunci
• Performa tidak datang secara otomatis; optimasi berkelanjutan yang sesuai dengan sistem/workload/infrastruktur tetap wajib dilakukan
• Di lingkungan layanan nyata, dibutuhkan pendekatan praktis dengan menguji langsung berbagai situasi, bukan hanya mengandalkan angka benchmark

[ethanhur]

Meskipun Redis memang membuat banyak keputusan yang keliru, tetap disayangkan kalau pihak yang bekerja keras justru bukan mereka yang menikmati hasilnya.

[kgcrom]

Ini adalah materi yang diunggah di Facebook "Redis User Group"
yang merangkum peningkatan apa saja yang dilakukan di Valkey 8.
https://www.facebook.com/groups/rediskorea/posts/3927030954110001/

Jika dibaca bersama isi di atas, sepertinya akan membantu untuk memahaminya.

[ndrgrd]

Sebenarnya bukan Valkey yang melakukan sesuatu... melainkan pihak sana yang runtuh dengan sendirinya...

[GN⁺]

Opini Hacker News

• Saya senang ValKey berhasil membuat kemajuan keren di bidang I/O threading, dan mulai mengadopsi beberapa perubahan yang paling menarik belakangan ini. Terima kasih banyak kepada para kontributor ValKey. Namun, saya rasa tulisan ini agak cenderung menyesatkan. Di Redis asli, arsitektur shared nothing adalah filosofi yang sangat penting, dan sayalah yang langsung memperkenalkan I/O threading pada 2020. Tanpa merusak semangat shared nothing, dengan mempertimbangkan bahwa syscall write(2)/read(2) bisa sangat lambat saat kembali dari event loop, saya memperkenalkan struktur yang pada titik itu memproses hanya I/O secara paralel di N thread dalam kondisi zero contention lalu segera kembali ke single thread sesudahnya. Saya berterima kasih karena tim ValKey telah mengembangkan sistem ini lebih jauh. Sistem itu sudah lama bekerja, dan saya kurang nyaman dengan kecenderungan media melebih-lebihkan data yang secara realistis tidak banyak berubah. Fitur-fitur seperti ini pada praktiknya lebih menarik bagi pengguna enterprise atau penyedia cloud (Amazon, Google, dan lain-lain) daripada mayoritas pengguna Redis biasa. Kecuali Anda memang harus menangani beban sangat besar atau banyak pengguna secara bersamaan, kenyataannya penggunaan CPU Redis untuk kebanyakan kasus rendah sehingga tidak perlu diaktifkan. Baru-baru ini, saat mengembangkan vector set data type di Redis, kami menjadikan threading sebagai default, dan penulisan vector set melalui VADD juga bisa dilakukan dengan pendekatan threaded. Struktur data seperti HNSW memiliki waktu konstan yang besar untuk pertama kalinya dalam sejarah Redis, jadi ruang desainnya sendiri berubah. Dulu saya juga sudah menerapkan dukungan thread untuk modul. Apakah thread dipakai atau tidak adalah keputusan yang bergantung pada situasi.
  • Sudut pandang yang bernuansa memang tidak mendatangkan klik
  • Rasanya tulisan kritik seperti ini naik ke beranda HN tiap bulan, dan saya selalu ingin mendukung antirez. Saya setuju dengan poin teknisnya, tetapi saya melihat kritik seperti ini sering kali berkaitan bukan dengan hal yang spesifik melainkan dengan tall poppy syndrome klasik—menyerang orang yang sangat sukses. Karena kita tidak bisa mengendalikan reaksi orang lain, mungkin lebih sehat jika menganggap tulisan kritik seperti ini sebagai pengakuan tidak langsung bahwa pencapaian Anda besar. Saya juga menghargai sudah terhubung di LinkedIn lihat Tall Poppy Syndrome
• Saya ingat antirez pernah mengumumkan bahwa Redis akan kembali menjadi open source tulisan terkait. Dulu Node.js hampir runtuh akibat drama fork Io.js, tetapi komunitas berhasil memulihkannya. Saya penasaran apakah Redis juga bisa pulih seperti itu. Saya dulu sering memakai Redis, tetapi beberapa tahun terakhir tidak terlalu mengikuti dinamika komunitasnya
  • Terakhir saya cek, Redis masih meminta CLA (Contributor License Agreement). Itu berarti mereka tetap punya hak eksklusif untuk menutup source lagi kapan saja. Jika kontributor harus menyetujui klausul seperti ini, tidak ada alasan untuk percaya mereka tidak akan mengulangi hal yang sama lagi
  • Redis didistribusikan dengan AGPL, Valkey dengan lisensi BSD (BSD adalah lisensi Redis dulu). Keduanya lisensi open source resmi, tetapi BSD jauh lebih permisif
  • Sejujurnya 99% pengguna tidak peduli siapa pemiliknya, selama penyimpanan key-value gratisnya berjalan baik. Dari sisi bisnis, Redis ada di posisi yang unik: fiturnya sangat banyak, tetapi pengguna nyata hanya memakai 5%-nya dan tidak peduli dengan fitur rumit seperti Sentinel/Streams. Saat Anda mencoba memonetisasinya, pilihan pengguna sangat beragam: "tidak memakainya saja", "pindah ke pesaing", "membangun sendiri hanya fitur yang benar-benar dibutuhkan", atau "fork versi open source terakhir lalu merawatnya sendiri demi menghemat biaya". Dibanding PostgreSQL, versi sederhana Redis (hashmap + antarmuka jaringan) lebih mudah dibuat sendiri, jadi bagi banyak bisnis, fork atau membangun sendiri adalah pilihan yang lebih baik
  • Menurut saya juga ini sudah terlambat. Setelah perubahan kebijakan Redis yang drastis, bagi saya Redis sekarang sudah tidak bisa dipercaya, dan ke depan Valkey akan jadi pilihan default. Sekali tertipu, kedua kali tidak akan percaya
  • Muncul pertanyaan bagaimana mungkin Redis bisa dipercaya setelah situasi yang mereka buat
• Saya rasa Valkey harus masuk ke package manager distribusi secara default. Misalnya saat hendak memasangnya di GitHub Action runner, repot sekali harus menambahkan key dan memperbarui distribusi setiap kali
  • Saya penasaran distribusi mana yang belum punya. Dari data repology, sepertinya sudah ada di nixpkgs, Arch, Ubuntu, Fedora, Debian, EPEL, dan lainnya. Hanya saja Debian mulai dari 13 atau 12+backports
  • Sebagai referensi, di Arch Linux Valkey sudah menggantikan Redis
  • Jika di CI pekerjaan pertama Anda setelah menarik image container adalah memasang ini-itu, lebih baik membuat image sendiri
• Saya sangat senang perubahan seperti ini terjadi dan Valkey terus berjalan baik. Semoga Redis segera menghilang
  • Dengan nada satir bahwa open source itu untuk perusahaan monopolistik, ada penyesalan bahwa hyperscaler seperti AWS menghasilkan ratusan juta dolar dari Redis tetapi para pengembang dan kontributor sebenarnya tidak menikmati manfaat itu. Karena itu startup database seharusnya sejak awal memakai fair source (lisensi dengan klausul anti-hyperscaler), sehingga siapa pun tetap bebas memakai kodenya, tetapi jika AWS atau Google ingin menjualnya sebagai managed service, mereka harus membayar. Disebutkan bahwa Redis dan Elasticsearch, yang sejak awal memakai lisensi sangat permisif, sudah sulit membalikkan nasib itu
• Belakangan ini makin banyak proyek dotnet beralih menjadi komersial. Perubahan seperti ini terasa bagi para pengembang seperti rug pull—perubahan kebijakan mendadak yang merusak kepercayaan. Suasana seperti ini juga bisa menghambat penyebaran library open source dotnet lain
  • Di .NET, kecenderungan komersialisasi seperti ini bukan hal baru; memang dari awal ada kecenderungan freeware/open-core dan bisnis selalu berjalan beriringan
• Saya sudah mendengar tentang Valkey sejak tahun lalu, dan senang melihatnya masih berjalan baik
• Saya penasaran apakah Valkey menyediakan library kliennya sendiri. Saat ini di lingkungan GCP saya memakai Redis/Redis Cluster baik di MemoryStore maupun lingkungan yang dikelola sendiri. Library C resmi mengecewakan saat dipakai dengan Redis Cluster+TLS, sehingga saya terpaksa memakai klien tidak resmi hiredis-cluster (https://github.com/Nordix/hiredis-cluster). Saya juga kurang puas dengan Memorystore milik GCP. Saya sedang mempertimbangkan pindah ke Scylla
  • Ada fork resmi bernama libvalkey yang menggabungkan hiredis dan hiredis-cluster, dikelola oleh para maintainer hiredis/hiredis-cluster yang sudah ada lihat libvalkey
• Sekarang Redis sudah mengubah kebijakannya, saya penasaran apakah Valkey dan Redis bisa berdialog lalu bergabung lagi
  • Ditunjukkan bahwa ini bukan benar-benar putar balik karena lisensinya tidak dikembalikan seperti semula, melainkan dipindah ke AGPL
• Dibagikan tautan tulisan penjelasan yang bagus tentang FUD (fear, uncertainty, doubt) seputar GPL yang diperkirakan akan muncul tulisan terkait
  • Saya merasa klaim dalam tulisan itu bahwa lisensi copyleft lebih bebas adalah logika yang agak terlalu mudah. Semakin banyak kewajiban, semakin berkurang kebebasan, jadi menurut saya pembahasan tentang gaya mana yang lebih "bebas" perlu lebih dalam
• Saya memakai Redis di puluhan aplikasi. Karena AWS menawarkan Valkey dengan harga diskon, saya mencobanya sejak 2 bulan lalu dan tidak merasakan perbedaan performa. Namun Valkey tiba-tiba macet total, dan AWS masih menganggapnya berjalan tetapi koneksi sepenuhnya terputus. Selama lebih dari 12 jam tidak pulih, lalu terulang lagi. AWS menyelidikinya selama 2 minggu tetapi tidak menemukan penyebabnya. Setelah itu sulit bagi saya memakai Valkey di lingkungan mission-critical. Kemudian saya menggantinya dengan Redis untuk workload yang sama dan tidak ada masalah
  • Mungkin ini masalah AWS. Kami juga pernah mengalami hal serupa pada cluster RDS postgres produksi. Respons jaringan berhenti, kami mendapat dukungan enterprise AWS, tetapi akhirnya tetap harus memulihkan backup sendiri untuk membuat cluster baru, memakan waktu 4 jam. Setelah itu kami menghindari layanan encapsulated AWS dan beralih ke EC2 biasa dengan replication, snapshot, replikasi S3, dan sebagainya
  • Bisa juga ini masalah operasional AWS; saya baru menjalankan Redis sendiri, jadi belum tentu masalahnya ada di Valkey itu sendiri
  • Saya penasaran kenapa tidak menjalankan instance Valkey sendiri
  • Saya ingin tahu jenis instance yang dipakai, untuk referensi