Veritabanı Önünde Cache Katmanı Kurma

Trafik arttıkça hemen herkes aynı noktaya gelir: veritabanı sunucusu yükün altında zorlanmaya başlar ve ilk akla gelen çözüm "önbellek koyalım" olur. Doğru bir refleks, ama yanlış uygulandığında önbellek sorunu çözmek yerine yeni ve daha sinsi bir sorun sınıfı doğurur: eski veri gösteren sayfalar, önbellek boşaldığı anda çöken sunucular ve neyin ne zaman güncelleneceğini kimsenin bilmediği bir kod tabanı.

Bu rehberde veritabanı önünde çalışan bir önbellek katmanını baştan sona kuracağız. Önce önbelleğe almadan önce sorulması gereken üç soruyu, sonra Redis ile Memcached arasındaki gerçek farkları, güvenli kurulumu, cache-aside deseninin uygulanışını, anahtar isimlendirmeyi, TTL seçimini ve geçersiz kılma stratejilerini ele alacağım. Son bölümlerde de önbellek çığı (cache stampede) gibi klasik tuzakları ve hit oranını nasıl ölçeceğinizi anlatacağım.

Önbelleğe Almadan Önce Sorulacak Üç Soru#

Önbellek bir performans aracı değil, bir erteleme aracıdır: pahalı bir işi tekrar tekrar yapmak yerine sonucunu saklarsınız. Bu yüzden asıl iş pahalı olmak zorunda değilse önbellek sadece karmaşıklık ekler. Kurmadan önce şunları sorun.

Birincisi: sorgu gerçekten pahalı mı? Birincil anahtar üzerinden çalışan ve 0,3 ms süren bir sorguyu önbelleğe almak, ağ turunu ve serileştirme maliyetini geri getirdiği için bazen daha yavaştır. Önbellek, ölçülmüş pahalı sorgular için vardır: çoklu birleştirmeli raporlar, toplama işlemleri, dış API sonuçları.

İkincisi: aynı sonuç kaç kez isteniyor? Her kullanıcı için farklı olan bir sonucun önbellek isabet oranı düşük olur; belleği doldurur ama kazandırmaz. En iyi adaylar, çok kullanıcının aynı sonucu gördüğü verilerdir: kategori ağacı, ana sayfa listeleri, döviz kuru, ayar tabloları.

Üçüncüsü: eski veri ne kadar tolere edilebilir? Önbellek her zaman biraz bayat veri demektir. Ürün stoğunda 30 saniyelik bayatlık kabul edilebilir, ödeme bakiyesinde edilemez. Bu soruya cevabınız "hiç" ise, o veriyi önbelleğe almayın.

Bu üç sorudan önce yapılması gereken bir şey daha var: uygulamanın gereksiz sorgu üretip üretmediğini kontrol etmek. Yüzlerce küçük sorguyu önbelleğe almak yerine önce sayılarını düşürün; anlatımı N+1 sorgu problemi yazısında.

Redis mi Memcached mi#

İkisi de bellekte anahtar-değer saklar ve ikisi de hızlıdır. Fark, Redis'in bir "veri yapısı sunucusu" olmasından gelir: liste, küme, sıralı küme, hash ve sayaç gibi tipleri destekler, kalıcılık (disk) seçeneği vardır, çoğaltma ve yayın-abone (pub/sub) yapabilir. Memcached ise tek bir işi yapar ve onu çok sade yapar: düz anahtar-değer, çok iş parçacıklı, çok düşük ek yük.

Pratik tavsiyem: tek bir bileşenle hem önbellek hem oturum deposu hem basit kuyruk istiyorsanız Redis; yalnızca saf önbellek istiyorsanız ve sunucuda çok çekirdek varsa Memcached fazlasıyla iş görür. Memcached tarafının ayrıntıları için Memcached nedir yazısına bakabilirsiniz; aşağıdaki örneklerde Redis'i temel alacağım çünkü geçersiz kılma desenleri için gereken araçları o sağlıyor.

Kurulum ve Güvenli Yapılandırma#

Kurulum kısmı kolay, güvenlik kısmı ise sürekli atlanıyor. İnternete açık, parolasız bir Redis örneği, saldırganın veri okumasından çok daha fazlasına izin verebilir; bu yüzden ilk yapılacak iş dinlemeyi yerelle sınırlamaktır.

# Ubuntu/Debian üzerinde kurulum
sudo apt update && sudo apt install -y redis-server

