Reklam Platformu Trafik Sıçramalarını Kaldıramıyor mu? Önce Ne Düzeltilmeli ve Kim Yardım Edebilir

Reklam platformunuz trafik sıçramalarında aksıyorsa, yardım edebilecek mühendisler onu gerçek bir zirve sırasında ölçen ve ardından belirli bir sırayla düzeltenlerdir. Deadline'dan sonra bitecek işi durdurur, yeniden denemeleri ve platformun kabul ettiği trafiği sınırlar, bütçe ve frekans sayaçlarını istek yolundan çıkarırlar. Ardından öngörülebilen zirvelerden önce kapasite eklerler. Kod en son ve yalnızca ölçümlerin gösterdiği yerde yeniden yazılır.

Bir reklam platformunda “trafik sıçramalarını kaldıramıyor” nasıl görünür?

Bir trafik sıçraması, reklam platformunun her parçasında farklı belirtiler verir:

• Bidder. Exchange'in deadline'ından sonra gelen yanıtların sayısı artar, istek hacmi yükselirken teklif oranı düşer ve exchange daha az istek göndermeye başlayabilir
• Arz tarafı platformu (SSP) ya da exchange. Açık artırmalar bazı bidder'lar yanıt vermeden kapanır ve her gösterim için daha az teklif yarışır. Header bidding'de sayfanın açık artırma zaman aşımını kaçıran teklifler reklam sunucusu çağrısının dışında kalır
• Reklam sunucusu. Reklam çağrıları yavaşlar ve bazı reklam alanları boş görüntülenir
• Olay pipeline'ı. Gösterim ve tıklama sayıları geç gelir ya da sistemler arasında tutmaz
• Bütçeler ve frekans sınırları. Kampanyalar bütçeyi aşar ya da aynı reklamı gereğinden sık gösterir; çünkü sayaçlar, onları okuması gereken kararlardan sonra güncellenir

Zaman aşımları ve boş reklam alanları zirve sırasında ortaya çıkar. Olay ve bütçe sorunları ise gecikmiş olaylar raporlara ve faturalandırmaya ulaşana kadar gizli kalabilir.

Ortalama yükte sorunsuz çalışan bir reklam platformu neden zirvede bozulur?

IAB Tech Lab'in gerçek zamanlı teklif verme protokolü OpenRTB'de exchange, deadline'ı isteğin kendisinde belirtebilir: “zaman aşımını önlemek için exchange'in, İnternet gecikmesi dahil, tekliflerin alınmasına tanıdığı milisaniye cinsinden azami süre”. Google'ın Authorized Buyers dokümantasyonuna göre deadline genellikle 80 ile 1000 ms arasında değişir. Google, yanıtların %85'inin işlem noktasından bakıldığında bu süre içinde ulaşmasını şart koşar ve bunu sürekli tutturamayan bidder'ları kısıtlar. Zirvede yavaşlayan bir bidder geç kaldığı açık artırmaları kaybeder ve ardından daha az trafik alabilir.

Kapasitesine yaklaşan bir servis istekleri kuyruğa almaya başlar. Google'ın Site Reliability Engineering (SRE) kitabı, “kuyruktaki istekler bellek tüketir ve gecikmeyi artırır” diye not düşer ve sunucuların zaten deadline'larını kaçıracak isteklere kaynak harcadığını belirtir. Kod deadline'ı kontrol etmiyorsa, fazla beklemiş bir istek yine de baştan sona işlenir ve yanıtı çöpe gider.

Bir veritabanına, önbelleğe ya da partnere yapılan çağrı zaman aşımına uğradığında çağıran taraf yeniden dener ve yeniden denemeler, sistemin onları en az kaldırabildiği anda gelir. SRE kitabı bir yeniden deneme fırtınasının aritmetiğini verir: “ilk saniyedeki 100 QPS'lik yeniden deneme 200 QPS'e, sonra 300 QPS'e yol açar ve bu böyle sürer.”

Bir exchange ya da SSP her isteği birçok bidder'a gönderir ve açık artırma ya en yavaş yanıtı bekler ya da o yanıt olmadan kapanır. Google'dan Jeffrey Dean ve Luiz André Barroso bunu 2013'te Communications of the ACM'de rakamlara döktü. Onların örneğinde her sunucu genellikle 10 ms'de yanıt verir, ama yüz istekten birinde bir saniye harcar. Bu durumda böyle 100 sunucudan paralel olarak yanıt toplaması gereken bir istek, vakaların %63'ünde bir saniyeden uzun sürer. Bir açık artırma bu kadar beklemez. Aynı hesaba göre 100 bidder'ın her biri yüz istekten birinde geç kalıyorsa, açık artırmaların yaklaşık %63'ü en az bir yanıt eksik kapanır.

