Cloudflare beroperasi pada skala yang begitu besar sehingga bahkan setelah bekerja di sini selama bertahun-tahun, hal itu tidak terasa nyata. Kami memiliki ribuan server di seluruh dunia dengan petabyte RAM dan jutaan inti CPU, dan semuanya didorong hingga maksimal. Sebesar apa pun sumber daya itu terasa, mereka tetap terbatas, dan ketika Anda membutuhkan setiap layanan untuk berjalan di setiap node, itu tidak menyisakan ruang untuk pemborosan. Pada skala ini, peningkatan kecil sangat diperbesar, jadi bahkan peningkatan 1% sekaligus layak dirayakan. Dan beberapa penyesuaian berjumlah jauh lebih banyak: dalam posting ini, kita akan melihat bagaimana perubahan kecil pada satu algoritma secara signifikan mengurangi jejak memori salah satu layanan kami yang berbasis Pingora. Itu memungkinkan kami untuk memulihkan lebih dari 100TB RAM secara global, di atas 100TB memori yang berhasil dihemat tim DNS bulan lalu.

Jangan buang-buang Menjaga pembagian sumber daya yang adil antar tim tidaklah mudah, terutama di organisasi besar. Salah satu cara Cloudflare memastikan keseimbangan terjaga adalah melalui upaya tanpa lelah dari tim Performance yang luar biasa. Kisah ini dimulai dengan tiket yang diajukan oleh Ivan yang menemukan: Penggunaan memori berlebihan dari pingora-ketama di Pingora Backend Router. Temuannya adalah bahwa layanan penyeimbangan beban internal kami, Pingora Backend Router (ya, PBR), menggunakan memori jauh lebih banyak dari yang diharapkan — khususnya dalam struktur yang terkait dengan pingora-ketama, yang merupakan pustaka open-source kami untuk menangani hashing konsisten. Untuk membahas bagaimana kami mengatasi penggunaan memori yang tampak berlebihan ini, kita perlu membahas apa itu hashing konsisten, mengapa kami menggunakannya di PBR, dan bagaimana ia menjadi begitu haus memori. Sepanjang jalan, kita akan belajar sedikit Rust dan bahkan sedikit matematika.

Hashing konsisten Hashing konsisten adalah metode yang banyak digunakan untuk mendistribusikan tugas ke beberapa server dengan cara yang tidak memerlukan perubahan besar saat server ditambahkan atau dihapus. Secara internal kami menggunakannya untuk merutekan permintaan yang dapat di-cache ke server berdasarkan URL. Ini memungkinkan kami untuk menyimpan hanya satu salinan file per pusat data dan memberikan cara yang stabil untuk menemukan lokasi setiap file. Kami telah menyebutkan sistem ini sebelumnya, tetapi mari luangkan waktu untuk menelusuri bagaimana dan mengapa algoritma ini digunakan dan bagaimana cara kerjanya. Konsep kunci dari hashing konsisten adalah bahwa meskipun fungsi hash dapat menerima segala jenis input, outputnya terbatas pada satu bilangan bulat tak bertanda (bilangan bulat 32, 64, atau 128-bit tergantung pada fungsi hash mana). Ini memungkinkan kami untuk menghubungkan tugas dan server satu sama lain dengan cara yang konsisten. Sebagian besar diskusi tentang hashing konsisten membuat Anda membayangkan ruang output itu sebagai cincin melingkar yang kontinu yang membungkus dari nilai maksimumnya ke nol. Penggambaran ini menghasilkan beberapa visualisasi yang bagus, tetapi juga dapat membuat konsep sederhana tentang rentang bilangan bulat tampak lebih rumit dari yang seharusnya. Untuk diskusi kita, kita akan merepresentasikan output 32-bit dari fungsi hash kita sebagai garis bilangan. Sekarang, katakanlah kita memiliki satu set server, A, B, & C, dan satu set tugas t-z. Kita dapat memetakan masing-masing ke garis bilangan berdasarkan hash dari nilai representatifnya, seperti alamat IP untuk server dan kunci cache untuk tugas. Menetapkan tugas ke server sekarang hanya masalah menemukan server pertama di sebelah kiri setiap tugas. Kita dapat merepresentasikan ini secara visual dengan mewarnai wilayah hash yang akan dikaitkan dengan setiap server. Perhatikan bahwa rentang yang dicakup oleh server C membungkus ke awal, maka dari itu gagasan bahwa hash ada dalam sebuah cincin. Dan itu saja. Pada tingkat dasar, hashing konsisten sesederhana ini — tetapi tidak butuh waktu lama untuk melihat bahwa ada ruang untuk perbaikan. Perhatikan bahwa rentang yang dicakup oleh server A dalam contoh kita jauh lebih besar daripada B atau C. Ini adalah masalah karena fraksi permintaan yang ditangani server akan sebanding dengan ukuran rentangnya pada garis bilangan. Idealnya kita ingin menjamin setiap server akan memiliki ukuran yang sama, tetapi karena hash pada dasarnya adalah angka acak, kita harus...