Cache Transcoding Cloudflare: Kompresi Zstd di Pingora Bisa Hemat Petabytes Storage

Biaya memori naik drastis belakangan ini. Harga RAM dan hard disk melonjak sepanjang tahun lalu, dan ini jadi masalah nyata bagi layanan yang mengandalkan cache dalam skala besar. Cloudflare menjalankan beberapa produk storage terdistribusi, termasuk CDN terkenalnya, yang bergantung pada efisiensi pemakaian memori supaya tetap bisa melayani semua pelanggan. Untuk menjawab tantangan ini, mereka memproteksi sebuah pendekatan bernama Cache Transcoding: mengompresi aset yang memenuhi syarat memakai Zstandard (zstd) di dalam Pingora, arsitektur proxy yang mereka bangun sendiri.

Idenya sederhana tapi dampaknya besar. Saat sebuah respons masuk ke cache, aset tersebut di-encode memakai zstd sebelum ditulis ke disk. Bentuk terkompresi itu dipertahankan selama aset hidup di cache dan berpindah antar data center lewat Tiered Cache, lalu di-decode kembali sebelum dikirim ke klien. Dalam pengujian awal, encoding ini mengecilkan aset yang memenuhi syarat menjadi sepertiga ukuran aslinya di disk. Estimasi biaya CPU ekstra di proxy yang menghadap origin memang ada, tapi kecil. Trade-off-nya jelas: sedikit tambahan CPU memberi Cloudflare kapasitas cache efektif sebesar petabyte dan mengurangi data yang ditransfer antar data center.

Biaya encoding hanya dibayar sekali, saat aset masuk cache. Hemat storage dan bandwidth terus berulang setiap kali aset itu dipakai lagi. Ini pola pikir yang menarik: alih-alih menambah hardware, ubah representasi data di disk.

Apa Itu Zstandard?

Zstandard, atau zstd, adalah algoritma kompresi lossless yang dikembangkan Yann Collet di Facebook dan dirilis open-source pada 2016. Lossless artinya setelah data terkompresi di-decode, setiap byte identik dengan data aslinya. Kita bisa mengubah cara aset direpresentasikan di disk tanpa mengubah aset itu sendiri.

Zstd dirancang untuk menyeimbangkan rasio kompresi dengan kecepatan. Dalam pengujian kompresi browser Cloudflare sebelumnya, zstd mengompresi data 42 persen lebih cepat daripada Brotli sambil menghasilkan ukuran file yang hampir sama, dan menghasilkan file 11,3 persen lebih kecil daripada gzip pada kecepatan yang sebanding. Keseimbangan ini penting karena Cache Transcoding akan menyentuh trafik dalam jumlah besar, jadi encoding dan decoding harus tetap cepat.

Prototype ini memakai zstd level 3, yang memberi sebagian besar manfaat kompresi tanpa mengubah cache fill menjadi bottleneck CPU. Cloudflare biasanya menyimpan aset memakai content encoding yang diberikan origin. Kalau origin mengirim respons tak terkompresi, byte mentahnya disimpan di disk dan dipindahkan antar data center dalam bentuk yang sama. Cache Transcoding menambahkan kompresi di dalam cache itu sendiri.

Semua Aset Tidak Layak Dikompresi

Transcoding bukan berarti mengompresi semuanya. Gambar, video, dan font biasanya sudah terkompresi. Dalam sampel trafik mereka, media ini mewakili 21,4 persen request tapi 63,3 persen byte. Mengompresinya lagi hanya akan membakar CPU tanpa hasil.

Teks yang bisa dikompresi berbeda cerita. HTML, JSON, CSS, dan JavaScript mewakili 67,3 persen request dan 22,3 persen byte. Di dalam slice teks itu, sekitar 71 persen tiba tanpa kompresi dengan Content-Encoding kosong, dan teks ini terkompresi dengan baik. Dalam korpus uji terkontrol, aset yang memenuhi syarat terkompresi sekitar 2,8 kali lipat.

Angka pengukuran dari pengujian mereka:

