Altyapı Maliyetleri Artarken Zaman Aşımı Yüzünden Açık Artırma Kaybeden DSP: Ne Ölçülmeli ve Kimin Düzeltebileceği Nasıl Kontrol Edilir

DSP'niz iki exchange bağlantısında zaman aşımına uğruyor, diğerlerinde uğramıyorsa, önce bu ikisinde olup geri kalanlarda olmayan şeye bakın. Olası nedenler daha uzun bir ağ rotası, daha kısa bir deadline, daha ağır istekler ya da gereğinden sık yeniden açılan ağ bağlantılarıdır. Aynı nedenler faturayı gelirden daha hızlı büyütebilir; çünkü sunucularınız, sayılmayacak kadar geç gelen yanıtlar için de işi yine yapar.

DSP'miz neden iki exchange bağlantısında zaman aşımına uğruyor da diğerlerinde uğramıyor?

IAB Tech Lab'in gerçek zamanlı teklif verme (RTB) protokolü OpenRTB'de exchange, deadline'ı her isteğin içinde zorunlu olmayan tmax alanıyla iletebilir ve İnternette geçen süre de bu deadline'a dahildir. Yalnızca iki bağlantı aksıyorsa, işe bu ikisini farklı kılan şeyden başlayın:

• Mesafe her deadline'ın bir kısmını tüketir. Google'ın Authorized Buyers dokümantasyonu, teklif istekleri için Kuzey Virginia, San Francisco Körfez Bölgesi, Amsterdam ve Singapur'da olmak üzere dört işlem noktası sayar ve bidder'lara sunucularını bu noktalara yakın yerleştirmelerini tavsiye eder. Google, çok sayıda istek alan bidder'lara ayrıca gecikmeyi ve gecikmenin ne kadar dalgalandığını azaltmak için peering'i, yani kendi ağlarını Google'ın ağına doğrudan bağlamayı önerir
• Deadline'lar exchange'e ve isteğe göre değişir. Google'da deadline, reklam formatına ve açık artırma türüne bağlıdır. Bir isteği ileriye aktaran bir exchange, sürenin bir kısmını kendine de ayırabilir. Örneğin Equativ'in teklif isteği spesifikasyonu, bidder'larına gönderilen tmax değerinin, teklif yanıtlarını işlemeye yetecek süre kalsın diye her zaman daha düşük olduğunu söyler
• Bazı exchange'ler daha ağır istekler gönderir. OpenRTB, her exchange'in kendine özgü ek alanlar eklemesine ve tek bir istekte birden fazla gösterim sunmasına izin verir; isteklerin düz JSON olarak mı, ikili bir formatta mı yoksa sıkıştırılmış olarak mı geleceği de her exchange ile ayrıca kararlaştırılır. Daha büyük bir isteği almak ve çözümlemek daha uzun sürer; her ek gösterim de kampanyaların bir kez daha kontrol edilmesi demektir
• Yeni ağ bağlantıları daha az süreyle başlar. Google'ın RTB uygulamaları için en iyi yöntemler rehberi, yeni bir bağlantıdaki ilk isteğin fiilî deadline'ının daha kısa olduğunu ve zaman aşımına uğrama olasılığının daha yüksek olduğunu söyler ve boşta kalan bağlantıların 2,5 dakika açık tutulmasını önerir. Sunucularınız ya da önlerindeki bir yük dengeleyici veya proxy boştaki bağlantıları daha erken kapatıyorsa, bazı istekler kendi deadline'ları içinde yeni bir bağlantının açılmasını beklemek zorunda kalır
• Bazı adımlar yalnızca belirli istekler için çalışır. Kullanıcı verisi sorgusu ya da tek bir reklam formatı için kullanılan bir model yavaş kaldığında, gecikme yalnızca istekleri bu adımdan geçen bağlantılara biner
• Bir exchange'in trafiği daha yoğun sunuculara düşebilir; orada istekler, hiçbir iş başlamadan önce kuyrukta bekler. Google, bir proxy üzerinden kurulan ağ bağlantılarının zamanla dengesizleşebileceğini ve sunucularınızdaki yükü eşitsiz bırakabileceğini belirtir