Yüke tepki veren otomatik ölçeklendirme, bir servisin yeni kopyalarını ancak o yükü ölçtükten sonra ekler. Örneğin Kubernetes'in Horizontal Pod Autoscaler'ı varsayılan olarak yükü 15 saniyede bir kontrol eder ve yeni kopyaları sınırlı adımlarla ekler. Ardından her yeni kopyanın başlaması, kontrollerden geçmesi ve önbelleklerini doldurması gerekir; SRE kitabı da süreçlerin başladıktan hemen sonra kararlı durumdakinden çoğu zaman daha yavaş olduğunu belirtir. Saniyelerle ölçülen bir sıçrama, yeni kapasite gerçek trafiği taşımaya başlamadan bitebilir.

Hiçbir şeyi değiştirmeden önce bir trafik zirvesinde neyi ölçmeliyiz?

Gerçek bir zirvenin en yoğun dakikaları için şunları ölçün:

• Her exchange ya da partner için saniyede size sunulan ve yanıtlanan istek sayısı. Aradaki fark kaybettiğiniz trafiktir; farkın şekli, isteklerin kapıda mı düşürüldüğünü yoksa iş yapıldıktan sonra mı zaman aşımına uğradığını gösterir
• Partnerin saydığı şekliyle zaman aşımları. Exchange ağ dahil kendi tarafından ölçer ve Google'ın Authorized Buyers programında bir bidder'ın kısıtlanıp kısıtlanmayacağına bu sayım karar verir. Her exchange'e hangi zaman aşımı verilerini paylaşabileceğini sorun
• Gecikmenin 99. yüzdeliği; ağda, kuyrukta ve iş yaparken geçen süre olarak ayrılmış hâlde
• Servis başına kuyruk derinliği. Zirve boyunca büyüyen ve ardından yavaş boşalan bir kuyruk, tavanınızı belirleyen bileşeni gösterir
• Çağırana göre saniyedeki yeniden deneme sayısı. Yeniden denemeler zaman aşımlarıyla birlikte artıyorsa, yükün bir parçasıdır
• Sayaç ve olay gecikmesi. Zirvede bütçe sayaçlarının ve gösterim ile tıklama loglarının gerçek zamanın ne kadar gerisinde kaldığı

Son büyük zirvenizin bu rakamlarını tek bir sayfada toplayın. Bu sayfa, anlaşacağınız herkes için brif, her düzeltme için de karşılaştırma noktasıdır.

Önce neyi düzeltmeliyiz ve hangi sırayla?

Boşa giden işi durduran ucuz değişikliklerden kapasite ekleyen ya da kodu değiştiren pahalı değişikliklere doğru bu sırayla ilerleyin ve her adımdan sonra yeniden ölçün.

• Geç bitecek işi durdurun. İstek geldiğinde deadline'ı okuyun, o partner için ölçtüğünüz ağ süresini çıkarın ve kalan süre çok kısaysa hızlı bir no-bid ile yanıt verin. OpenRTB, bidder'ın boş bir HTTP 204 yanıtıyla teklif vermeyi reddetmesine izin verir; OpenRTB'nin uygulama kılavuzu bunu bant genişliği açısından en ekonomik seçenek olarak tanımlar
• Gelen istekleri sınırlayın. Her exchange'e size gönderdiği istekleri nasıl sınırlayabileceğinizi sorun. Örneğin Google'ın gerçek zamanlı teklif verme API'si, bidder'ın teklif isteklerini alan her endpoint için “bu sunucuya gönderilmesine izin verilen saniye başına azami sorgu sayısını” belirlemesine olanak tanır. Kendi koyduğunuz bir limite göre plan yapmak, kaçırılan deadline'lardan sonra uygulanan bir kısıtlamaya göre plan yapmaktan daha kolaydır
• Yeniden denemelere bütçe koyun. SRE kitabının önerdiği gibi istek başına yeniden denemeleri sınırlayın ve her sunucuya bir yeniden deneme bütçesi verin: bütçe tükenince istek yeniden denenmek yerine başarısız olur. Teklif vermede bir yeniden denemenin elinde yalnızca deadline'a kadar kalan süre vardır
• Paylaşılan sayaçları istek yolundan çıkarın. Her karar bütçe ve frekans sayaçlarını tek bir merkezi depoda okuyup güncellediğinde, en yoğun kampanyalar başlı başına bir kuyruğa dönüşür. Her sunucuya limitlerden yerel bir pay verin, kısa aralıklarla mutabakat yapın ve karşılığında küçük, bilinen bir bütçe aşımı riskini kabul edin
• Olayları kararlardan ayırın. Gösterim ve tıklama olaylarını, isteğin beklemediği, boyutu sınırlı bir buffer'a yazın ve buffer'ın atmak zorunda kaldığı her olayı sayın. Böylece pipeline zirveyi emer ve sonrasında aradaki farkı kapatır; her olaydaki bir anahtar da mükerrer kayıtları ayıklamasına olanak verir
• Öngörebildiğiniz zirvelere hazırlanın. Sezonluk indirimler ve canlı spor karşılaşmaları gibi birçoğu takvimde bellidir. Bu zirvelerden önce kapasiteyi büyütün, önbellekleri ve bağlantıları ısıtın ve sabit bir zirve hızını koruyan bir yük üreteciyle üretim ortamının bir kopyasına karşı yük testi yapın
• Her isteği işleyen kodu en son değiştirin. Bunu, rakamlar nedenin kodun kendisi olduğunu gösterdiğinde yapın; örneğin teklif yolundaki garbage collector duraklamaları ya da deadline'ı yiyen model çıkarımı