• Rasio kompresi: 2,834x
• Biaya encode: 4,31 ns per byte, sekitar 232 MB/detik, dibayar sekali per fill
• Biaya decode: 1,56 ns per byte, sekitar 641 MB/detik, dibayar setiap serve

Encoding memang lebih mahal per byte, tapi aset disajikan jauh lebih sering daripada diisi. Dengan mengubah cara aset direpresentasikan, hardware yang ada bisa menyimpan lebih banyak konten pelanggan. Lebih sedikit byte di disk berarti setiap server bisa menahan lebih banyak objek. Ini meningkatkan densitas cache dan mengurangi kemungkinan konten berguna ter-evict karena representasi tak terkompresi memakan lebih banyak ruang daripada yang diperlukan. Representasi yang lebih kecil juga membantu saat aset bergerak lewat Tiered Cache karena mengurangi data yang ditransfer antar data center Cloudflare, membuat pemakaian backbone lebih efisien.

Biaya Kompresi: Dibayar Sekali, Dinikmati Berkali-kali

Kompresi tidak pernah gratis. Encoding dan decoding sama-sama memakai CPU, jadi pertanyaan pentingnya adalah apakah hemat byte sebanding dengan biaya proses. Di zstd level 3, model mereka menjaga biaya CPU ekstra tetap di beberapa persen berdasarkan asumsi trafik dan reuse yang diuji.

Awalnya mereka sempat mempertimbangkan membatasi transcoding ke konten populer saja, karena aset panas lebih sering dipakai ulang. Ternyata itu tidak membantu. Decoding terjadi setiap kali aset disajikan, jadi membatasi fitur hanya ke konten terpanas mengurangi hemat storage tanpa memotong CPU di jumlah yang sama. Kebijakan yang lebih sederhana justru berkinerja lebih baik.

Transcoding semua teks kompresibel yang memenuhi syarat di atas 4 kibibyte (KiB) menangkap hampir seluruh manfaat storage yang terukur, sambil tetap berada dalam anggaran CPU. Ambang 4 KiB menghilangkan banyak request kecil dan hanya menyisakan sekitar 1 persen byte yang seharusnya memenuhi syarat. Menurunkannya akan menambah overhead per objek tanpa menghemat storage lebih banyak. Ambang dan level zstd ini adalah parameter, bukan batas permanen, jadi masih bisa dieksplorasi level kompresi yang lebih tinggi nantinya.

Bagaimana Cache Transcoding Bekerja

Pada cache miss, proxy berbasis Pingora meng-encode body memakai zstd sebelum menulisnya ke disk. Metadata cache mencatat bahwa representasi yang disimpan terkompresi dan mempertahankan panjang konten asli. Sebelum respons keluar dari proxy, body di-decode kembali ke representasi identitas aslinya.

Pada cache hit, objek zstd yang tersimpan dibaca dari disk dan di-decode. Dengan Tiered Cache, representasi terkompresi ditransfer dari upper tier ke lower tier dalam bentuk terkompresi. Decoding hanya terjadi di hop yang menghadap klien.

Pada cache miss penuh, upper tier mengambil byte identitas dari origin. Byte itu di-encode sekali, disimpan sebagai zstd, dan ditransfer ke lower tier dalam bentuk terkompresi. Lower tier juga menyimpan representasi zstd, lalu men-decode-nya untuk jalur request. Kalau lower tier miss tapi upper tier sudah punya objeknya, origin tidak terlibat sama sekali. Objek terkompresi bergerak langsung antar tier cache, tetap terkompresi di wire dan di disk, lalu di-decode sekali di lower tier.

Kalau lower tier sudah punya objeknya, tidak ada transfer jaringan atau encoding yang diperlukan. Lower tier membaca byte zstd dari disk, men-decode-nya, dan meneruskan aset asli. Penanda encoding storage mencegah objek di-encode lebih dari sekali. Tier cache yang menerima objek dari tier lain bisa melihat bahwa objek itu sudah disimpan memakai zstd dan mempertahankannya dalam bentuk tersebut.

Kenapa Hanya Teks Tertentu yang Di-Transcode

