100K QPS için Gerçek Zamanlı Teklif Altyapısı Mühendisliği

Ad exchange'den bir teklif isteği gelir. Teklif altyapısının gösterimi değerlendirmek, aktif kampanyalara göre puanlamak, bir teklif fiyatı hesaplamak ve yanıt döndürmek için 10ms'si vardır.

Süreyi kaçırırsanız gösterim gider. Yeniden deneme yoktur. 100.000+ QPS'te %1'lik bir zaman aşımı oranı bile saniyede 1.000 kayıp fırsat demektir.

Değerlendirme süresini geri kazanmak için bidder'ları exchange'lerle aynı noktaya konumlandırın

Teklif verici ile ad exchange arasındaki ağ gecikmesi, teklif değerlendirmesi için kalan süreyi doğrudan azaltır. Exchange'e 50ms ağ mesafesindeki bir teklif verici, kodu çalışmadan önce kaybetmiştir.

Bidder örneklerini büyük exchange'lerle aynı noktaya konumlandıran DSP geliştirme ekipleri kritik milisaniyeleri geri kazanır:

• 6-8 küresel veri merkezine dağıtım, merkezî dağıtıma kıyasla istek başına 5-15ms değerlendirme süresi kazandırır
• Her bölgedeki otomatik ölçekleme grupları trafik örüntülerine yanıt verir - ABD Doğu iş saatlerinde zirve yaparken APAC ölçeği küçültür
• Bölgesel bidder instance'ları kampanya hedefleme verisinin yerel kopyalarını tutar; bu kopyalar merkezi depodan her 5-10 saniyede bir senkronize edilir
• Veri merkezleri arasındaki fiber optik kablolar senkronizasyon trafiğini taşır, ancak teklif değerlendirme yolu asla bölge sınırlarını aşmaz

Bellek ayırmayı teklif değerlendirmenin hot path'inden çıkarın

100K QPS'te bellek ayırma desenleri, sistemin gecikme bütçesini tutturup tutturmadığını belirler. 100 QPS'te fark edilmeyen çöp toplama duraklamaları, ölçekte felakete dönüşür.

Teklif değerlendirme yolu belirli teknikler kullanır:

• Kampanya hedefleme kriterleri, frequency cap'ler ve bütçe kısıtları için önceden hesaplanmış arama tabloları - ana kampanya deposundan her 5-10 saniyede bir asenkron güncellenir
• İstek başına heap tahsislerini tamamen ortadan kaldırmak için nesne havuzu ve arena tahsisi
• Paylaşılan durum için kilitsiz veri yapıları - frequency capping için bloom filtreleri, bütçe dağıtımı için atomik sayaçlar
• Hedefleme değerlendirmesi için önceden hazırlanmış karar ağaçları - ağacı kurmak saniyeler, değerlendirmek mikrosaniyeler sürer

Sıcak yolda sıfır bellek ayırma bir optimizasyon değildir. 100K QPS'te bir gerekliliktir.

ML model çıkarımını teklif başına 3ms'nin altında çalıştırın

Tıklama oranı tahmini ve dönüşüm olasılığı modelleri, genel teklif değerlendirme hattının parçası olarak çıkarımı 2-3ms içinde tamamlamalıdır. Çıkarıma harcanan her milisaniye, diğer teklif mantığına kalmaz.

Nicemlenmiş INT8 modelleriyle ONNX Runtime, gecikme-doğruluk dengesinde en iyi sonucu verir:

• Kullanıcı ve bağlam sinyalleri içeren önceden hesaplanmış feature store'larla, teklif isteğinden 0.5ms'nin altında öznitelik çıkarımı
• Thread'e sabitlenmiş yürütmeyle batch ONNX değerlendirmesi kullanarak 1-2 ms'de model çıkarımı - skorlama sırasında bağlam değişimi yok
• Kampanya kademesi başına ön hesaplanmış fiyat eğrileriyle 0,5 ms'nin altında skor kalibrasyonu ve bid fiyatı hesaplama
• Model güncellemeleri blue-green geçişle devreye alınır - yeni model gölge modda yüklenir, üretim tahminlerine karşı doğrulanır, ardından atomik olarak devralır

Teklif verme yoluna ek yük bindirmeden ölçekte izleyin

100K QPS'te geleneksel loglama, teklif mantığının kendisinden daha fazla yük üretir. İzleme yığını da uygulama kadar performans bilincine sahip olmalı:

• Örneklemeye dayalı metrik toplama - 1.000 istekten 1'ini ayrıntılı loglayın, geri kalanını atomik olarak güncellenen sayaç ve histogramlarda toplayın
• Bölge, reklam borsası ve kampanya kademesi bazında p50, p95 ve p99'da gerçek zamanlı yüzdelik takibi
• p99 yanıt süreleri exchange zaman aşımını aştığında bir teklif verici örneğini rotasyondan çıkaran otomatik devre kesiciler
• Teklif oranı düşüşleri, kazanma oranı değişimleri ve harcama hızı sapmaları üzerinde anomali tespiti - eskimiş modelleri ve ağ bozulmasını hata oranı izlemesinden daha hızlı yakalar

Açık artırma denkleminin SSP tarafını üstlenin

Arz tarafı platformu aynı sorunun ayna görüntüsüyle uğraşır. Onlarca teklif vericiye teklif isteği yayınlar, yanıtları toplar, taban fiyatları değerlendirir, açık artırmayı yürütür ve bir kazanan döndürür - hepsini kendi dar zaman aşımı içinde.

SSP geliştiren ekipler ek karmaşıklıkla karşılaşır:

• Header bidding, birden fazla açık artırmayı paralel yürütmek demektir - her bidder'ın zaman aşımı, SSP'nin gecikme bütçesidir
• ML modelleriyle taban fiyat optimizasyonu, gecikme eklemeden aynı açık artırma penceresi içinde çalışmalıdır
• Yüksek performanslı açık artırma mantığı, gösterim başına 20-50 teklif yanıtını değerlendirir ve kazananı 1ms'nin altında seçer

Ölçekte programatik reklamcılık, açık artırmanın her iki tarafının da low latency için durmadan optimize etmesini gerektirir.

Teklif altyapısını mobil uygulama ve uygulama içi envantere uyarlayın

Uygulama içi teklif istekleri, web isteklerinden farklı sinyaller taşır. Çerez tabanlı sinyallerin yerini cihaz düzeyindeki tanımlayıcılar (mevcut olduğunda), uygulama bağlamı ve SDK'nın bildirdiği görüntülenebilirlik alır.

Web envanterinde eğitilen tıklama oranı modelleri, kullanıcı etkileşim örüntülerinin belirgin biçimde farklı olduğu uygulama içi bağlamlar için yeniden eğitilmelidir.

• Mobilde atribüsyon modellemesi, MMP'lerle sunucudan sunucuya postback entegrasyonu gerektirir
• Birden fazla atribüsyon penceresi genelinde tekilleştirme, dönüşümlerin iki kez sayılmasını önler
• Olasılıksal ve deterministik eşleşme uzlaştırması asenkron çalışır - sonuçlar 24 saat içinde teklif modeline geri beslenir