Dalam lingkungan permainan multipemain berskala besar Roblox, pengguna membaca dan menulis data dengan volume dan kecepatan yang akan melampaui pola penyimpanan cache standar. Seorang pengguna mungkin tidak menyadari penundaan 200 milidetik pada halaman web standar yang menyimpan data statis, tetapi penundaan 200 milidetik dalam mengambil data interaksi atau metadata server di Roblox dapat menghentikan permainan dan mengganggu dunia game yang disimulasikan. Roblox beroperasi pada ekosistem data yang tidak dapat diprediksi, berkecepatan tinggi, dan bersifat sementara yang harus diambil dalam hitungan milidetik untuk menjaga imersi. 

Lapisan caching kami dirancang untuk bertindak sebagai peredam guncangan besar antara jutaan pengguna bersamaan dan penyimpanan persisten kami. Lapisan ini menangani beban puncak sebesar 1,38 miliar kueri per detik (QPS), dengan kluster logis tunggal mencapai lebih dari 100 juta QPS. Dalam posting ini, kami akan mengungkap bagaimana kami merancang layanan caching terfederasi untuk berskala melampaui batas node Redis® demi throughput yang sangat besar, sambil menghadapi lonjakan lalu lintas 10 kali lipat yang belum pernah terjadi sebelumnya di kluster terbesar kami.

Melampaui Batas Industri untuk Memenuhi Permintaan yang Terus Bertambah

Di Roblox, layanan caching kami dibangun di atas teknologi Redis®, dan satu kluster Redis® berpotensi mendukung hingga 1.000 node. Namun, batas empiris dan yang diterima industri jauh lebih rendah—sekitar 400–500 node.¹ Hal ini disebabkan oleh protokol Gossip yang terdesentralisasi dari Redis®, yang menggunakan komunikasi antar-node untuk berbagi informasi kesehatan, status, dan pemetaan shard. Pada kluster yang lebih besar dari beberapa ratus node, lalu lintas data dari protokol Gossip mulai mengonsumsi sumber daya CPU dan jaringan yang signifikan. Setiap node harus memproses pembaruan status dari jumlah peer yang terus bertambah, yang mengalihkan sumber daya dari tugas utama menyajikan data dengan latensi rendah. Beban kerja kontrol ini dapat menyebabkan ketidakstabilan dan kinerja yang tidak dapat diprediksi, itulah sebabnya penyedia cloud terkelola memberlakukan batasan node. Ini adalah batas praktis yang tidak dapat dilampaui tanpa mengorbankan keandalan.

Batas kluster tunggal yang praktis ini tidak cukup untuk mendukung platform yang beroperasi pada skala Roblox, di mana layanan backend terbesar menuntut lebih dari 100 juta QPS dari salah satu kluster Redis® logis kami pada puncaknya, naik dari 10 juta dalam tiga bulan.

Kami mengadopsi arsitektur federasi untuk mengatasi batasan arsitektural ini, dengan menempatkan proxy terbalik klien di depan beberapa kluster Redis® yang lebih kecil dan independen. Kami menerapkan batas 400 node per kluster untuk memastikan kinerja yang dapat diprediksi. 

Dari perspektif ribuan aplikasi dan layanan kami, proxy terbalik klien menampilkan kluster-kluster yang terpisah ini sebagai layanan caching tunggal, terpadu, dan skalabel. Federasi ini memungkinkan kami untuk melakukan skalabilitas horizontal hampir tanpa batas dengan hanya menambahkan lebih banyak kluster ke dalam federasi, sepenuhnya mengabaikan batasan protokol Gossip. Saat ini, penyebaran caching tunggal terbesar kami terdiri dari lebih dari 6.000 node Redis®, yang didukung oleh lebih dari 15 kluster Redis® independen—skala yang hanya dimungkinkan oleh model federasi ini.

Proses Migrasi Tiga Tahap

Beralih dari pengaturan tradisional ke arsitektur terintegrasi sambil mengelola ratusan klaster produksi aktif merupakan upaya yang signifikan. Pada akhir tahun 2024, banyak dari klaster ini sudah mendekati batas 400 node kami, sehingga transisi ke model berkapasitas lebih tinggi menjadi sangat mendesak. Tantangan utamanya adalah bahwa instance Redis® standar beroperasi secara terpisah dan tidak memiliki kesadaran inheren terhadap klaster lain, sehingga memerlukan metode khusus untuk mereplikasi data selama proses pemindahan.

Untuk mengatasi hal ini, kami mengembangkan jalur migrasi tiga tahap yang transparan, yang dirancang untuk mentransisikan layanan tanpa keterlibatan pelanggan atau perubahan di sisi aplikasi.

Alur Kerja Migrasi

