Roblox’un devasa ölçekli çok oyunculu oyun ortamında, kullanıcılar standart önbellekleme modellerini alt üst edecek hacim ve hızda veri okur ve yazar. Bir kullanıcı, statik verileri önbelleğe alan standart bir web sayfasında 200 ms'lik bir gecikmeyi fark etmeyebilir, ancak Roblox'ta etkileşim verilerini veya sunucu meta verilerini alırken 200 ms'lik bir gecikme, oyun akışını durdurabilir ve simüle edilmiş oyun dünyasını bozabilir. Roblox, sürükleyiciliği korumak için milisaniyeler içinde alınması gereken, öngörülemez, yüksek hızlı ve geçici verilerden oluşan bir ekosistem üzerinde çalışır. 

Önbellekleme katmanımız, milyonlarca eşzamanlı kullanıcı ile kalıcı depolama alanımız arasında devasa bir amortisör görevi görecek şekilde tasarlanmıştır. Saniyede 1,38 milyar sorgu (QPS) gibi bir tepe yükünü işlerken, tek bir mantıksal küme 100 milyon QPS'yi aşmaktadır. Bu yazıda, en büyük küremizde eşi görülmemiş bir 10 kat trafik artışını yönetirken, devasa bir verim için Redis® düğüm sınırlarının ötesine ölçeklenebilecek bir federatif önbellekleme hizmetini nasıl tasarladığımızı ortaya koyacağız.

Sürekli Artan Talepleri Karşılamak İçin Sektör Sınırlarının Ötesine Geçmek

Roblox'ta, önbellekleme hizmetimiz Redis® teknolojisi üzerine kuruludur ve bir Redis® kümesi 1.000 düğüme kadar destekleme potansiyeline sahiptir. Ancak, deneysel ve sektör tarafından kabul edilen sınır çok daha düşüktür — yaklaşık 400–500 düğüm.¹ Bunun nedeni, sağlık, durum ve parça eşlemesini paylaşmak için düğümler arası iletişimi kullanan Redis®'in merkezi olmayan Gossip protokolüdür. Birkaç yüz düğümden daha büyük kümelerde, Gossip protokolünden gelen iletişim, önemli miktarda CPU ve ağ kaynağını tüketmeye başlar. Her düğüm, giderek artan sayıda eşten gelen durum güncellemelerini işlemek zorundadır ve bu da düşük gecikmeyle veri sunma gibi birincil görevden kaynakları çalar. Bu kontrol düzlemi yükü, istikrarsızlığa ve öngörülemeyen performansa yol açabilir; bu nedenle yönetilen bulut sağlayıcıları düğüm sınırları uygular. Bu, güvenilirlikten ödün vermeden aşılamayacak pratik bir tavandır.

Bu pratik tek küme sınırı, Roblox ölçeğinde çalışan bir platformu desteklemek için yeterli değildir; burada en büyük arka uç hizmeti, üç ay içinde 10 milyondan zirveye ulaşan 100 milyondan fazla QPS'yi mantıksal Redis® kümelerimizden birinden talep etmiştir.

Bu mimari sınırlamayı aşmak için birleşik bir mimari benimsedik ve birden fazla küçük, bağımsız Redis® kümesinin önüne bir istemci ters proxy yerleştirdik. Öngörülebilir performans sağlamak için küme başına 400 düğüm sınırı kullanıyoruz. 

Binlerce uygulamamız ve hizmetimiz açısından, istemci ters proxy'si bu farklı kümeleri tekil, birleşik ve ölçeklenebilir bir önbellekleme hizmeti olarak sunar. Bu federasyon, Gossip protokolünün kısıtlamalarını tamamen atlayarak, federasyona daha fazla küme ekleyerek neredeyse sınırsız bir şekilde yatay ölçeklendirme yapmamızı sağlar. Bugün, en büyük tek önbellekleme dağıtımımız, 15'ten fazla bağımsız Redis® kümesinin desteklediği 6.000'den fazla Redis® düğümünden oluşmaktadır; bu ölçek, yalnızca bu federasyon modeli sayesinde mümkün olmaktadır.

Üç Aşamalı Geçiş Süreci

Yüzlerce aktif üretim kümesini yönetirken geleneksel bir kurulumdan birleşik bir mimariye geçmek önemli bir girişimdi. 2024'ün sonunda, bu kümelerin çoğu zaten 400 düğüm sınırımıza yaklaşmıştı, bu da daha yüksek kapasiteli bir modele geçişi acil hale getiriyordu. Temel zorluk, standart Redis® örneklerinin izole bir şekilde çalışması ve diğer kümeler hakkında doğal bir farkındalığa sahip olmamasıydı; bu da taşıma sırasında verileri çoğaltmak için özel bir yöntem gerektiriyordu.

Bunu çözmek için, müşterilerin katılımı veya uygulama tarafında herhangi bir değişiklik olmaksızın hizmetleri geçirmek üzere tasarlanmış şeffaf, üç aşamalı bir geçiş süreci geliştirdik.

