Editörden

Bugünün kapağı, işe yarayan bir optimizasyonun altındaki varsayım çürüdüğünde ne olduğunu anlatıyor: Cloudflare'in "en yakın sunucuyu bul" algoritması, bulut kaynaklarında tutunacak bir şey bulamıyor. Yanına arşivden iki yazı ekledim — kendi yazdığın kuyruğu silmek ve embedding'lerle öneri kurmak.

Günün Kapağı
Cloudflare Blog 10 Temmuz 20266 dk okuma ileri

Ölçüm tutunacak bir şey bulamayınca: anycast ve önbellek verimliliği

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 hızlı yol 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: önbellek verimliliği. Çünkü aynı içerik birden fazla üst katmanda ayrı ayrı önbelleklenir; 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?

Sende karşılığı

İ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. Katmanlı önbellek: uç sunucuların doğrudan kaynağa gitmek yerine bir ara önbellek 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 önbellek (Caffeine) ile paylaşılan Redis önbelleğini birlikte kullanmak tam olarak katmanlı önbellektir ve veritabanına giden yükü ciddi düşürür.

Sözlük

anycast anycast
Aynı IP adresinin birden çok konumdan duyurulması; ağ, isteği en yakın konuma yönlendirir.
tiered cache katmanlı önbellek
Uç önbelleklerin kaynağa doğrudan gitmek yerine bir ara önbellek katmanından geçmesi; kaynak yükünü azaltır.
graceful degradation kademeli bozulma
Bir bileşen ideal çalışamadığında sistemin tamamen durmak yerine daha düşük verimle çalışmaya devam etmesi.
Orijinali oku

Arşivden Seçmeler

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.

Arşivden Netflix Tech Blog 22 Haziran 2026 6 dk orta

Kendi yazdığın kuyruğu silmek: Netflix'in Kueue'ya geçişi

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 kiracı hiyerarşisi üzerinden iş yüklerini yönetip kuyruklamak, öncelikle sıralı çalıştırma sağlamak ve kapasiteyi kiracı bazında yönetmek. Kiracılar organizasyon, platform ya da uygulama bazında gruplama sağlıyor ve her kiracının bir kapasite yapılandırması var — ağırlık ve diğer kiracılardan izolasyon garantileri dahil.

Yazı milyonlarca toplu işin nasıl taşındığını da anlatıyor.

  • 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.
  • Kiracı 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ı.

Sende karşılığı

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 ise şu ayrımı öğren: Deployment sürekli çalışan servisler için, Job/CronJob ise başlayıp biten işler için. Bu gazetenin günlük pipeline'ı bir CronJob'un tam örneği — GitHub Actions cron'u da aynı işi yapan daha basit bir araç.

Sözlük

batch workload toplu iş yükü
Başlayıp tamamlanan, sürekli çalışmayan hesaplama işi (rapor üretme, veri işleme gibi).
multi-tenancy çok kiracılılık
Aynı platformu birden çok takımın/uygulamanın paylaşması; adil kapasite paylaşımı gerektirir.
job queueing iş kuyruklama
Çalıştırılacak işlerin öncelik ve kapasiteye göre sıraya alınıp zamanlanması.
Orijinali oku
Arşivden Uber Engineering 14 Nisan 2026 16 dk ileri

Two-Tower embedding: öneri sistemlerinin çalışan iskeleti

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ş.

  • İ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ı.

Sende karşılığı

Sen zaten embedding ve RAG ile çalışıyorsun, bu yüzden buradan alacağın şey somut: çift kule ayrımını kendi sisteminde tanı. Mobit'teki doküman aramada belge embedding'lerini önceden hesaplayıp saklıyorsun (öğe kulesi), sorgu geldiğinde sadece sorguyu vektörleştiriyorsun (kullanıcı kulesi). Aynı desen. 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 alan-özgü aramada belirgin fark yaratır. Ayrıca yaklaşık en yakın komşu (ANN) araması öğren: pgvector PostgreSQL'de bunu doğrudan veriyor, senin stack'ine tam oturur.

Sözlük

embedding gömme vektörü
Bir varlığın anlamsal özelliklerini taşıyan sayısal vektör temsili.
two-tower model çift kule modeli
Kullanıcı ve öğeyi ayrı ağlarla vektöre çevirip benzerliklerini karşılaştıran öneri mimarisi.
approximate nearest neighbor (ANN) yaklaşık en yakın komşu
Milyonlarca vektör arasında en benzerlerini, tam doğruluktan biraz ödün vererek çok hızlı bulma tekniği.
Orijinali oku