1. Penulisan ganda: Kami mengonfigurasi proxy terbalik klien untuk melakukan penulisan ganda, mengirimkan data yang masuk ke kluster asli dan tujuan federasi baru secara bersamaan.
2. Paritas dan peralihan baca: Setelah proses penulisan ganda mengisi kluster baru dengan data yang identik, karena semua data dibatasi oleh waktu hidup (TTL), kami mengalihkan lalu lintas baca dari kluster lama ke arsitektur federasi baru.
3. Penonaktifan: Setelah memastikan stabilitas kluster baru, kami menghentikan semua operasi penulisan ke kluster asli dan menonaktifkannya.

Kami berhasil memindahkan layanan paling kritis kami ke model federasi yang mendukung lebih dari 6.000 node, jauh melampaui batasan kluster Redis® tunggal. 

Menangani Pertumbuhan Eksplosif Grow a Garden

Mulai April 2025, kami menghadapi tantangan kapasitas yang jarang dihadapi oleh layanan lain. Katalisnya adalah kesuksesan fenomenal Grow a Garden. Hanya dalam beberapa minggu setelah peluncuran, Grow a Garden mulai memecahkan tidak hanya rekor Roblox tetapi juga rekor industri game sepanjang masa untuk pengguna bersamaan (CCU). Hanya dalam tiga bulan, jumlah pemain game ini melonjak melampaui rekor CCU game tunggal kami sebelumnya sebesar 2,8 juta pemain hingga mencapai puncak lebih dari 21 juta. Pertumbuhan eksplosif ini mengirimkan lalu lintas 10 kali lipat ke kluster Redis® terbesar kami dan 3 kali lipat ke sistem caching secara keseluruhan.

Roblox menjalankan sistem caching kami pada mesin fisik di pusat data kami sendiri, dan pertumbuhan yang belum pernah terjadi sebelumnya ini tidak termasuk dalam rencana kapasitas jangka panjang kami. Untuk bertahan dari gelombang besar ini dan menjaga stabilitas platform, kami harus secara radikal meningkatkan efisiensi armada yang ada sambil memprioritaskan keandalan. 

Meningkatkan Efisiensi Selama Lonjakan

Pertama, kami perlu mengidentifikasi titik leher botol yang paling berdampak di sistem kami agar dapat memprioritaskan pekerjaan optimasi. Roblox Caching berjalan di dua kelompok perangkat keras yang berbeda: satu untuk node backend Redis® dan satu untuk Envoy. Armada Redis® kami terutama dibatasi oleh memori, sedangkan proxy klien dibatasi oleh komputasi. 

Untuk armada Redis® kami yang terikat memori, kami menerapkan kebijakan penjadwalan baru untuk menyeimbangkan pemanfaatan memori secara lebih baik di seluruh kelompok mesin fisik kami. Kami juga menyempurnakan ukuran kontainer untuk mengurangi fragmentasi memori. 

Untuk meningkatkan pemanfaatan CPU, kami menerapkan dua pengoptimalan utama pada sistem cache kami:

1. Penskalaan otomatis proxy klien: Kami menyesuaikan kebijakan penskalaan otomatis untuk armada proxy klien kami yang terikat komputasi. Dengan menurunkan deviasi yang diizinkan dari CPU target, kami mencapai pemanfaatan CPU rata-rata yang lebih tinggi untuk pekerjaan tanpa mengubah ambang batas peningkatan skala.
2. Pemeriksaan kesehatan klaster internal: Kami mengoptimalkan pemeriksaan kesehatan internal untuk menghilangkan detak jantung yang tidak perlu, mempertahankan interval deteksi asli sambil menghemat sumber daya komputasi.

Perubahan ini menghasilkan peningkatan pemanfaatan CPU hampir 10%. Terakhir, kami menempatkan dua beban kerja yang sangat berbeda ini ke dalam kumpulan mesin yang sama dengan isolasi tingkat kontainer cgroup, yang mengurangi kebutuhan kapasitas kami secara keseluruhan sebesar 25%.

Rekayasa untuk Keandalan yang Tak Tergoyahkan

Keandalan tetap menjadi prioritas utama kami, bahkan saat kami berupaya keras untuk memenuhi permintaan yang memecahkan rekor. 

Pengamatan Ujung ke Ujung