# Servis durumu
systemctl status redis-server --no-pager

# Yalnızca yerel dinlediğini doğrula
ss -tlnp | grep 6379

/etc/redis/redis.conf içinde değiştirilmesi gereken satırlar şunlar:

# Yalnızca yerel arayüzü dinle
bind 127.0.0.1 -::1
protected-mode yes
port 6379

# Güçlü bir parola
requirepass cok-uzun-ve-rastgele-bir-deger

# Önbellek olarak kullanılacaksa bellek sınırı ve tahliye politikası ŞART
maxmemory 512mb
maxmemory-policy allkeys-lru

# Saf önbellekte kalıcılığa gerek yok; disk yazmayı kapatmak I/O yükünü düşürür
save ""
appendonly no

Buradaki en kritik iki satır maxmemory ve maxmemory-policy. Sınır koymazsanız Redis belleği doldurana kadar büyür ve işletim sistemi sonunda süreci sonlandırır — üstelik bunu genelde en yoğun anda yapar. allkeys-lru politikası, sınıra gelindiğinde en az kullanılan anahtarları atarak servisi ayakta tutar. Parola üretmek için şifre üretici aracımızı kullanabilirsiniz.

Memcached tarafında karşılığı /etc/memcached.conf dosyasıdır:

-m 512
-l 127.0.0.1
-p 11211
-U 0

-U 0 satırı UDP'yi kapatır ve bu güvenlik açısından önemlidir; açık UDP portu yansıtmalı saldırılarda kötüye kullanılabilir.

Cache-Aside Deseni ve Anahtar Tasarımı#

En yaygın ve en anlaşılır desen cache-aside'dır: uygulama önce önbelleğe bakar, bulamazsa veritabanından okur ve sonucu önbelleğe yazar. Akış şöyledir:

1. Anahtarı üret (deterministik olmalı).
2. Önbellekten oku. Varsa döndür, bitti.
3. Yoksa veritabanından oku.
4. Sonucu TTL ile önbelleğe yaz.
5. Sonucu döndür.

Anahtar tasarımı, katmanın uzun vadeli sağlığını belirleyen kısımdır. İyi bir anahtar okunabilir, çakışmaz ve sürümlenebilir olmalıdır:

# Kötü: neyi tuttuğu belli değil, çakışmaya açık
redis-cli SET "12" "..." EX 300

# İyi: alan:varlık:kimlik:sürüm biçimi
redis-cli SET "urun:detay:v3:8241" '{"ad":"Ornek","fiyat":249.9}' EX 300
redis-cli SET "kategori:liste:v3:12:sayfa:1" '[...]' EX 600

Anahtarın içindeki v3 sürüm numarası, ileride veri biçimini değiştirdiğinizde tüm önbelleği tek hamlede geçersiz kılmanızı sağlar: sürümü v4 yaparsınız, eski anahtarlar kimse tarafından okunmaz ve TTL dolduğunda kendiliğinden silinir. Bu, FLUSHALL çalıştırmaktan çok daha güvenlidir — FLUSHALL oturumlarınızı da siler.

Sorgu bazlı önbelleklemede anahtarı sorgunun karmasından üretmek de yaygındır. Karma değeri kısa ve deterministik olmalıdır; hash üretici aracıyla mantığı deneyebilirsiniz. Ancak anahtar tamamen karmadan ibaretse hata ayıklamak zorlaşır; önüne okunur bir ön ek koyun: rapor:aylik:v1:<karma>.

TTL Seçimi ve Geçersiz Kılma#

Önbellekte iki geçersiz kılma yolu vardır ve ikisini birlikte kullanmak gerekir. Zaman tabanlı (TTL) yaklaşım basittir: veri belirli süre sonra kendiliğinden ölür. Olay tabanlı yaklaşım daha doğrudur: veri değiştiğinde ilgili anahtar silinir. TTL bir güvenlik ağıdır; olay tabanlı silmeyi unuttuğunuz yerlerde bayat veriyi sınırlar.

Olay tabanlı silme için tekil anahtarı silmek yeterlidir. Asıl zorluk, bir kaydın birden çok listede görünmesidir: bir ürünün fiyatı değiştiğinde o ürünün detay anahtarını silmek kolaydır, ama ürünün göründüğü 40 farklı liste sayfasını bulmak zordur. Buradaki pratik çözüm, liste anahtarlarına ortak bir sürüm ön eki koymaktır:

