Merhaba! Ben Jayon.

Bugün size önbellek ayarlama kriterlerini açıklayacağım. Kişisel olarak iş deneyimlerimden yola çıkarak yazdığım bir yazı olduğu için, lütfen sadece referans olarak düşünün ㅎㅎ

Önbellek nedir?

Önbellek, daha sonraki isteklerde kullanılacak sonuçları önceden depolamak ve hızlı bir şekilde sunmayı ifade eder. Başka bir deyişle, önceden sonuçları depolar ve daha sonra gelen istekler için veritabanına veya API'ye başvurmak yerine önbelleğe erişerek istekleri işleyen bir tekniktir. Önbelleğin ortaya çıkmasının arkasında Pareto prensibi vardır.

Pareto prensibi, sonuçların %80'inin nedenlerin %20'sinden kaynaklandığı anlamına gelir. Aşağıdaki resme bakmak isteyebilirsiniz!

Yani, önbelleğin tüm sonuçları önbelleklemesi gerekmez. Sadece hizmet sunumunda sık kullanılan %20'lik kısmı önbelleklemek, genel olarak verimliliği artırabilir.

Hangi veriler önbelleğe alınmalıdır?

Pareto prensibine göre, herhangi bir veriyi önbelleğe almamalıyız. Sadece gerekli verileri önbelleğe almamız gerekir. Peki, hangi verileri önbelleğe almalıyız?

Sık sık okunması gereken ancak nadiren yazılması gereken veriler

İşte, teoride "Sık sık okunması gereken ancak nadiren yazılması gereken veriler önbelleğe alınmalıdır" deniyor, ancak "Sık sık okuma" ve "Nadiren yazma" kriterleri oldukça belirsizdi.

Bu nedenle, önbelleğe alınacak verileri araştırmak için aşağıdaki adımları izliyorum.

• DataDog gibi bir APM aracılığıyla RDB'deki sorgu çağrı geçmişinin ilk 5'ini kontrol edin.
• Bunların arasında, sorgu sorgularını bulun ve hangi tablolardan sorgu yapıldığını kontrol edin.
• İlgili tablonun güncelleme sorgusunun kaç kez çağrıldığını kontrol edin.

Yukarıdaki süreci izleyerek sorguların çok olmasına rağmen güncelleme sorgularının az olduğunu kontrol etmektir. İş deneyimlerimde gördüğüm bir tabloda, sorgu sorguları günde 1.74 milyon kez gerçekleşiyordu, ancak güncelleme sorguları en fazla 500 kez gerçekleşiyordu. Bu, herkesin kabul edebileceği bir önbellek için uygun bir koşuldur ㅎㅎ

Güncelleme duyarlılığı yüksek veriler

Güncelleme duyarlılığı yüksek veriler, RDB ve önbellek arasındaki tutarsızlığın kısa olması gerektiği anlamına gelir. Örneğin, ödemeyle ilgili bilgiler, güncelleme duyarlılığı çok yüksek olduğundan, yukarıdaki önbellek koşulunu karşılasa bile uygulamayı düşünmek gerekir.

Yukarıdaki iki özelliğe uygun ödemeyle ilgili tabloları önbelleğe almam gerekiyordu. Bu nedenle, bu ödemeyle ilgili tabloyu kullanan tüm mantıklarda önbellek uygulamadım ve aslında ödemenin gerçekleşmediği nispeten güvenli mantıklarda kısmi olarak önbelleklemeye karar verdim.

Yerel önbellek mi, küresel önbellek mi?

Şimdi, hangi verileri önbelleğe alacağımızı ve önbelleğe alma kapsamını belirledik. Peki, önbellek verilerini "nerede" depolayacağımızı düşünmemiz gerekiyor. Genellikle, yerel belleğe depolayabiliriz veya Redis gibi ayrı bir sunucuya depolayabiliriz.

Yerel önbellek

Yerel önbellek, önbelleğe alınacak verileri uygulama sunucusunun belleğine kaydetme yöntemidir. Genellikle Guava cache veya Caffeine cache kullanılır.

Avantajlar

• Uygulama mantığını çalıştırırken, aynı sunucunun belleğinde bulunan önbelleğe erişerek, hız avantajı sağlar.
• Uygulaması kolaydır.

Dezavantajlar

• Birden fazla örneğin olması durumunda, bazı sorunlar ortaya çıkabilir.
  • Bir örnekte yapılan önbellek değişiklikleri, diğer örneklere yayılamaz. Ancak, değişiklikleri diğer örneklere yaymak için yerel önbellek kitaplıkları da vardır.
  • Her örnekte önbellek depolandığı için, yeni bir örnek açıldığında önbelleği yeniden doldurmanız gerekir. Bu, önbellek iskaçı sıklığına neden olabilir ve trafikle başa çıkamayarak örneklerin çökmesine yol açabilir.

Küresel önbellek

Küresel önbellek, Redis gibi ayrı bir önbellek veri depolamak için kullanılan sunucu kullanma yöntemidir.

Avantajlar

• Örnekler arasında önbellek paylaşıldığı için, bir örnekte önbelleğin değiştirilmesi, tüm örneklerin aynı önbellek değerini elde etmesini sağlar.
• Yeni bir örnek açıldığında, zaten mevcut olan önbellek depolama alanını kullanabilir, bu da önbelleği doldurma işlemini ortadan kaldırır.