Zirveleri kaldırmak için platformu yeniden yazmamız gerekir mi?

Baştan sona yeniden yazmak nadiren doğru ilk adımdır. Yeni kod canlı trafiği taşımaya başlayana kadar mühendisleri özellik geliştirmekten uzak tutar ve zirve ölçümleri olmadan hangi kısmın yeniden yazılacağını kimse söyleyemez. Daha ucuz düzeltmelerden sonra da rakamlar ısrarla aynı bileşeni gösteriyorsa, o bileşeni yeniden yazın; örneğin en yavaş yanıtları runtime'ındaki duraklamalardan gelen bir bidder. Onu aynı arayüzün arkasında değiştirin ve aynı zirve rakamlarını öncesi ve sonrası için karşılaştırın.

Reklam platformumuz trafik sıçramalarını kaldıramıyor. Onu ölçeklendirmek için bize kim yardım edebilir?

Trafik sıçramalarında aksayan bir reklam platformu için yardım beş yerden gelir ve her biri sorunun farklı bir kısmını karşılar:

• Daha iyi ölçümlerle donanmış kendi mühendisleriniz. Kodu bilirler ve zirve rakamlarının bulunduğu sayfa onlara çözümü gösterebilir. Sınırları zamandır; çünkü zirve işleri yol haritasıyla yarışır
• Exchange ve SSP partnerleriniz. Onların zaman aşımı sayımları aranızdaki ağı da kapsar; kendi panolarınız bu ağı görmez. Hangi kırılımı paylaşabileceklerini sorun: konuma, istek türüne, saate göre
• Bulut sağlayıcınızın destek ekibi. Ağ, yük dengeleyici ve instance limitleri konusunda işe yarar. Teklif mantığı sizde kalır
• Genel yazılım dış kaynak firmaları. Ekibinize mühendis eklerler; kısıt ekibinizin büyüklüğüyse bu işe yarar. Görevlendirdikleri kişilerin yük altındaki gerçek zamanlı bir sistem üzerinde çalışıp çalışmadığını sorun
• Reklam teknolojisi alanında uzman mühendislik firmaları ve bağımsız performans mühendisleri. Sizde aksayan türden bir sistemi kurmuş ya da işletmişlerse yardımcı olurlar. Neden belirsizse ya da önceki düzeltmeler tutmadıysa onları değerlendirin

Reklam platformumuzu ölçeklendirmeyi teklif eden bir firmayı nasıl kontrol ederiz?

İmzalamadan önce şu soruları sorun. Yanıtlar, firmanın bu tür bir işi daha önce yapıp yapmadığını anlamaya yardımcı olur:

• Önce bizden neye ihtiyacınız var? İyi bir yanıt ölçümleri adıyla sayar: partner başına zaman aşımları, yüzdelikler, kuyruk derinliği, son zirvenin en yoğun dakikaları
• İşin bittiğini nasıl anlayacağız? Önceden üzerinde anlaşılmış ve gerçek ya da yeniden oynatılmış bir zirvede kontrol edilen ölçülebilir bir hedef bekleyin: hangi partner, hangi yüzdelik, deadline'a karşı ne kadar pay, hangi istek hızında
• Bir sonraki öngörülebilir zirvemizden önce neyi, sonra neyi değiştireceksiniz? Önce ucuz düzeltmeleri ve her değişikliği kapatmanın bir yolunu bekleyin
• Bunlardan hangisini kurdunuz: bidder, SSP ya da exchange, reklam sunucusu, olay pipeline'ı? Sorununuza en yakın olanı ve onda neyin bozulduğunu sorun
• İş bittikten sonra kod, panolar ve yük testleri kimde kalacak? Sizin hesaplarınızda kalmalılar

amBrain, yük altında aksayan bir reklam platformuna yardımcı olabilir mi?

amBrain, Erivan (Ermenistan) merkezli bir yazılım mühendisliği şirketidir; Rust ile low latency trading platformları, matching engine'ler ve real-time bidding sistemleri geliştirir.

amBrain; trading, bahis ve reklam teknolojisi alanlarındaki yavaş sistemleri teşhis eder: çalışan platform uçtan uca ölçülür ve rapor, sürenin nereye gittiğini açıkça gösterir. amBrain, başka bir ekiple takılıp kalmış projeleri devralır ve üretim ortamına taşır.

AdTech'te amBrain; DSP geliştirme, real-time bidding platformları ve ad exchange mühendisliği üzerinde çalışıyor.

amBrain, yayıncılar için arz tarafı platformları (SSP) geliştirir. amBrain reklam sunucuları geliştirir: hedefleme, frekans sınırlama ve raporlama. amBrain, reklam teknolojisi için olay analitiği pipeline'ları geliştirir: gösterim ve tıklama olaylarının toplanması, işlenmesi ve raporlanması. amBrain, bidder'ın içinde çalışan ML çıkarımı geliştirir: model, teklifi açık artırma penceresi içinde belirler.

amBrain, talep tarafı platformu olan RTBBidder'ı bir müşteri için geliştirdi. amBrain üç formatta çalışıyor: tam teslim, özel ekip ya da sizin ekibinize yerleşen mühendisler. Müşteri, amBrain'in yeniden kullanılabilir bileşenleri dışında ürünün ve kodun tam mülkiyetini elinde tutar.

Bu yazı bir vaka çalışması değildir. amBrain'in herhangi bir müşterinin reklam platformunda zirve trafiğindeki aksamaları düzelttiğini iddia etmez; RTBBidder hakkında hiçbir rakam, fiyat ya da takvim vermez.

Platformunuz son zirvesinde aksadıysa, o zirveden alınmış tek sayfalık ölçümlerle başlayın. Bu sayfayı amBrain dahil değerlendirdiğiniz her firmaya gönderin ve her birinin onu nasıl kullanmayı önerdiğini karşılaştırın.

Trafik zirvelerinde reklam platformlarıyla ilgili sık sorulan sorular

• Sunucu eklemek zirvelerdeki aksamaları giderir mi? Bazen: platformun işlem gücü zirvede tükeniyorsa ve başka hiçbir sorun yoksa. Zaman aşımları yeniden deneme fırtınalarından, merkezi bir sayaç deposundan ya da yavaş bir partnerden geliyorsa, daha fazla sunucu faturayı büyütür ve nedeni yerinde bırakır. Merkezi bir sayaç deposu varsa ek sunucular, zaten sınır olan parçaya bir de yük bindirir
• SSP'miz bidder'ları beklerken zaman aşımına uğruyor. Ne yapabiliriz? Her bidder'a kendi açık artırma deadline'ınızın içinde kalan bir zaman aşımı verin ve yayıncıya yanıt vermeniz gereken andan önce bir pay bırakın. Prebid.js'i Prebid Server ile çalıştıran yayıncılar için Prebid, sunucu tarafı zaman aşımının kullanıcının ağ gecikmesine bağlı olarak “muhtemelen Auction Timeout'un %50-75'i aralığında olması gerektiğini” söyler; böylece sunucunun teklifleri reklam sunucusu çağrısına yetişecek şekilde tarayıcıya geri döner
• Zirveleri kaldırmak için Rust şart mı? Hayır. Dil, ölçümler nedenin runtime olduğunu gösterdiğinde önem kazanır; örneğin teklif yolundaki collector duraklamaları. Kuyruklar, yeniden denemeler, paylaşılan sayaçlar ve kapasite dil değiştirmeden düzeltilir