Operasi kompresi tercepat adalah operasi yang tidak perlu dilakukan. Cache Transcoding karena itu memakai serangkaian pemeriksaan kelayakan untuk menghindari konten yang tidak mungkin diuntungkan. Prototype hanya men-transcode respons 200 OK saat Content-Encoding kosong, Content-Type berupa teks kompresibel, dan respons punya Content-Length yang diketahui minimal 4 KiB. Slice subrequest, respons yang memakai kompresi upstream aktif, range request, respons terkompresi sebelumnya, body dengan panjang tak diketahui, dan konten biner semuanya dilewati.

Pengujian Lebih dari Satu Juta Request

Prototype ini diuji terhadap zone uji terkontrol, dengan setiap request dikorelasikan melintasi request log, metrik Prometheus, dan jejak Jaeger. Kampanye kebenaran mencakup cache miss, cache hit, single-hop fill, Tiered Cache fill, dan lainnya. Mereka memvariasikan cache key supaya setiap request mengikuti jalur tertentu dan memakai jejak untuk mengonfirmasi di mana encoding dan decoding terjadi.

Satu kampanye performa mengirim lebih dari satu juta request melintasi 10 cache server. Separuh kampanye berjalan dengan Tiered Cache nonaktif dan separuhnya lagi aktif. Ini memungkinkan pengukuran perilaku cache lokal secara terpisah dari transfer antar tier cache. Dua aset uji berukuran sekitar 195 KiB dan 272 KiB, dan keduanya terkompresi sekitar 2,8 kali lipat. Ini memang korpus uji yang sengaja bisa dikompresi, jadi hasilnya memberi sinyal yang jelas untuk memvalidasi arsitektur, tapi tidak mewakili setiap objek teks di internet. Korpus yang lebih luas diperlukan sebelum rasio kompresi terukur dianggap sebagai konstanta di seluruh fleet.

Pelajaran untuk Arsitektur Cache

Eksperimen ini menunjukkan masih ada efisiensi signifikan yang bisa diterapkan di layanan cache yang menguntungkan semua pelanggan. Cache Transcoding membuktikan trade-offnya menguntungkan dalam kondisi yang diuji: arsitektur mempertahankan konten dan tetap dalam anggaran CPU. Langkah berikutnya mencakup evaluasi level zstd yang lebih tinggi, pengujian tipe konten dan ukuran objek yang lebih luas, serta penyesuaian parameter lain dari kriteria kelayakan. Pekerjaan di masa depan juga bisa meneliti range request, respons origin yang sudah terkompresi sebelumnya, dan meneruskan objek terkompresi langsung ke komponen hilir yang sudah mendukungnya tanpa decoding.

Pola pikir "compress once, benefit many times" ini relevan untuk siapa pun yang membangun cache besar, baik di CDN, edge proxy, maupun server aplikasi sendiri. Sebelum menambah disk, coba lihat apakah representasi data di cache sudah efisien. Terkadang solusi storage terbesar bukan hardware baru, tapi mengubah cara byte disimpan.

Implikasi Biaya: Kenapa Ini Relevan Sekarang

Konteks ekonomi di balik eksperimen ini penting. Cloudflare menyebut harga RAM dan hard disk melonjak drastis dalam setahun terakhir. Untuk operator infrastruktur, ini berarti biaya penyimpanan cache bukan lagi angka yang bisa diabaikan. Menambah kapasitas dengan membeli disk baru di tengah kenaikan harga adalah keputusan yang mahal, sementara banyak byte di cache sebenarnya bisa dikompresi tanpa mengubah pengalaman pengguna sama sekali.

Pendekatan Cache Transcoding memindahkan beban dari storage yang mahal ke CPU yang relatif lebih murah dan sering kali belum termanfaatkan penuh. Ini pola yang sama dengan tren komputasi modern: alih-alih membeli lebih banyak hardware, optimalkan representasi data supaya hardware yang ada bisa menampung lebih banyak. Bagi perusahaan rintisan atau tim kecil yang menjalankan cache sendiri, ide ini bisa langsung diadaptasi: kompresi layer cache memakai zstd adalah optimasi yang terjangkau dan efeknya terukur.