# Kategori listelerinin sürümünü tutan sayaç
redis-cli INCR "surum:kategori:12"
# Yeni değer 7 dönerse, liste anahtarları artık şu biçimde üretilir:
# kategori:liste:v3:12:s7:sayfa:1

Sayaç arttığı anda eski anahtarları kimse okumaz; silmeye bile gerek kalmaz, TTL onları temizler. KEYS kategori:* gibi desen taraması yapmaktan kaçının: Redis tek iş parçacıklı çalıştığı için büyük veri kümesinde KEYS tüm sunucuyu bloke eder. Zorunluysa SCAN kullanın.

Cache Stampede ve Diğer Tuzaklar#

Önbelleğin en tehlikeli anı, popüler bir anahtarın süresinin dolduğu andır. O anda gelen 500 istek aynı anda önbellekte boşluk bulur ve 500'ü birden veritabanına gider. Buna önbellek çığı (cache stampede) denir ve çoğu zaman veritabanını devirir — üstelik önbellek olmasaydı yük sabit kalacaktı. Üç çözüm var:

1. Kilit (mutex) deseni. İlk gelen istek SET anahtar_lock 1 NX EX 10 ile kilidi alır, veriyi üretir ve yazar; diğerleri kısa süre bekleyip önbelleğe tekrar bakar.
2. Erken yenileme. TTL'in son yüzde 10'unda, isteklerden küçük bir olasılıkla biri veriyi arka planda yeniler; diğerleri hâlâ eski değeri okur.
3. Bayat veriyi sunma. Anahtarı iki TTL ile tutun: mantıksal ve fiziksel. Mantıksal süre dolduğunda veri yenilenirken bayat kopya sunulmaya devam eder.

# Kilit deseninin çekirdeği: yalnızca ilk isteğin alabildiği kilit
redis-cli SET "kilit:rapor:aylik" 1 NX EX 10
# Cevap OK ise üretimi bu istek yapar, nil ise 50 ms bekleyip önbelleğe tekrar bakılır

Diğer klasik tuzaklar şunlar: TTL'leri hep aynı vermek (aynı anda oluşan bin anahtar aynı anda ölür, mini bir çığ yaratır — süreye rastgele birkaç saniye ekleyin), önbelleği tek doğruluk kaynağı sanmak (Redis yeniden başladığında veri gitmelidir ve gitmesi de normaldir, uygulama bu durumda çalışabilmelidir), kullanıcıya özel veriyi ortak anahtarda tutmak (bir kullanıcının sepetini başkasına göstermenin en kolay yolu) ve çok büyük değerler saklamak (megabaytlık bir JSON'u her istekte serileştirip çözmek, kazandığından fazlasını götürür).

Ölçme: Hit Oranı ve Bellek Yönetimi#

Önbellek kurup ölçmemek, kurmamaktan biraz daha iyidir sadece. Bakılacak ilk metrik isabet oranıdır:

# Redis: isabet ve ıskalama sayaçları
redis-cli INFO stats | grep -E "keyspace_hits|keyspace_misses"

# Bellek kullanımı ve tahliye sayısı
redis-cli INFO memory | grep -E "used_memory_human|maxmemory_human"
redis-cli INFO stats | grep evicted_keys

İsabet oranı hits / (hits + misses) formülüyle hesaplanır. Sağlıklı bir önbellekte bu oran genelde %80'in üzerindedir; düşükse ya TTL çok kısadır ya da önbelleğe aldığınız veri gerçekten paylaşılan bir veri değildir. evicted_keys sürekli artıyorsa bellek yetmiyor demektir: ya sınırı yükseltin ya da neyi sakladığınızı gözden geçirin.

Memcached tarafında karşılığı şudur:

# get_hits ve get_misses değerlerine bakın
echo "stats" | nc 127.0.0.1 11211 | grep -E "get_hits|get_misses|evictions"

Önbellek metriklerini veritabanı metrikleriyle birlikte izleyin; önbellek isabet oranı düştüğü anda veritabanı yükünün nasıl fırladığını görmek, katmanın gerçekten çalıştığının en net kanıtıdır. İzleme kurulumu için veritabanı izleme metrikleri yazısına bakın. Önbellek de yetmediğinde bir sonraki adım okuma trafiğini dağıtmaktır; onu da read replica ile okuma yükünü dağıtma yazısında ele aldım.

Sıkça Sorulan Sorular#

Redis mi Memcached mi daha hızlı#

