Sayı 57

Canlı bir sistemin altındaki protokolü değiştirmek, protokolün kendisinden çok geçişin nasıl yapıldığıyla ilgilidir. Meta, Instagram Live’ın yükleme protokolünü kimse fark etmeden değiştirdi ve nasıl yaptığını anlatıyor. Yanında boşta duran inference kapasitesini işe koşan bir sistem ve logları yola çıkmadan süzmek var.

Günün kapağı Meta Engineering 12 Ekim 2026 8 dk okuma ileri

Canlı yayının altındaki protokolü değiştirmek: Instagram Live’da Media over QUIC

Shipping Media Over QUIC at Meta Scale for Instagram Live Ingest

Instagram Live artık iOS ve Android’de canlı video yüklemesi (ingest) için açık standart Media over QUIC (MoQ) kullanıyor. İnternet yıllar içinde her biri kendi sorununa göre biçimlenmiş bir protokol yığını biriktirdi: yükleme için RTMP, oynatma için HLS ve DASH, gerçek zamanlı aramalar için WebRTC. Meta’da canlı yayın başlatıp aynı uygulamada sesli arama yapan biri üç ayrı protokol yığınına dokunuyor; her birinin kendi sunucu altyapısı, izlemesi ve uzmanlığı var. MoQ’un vaadi, yükleme, dağıtım ve oynatma için tek bir taşıma katmanı.

MoQ nasıl çalışır? IETF’te Meta, Google, Akamai, Cisco, Cloudflare ve akademinin katılımıyla geliştirilen bir standart. Temel soyutlama Track: yayıncıların ittiği, abonelerin bir relay (relay) ağı üzerinden aldığı adreslenebilir medya nesnesi akışı. Relay’ler nesneleri medya içeriğini çözümlemeden cache’e alıp iletiyor. Öne çıkan özellikler: QUIC sayesinde akışlar arası TCP tarzı head-of-line blocking yok; caching ve çoğaltma protokolün içinde; aynı Track’in iki abonesi aynı anda farklı gecikmelerde çalışabiliyor (etkileşimli katılımcı için yaklaşık 100 ms, arşiv için birkaç saniye); relay’ler tıkanıklıkta nesneleri metadata’ya göre düşürüp önceliklendirebiliyor; QUIC engellendiğinde standart bir TCP geri dönüşü var.

Geçiş nasıl yapıldı? Canlı yükleme yaklaşık on yıldır Meta’nın kendi QUIC tabanlı protokolü RUSH üzerindeydi. Yazının itirafı şu: canlı bir sistemde taşıma protokolünü değiştirmenin zorluğu protokolle pek ilgili değil. Üç kısıtlı probleme böldüler. İstemci: açık kaynak MoQ kütüphaneleri moxygen üzerine kurulu bir yayıncı; tek bir yapılandırma parametresi yayın başına MoQ ya da RUSH seçiyor. Arka ucu yeniden yazmak yerine uçta çeviri: MoQ bağlantıları özel uç noktalarda sonlanıyor ve bir çeviri katmanı MoQ çerçevelerini arka ucun zaten anladığı RUSH biçimine dönüştürüyor. Aşağı akışta hiçbir şey değişmiyor; çevirici geçici bir iskele. Sunucu taraflı yönlendirme: yayın URL’si üretilirken deney grubuna göre MoQ uç noktası seçiliyor; böylece yayılım uygulama sürümünün benimsenmesine bağlı değil ve deney dakikalar içinde büyütülüp küçültülebiliyor.

Operasyonel engeller. Taslak standart geliştirme sürerken değişti: belirli taslak sürümlerine sabitlendiler ve eski istemciler için uyumluluk katmanları tuttular. UDP/443 kurumsal ve operatör ağlarının azımsanmayacak bir bölümünde engelli: yayın başında TCP ve QUIC handshake’leri yarıştırılıyor, kazanan oturum boyunca kullanılıyor. QUIC şifrelemesi çerçeveleri kendi paket yakalamalarından da gizlediği için uca MoQ’u tanıyan izleme eklediler.

