Postmortem: deploy anındaki cache ısıtma işlemi 180.000 anahtarın aynı anda expire olmasına yol açtı

Ekibin gördüğü

dev.to'da Sergey Shinder tarafından yayımlanan bir postmortem'e göre, bir ürün katalog servisi Mayıs ayından itibaren her dağıtımdan yaklaşık bir saat sonra başlayan, kabaca altı dakikalık bir yavaşlamadan mustarip oldu. Veritabanı CPU'su tavana dayandı, sayfa yükleme süreleri bir saniyenin altından sekiz dokuz saniyeye çıktı ve sonra sistem kendiliğinden düzeldi. Bazı günlerde ilk dalgadan bir saat sonra daha küçük bir ikinci dalga geldi. Mühendislerin var olmayan saatlik bir cron job'ı aramakla iki gün harcadığı bildiriliyor.

Soruna yol açan iyileştirme

Tetikleyici, ekibin memnun olduğu bir değişiklikti. Yeni dağıtılan pod'lar boş bir cache ile başlıyor ve gerçek trafik cache'i doldurana kadar ilk birkaç dakika yavaş çalışıyordu. Bu soğuk başlangıcı ortadan kaldırmak için bir ısınma aşaması eklediler: bir pod trafiği kabul etmeden önce yaklaşık 180.000 ürün kaydını paylaşılan cache'e, her biri bir saatlik time to live ile önceden yüklüyordu. Soğuk başlangıçlar kayboldu ve aynı anda görünmez bir problem üretildi.

Isınma işlemi yaklaşık iki dakika sürdüğü için her kayıt aynı iki dakikalık pencere içinde oluşturuldu ve bir saat sonra tüm katalog aynı pencere içinde expire oldu. Her istek miss oldu, her miss veritabanına gitti ve veritabanı, kararlı durumdaki bir cache'in ürettiği küçük miss yüzdesi için boyutlandırılmıştı. İkinci dalganın kökeni de aynıydı: dalga sırasında yeniden doldurulan kayıtlar birlikte doldurulduğu için yeniden birlikte expire oldular. Ekibin değiştirdiği lazy cache hiç bu şekilde davranmamıştı, çünkü normal trafik, kimsenin karar vermediği halde expire zamanlarını saat boyunca dağıtmıştı.

Dört hafifletme

Shinder olayları çözen dört değişikliği anlatıyor:

1. Her TTL artık yirmi yüzde rastgele jitter taşıyor, böylece birlikte yüklenen kayıtlar ayrı ayrı expire oluyor.
2. Aynı anahtardaki miss'ler birleştiriliyor: tek bir ürün için gelen bin eşzamanlı istek, diğerleri beklerken tek bir veritabanı sorgusu üretiyor.
3. Kayıtlar, expire olduktan sonra en fazla beş dakika boyunca stale olarak sunuluyor ve tek bir arka plan yenilemesi onların yerine geçerken expire kullanıcılar için görünmez hale geliyor.
4. Cache doldurma işlemleri kendi küçük veritabanı bağlantı havuzundan geçiyor, böylece bir stampede'nin yapabileceği en kötü şey yeniden doldurmayı yavaşlatmak, başka her şeyden bağlantı çalmak değil.

Neden önemli

Temel ders, kimsenin tasarlamadığı eşzamanlılıkla ilgili. Sistemler çoğu zaman yükü tesadüfen zamana yayar ve bu tesadüf sessizce yük taşıyıcı olabilir. Deploy sırasında bir cache'i doldurmak gibi bariz güvenli görünen bir temizlik veya optimizasyon, koruma işlevi gören rastgeleliği ortadan kaldırabilir ve arıza yalnızca bir saat sonra, ona neden olan değişiklikten çok uzakta ortaya çıkar. Hata ayıklama biçimi de öğretici: cron görünümlü, tekrarlayan ve kendiliğinden düzelen olaylar aslında kendi deploy zamanı davranışınızdan kaynaklanan, kendi elinizle yaratılmış eşzamanlılık olabilir.

Cache'leri önceden dolduran ya da zamana göre anahtarlanmış herhangi bir şeyi toplu ekleyen deploy pipeline'ları inşa edenler için pratik kontrol listesi kısa. Varsayılan olarak her TTL'ye jitter ekleyin. Sıcak anahtarlardaki miss'leri birleştirin. Expire kullanıcıya görünmesin diye arka plan yenilemesinin arkasında stale veri sunun. Cache doldurma trafiğini kendi bağlantılarına izole edin ki bir yeniden doldurma fırtınası sistemin geri kalanını açlıkta bırakmasın. Ve yalnızca hit oranını değil, expire zamanlarının dağılımını ölçün; çünkü yüzde 99 hit oranına sahip bir cache, tüm miss'ler aynı dakikaya denk gelirse veritabanını yine de devirebilir.