Perbandingan dengan Pendekatan Kompresi Lain

Mengapa memilih zstd dan bukan gzip atau Brotli? Ketiganya adalah algoritma lossless yang matang, tapi profilnya berbeda. Gzip sudah menjadi standar de facto selama puluhan tahun dengan dukungan di hampir semua server dan klien, tapi rasionya kalah dari pesaing yang lebih baru. Brotli, yang dikembangkan Google, menawarkan rasio lebih baik daripada gzip tapi kecepatan kompresinya lebih lambat, terutama di level tertinggi.

Zstd berada di tengah: rasio kompresi mendekati Brotli, tapi kecepatan encoding dan decoding jauh lebih tinggi. Untuk skenario cache di mana encoding terjadi sekali per fill dan decoding terjadi setiap kali aset disajikan, kecepatan decoding yang tinggi sangat berharga. Data Cloudflare dari pengujian browser menunjukkan zstd mengompresi 42 persen lebih cepat daripada Brotli dengan ukuran hampir sama, dan 11,3 persen lebih kecil daripada gzip pada kecepatan sebanding. Level kompresi zstd juga bisa disetel dinamis, memberi fleksibilitas untuk menukar rasio dengan kecepatan sesuai kebutuhan trafik.

Keputusan memakai zstd level 3 sebagai titik awal mencerminkan konservatisme yang sehat: dapatkan sebagian besar manfaat kompresi tanpa mengambil risiko bottleneck CPU pada cache fill. Level yang lebih tinggi bisa dievaluasi setelah anggaran CPU awal dipahami, persis seperti yang direncanakan Cloudflare sebagai langkah berikutnya.

Arsitektur Pingora dan Kebebasan Bereksperimen

Bagian yang sering terlewat dari cerita ini adalah peran Pingora. Pingora adalah framework proxy yang ditulis Rust dan dikembangkan Cloudflare sebagai pengganti Nginx untuk layanan yang menghadap trafik besar. Salah satu keuntungan terbesar framework semacam ini adalah kontrol penuh atas siklus hidup request, termasuk kemampuan menyisipkan logika custom di titik mana pun: sebelum menulis ke cache, setelah membaca dari cache, atau saat mentransfer antar tier.

Dengan Nginx, mengubah perilaku cache sedalam ini biasanya butuh modul C yang kompleks atau konfigurasi yang membatasi. Dengan Pingora, logika Cache Transcoding hanyalah kode Rust biasa yang berjalan di dalam proxy. Inilah alasan Cloudflare bisa memproteksi ide eksperimental seperti ini selama program magang dan mengukurnya secara ketat dengan satu juta request.

Pelajaran arsitekturalnya: kemampuan bereksperimen di layer proxy adalah aset kompetitif. Tim yang bisa mengubah perilaku cache, routing, atau kompresi dengan cepat punya siklus inovasi yang jauh lebih pendek. Bagi developer yang membangun proxy sendiri, memilih framework yang memberi kontrol programatik penuh sejak awal bisa membuka optimasi yang tidak mungkin dilakukan di perangkat lunak kotak.

Kesimpulan

Cache Transcoding Cloudflare adalah contoh menarik bagaimana sebuah proxy modern seperti Pingora bisa membuka optimasi yang sebelumnya sulit dilakukan. Dengan memakai Zstandard untuk mengompresi aset cache sekali dan men-decode-nya hanya saat disajikan, mereka mendapat penghematan storage hingga sepertiga ukuran asli dan pengurangan transfer antar data center, dengan biaya CPU yang kecil dan terkendali. Kuncinya ada pada seleksi: hanya teks kompresibel di atas 4 KiB yang di-transcode, sehingga CPU tidak terbuang untuk media yang sudah terkompresi.

Untuk developer Indonesia yang mengelola infrastruktur sendiri, idenya bisa langsung diadopsi dalam skala kecil: kompresi di layer cache dengan zstd, seleksi aset yang benar-benar layak, dan pengukuran biaya CPU versus hemat byte. Tidak perlu menunggu skala Cloudflare untuk mulai berpikir seperti ini.