Sonuç: aylarca süren deneyin ardından MoQ yolu, kalite ve güvenilirlik göstergelerinde RUSH ile eşit çıktı. Bu aşamanın hedefi iyileşme değil eşitlikti: üretimdeki bir taşıma katmanını kimseyi rahatsız etmeden değiştirebildiklerini gösterdi ve sonraki adımlar için temiz bir taban verdi.

Öne çıkanlar

  1. Büyük bir geçişte ilk hedef iyileşme değil eşitliktir; eşitlik sonraki her adımın tabanıdır.
  2. Geçici bir çeviri katmanı, istemci ve arka uç değişikliklerini birbirinden ayırır.
  3. Yayılımı istemci sürümüne değil sunucu taraflı yönlendirmeye bağlamak, saniyeler içinde rollback’ı sağlar.
  4. Yeni protokol her ağda çalışmaz; geri dönüş yolu tasarımın parçası olmalı.
  5. Şifreli protokolde debugging için gözlemlenebilirliği uç noktaya kendin koymalısın.

Neden önemli?

Çalışan bir sistemin temel bileşenini değiştirmek, mühendisliğin en riskli işlerinden biri. Bu yazıdaki üçlü (bayrakla seçilebilir yeni yol, geçici çeviri katmanı, sunucu taraflı yayılım) protokolden bağımsız, her büyük geçişe uyan bir kalıp.

Pratikte

Bu kalıbı bir sonraki büyük değişikliğinde uygula; örneğin mesajlaşmayı polling’den WebSocket’e ya da bir kütüphaneyi diğerine taşırken. Bir: yeni yolu bir feature flag’in arkasına koy ve eski yolu silme. İki: yeni istemciyi eski backend’e bağlayan ince bir adapter yaz; iki tarafı aynı anda değiştirme. Üç: flag’i sunucuda tut ki uygulama güncellemesi beklemeden kapatabilesin. Dört: başarı ölçütünü baştan yaz: ‘hata oranı ve p95 gecikme eskisiyle aynı’. WebSocket için de aynı ders geçerli: bazı ağlar bağlantıyı keser, long polling’e geri dönüş yolunu baştan tasarla.

Sözlük

Media over QUIC (MoQ)
Canlı yayın ve gerçek zamanlı iletişim için QUIC üzerinde çalışan, IETF’te geliştirilen medya taşıma protokolü.
ingest
Yayıncının cihazından sunucuya giden canlı video akışı.
head-of-line blocking
Kaybolan tek bir paketin, arkasındaki ilgisiz verilerin de beklemesine yol açması.
relay
Medya nesnelerini içeriğini çözmeden cache’e alıp abonelere ileten ara sunucu.
feature flag
Bir özelliği kod dağıtmadan açıp kapatmayı sağlayan yapılandırma anahtarı.
Orijinali oku

Kısa kısa

Meta Engineering 12 Ekim 2026 10 dk okuma ileri

Küresel olarak kıt, yerel olarak boşta: Meta atıl inference kapasitesini nasıl kullanıyor

Turning Opportunistic AI Inference Capacity Into Better Ads Recommendations

Inference filolarında bir paradoks var: kapasite küresel olarak kısıtlıyken yerel olarak anlamlı miktarda boşta kalabiliyor. Nedenleri tanıdık: filo tepe talebe göre kuruluyor ama trafik gün içinde değişiyor; donanım tedarik zincirinin takvimiyle, modeller ise başka bir takvimle geliyor. Meta bu boş cepleri ortak bir opportunistic capacity havuzunda toplayıp daha iyi reklam önerisine çeviriyor. Zorluk şu: bu kapasite ekiplere, bölgelere ve hızlandırıcı türlerine dağılmış ve çok kısa bir uyarıyla geri alınabiliyor.