Saf anahtar-değer okuma yazma işinde ikisi de mikrosaniyeler seviyesindedir ve fark çoğu uygulamada ölçülemeyecek kadar küçüktür. Memcached çok çekirdekli sunucularda yoğun eşzamanlı yükte biraz avantajlı olabilir, Redis ise veri yapıları sayesinde aynı işi daha az ağ turuyla yaptırabildiği için pratikte çoğu zaman öne geçer. Seçimi hızdan çok ihtiyaç duyduğunuz özelliklere göre yapın.

Önbellek verisi ne kadar süre saklanmalı#

Tek bir doğru süre yok; ölçüt, o verinin bayatlığının ne kadar tolere edilebildiğidir. Ayar ve kategori gibi seyrek değişen veriler saatlerce tutulabilir, ürün fiyatı gibi veriler dakikalarla sınırlanmalıdır. Kullanıcıya özel ve para ile ilgili veriler için genellikle doğru cevap hiç önbelleğe almamaktır. Her durumda TTL'i bir güvenlik ağı olarak koyun, asıl geçersiz kılmayı veri değiştiğinde yapın.

Cache invalidation neden bu kadar zor#

Çünkü bir verinin kaç farklı yerde türetilmiş halde durduğunu takip etmek zordur. Tek kayıt için anahtarı silmek kolaydır, ama o kaydın göründüğü listeler, sayfalar ve raporlar da bayatlar. Bu yüzden pratik çözüm tek tek silmeye çalışmak değil, liste anahtarlarını bir sürüm sayacıyla üretip sayacı artırmaktır; eski anahtarlar okunmaz hale gelir ve TTL ile temizlenir.

Önbellek sunucusu çökerse ne olur#

Doğru kurulmuş bir uygulamada hiçbir şey olmaz: her istek önbelleği ıskalar, veritabanına gider ve sistem yavaşlar ama çalışır. Yanlış kurulmuş bir uygulamada ise hata fırlatılır ve site tamamen durur. Bu yüzden önbellek çağrılarını mutlaka hata toleranslı yazın, kısa bir zaman aşımı koyun ve önbellek erişilemediğinde sessizce veritabanına düşün.

WordPress veya benzeri bir uygulamada nasıl kullanırım#

Yaygın içerik yönetim sistemlerinin çoğunda hazır nesne önbelleği eklentileri vardır; sunucuda Redis ya da Memcached kurulu olduğunda eklenti veritabanı sorgularının sonucunu otomatik olarak önbelleğe alır. Bu, elle anahtar yönetmenize gerek bırakmadan en büyük kazancı sağlar. Yapmanız gereken tek şey servisi kurmak, parolayı ayarlamak ve eklentinin bağlantı bilgilerini girmektir.

Önbellek hit oranım düşükse ne yapmalıyım#

Önce neyi önbelleğe aldığınıza bakın: sonuç her kullanıcı için farklıysa isabet oranı yapısal olarak düşük olur ve önbellek yanlış yerdedir. Sonra TTL'i kontrol edin; çok kısa süreler anahtarların ısınmadan ölmesine yol açar. Üçüncü olarak evicted_keys sayacına bakın: bellek yetmiyorsa anahtarlar süresi dolmadan atılıyordur ve çözüm daha fazla bellek ya da daha az veri saklamaktır.

Kapanış#

Önbellek katmanı doğru kurulduğunda veritabanı yükünü kat kat düşürür; yanlış kurulduğunda ise hata ayıklaması zor bir bayat veri kaynağına dönüşür. Aklınızda tutmanız gereken dört alışkanlık şu: yalnızca ölçülmüş pahalı ve paylaşılan sorguları önbelleğe alın, anahtarlarınızı sürümlü ve okunur tasarlayın, TTL'i güvenlik ağı olarak kullanıp asıl geçersiz kılmayı olay tabanlı yapın ve isabet oranı ile tahliye sayacını izleyin. Popüler anahtarlarda çığ korumasını da baştan ekleyin.

Redis ya da Memcached kurabileceğiniz tam root erişimli sunucular için VDS ve bulut sunucu paketlerimize bakabilirsiniz; nesne önbelleği hazır gelen bir ortam istiyorsanız WordPress hosting ve e-ticaret hosting çözümlerimiz uygun. Kurulum, ayar ve izlemeyi bizim üstlenmemizi tercih ederseniz sunucu yönetimi hizmetimiz bu işi kapsıyor.