Bidder sürecinin tamamındaki bir yavaşlama her bağlantıyı aynı anda geciktirir. Go ya da Java ile yazılmış bir bidder'da buna garbage collection (GC), yani runtime'ın programın artık ihtiyaç duymadığı belleği yeniden kullanıma kazandırma işi yol açabilir. Ağ süresi ve her isteğin gerektirdiği iş düşüldükten sonra en az payı kalan bağlantılar deadline'larını ilk kaçıranlar olur. Bu yüzden yalnızca bu iki bağlantıda olan bir neden aramadan önce her bağlantının deadline'ını ağ süresiyle ve istek boyutuyla karşılaştırın. Yukarıda bağlantısı verilen Go GC duraklamaları yazısı, mühendislerin bu nedenleri nasıl birbirinden ayırdığını gösteriyor.

Altyapı faturamız neden gelirden daha hızlı büyüyor?

Fatura, sunucularınızın aldığı ve yanıtladığı her istekle büyür; gelir ise yalnızca kazandığınız açık artırmalardan gelir. Aradaki fark birkaç yoldan açılır:

• Hiç kampanyanızın olmadığı bir format ya da ülke için gelen istek yine de alınıp ayrıştırılmak zorundadır ve kazanamaz. Google'ın ön hedefleme (pretargeting) özelliği, bir bidder'ın yalnızca kendi hedefleme ölçütlerine uyan istekleri almasına olanak tanır. Her exchange'e hangi filtrelemeyi sunduğunu sorun
• Geç yanıtlar size gönderilen trafiği de küçültebilir. Google'ın RTB grafikleriyle ilgili yardım sayfası, yanıtların %15'ten fazlası geçersiz olduğunda ya da zaman aşımına uğradığında Google'ın, hata oranı %15'in altına inene ya da istekler asgari bir düzeye düşene kadar daha az istek gönderdiğini söyler. Trafik sık sık ve uzun süreler boyunca kısıtlanıyorsa Google, bidder'ın kotasını, yani göndereceği saniye başına azami istek sayısını, bidder'ın daha tutarlı biçimde karşılayabileceği bir düzeye ayarlayabilir. Eski kotaya göre boyutlandırılmış sunucular, biri onları yeniden boyutlandırmadıkça maliyet çıkarmaya devam eder
• Aynı veri merkezine eklenen sunucular faturayı büyütür ama exchange'e giden uzun bir rotayı kısaltmaz ya da boştaki ağ bağlantılarının fazla erken kapatılmasını engellemez
• Aynı gösterim size birden fazla exchange üzerinden ulaşabilir. OpenRTB 2.6, bir teklif isteğinin tüm katılımcıları arasında (bunlar birkaç exchange'i de kapsayabilir) ortak olması gereken bir işlem kimliğini (transaction ID) ve ödemenin doğrudan akışında yer alan şirketleri listeleyen bir tedarik zinciri (supply chain) nesnesini tanımlar. Exchange'lerin bu alanları doldurduğu durumlarda bu alanlar, iki bağlantının size aynı gösterimi sunduğunu gösterebilir; her kopya da size sunucu zamanına mal olur
• Bir miktar yedek kapasite gereklidir. Trafiğin bölgeler arasındaki geçici kaymalarını karşılamak için Google, yedi günlük zirve ile her işlem noktası için belirlenen saniye başına istek sayısı arasında %15'lik bir pay bırakmayı önerir. İlk sorgulanması gereken yedek kapasite, bir olaydan sonra onu haklı çıkaracak bir ölçüm olmadan eklenen kapasitedir

Farkın nerede açıldığını görmek için her exchange bağlantısında milyon istek başına maliyeti ve geliri yan yana koyun. Önce çok istek getirip az kazanım sağlayan bir bağlantıya bakın ve bunun zaman aşımına uğrayan iki bağlantıdan biri olup olmadığını kontrol edin.

Kimseyle anlaşmadan önce neyi ölçmeliyiz?

Bunları her exchange bağlantısı için bir satır olacak şekilde, normal bir hafta ve o haftanın en yoğun saati için tek bir sayfaya koyun:

• Exchange ve bölgeye göre saniyedeki istek sayısı ve ortalama istek boyutu
• Bu isteklerdeki deadline'ların dağılımı: exchange tmax gönderiyorsa tmax'tan, göndermiyorsa exchange'in dokümantasyonundan okunur
• Her exchange bağlantısında, yanıtlarınızın yalnızca en yavaş %1'inin aştığı yanıt süresi (99. yüzdelik); iki yöndeki ağ süresi, sunucularınızın içinde geçen süreden ayrılmış olarak
• Her exchange'in bildirdiği zaman aşımları ve yanında kendi loglarınızdaki sayı. Örneğin Google'ın RTB grafikleri; ön hedeflemenize uyan istekleri, fiilen gönderilen istekleri, zaman aşımı süresi içindeki geçerli yanıtları, teklifleri ve kazanılan açık artırmaları sayar, ayrıca her endpoint için, yani bidder'ınızın istekleri aldığı adres için gecikme yüzdeliklerini gösterir. Diğer exchange'lerin neleri bildirdiğini öğrenin
• Her exchange için dakikada açılan yeni ağ bağlantısı sayısı ve o exchange'e yanıt veren sunucuların nerede bulunduğu
• Exchange başına teklif oranı, kazanma oranı, harcama ve gelir
• Her exchange için milyon istek başına altyapı maliyeti; sunucular ve bant genişliği dahil

Bu sayfayı görüştüğünüz her ekibe verin ve bugünkü rakamları saklayın; çünkü bir ekibin yaptığı her değişiklik bu rakamlara göre değerlendirilecek. Yukarıdaki nedenlerin birkaçı, kimse kodu açmadan bu rakamlarla doğrulanabilir ya da elenebilir. Zirvelerde başka neyin ölçüleceğini trafik sıçramaları yazısı sıralıyor.

Teklif yolundaki gecikmeyi gerçekten düzeltmiş bir ekip önerebilir misiniz?

Bu yazı firmaları sıralamıyor. Bir ekibin teklif yolundaki gecikmeyi gerçekten düzeltip düzeltmediği, kendi başınıza kontrol edebileceğiniz kanıtlarda görünür:

• Ekibin kurduğu ya da onardığı ve hâlâ üretimde çalışan bir bidder ya da exchange; müşterinin adıyla ya da adının neden verilemediğinin gerekçesiyle
• O müşteride, görüşmede ekip olmadan sizinle konuşacak bir mühendis
• Adı verilen exchange bağlantıları için müşterinin doğruladığı öncesi ve sonrası rakamları; örneğin exchange'in saydığı şekliyle zaman aşımı oranı ve milyon istek başına maliyet
• Önceki bir işten kalma, müşterinin verileri çıkarılmış bir teşhis raporu ya da plan

Bir ekibin gerçek olup olmadığını nasıl kontrol ederiz?

Teklif yolunda herhangi bir iş başlamadan önce bu beş kontrolü sırayla yapın.

Ekibe bağlantı başına rakamları içeren sayfanızı gönderin ve önce neyi test edeceğini sorun. Bu işi daha önce yapmış bir ekip, iki bağlantınız için olası nedenleri ve her birini doğrulayacak ya da eleyecek ölçümü söyler. İlk yanıtta bir programlama dili ya da fiyat geçiyorsa, ekip büyük ihtimalle rakamlarınızı henüz okumamıştır.

Herhangi bir yeniden yazımdan önce yazılı bir plan isteyin. Planda şunlar yer almalı:

• Ekibin önce neyi ölçeceği ve hangi erişime ihtiyaç duyduğu
• Hangi değişikliklerin önce geleceği (en ucuzundan başlayarak) ve her birinin nasıl geri alınabileceği
• İki exchange bağlantısının her biri için, o exchange'in bildirdiği şekliyle hedef zaman aşımı oranı, milyon istek başına hedef maliyet ve ikisinin de kontrol edileceği trafik düzeyi
• Yeniden kurulan bir parçanın canlı trafiğin bir kopyası üzerinde mevcut parçanın yanında nasıl çalışacağı ve ardından bağlantıları birer birer nasıl devralacağı
• Ekibin neye dokunmayacağı

Teşhisin ve planın ücretini ayrı bir iş olarak ödeyin ve devam etseniz de etmeseniz de raporun sizin olmasını sağlayın.

Bidder'ını ya da exchange'ini ekibin kurduğu veya onardığı ve onu hâlâ çalıştıran bir müşteriyi arayın. O müşterinin mühendisleriyle görüşmede ekip olmadan konuşun ve şunları sorun:

• Ekip herhangi bir şeyi değiştirmeden önce neyi ölçtü?
• Hangi rakamlar, hangi exchange bağlantılarında değişti ve bunları kim ölçtü?
• Kodu bugün kim işletiyor ve kim değiştiriyor?
• İş sırasında neler ters gitti ve ekip bu konuda ne yaptı?

İşi yapacak mühendislerle tanışın ve ekip liderine düzelttiği son gecikme sorununu sorun. Bu işi yapmış biri exchange'in adını ve değişen rakamı söyleyebilir; genellikle de önce denediği ama işe yaramayan şeyi hatırlar. Bu mühendislerin adlarını sözleşmeye yazın.

Mülkiyet koşullarını en son okuyun. Kod ilk günden sizin depolarınızda durmalı ve yazılı olarak şirketinize devredilmelidir. Ekibin elinde tuttuğu her şey, iş bittikten sonra onu kullanmanızı ve değiştirmenizi sağlayan bir lisansla birlikte adıyla listelenmeli; bidder da ekibin sunucuları ya da lisans anahtarları olmadan çalışmalıdır.

Hangi firmalar, platformumuzun içinde çalışan özel bir ekip olarak bir DSP bidder'ı kurabilir ya da yeniden kurabilir?

Reklam teknolojisi alanında uzman mühendislik firmaları, bidder ve exchange kurmayı ve onarmayı asıl işleri olarak yapar. Bağımsız bir performans mühendisi teşhisi tek başına yürütebilir, ama yeniden kurmak bir ekip ister. Daha geniş kapsamlı bir yazılım firması da görevlendirdiği kişiler daha önce bir bidder üzerinde çalışmışsa aynı işi yapabilir; bu yüzden o kişileri adlarıyla isteyin.

Düşük gecikme, GC duraklaması olmaması ve yüksek QPS isteyen bir brief, bu ifadelerin her birinin ne anlama geldiğini söylemelidir:

• “Düşük gecikme”, kendi bağlantılarınızda, 99. yüzdelikte her exchange'in deadline'ı içinde kalan yanıtlar demektir. Bidder'ın tamamı üzerinden alınan bir ortalama, aksayan iki bağlantıyı gizleyebilir
• “GC duraklaması yok”, garbage collection ile ilgilidir; yani bidder'ın yazıldığı dile ve o dilin runtime'ına dair bir gerekliliktir. Rust kitabı, Rust'ın belleği “derleyicinin denetlediği bir dizi kurala sahip bir sahiplik sistemi” aracılığıyla yönettiğini söyler; bu yüzden bir Rust bidder'ında onu duraklatacak bir collector yoktur. Go ve Java bidder'larında ise bir collector vardır ve ayarları iyileştirilebilir. Uzun bir ağ rotası ya da bir kuyruk yine de her bidder'ı geciktirebilir
• “Yüksek QPS”, yani saniyede çok sayıda sorgu, arkasındaki istek boyutu ve yayındaki kampanya sayısı bilinmeden pek bir şey ifade etmez. Bir rakamın üretimden mi yoksa bir testten mi geldiğini ve kimin trafiğiyle elde edildiğini sorun

Platformunuzun içindeki bir ekip sizin depolarınızda ve bulut hesaplarınızda çalışır, değişiklikleri de sizin inceleme sürecinizden geçer. Erişimini siz verirsiniz ve geri alabilirsiniz; önceliklerini de sizin tarafınızdan biri belirler. İş sırasında ve sonrasında teklif yolu için kimin nöbet tutacağında anlaşın ve bilgi sizin mühendislerinizde kalsın diye onları ekiple eşleştirin.

Teklif yolu işi için bir ekiple anlaşırken tehlike işaretleri nelerdir?

• Kimse bağlantı başına rakamlarınızı görmeden bir yeniden yazım ya da yeni bir dil öneriliyor
• İlk görüşmede bir gecikme rakamı ya da faturanızda bir tasarruf vaat ediliyor
• Kanıt olarak sunulan şey, ekibin kendi donanımında kendi istekleriyle yapılmış bir kıyaslama testi
• Platformunuzun içinde çalışacak bir ekip istemiş olmanıza rağmen bidder ekibin sunucularında ya da onun lisansıyla çalışacak
• Hiçbir müşteri görüşmeyi kabul etmiyor ve çalışan hiçbir bidder ya da exchange gösterilemiyor
• Proje teklifindeki her düzeltme sunucu ekliyor

amBrain nerede devreye girer?

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

amBrain; trading 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 üç 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.

amBrain 2019'dan bu yana yazılım geliştiriyor. amBrain, talep tarafı platformu olan RTBBidder'ı bir müşteri için geliştirdi.

Bu yazı bir vaka çalışması değildir. O platformu (tasarımını, dilini ya da performansını) anlatmaz ve amBrain'in herhangi bir müşteri için teklif yolundaki gecikmeyi teşhis ettiğini ya da düzelttiğini iddia etmez. Fiyat ya da takvim vermez.

Exchange bağlantılarınızdan ikisi zaman aşımına uğruyorsa, kimseyle konuşmadan önce onların rakamlarını tek bir sayfaya koyun. Sonra amBrain'e ya da listenizdeki başka herhangi bir ekibe o iki bağlantıda önce neyi ölçeceğini sorun ve her ekibi aynı beş kontrolden geçirin.

Sık sorulan sorular

• Bir exchange'in istek gönderdiği her bölgede bir bidder'a ihtiyacımız var mı? Her zaman değil. Google her isteği kullanıcıya en yakın işlem noktasına göndermeye çalışır ama bunu garanti etmez; bu yüzden gösterimlerinin tamamını almak, dört noktanın hepsinden erişilebilen sunucular gerektirir. Google'ın test rehberi, birkaç işlem noktasından gösterim almanın genellikle her bölgede teklif sunucuları çalıştırmak anlamına geldiğini de ekler. Trafiğin yalnızca bir kısmını istiyorsanız, Google'a göre noktaların bazılarındaki sunucular yetebilir; bu yüzden bölgeleri kampanyalarınızın nerede satın alma yaptığına göre seçin
• Bir exchange'in bize gönderdiği istekleri sınırlamak kazanım kaybetmemize yol açar mı? Bu, exchange'in hangi istekleri geri tuttuğuna bağlı. Google'da bir bidder'ın ön hedeflemesine uyan istekler kotasını aştığında fazlası kısıtlanır ve bidder'ın yanıt vermesi muhtemel istekler, yakın dönemdeki teklif geçmişine göre zaman zaman önceliklendirilir. Diğer exchange'ler farklı karar verebilir; bu yüzden her birine sorun