Kami pertama-tama berfokus pada pemahaman potensi kegagalan dengan berinvestasi besar-besaran pada tumpukan observabilitas kami untuk pemantauan kesehatan sistem caching secara komprehensif dan end-to-end. Dengan melacak keberhasilan server dan kegagalan sisi klien di seluruh siklus hidup permintaan, kami dapat mendeteksi dan mendiagnosis masalah dengan cepat, seringkali mencegah dampak pada pengguna. Misalnya, kami menambahkan deteksi hot key, yang mengambil sampel lalu lintas langsung untuk mengidentifikasi data yang diakses secara berlebihan dan membebani lapisan caching. Ketika sistem menandai hot key, kami dapat secara proaktif membatasi lalu lintas ke kunci-kunci ini baik di sisi server maupun klien untuk mencegah kelebihan beban sistem.

Penanganan Kegagalan

Dalam sistem terdistribusi berskala besar seperti ini, kegagalan parsial terkadang terjadi. Kami telah merancang sistem kami untuk menangani kegagalan ini dengan baik dan meminimalkan dampaknya.

• Kegagalan parsial dalam permintaan batch: Kami merancang ulang sistem untuk menangani kegagalan parsial dalam permintaan batch. Sebelumnya, kegagalan satu permintaan dalam permintaan batch yang dibagi akan menyebabkan seluruh batch gagal. Kini, permintaan dapat berhasil meskipun beberapa kunci gagal diambil.
• Mengurangi head-of-line blocking: Sistem caching diharapkan berjalan cepat. Penurunan kecepatan jaringan sekecil apa pun dapat menyebabkan permintaan menumpuk dan time out, fenomena yang dikenal sebagai head-of-line blocking. Kami telah menerapkan mekanisme retry cerdas dan strategi pooling koneksi di lapisan klien dan proxy untuk mencegah permintaan lambat tunggal memengaruhi permintaan lain.
• Injeksi kesalahan dan latensi: Untuk menguji ketahanan, kami secara rutin menyisipkan kegagalan terkontrol (pemadaman node, pemadaman rak, latensi jaringan, kesalahan API) ke dalam produksi menggunakan kerangka kerja injeksi kesalahan kami. Dengan menganalisis perilaku sistem dalam kondisi ini, kami secara proaktif mengidentifikasi dan memperbaiki kelemahan, memastikan keandalan yang berkelanjutan.

Ketahanan Sisi Klien

Untuk mencegah sistem caching kami kewalahan oleh lonjakan lalu lintas yang tiba-tiba, kami menerapkan ketahanan kegagalan sisi klien yang tangguh. Mekanisme ini beroperasi di tingkat aplikasi, memastikan bahwa tidak ada layanan tunggal yang dapat memonopoli sumber daya cache.

• Pembatasan laju untuk pengendalian aliran: Klien kami memiliki batasan pada total lalu lintas keluar, memastikan bahwa ia tidak mengirimkan lebih banyak permintaan daripada yang dapat ditangani oleh layanan backend. Permintaan dibatasi saat batas ini terlampaui, yang mencegah layanan kewalahan.
• Mekanisme percobaan ulang dan batas waktu: Pustaka klien kami menggunakan mekanisme percobaan ulang yang disesuaikan dengan cermat, termasuk batas waktu dan kuota percobaan ulang, untuk mencegah masalah thundering herd. Hal ini membatasi jangkauan dampak, membebaskan sumber daya, dan meningkatkan responsivitas sistem secara keseluruhan dengan mencegah sistem macet tanpa batas waktu dan percobaan ulang secara bersamaan yang membebani sistem.

Masa Depan Caching Roblox

Perjalanan caching Roblox dimulai dengan klaster Redis® bare-metal yang dikelola langsung oleh masing-masing pemilik aplikasi, kemudian beralih ke klaster Memcached yang dikelola oleh tim caching kami, dan akhirnya beralih ke model Redis®-as-a-service, di mana klaster Redis® disediakan sebagai layanan terkelola. Meskipun model ini terbukti sangat efektif pada skala kami saat ini, kami menyadari keterbatasannya dalam hal efisiensi layanan dan isolasi sumber daya untuk platform yang dinamis seperti Roblox.

Seiring pertumbuhan platform, kami berencana melakukan investasi besar dalam layanan caching multitenant generasi berikutnya yang dibangun di atas ValKey. Arsitektur ini dirancang untuk secara drastis mengurangi biaya dengan berbagi sumber daya bersama melalui multitenancy sambil memastikan isolasi data, sumber daya, dan kegagalan untuk setiap tenant. Tujuan kami adalah meningkatkan kinerja, skalabilitas, keandalan, dan efisiensi biaya infrastruktur caching kami secara signifikan untuk memenuhi tuntutan pengalaman yang semakin masif di Roblox.

Ucapan Terima Kasih: 

Pencapaian ini merupakan hasil kerja sama tim. Terima kasih kepada anggota tim lain yang telah berkontribusi secara signifikan: Utkarsh Singh, Karthick Ramachandran, Vineesha Kasireddy, Weiji Hu, dan Leon Gao.