Improving Smart Tiered Cache for Public Cloud Regions · Chenxi Zhang
2021'de çıkan Smart Tiered Cache'in fikri basitti: sitenin arkasındaki her kaynak (origin) için Cloudflare, gerçek zamanlı gecikme ölçümlerine bakarak tek bir en iyi üst katman veri merkezi seçer. Tek anahtarı çevirirsin, ağdan kaynağına en fast path bulunur.
Bu, bir kaynak IP'si sabit bir yerde durduğu sürece çalışıyor. Genel bulut kaynakları genelde durmuyor. Anycast ya da bölgesel unicast ön yüzlerin arkasında oturuyorlar; yani tek bir kaynak IP'si aynı anda bir düzine Cloudflare veri merkezine eşit derecede yakın görünebiliyor — ve gecikme ölçümlerinin tutunacak bir şeyi kalmıyor.
Smart Tiered Cache bu durumu güvenli yoldan ele alıyor: net bir kazanan yoksa birden fazla üst katmana düşüyor. Hiçbir şey bozulmuyor. Sadece tek bir en yakın katmanı değerli kılan şeyi kaybediyorsun: cache verimliliği. Çünkü aynı içerik birden fazla üst katmanda ayrı ayrı cache’lenir; her biri kaynağa ayrı gider.
Çözüm bir bölge ipucu (region hint) vermene izin vermek. Bu ipuçla Cloudflare, kaynak IP'si her yere yakın görünse bile bulut kaynağını doğru bölgeye eşleyip daha iyi birincil ve yedek üst katman seçebiliyor.
Öne çıkanlar
- Sessiz bozulma (graceful degradation) doğru tasarım — ama neyi kaybettiğini bilmek gerekiyor: burada kaybedilen doğruluk değil verimlilik.
- Anycast bir adresi çok yerde duyurur; bu ağ katmanında harika, ama "nerede?" sorusunu cevapsız bırakır.
- Otomatik keşif başarısız olduğunda çözüm, insanın bildiği bilgiyi sisteme ipucu olarak vermek.
Neden önemli?
Her otomatik optimizasyon bir varsayıma dayanır. Bu yazı o varsayımı ("kaynak sabit bir yerdedir") ve çürüdüğünde ne olduğunu açıkça gösteriyor. Kendi sistemlerinde de sor: bu otomatik davranış hangi varsayıma dayanıyor ve varsayım bozulduğunda sistem ne yapıyor — gürültülü mü başarısız oluyor, yoksa sessizce mi kötüleşiyor?
Pratikte
İki kavram burada senin için kritik. Anycast: aynı IP adresinin dünyada birçok noktadan duyurulması, trafiğin en yakın noktaya gitmesi. 1.1.1.1 ve 8.8.8.8 böyle çalışır. Tiered cache: uç sunucuların doğrudan kaynağa gitmek yerine bir ara cache katmanından geçmesi — 100 uç sunucu ıskaladığında kaynağa 100 değil 1 istek gider. Bu ikinci fikri kendi ölçeğinde de kur: Spring Boot uygulamanda uygulama içi cache (Caffeine) ile paylaşılan Redis cache’ini birlikte kullanmak tam olarak tiered cache’tir ve veritabanına giden yükü ciddi düşürür.
Sözlük
- anycast
- Aynı IP adresinin birden çok konumdan duyurulması; ağ, isteği en yakın konuma yönlendirir.
- tiered cache
- Uç cache’lerin kaynağa doğrudan gitmek yerine bir ara cache katmanından geçmesi; kaynak yükünü azaltır.
- graceful degradation
- Bir bileşen ideal çalışamadığında sistemin tamamen durmak yerine daha düşük verimle çalışmaya devam etmesi.
Bugün az yayın çıktı. Bu yazılar daha eski tarihli ama hâlâ öğretici;
her birinin gerçek yayın tarihi başlığın üstünde yazıyor.
How Netflix Simplified Batch Compute with Kueue
Netflix hesaplama altyapısını daha Kubernetes-yerel hâle getirme yolculuğunda, Kubernetes ekosisteminden bileşenleri kendi konteyner platformu Titus'a dahil ediyor. Örneklerden biri Kueue: toplu iş yükleri için bulut-yerel bir iş kuyruğu sistemi.
Kueue, kendi geliştirdikleri CMB (Compute Managed Batch) çözümündeki özel kuyruklama ve zamanlama mantığının büyük kısmının yerini almış. CMB'nin yaptığı işler tanıdık: bir tenant hiyerarşisi üzerinden iş yüklerini yönetip kuyruklamak, öncelikle sıralı çalıştırma sağlamak ve kapasiteyi tenant bazında yönetmek. Tenant’lar organizasyon, platform ya da uygulama bazında gruplama sağlıyor ve her tenant’ın bir kapasite yapılandırması var — ağırlık ve diğer tenant’lardan izolasyon garantileri dahil.
Yazı milyonlarca toplu işin nasıl taşındığını da anlatıyor.
Öne çıkanlar
- Kendi yazdığın altyapıyı, olgunlaşan bir ekosistem bileşeniyle değiştirmek bakım yükünü kalıcı olarak düşürür.
- Tenant hiyerarşisi + kapasite ağırlıkları, çok takımlı bir platformda adil paylaşımın standart çözümü.
- Göç "milyonlarca iş" ölçeğinde yapılmış — yani kesintisiz geçiş tasarımı işin asıl zor kısmı.
Pratikte
Bu yazının bir alt seviyedeki karşılığını sen de yaşayacaksın: kendi yazdığın yardımcı sınıflar ve altyapı kodu. ‘Ben yazdım, çalışıyor’ bir kodu tutmak için yeterli sebep değil; bakımını kim yapacak sorusu daha önemli. Kubernetes tarafında şu ayrımı öğren: Deployment sürekli çalışan servisler için, Job/CronJob başlayıp biten işler için. Günlük çalışan bir veri pipeline’ı bir CronJob’un tam örneği; GitHub Actions cron’u da aynı işi yapan daha basit bir araç.
Sözlük · 3 terim
- batch workload
- Başlayıp tamamlanan, sürekli çalışmayan hesaplama işi (rapor üretme, veri işleme gibi).
- multi-tenancy
- Aynı platformu birden çok takımın/uygulamanın paylaşması; adil kapasite paylaşımı gerektirir.
- job queueing
- Çalıştırılacak işlerin öncelik ve kapasiteye göre sıraya alınıp zamanlanması.
Innovative Recommendation Applications Using Two Tower Embeddings at Uber
Uber'in ML ekibi 2022'de embedding'lere yatırım yapmış ve odak noktası Two-Tower Embeddings (TTE) olmuş. Amaç öneri sistemlerini beslemek: yemek siparişi verenler (eater) ve restoranlar (store) için embedding üretip uygulamak.
Embedding'in tanımı yazıda net veriliyor: bir varlığın (mağaza, kullanıcı, ürün, sürücü, konum) zengin bir temsili. İnsan dostu özellikleri — mağaza menüsü, ürün fiyatı, kullanıcının tercih ettiği mutfak, geçmiş siparişleri — makine öğrenmesi dostu vektörlere dönüştürüyor.
"Two-tower" adı mimariden geliyor: iki ayrı ağ (kule), biri kullanıcıyı biri öğeyi kendi vektörüne çeviriyor; eşleşme skoru bu iki vektörün benzerliği. Bunun pratik değeri büyük — öğe vektörlerini önceden hesaplayıp saklayabilirsin, sorgu anında yalnızca kullanıcı vektörünü hesaplayıp en yakın komşuları ararsın.
Yol da dürüstçe anlatılmış: yaklaşım yaklaşık bir yıl sonra yayına girmiş, ve şehir bazında binlerce modelden tek bir küresel bağlamsal modele doğru evrilmiş.
Öne çıkanlar
- İki kule ayrımı, öğe tarafını önceden hesaplanabilir kılıyor — gerçek zamanlı öneri bu sayede mümkün.
- "Binlerce şehir modeli"nden "tek küresel model"e geçiş, ML sistemlerinde tekrarlanan bir olgunlaşma yolu.
- Bir yıllık geliştirme süresi açıkça yazılmış — gerçekçi bir beklenti çıpası.
Pratikte
Embedding ve RAG ile çalışıyorsan buradan alacağın şey somut: two-tower ayrımını kendi sisteminde tanı. Bir doküman aramada belge embedding’lerini önceden hesaplayıp saklıyorsan (item tower), sorgu geldiğinde yalnızca sorguyu vektörleştiriyorsan (query tower), aynı desendesin. Bir adım ilerisi: iki tarafı aynı hazır modelle değil, kendi verinle eğitilmiş iki ayrı kuleyle temsil etmek; Uber’in yaptığı bu ve alana özgü aramada belirgin fark yaratır. Ayrıca approximate nearest neighbor (ANN) aramasını öğren: pgvector bunu PostgreSQL’de doğrudan veriyor.
Sözlük · 3 terim
- embedding
- Bir varlığın anlamsal özelliklerini taşıyan sayısal vektör temsili.
- two-tower model
- Kullanıcı ve öğeyi ayrı ağlarla vektöre çevirip benzerliklerini karşılaştıran öneri mimarisi.
- approximate nearest neighbor (ANN)
- Milyonlarca vektör arasında en benzerlerini, tam doğruluktan biraz ödün vererek çok hızlı bulma tekniği.