Geçiş İş Akışı

1. Çift yazma: Gelen verileri hem orijinal kümeye hem de yeni birleştirilmiş hedefe aynı anda göndermek üzere, istemci ters proxy'sini çift yazma gerçekleştirecek şekilde yapılandırdık.
2. Eşlik ve okuma geçişi: Çift yazma süreci yeni kümeyi aynı verilerle doldurduktan sonra, tüm veriler bir zaman sınırı (TTL) ile sınırlandırıldığından, okuma trafiğini eski kümeden yeni federasyon mimarisine geçirdik.
3. Hizmetten Çıkarma: Yeni kümenin kararlılığını doğruladıktan sonra, orijinal kümeye yönelik tüm yazma işlemlerini durdurduk ve kümeyi hizmetten çıkardık.

En kritik hizmetlerimizi, tek bir Redis® kümesinin sınırlarını çok aşan, 6.000'den fazla düğümü destekleyen bir federasyon modeline başarıyla taşıdık. 

Grow a Garden'ın Patlayıcı Büyümesini Yönetme

2025 yılının Nisan ayından itibaren, çok az hizmetin karşılaştığı büyüklükte bir kapasite sorunuyla karşı karşıya kaldık. Bunun katalizörü, Grow a Garden'ın olağanüstü başarısıydı. Lansmandan sadece birkaç hafta sonra, Grow a Garden sadece Roblox rekorlarını değil, aynı anda en fazla kullanıcı (CCU) sayısına ilişkin tüm zamanların oyun sektörü rekorlarını da kırmaya başladı. Sadece üç ay içinde, oyunun kitlesi önceki tek oyun CCU rekorumuz olan 2,8 milyon oyuncuyu aşarak 21 milyondan fazla bir zirveye ulaştı. Bu patlayıcı büyüme, en büyük Redis® kümemize 10 kat daha fazla trafik ve genel önbelleğe 3 kat daha fazla trafik gönderdi.

Roblox, önbellekleme sistemlerimizi kendi veri merkezlerimizdeki fiziksel makinelerde çalıştırıyor ve bu benzeri görülmemiş büyüme, uzun vadeli kapasite planımızın bir parçası değildi. Bu dev dalgayı atlatmak ve platformu istikrarlı tutmak için, güvenilirliği ön planda tutarken mevcut donanımımızın verimliliğini radikal bir şekilde artırmamız gerekiyordu. 

Artış Sırasında Verimliliği Artırma

İlk olarak, optimizasyon çalışmalarına öncelik verebilmek için sistemimizdeki en etkili darboğazları belirlememiz gerekiyordu. Roblox Caching, iki farklı donanım havuzunda çalışır: biri Redis® arka uç düğümleri, diğeri Envoy içindir. Redis® filomuz esas olarak bellek sınırlıyken, istemci proxy'si hesaplama sınırlıdır. 

Bellek sınırlı Redis® filomuz için, fiziksel makine gruplarımız arasında bellek kullanımını daha iyi dengelemek amacıyla yeni bir zamanlama politikası uyguladık. Ayrıca, bellek parçalanmasını azaltmak için konteyner boyutunu da ince ayarladık. 

CPU kullanımını iyileştirmek için önbellek sistemimize iki önemli optimizasyon uyguladık:

1. İstemci proxy otomatik ölçeklendirme: İşlemciye bağlı istemci proxy filomuz için otomatik ölçeklendirme politikasını ayarladık. Hedef CPU'dan izin verilen sapmayı azaltarak, ölçeklendirme eşiğini değiştirmeden işler için daha yüksek bir ortalama CPU kullanımı elde ettik.
2. Dahili küme durum kontrolleri: Gereksiz kalp atışlarını ortadan kaldırmak için dahili durum kontrollerini optimize ettik; böylece orijinal algılama aralığını korurken hesaplama kaynaklarından tasarruf ettik.

Bu değişiklikler, CPU kullanımında yaklaşık %10'luk bir iyileşme sağladı. Son olarak, bu iki çok farklı iş yükünü cgroup konteyner düzeyinde izolasyon ile aynı makine havuzunda bir araya getirdik ve bu sayede genel kapasite ihtiyaçlarımızı %25 oranında azalttık.

Sarsılmaz Güvenilirlik için Mühendislik

Rekor kıran talebi karşılamak için acele etsek de, güvenilirlik bizim için en önemli öncelik olmaya devam etti. 

Uçtan Uca Gözlemlenebilirlik

Öncelikle, önbellekleme sistemimizin kapsamlı ve uçtan uca durum izlemesi için gözlemlenebilirlik yığınımıza yoğun bir şekilde yatırım yaparak potansiyel arızaları anlamaya odaklandık. Tüm istek yaşam döngüsü boyunca sunucu başarılarını ve istemci tarafındaki arızaları izleyerek, sorunları hızlı bir şekilde tespit edip teşhis ettik ve çoğu zaman kullanıcıların etkilenmesini önledik. Örneğin, aşırı erişilen ve önbellek katmanını zorlayan verileri belirlemek için canlı trafiği örnekleyen sıcak anahtar algılama özelliğini ekledik. Sistem bir sıcak anahtarı işaretlediğinde, sistemin aşırı yüklenmesini önlemek için hem sunucu hem de istemci tarafında bu anahtarlara giden trafiği proaktif olarak kısıtlayabiliriz.