Dezavantajlar

• Ağ trafiğini geçmesi gerektiği için, yerel önbelleğe göre daha yavaştır.
• Ayrı bir önbellek sunucusu kullanılması gerektiği için, altyapı yönetimi maliyeti oluşur.
  • Altyapı yönetimi maliyeti mi? → Sunucu ücreti, altyapı kurulumu ve bakımı için harcanan zaman, hata yönetimi planı vb.

Yazar neyi seçti?

Şu anda şirketin uygulama sunucuları, birden fazla örnek çalıştırma yapısına sahip ancak yerel önbelleği seçtim.

Bunun temel olarak üç nedeni var.

• RDB'de depolanan önbelleğe alınacak veriler yaklaşık 40.000'dir, bunların hepsini belleğe yüklemek bile 4MB'den azdır.
• Ödemeyle ilgili verilerin sorgu performansının iyi olması gerekiyordu.
• Redis zaten mevcut olsa da, yeni önbelleği Redis'e kaydetmek altyapı maliyeti gerektirir.

Önbellek nasıl güncellenecek?

Uygulama sunucuları birden fazlaysa ve bu sunuculara yerel önbellek uygulanmışsa, her uygulama sunucusunda depolanan önbellek değerleri farklı olabilir. Örneğin, A sunucusunda depolanan önbellek verisi "1" iken, B sunucusunda depolanan önbellek verisi B sunucusunda değiştirilerek "2" olabilir. Bu durumda, kullanıcı yük dengeleyiciye istek gönderirse, A sunucusu ve B sunucusu farklı değerler döndürür.

Bu nedenle, her örnekte önbelleğin otomatik olarak silinmesi ve verilerin RDB'den sorgulanması gerekir. Bu durumda, genellikle TTL kullanılır.

TTL nasıl ayarlanmalı?

TTL, Time To Live'ın kısaltmasıdır ve belirli bir süre geçtiğinde önbelleğin silinmesini sağlayan bir ayardır. Örneğin, TTL'yi 5 saniye olarak ayarladıysanız, önbellek verisi 5 saniye sonra otomatik olarak silinir. Daha sonra, önbellek iskaçı meydana gelirse, veriler RDB'den sorgulanır ve kaydedilir.

Peki, TTL nasıl ayarlanmalı?

Okuma/yazma işlemi tek bir önbellek sunucusunda gerçekleşiyorsa

Okuma/yazma işlemi Redis gibi küresel bir önbellek sunucusunda veya yerel önbellek uygulanan tek bir uygulama sunucusunda gerçekleşiyorsa, TTL değeri saat veya daha uzun süre olarak ayarlanabilir. Sonuçta, yazma işlemi yapıldığında mevcut önbelleği değiştireceksiniz ve bu önbellekten veri alan sunucu her zaman güncellenmiş verileri görecektir.

Bu durumda, TTL ayarlanmayabilir ve önbellek sunucusu dolu olduğunda, önbelleği kademeli olarak temizlemek için LRU algoritması kullanılabilir.

Okuma/yazma işlemi birden fazla önbellek sunucusunda gerçekleşiyorsa

Okuma/yazma işlemi, çoğaltılmış küresel önbellek sunucularında veya yerel önbellek uygulanan birden fazla uygulama sunucusunda gerçekleşiyorsa, TTL değeri saniye veya dakika olarak ayarlanmalıdır. Çünkü henüz güncellenmiş verileri yansıtmayan önbellek sunucularının eski verileri okuma olasılığı vardır.

Bu durumda, TTL, çeşitli bağlamlarda belirlenir. Güncelleme önemliyse ve değerlerin değişme olasılığı yüksekse, TTL kısa tutulmalıdır. Güncelleme daha az önemliyse ve değerlerin değişme olasılığı düşükse, TTL daha uzun süreli olarak ayarlanabilir.

Yazar TTL'yi nasıl ayarladı?

Önbelleğe alacağım veriler ödemeyle ilgilidir ve aslında ödeme işleminin gerçekleştiği sıkı mantıklarda önbellek uygulanmıyor olsa bile, ödeme doğası gereği güncelleme önemlidir. Ancak, güncelleme olasılığı düşük olduğundan, TTL'yi güvenlik amacıyla yaklaşık 5 saniye olarak ayarladım.

Sonuç

Özetle, benim seçtiğim önbellek yöntemi şu şekildedir:

• Ödemeyle ilgili veriler
• Sorgular çok sık yapılıyor, ancak güncellemeler neredeyse hiç gerçekleşmiyor.
• Ödeme gerçekleşmese bile sorgu gerçekleştiği mantıklarda önbellek uygulanıyor.
• Yerel önbellek uygulanmış ve TTL 5 saniye olarak ayarlanmıştır.

Bundan sonraki adım, aslında uygulanan önbellek yöntemini kullanarak performans testi yapmaktır. Performans testini nasıl yapacağımı henüz tam olarak düşünmüyorum, bu nedenle daha sonraki yayınlarda ayrıntılı olarak ele alacağım!