Önbellek Olarak Redis vs Veritabanı Olarak Redis

Redis bir projeye inanılmaz derecede sessiz girme eğilimindedir. Birisi can sıkıcı derecede yavaş bir veritabanı sorgusunu önbelleğe (cache) almak için onu araya atar, tamamen varsayılan ayarlarla (defaults) bırakır ve yoluna devam eder.

On sekiz ay sonra, tıpatıp aynı Redis sunucusu aynı zamanda aktif kullanıcı oturumlarını, istek sınırlayıcı (rate-limiting) sayaçları, özellik bayraklarının (feature flag) durumunu ve bir iki tane de arka plan iş kuyruğunu (job queue) tutuyordur. Ve bunların kesinlikle hiçbiri ilk olarak kalıcı bir veritabanına yazılmamıştır. Redis sunucusunun kendisi değişmemiştir. Ancak körü körüne ona emanet edilen işler kökten değişmiş, yapılandırması (config) ise neredeyse hiçbir zaman bu yeni gerçekliğe ayak uyduramamıştır.

Önbellek modu: Veriyi kaybetmek tasarım gereği sorunsuzdur

Redis gerçekten sadece ve sadece bir önbellek olarak çalıştığında, içindeki her bir anahtar (key) aslında başka bir yerde halihazırda var olan bir şeyin geçici kopyasıdır ya da onu yeniden üretmenin hesaplama maliyetidir.

Eğer Redis tamamen yeniden başlar ve önbellek sıfırlanırsa, uygulama kendi kendini yeniden doldurana kadar gözle görülür şekilde yavaşlar, ancak kalıcı olarak hiçbir şey kaybolmaz. Sırf bu özel senaryo için, doğru yapılandırma o gerçekliği aktif olarak kucaklar:

maxmemory 2gb
maxmemory-policy allkeys-lru
save ""

maxmemory-policy allkeys-lru ayarı, Redis sert bellek (memory) sınırına çarptığı saniye, yenilerine yer açmak için en uzun süredir kullanılmayan anahtarları agresif bir şekilde dışarı atması (evict) demektir. Bu, bir önbellek için tam olarak en doğru davranıştır. save "" ise RDB snapshot almayı tamamen devre dışı bırakır. İçerideki her şey %100 yeniden üretilebilir olduğundan, diske yazma maliyetine (I/O) değecek hiçbir şey yoktur.

Veritabanı modu: Veriyi kaybetmek gerçek bir felakettir

Redis'in, başka hiçbir yerde orijinali olmayan bir şeyi tuttuğu o an her şey değişir. Kaybolursa müşteriyi dışarı atan bir kullanıcı oturumu, henüz işlenmemiş arka plan işlerinden oluşan bir kuyruk veya aniden sıfırlanan kritik bir sayaç... İşte tüm o hesaplamalar tamamen tersine döner.

Artık allkeys-lru aktif olarak tehlikelidir. Redis sırf rastgele bir önbellek girdisine yer açmak için, aktif bir kullanıcının oturum anahtarını sessizce silmeye karar verebilir ve verecektir. Bu bir performans hıçkırığı değildir; doğrudan bir veri kaybıdır. Yapılandırmanın bu yeni gerçekliğe uyması zorunludur:

maxmemory-policy noeviction
appendonly yes
appendfsync everysec

noeviction ayarı, bellek tamamen dolduğunda Redis'in sessizce bir şeyleri silmek yerine, yazma işlemlerinde sert bir şekilde hata döndürmesi (error on writes) anlamına gelir. Bu sizi kritik verileri sessizce kaybetmek yerine, bir kapasite sorununu acımasızca fark etmeye ve gerçekten çözmeye zorlar. appendonly yes özelliği, kaya gibi sağlam bir kalıcılık (persistence) için yalnızca eklenebilir dosyayı (AOF - append-only file) etkinleştirir. everysec ise dayanıklılığı yazma performansına karşı mükemmel bir şekilde dengeler. Sert bir çökme anında, son RDB snapshot'ından bu yana olan her şeyi değil, en fazla bir saniyelik yazma işlemini kaybedersiniz.

Asıl tehlike ikisini kasıtsızca birbirine karıştırmaktır

En riskli kurulum ne "önbellek" ne de "veritabanı" kurulumudur. En risklisi, ikisini de tamamen aynı sunucuda (instance) ve sadece birisi için seçilmiş bir yapılandırma altında çalıştırmaktır.

allkeys-lru kuralını, çöpe atılabilir önbellek girdileri ve kritik oturum anahtarlarıyla tıpatıp aynı anahtar alanında (keyspace) çalıştırmak demek, Redis'in kelimenin tam anlamıyla "kaybetmesi sorun olmayan bir önbellek" ile "kaybedilmemesi gereken bir oturum" arasındaki farkı anlayamaması demektir. O sadece en uzun süredir kullanılmayan şey her neyse onu siler, ki bu ikisi de olabilir. Bunun, yük altında rastgele çıkış yaptırılan kullanıcılar (users randomly get logged out) sorununa yol açtığını bizzat gördüm. Belirtilerin hiçbiri doğrudan Redis'in silme politikasına (eviction policy) işaret etmediği için, sorunun önbellek baskısı (cache pressure) nedeniyle silinen oturum anahtarları olduğunu bulmak günlerce sürmüştü.

Onları ayırmak ayrı fiziksel sunucular anlamına gelmez

Redis, tek bir sunucu üzerinde (varsayılan olarak SELECT 0 ile SELECT 15 arası) birden fazla mantıksal veritabanını (logical database) kesinlikle destekler. Ancak, bunlar tıpatıp aynı maxmemory sınırını ve silme politikasını tamamen ortak kullanırlar, dolayısıyla bu sorunu hiçbir şekilde çözmezler.

Gerçekten işe yarayan şey, tamamen aynı fiziksel sunucuda olsa bile, her birinin yapılandırması kendi görevine mükemmel şekilde uyan tamamen ayrı iki Redis servisi (instance) çalıştırmaktır:

redis-server /etc/redis/cache.conf --port 6379
redis-server /etc/redis/store.conf --port 6380

Önbellek (cache) servisi allkeys-lru kuralını alır ve sıfır kalıcılıkla (persistence) çalışır. Depo (store) servisi ise noeviction ve AOF kalıcılığı ile çalışır. İdeal olanı, diğer tüm veritabanları gibi yedeklenmesidir, çünkü o noktadan sonra yasal olarak artık bir veritabanıdır.

Periyodik olarak sorulmaya değer o soru

Bir süredir çalışmakta olan herhangi bir Redis sunucusu için şu soruyu sorun: Eğer şu saniye şiddetli bir şekilde ortadan kaybolsaydı, sadece yavaşlamak yerine kalıcı olarak herhangi bir şey kaybolur muydu?

Eğer cevap kesin bir hayırsa, önbellek yapılandırmanız doğrudur ve değiştirecek hiçbir şey yoktur. Eğer cevap, sadece tek bir anahtar deseni (key pattern) için bile evetse, o artık bir veritabanıdır. Birileri bunu bilerek tasarlamış olsun ya da olmasın, o sorunun cevabını acı yoldan öğrenmeden önce, o sunucuyu tıpkı bir veritabanı gibi yapılandırmaya, izlemeye ve yedeklemeye kesinlikle değer.