Arıza Yönetimi

Bu ölçekteki herhangi bir dağıtık sistemde, bazen kısmi arızalar meydana gelir. Sistemimizi, bu arızaları sorunsuz bir şekilde yönetmek ve etkilerini en aza indirmek üzere tasarladık.

• Toplu isteklerdeki kısmi arızalar: Toplu isteklerdeki kısmi arızaları yönetmek için sistemi yeniden tasarladık. Önceden, parçalanmış bir toplu istekte tek bir istek arızası, tüm toplu isteğin başarısız olmasına neden oluyordu. Artık bazı anahtarların alınması başarısız olsa bile istekler başarılı olabilir.
• Sıra başı engellemeyi azaltma: Önbellekleme sistemlerinin hızlı olması beklenir. Küçük bir ağ yavaşlaması bile isteklerin birikmesine ve zaman aşımına neden olabilir; bu duruma sıra başı engelleme denir. Tek bir yavaş isteğin diğerlerini etkilemesini önlemek için hem istemci hem de proxy katmanında akıllı yeniden deneme mekanizmaları ve bağlantı havuzu stratejileri uyguladık.
• Hata ve gecikme enjeksiyonu: Dayanıklılığı test etmek için, hata enjeksiyon çerçevemizi kullanarak üretim ortamına düzenli olarak kontrollü arızalar (düğüm kesintileri, raf kesintileri, ağ gecikmesi, API hataları) enjekte ediyoruz. Bu koşullar altında sistem davranışını analiz ederek, zayıflıkları proaktif olarak tespit edip düzeltir ve sürekli güvenilirliği sağlarız.

İstemci Tarafı Dayanıklılık

Önbellekleme sistemimizin ani trafik artışları nedeniyle aşırı yüklenmesini önlemek için, sağlam bir istemci tarafı hata dayanıklılığı uyguladık. Bu mekanizma uygulama düzeyinde çalışır ve hiçbir hizmetin önbellek kaynaklarını tek başına tekeline alamamasını sağlar.

• Akış kontrolü için hız sınırlaması: İstemcimizde toplam giden trafik için bir sınır vardır; bu sayede, arka uç hizmetinin işleyebileceğinden daha fazla istek gönderilmez. Bu sınır aşıldığında istekler kısıtlanır ve böylece hizmetin aşırı yüklenmesi önlenir.
• Yeniden deneme ve zaman aşımı mekanizmaları: İstemci kütüphanelerimiz, "thundering herd" sorunlarını önlemek için zaman aşımı ve yeniden deneme bütçesi dahil olmak üzere özenle ayarlanmış yeniden deneme mekanizmaları kullanır. Bu, etki alanını sınırlar, kaynakları serbest bırakır ve süresiz askıda kalma durumlarının ve eşzamanlı yeniden denemelerin sistemi aşırı yüklemesini önleyerek genel sistem yanıt hızını artırır.

Roblox Önbelleklemenin Geleceği

Roblox’un önbellekleme yolculuğu, her uygulama sahibi tarafından doğrudan yönetilen bare-metal Redis® kümeleriyle başladı, ardından önbellekleme ekibimiz tarafından yönetilen Memcached kümelerine geçti ve son olarak da bir Redis® kümesinin yönetilen hizmet olarak sunulduğu Redis®-as-a-service modeline geçiş yaptı. Bu model, mevcut ölçeğimizde oldukça etkili olduğunu kanıtlamış olsa da, Roblox gibi dinamik bir platform için hizmet verimliliği ve kaynak izolasyonu açısından sınırlılıklarını da kabul ediyoruz.

Platform büyümeye devam ettikçe, ValKey üzerine kurulu yeni nesil çok kiracılı bir önbellekleme hizmetine önemli bir yatırım yapmayı planlıyoruz. Bu mimari, çok kiracılılık yoluyla ortak kaynakları paylaşarak maliyetleri önemli ölçüde azaltırken, her kiracı için veri, kaynak ve arıza izolasyonunu sağlamak üzere tasarlanmıştır. Amacımız, Roblox'ta giderek artan devasa deneyimlerin taleplerini karşılamak için önbellekleme altyapımızın performansını, ölçeklenebilirliğini, güvenilirliğini ve maliyet verimliliğini büyük ölçüde artırmaktır.

Teşekkür: 

Bu başarı, ortak bir çabanın sonucudur. Önemli katkılarda bulunan diğer ekip üyelerine teşekkür ederiz: Utkarsh Singh, Karthick Ramachandran, Vineesha Kasireddy, Weiji Hu ve Leon Gao.