Sistem iki esneklik koluyla çalışıyor. Rank More Ads (RMA): sıralama aşamalarının değerlendirdiği aday sayısını artırıyor; ek adaylar getirme ve özellik işleme aşamalarından da geçtiği için hem CPU hem hızlandırıcı fazlası gerektiriyor. Serve Better Models (SBM): aday sayısını sabit tutup isteklerin daha büyük bir bölümünü daha güçlü bir modele yönlendiriyor; yalnızca hızlandırıcı fazlasını kullanabiliyor ve en çok fayda görecek istekleri değer sinyaliyle önceliklendiriyor. İkisi farklı kaynak bileşimleri tükettiği için birlikte daha geniş bir boşluğu dolduruyor. Temel iş yükünün kapasitesi fiziksel ve mantıksal yalıtımla korunuyor; kapasite çekilince değere duyarlı load shedding sistemi zarifçe geriletiyor.

Öne çıkanlar

  1. Tepe yüke göre kurulan her sistem, günün çoğunda boşta kapasite taşır.
  2. Geri alınabilir kapasiteyi yalnızca vazgeçilebilir, ek değer üreten işe ver.
  3. Farklı kaynak bileşimi tüketen iki ayar düğmesi, tek düğmeden daha fazla boşluğu doldurur.
  4. Yük atarken rastgele değil, en az değerli isteği önce at.

Pratikte

Küçük ölçekte aynı fikir: zorunlu işi (kullanıcıya cevap) ve isteğe bağlı işi (daha ayrıntılı geri bildirim, ikinci bir model geçişi) ayır. Sistem rahatken isteğe bağlı işi çalıştır, kuyruk uzayınca ilk onu kapat. Bunun adı graceful degradation ve bir if (queueDepth > N) kadar basit başlayabilir.

Sözlük · 3 terim
opportunistic capacity
O an boşta olan ama her an geri alınabilecek hesaplama kapasitesi.
load shedding
Aşırı yük altında sistemi ayakta tutmak için bazı istekleri bilerek reddetme ya da basitleştirme.
graceful degradation
Kaynak azaldığında sistemin tümüyle çökmek yerine kaliteyi kademeli düşürmesi.
Orijinali oku
Cloudflare Blog 12 Ekim 2026 8 dk okuma başlangıç

Logu yola çıkmadan süz: Logpush Transformers

Filter, reshape, and redact logs before export with Transformers

Ekipler Cloudflare loglarını SIEM’lere, analitik platformlarına ve nesne depolamaya aktarıyor. Loglar hedefe varmadan önce çoğu zaman sağlık kontrollerini çıkarmak, hassas alanları atmak ya da kayıtları yeniden biçimlendirmek gerekiyor ve bu, kurulup ölçeklenip izlenmesi gereken ayrı bir işleme servisi demek. Üstelik ekipler varır varmaz atacakları kayıtların aktarımı, alımı ve saklanması için de para ödüyor.

Transformers bu işlemi aktarım hattının içine alıyor. Bir Transformer, belirli bir veri kümesi için yazılmış bir SQL sorgusu: kayıtları filtreliyor, hassas veriyi karartıyor ve alan ekleyip yeniden adlandırarak, çıkararak ya da iç içe koyarak çıktıyı biçimlendiriyor. Sorgu her toplu gönderime aktarımdan önce uygulanıyor. Örnek kullanım: birden çok CDN’den log toplayan bir ekip, kayıtları ortak şemaya oturtmak için sabit bir provider alanı ekliyor.

Öne çıkanlar

  1. Kullanmayacağın veriyi taşımak ve saklamak için de ödersin; kaynağa en yakın yerde süz.
  2. Hassas alanı hedefte değil kaynakta karart; hedefe hiç ulaşmayan veri sızamaz.
  3. Dönüşümü SQL ile tanımlamak, ayrı bir servis işletme yükünü ortadan kaldırır.

Pratikte

Spring Boot’ta aynı ilke: /actuator/health isteklerini erişim loguna yazma ve e-posta, token, TC kimlik no gibi alanları log satırına hiç koyma (Logback’te bir maskeleme dönüştürücüsü ya da log öncesi bir DTO). Logu sonradan temizlemek yerine baştan temiz yazmak hem ucuz hem güvenli.

Sözlük · 2 terim
redaction
Hassas verinin kayıttan çıkarılması ya da maskelenmesi.
NDJSON
Her satırın bağımsız bir JSON nesnesi olduğu metin biçimi; log aktarımında yaygın.
Orijinali oku