Programatik ses dünyasında 101 milisaniye sıfır gelir anlamına gelir. Bu bir performans sorunu değil, varoluş sorunudur.    Her bir isteğin   Bu süreyi kaçırırsanız, teklifiniz reddedilir. 101 milisaniyede ise fiilen var olmuyoruz. Günde yaklaşık 350 milyon, haftada ise yaklaşık 2 milyar istek işleyen bir sesli reklam DSP'si işletiyoruz. 100 milisaniyeden kısa sürede alınması, değerlendirilmesi ve yanıtlanması gerekiyor.  Bunu üç kişilik bir mühendislik ekibi ve aylık 10.000 doların altında kalan bir bulut faturasıyla başarıyoruz. Her şey aynı ekip tarafından yönetiliyor: teklif veren altyapısı, uygulama katmanı, veritabanları ve operasyonlar.   RTB Ekosistemi  Eğer reklam teknolojisi konusunda çok bilgili değilseniz, kısaca özetlemek gerekirse: Programatik reklamcılık Gerçek Zamanlı Teklif Verme (RTB) prensibiyle çalışır.  Arz tarafında ise   yer almaktadır. Bunlar, AdsWizz veya Triton gibi binlerce uygulama ve yayıncıdan (podcast oynatıcılar, yayın uygulamaları ve diğer ses platformları) reklam envanterini bir araya getiren platformlardır. SSP'ler (Tedarik Tarafı Platformları)  Talep tarafında ise   bulunur; bunlar, reklamverenleri temsil eden ve belirli bir gösterim için teklif verip vermemeye gerçek zamanlı olarak karar veren, bizimkine benzer sistemlerdir. DSP'ler (Talep Tarafı Platformları)  Bir dinleyici podcast uygulamasını açtığında ve bir reklam alanı müsait hale geldiğinde, uygulama SSP'siyle (Supply-Side Platform) iletişim kurar. SSP daha sonra birden fazla DSP'ye (Dijital Reklam Platformu) teklif isteği gönderir. Sistemimiz bu isteği alır, kullanıcıyı ve aktif kampanyaları değerlendirir, bir teklif fiyatı hesaplar ve bir yanıt gönderir. Tüm bunların uçtan uca 100 milisaniyeden kısa sürede gerçekleşmesi gerekir.  Gecikme süresi burada sadece bir ölçüt değil, ürünün kendisi.  Bunu kabul ettikten sonra, standart web uygulaması kalıplarının işe yaramayacağı apaçık ortaya çıktı. Mikro hizmetler arasında ağ atlamalarına katlanamazdık ve kesinlikle geniş bir Kubernetes kurulumunun getirdiği bulut faturasını karşılayamazdık. Hayatta kalmak için öncelikle kısıtlamaları göz önünde bulundurarak tasarım yapmamız gerekiyordu.  Bu kısıtlama teorik değildi. Başlangıçta, bulut kredilerimiz varken verimlilik konusunda pek endişelenmiyorduk. Bu krediler tükendiğinde, her mimari kararın birdenbire gerçek bir maliyeti oldu. İşte o zaman geri adım atıp sistemi gecikme, maliyet ve operasyonel basitlik açısından yeniden tasarlamak zorunda kaldık.  Aşağıda, üç kişilik bir ekibin para harcamadan veya uykusuz kalmadan küresel bir RTB sistemini büyük ölçekte yönetmesini sağlayan mimari yer almaktadır.  1. Coğrafya İlk Filtre Olarak: Ağ Fiziği İçin Tasarım  Entegrasyon sağladığımız başlıca sesli reklam platformları (SSP'ler) olan   ABD, Avrupa ve Güneydoğu Asya'da barındırılmaktadır. Hindistan merkezli reklamverenler için kampanya mantığını barındıran uygulama katmanımız ise Hindistan'da bulunmaktadır. Triton, AdsWizz, Magnite (eski adıyla Rubicon) ve MCTV,  Bu bölgeler arasındaki ham ağ gidiş-dönüş süresi, herhangi bir uygulama mantığı çalıştırılmadan önce bile yaklaşık   . Bu da bizi izin verilen bütçenin iki katından fazla aşmış oluyor. 240 milisaniyedir  Çözüm basitti ancak pazarlık konusu değildi. Teklif verme kümelerimizi   dağıttık: ABD-Batı (Oregon), AB-Merkez (Frankfurt) ve Asya-Pasifik (Singapur ve Hong Kong). dört stratejik AWS bölgesine  Bu, bir SSP teklif isteği gönderdiğinde, donanıma olan mesafemizin ihmal edilebilir düzeyde (genellikle tek haneli milisaniyeler) olmasını sağlar ve 100 ms'lik bütçenin büyük bir kısmını gerçek hesaplama için bırakır.  2. Monolit-Mikroservis Hibriti   Geleneksel monolit ve mikro hizmet kurulumu arasında bir yerde konumlanan bir mimariye ulaştık. Hizmetleri ağa yaymak yerine,   bir araya getiriyoruz ve ardından bu sanal makineleri küresel bir yük dengeleyicinin arkasında yatay olarak ölçeklendiriyoruz. birbirine sıkıca bağlı hizmetlerden oluşan küçük bir kümeyi tek bir sanal makine üzerinde  Her bir sanal makine (tek bir düğüm olarak ele alınır) içinde, minyatür bir dağıtık sistem gibi görünür:    : Dahili trafik denetleyicisi görevi gören tek bir giriş konteyneri. Nginx    : İşlemciyi tam olarak kullanmak için aynı makinede çalışan Node.js teklif verme hizmetinin 3-5 kopyası. Teklif veren    : Kodun hemen yanında çalışan yerel bir Redis örneği. Redis  Bunun avantajı, varsayılan olarak veri yerelliğidir. Teklif veren, veri almak için ağ üzerinden geçiş yapmaz; verileri yerel sunucudan okur. Bu aynı zamanda   çok daha yüksek seviyelere çıkarmamızı sağlar. Daha büyük sanal makineler (örneğin, c6i.xlarge) kullanarak ve tek bir bellek içi veri kümesini birden fazla çalışan arasında paylaşarak, israfı en aza indirirken verimliliği en üst düzeye çıkaran çok daha iyi bir RAM-CPU oranı elde ederiz. kaynak yoğunluğunu  3. Mantık: Hızlı Başarısızlık  100 milisaniyelik bir süreye ulaşmak için hızlı kod yazmak yeterli değil. Sistem, ne zaman iş yapmaması gerektiğine de hızlıca karar vermelidir.  Gelen teklif taleplerinin çoğu asla kazanmayla sonuçlanmayacaktır. Bu taleplerin durum dosyalarına, veritabanlarına veya yazma yollarına dokunmasına izin vermek, gecikme bütçesini aşmanın en hızlı yoludur. Teklif vereni, "başarısızlık olasılığına" göre sıralanmış bir karar ağacı olarak yapılandırıyoruz ve en ucuz kontrolleri önce gerçekleştiriyoruz.  Kontroller kabaca şu sırayla yapılır:    : Tekliflerin büyük bir kısmı burada başarısız oluyor. Bu basit bir karşılaştırma ve neredeyse anında sonuç veriyor. Coğrafya kontrolü    : Coğrafi doğrulama başarılı olursa, platform ve cihaz kısıtlamalarını doğrularız. İşletim sistemi ve cihaz kontrolleri    : Uygulamanın izin verilen envanterimizle eşleşip eşleşmediğini kontrol etme. Yayıncı/Uygulama Hedefleme    : Bir istek bu filtrelerden geçtikten sonra ancak daha karmaşık yollara, kullanıcı düzeyindeki verilere, bütçe ve zamanlama mantığına veya koordinasyon gerektiren herhangi bir şeye dokunuruz. Durum bilgisi içeren mantık  Hızlı başarısızlık stratejisiyle, trafiğin %90'ını mikrosaniyeler içinde reddederek, işlemci kaynaklarını gerçekten dönüşüm sağlayan teklifler için ayırıyoruz.  4. Veri Mimarisi: Kurallar için Redis, Profiller için Aerospike  Veri mimarimizi erişim modellerine ve "eskime" maliyetine göre iki kademeye ayırdık.  Kurallar: Yerel Redis  Her düğüm, yerel Redis'inde "sıcak" meta verileri (aktif kampanyalar ve bütçe sınırları) tutar. Bir cron çalışanı, en son "gerçeği" indirmek için her 60 saniyede bir merkezi API'mize istek gönderen bir   kullanır. çekme modeli  Bizim ölçeğimizde, bu 60 saniyelik gecikme bir risk yaratıyor:   . Birden fazla düğüm aynı anda aynı eski bütçe verileri üzerinde işlem yaparsa, istemcinin tahsis ettiğinden daha fazla harcama yapabilirler. Aşırı Harcama  Bunu bir   ile ele alıyoruz: filo boyutunu bütçe kontrolüne girdi olarak değerlendiriyoruz. Aktif teklif veren düğüm sayısı arttıkça, her düğüm kullanmasına izin verilen bütçe "dilimini" dinamik olarak azaltır. Bir düğüm eski verilerle çalışıyor olsa bile, yerel limitleri zaten mevcut filo boyutuna göre kısıtlanmıştır. Harcama aniden artmak yerine kademeli olarak yavaşlar ve sistem bir sonraki yenileme döngüsünde dengeye ulaşır. Frenleme Mekanizması  Profiller: Aerospike (SSD Avantajı)  Kullanıcı düzeyinde veri profili aramaları, sıklık sınırlamaları ve yeniden hedefleme gibi işlemler, büyük ve değiştirilebilir veri kümelerine milisaniyenin altında erişim gerektirir. Geleneksel bir RDBMS, bu yükü bizim fiyat aralığımızda karşılayamaz.  Bu katman için   kullanıyoruz çünkü SSD'leri birincil depolama olarak ele alacak şekilde optimize edilmiştir ve tüm çalışma setini RAM'de tutmak yerine bu yöntemi tercih ediyoruz. Bu sayede, ElastiCache gibi tamamen RAM tabanlı bir çözüme kıyasla donanım maliyetlerini çok daha düşük tutarken, öngörülebilir bir gecikme süresi elde ediyoruz. Aerospike  Bu katmanı uygun fiyatlı tutmak için veri hijyeni konusunda son derece titiz davranıyoruz:  10 Günlük Kural: Yalnızca son 10 gün içinde aktif olan kullanıcıların verilerini saklıyoruz.  10 Milyonluk Sınır: Veri setini aktif olarak en aktif birkaç milyon kullanıcıya indirgiyoruz.  Bir kullanıcı etkileşimi durdurursa, verileri silinir. Bu disiplin, depolama maliyetlerinin sabit kalmasını sağlarken, teklif veren firmanın yalnızca önemli olan kullanıcılara odaklanmasını sağlar.  5. "Asenkron" Sırrı: Yükü Ayırmak  İlk versiyonumuz teknik olarak eşzamansız olmayı denedi. Teklif yanıtını hemen gönderir ve Node.js fonksiyonunun arka planda çalışmaya devam ederek logları MongoDB'ye yazmasını sağlardık.    : Trafik düz değil; patlamalar yaşanıyor. Yoğun dönemlerde, teklif yanıtı ortadan kalkmış olsa bile, Node.js konteynerlerimiz "boşta" kalıyor, açık bağlantıları tutuyor ve veritabanı yazma işlemlerini tamamlamaya çalışırken CPU döngülerini tüketiyordu. Bu durum, otomatik ölçekleyicimizin   karşılamak için daha fazla sanal makine başlatmasına neden oldu ve bu da veritabanımızı bağlantılarla çökertti. Tuzak yazma işlemlerinin birikimini    : "Asenkron Kod"dan "   "ye geçtik. Teklif veren ile yazma yolu arasına bir tampon görevi gören   ekledik. Artık teklif veren, Kafka'ya bir mesaj gönderiyor ve kaynaklarını anında serbest bırakıyor. "Yazma" işlemi, kontrollü bir hızda ayrı bir tüketici grubu tarafından gerçekleştiriliyor. Çözüm Asenkron Mimari Kafka'yı  6. Kıyaslama: Tahmin Etmeyin, Ölçün  Bu ölçekte, örnek türlerini tahmin etmek maliyetlidir. Bu nedenle teoriye güvenmek yerine, performans testleri yaptık.  Teklif verenin işlem gücü mü yoksa bellek mi sınırlı olduğu, düğüm başına kaç işçi sürecinin mantıklı olduğu ve örnek boyutunun gecikmeyi nasıl etkilediği gibi hipotezlerimiz vardı. Birden fazla AWS örnek ailesi ve boyutu üzerinde testler yaptık ve tek bir düğümde çalışan teklif verme hizmetlerinin sayısını değiştirdik.  Veri katmanında da aynı yaklaşımı benimsedik ve gerçek yük altında MongoDB için en iyi sonucu veren makine türlerini belirlemek amacıyla farklı makine türlerini denedik; en yüksek verim yerine istikrarlı gecikme süresine öncelik verdik.  Tüm bunlar, sisteme üretim ortamına benzer QPS (saniye başına sorgu) yükleyen ve yanıt sürelerini ve kuyruk gecikmesini ölçen yük testleriyle doğrulandı. Bazı varsayımlar doğru çıktı. Birçoğu ise doğru çıkmadı.  Özetle, sonuç basitti:   . 100 milisaniyelik bir zaman diliminde, kıyaslama testleri teoriyi her zaman geride bırakıyor  7. FinOps: Faturayı 10.000 Dolarda Nasıl Tutuyoruz?  Yeni kurulan şirketler trafik yoğunluğu arttığında değil, bulut kredileri tükendiğinde ölürler. Bizim için maliyet kontrolü sonradan düşünülen bir şey değil, sistem tasarımının bir parçasıdır.  Bazı tasarruflar pazarlıktan kaynaklanıyor. Faturalandırmayı, sabit hacim indirimi için bir bayi aracılığıyla gerçekleştirdik. Bant genişliği için,   taahhüdünde bulunduk; bu da CDN fiyatlarını isteğe bağlı oranlara kıyasla %60'tan fazla düşürmemizi sağladı. Trafik seviyelerimizde, bu tek taahhüt önemli bir fark yarattı. aylık yaklaşık 1 PB transfer  Ayrıca, temel işlevleri de birbirinden ayırıyoruz: Durumsuz teklif veren sunucular, büyük ölçüde indirimli spot kapasite üzerinde çalışırken, durumlu veritabanları öngörülebilir, uzun ömürlü örnekler kullanır.  Bizim ölçeğimizde, günde yüz milyonlarca kaydı depolamak zaman ayarlı bir bomba gibidir. Detaylı teklif kayıtlarının saklama süresi kısadır; aylar değil, günler mertebesindedir. Saklamak istediğimiz veriler, olay başına değil, saatlik olarak erken aşamada toplanır ve daha ucuz, sorgulamaya uygun depolama alanlarına taşınır. Yalnızca uyumluluk veya geçmişe dönük denetimler için gerekli olan her şey, maliyetlerin standart katmanlara kıyasla %80-90 oranında düştüğü soğuk depolama alanına gönderilir.  En büyük tasarruf indirimden değil,   kaynaklanıyor. kullanım oranından  Çoğu sistem, "güvenlik amacıyla" işlemcileri %20-30 oranında çalıştırır. Bizim sistemimizde buna gerek yok. Mimari hata toleranslı ve yükü kademeli olarak azaltacak şekilde tasarlandığı için, işlemcileri   oranında çalıştırmakta bir sakınca görmüyoruz. Boşta kalan döngüler için ödeme yapmıyoruz. Bir çekirdek için ödeme yapıyorsak, o çekirdek teklif veriyor demektir. %80 kullanım  Verimliliği birinci sınıf bir kısıtlama olarak ele alan bu zihniyet, trafik arttıkça bile faturaların sabit kalmasını sağlıyor.  8. Üç Kişiyle Çalışmak: "Öğrenim Ücreti" Felsefesi  Küresel ölçekte üç kişilik bir ekiple çalışmak, ancak sistemler (insanlar değil) yükü taşıdığında mümkün olur. Operasyonlarımızı, kritik yoldan insan müdahalesini ortadan kaldıracak ve mümkün olan her yerde tek hata noktalarını yok edecek şekilde tasarlıyoruz. Ayrıca rol ayrımından da kaçınıyoruz; her mühendis tüm yığını yönetebiliyor, böylece operasyonel bilgi asla tek bir hata noktası olmuyor.  Altyapı varsayılan olarak atılabilir yapıdadır. Bir düğümde sorun oluşursa, yerinde hata ayıklama yapmayız; onu sonlandırır ve otomatik ölçekleyici onun yerine geçer. Kurtarma, araştırmadan daha hızlıdır ve her örnek bilinen, temiz bir durumdan gelir.  Gözlemlenebilirlik önemlidir, ancak gösterge panelleri tek başına küçük bir ekibe yardımcı olmaz. Biz, yalnızca insan müdahalesi gerektiğinde tetiklenen eyleme geçirilebilir uyarılara (Datadog aracılığıyla) güveniyoruz. Bölgesel bir küme yavaşlarsa veya bir tüketici geride kalırsa, bize bildirim gönderilir. Geri kalan her şey otomatiktir.  Otomasyon ise sihir değil. Hâlâ zaman zaman öğrenim ücreti ödüyoruz.  İlk olaylardan birinde, bütçe durumunu güncellemekten sorumlu arka plan işlemi sessizce başarısız oldu. Teklif veren, eski verilerle çalışmaya devam etti ve sona ermesi gereken bir kampanyaya harcama yaptı; klasik bir "zombi teklif veren" senaryosu. Müşteriye para iadesi yaptık, açığı düzelttik ve Datadog tarafından izlenen kalp atışı kontrolleriyle sistemi güçlendirdik. Bütçe güncelliği artık açıkça belirtiliyor ve sessizlik bile bir uyarıyı tetikliyor. Teklif veren geçerli bir güncelleme almazsa, işlem kapatılarak başarısız oluyor.  Küçük bir ekipte hatalar kaçınılmazdır.  Ancak hataları tekrarlamak isteğe bağlıdır.  Sonuç Düşünceleri  Bu sistemdeki kararların hiçbiri tek başına sıra dışı değil. Onu işler kılan şey, bu kararların bir araya gelerek oluşturduğu etkidir.  Ağ fiziği sınırları belirler. Yerellik ve hızlı hata önleme mantığı 100 ms'lik yolu korur. Asenkron sınırlar trafik patlamalarını emer. Ölçüm, sezginin yerini alır. Maliyet disiplini ve yüksek kullanım oranı, ekonomiyi dürüst tutar. İşlemler, insanların yalnızca sistem kendi kendine toparlanamadığında müdahale edecek şekilde tasarlanmıştır.  Bu, reklam teknolojisi veya belirli bir teknoloji yığını hakkında bir hikaye değil. Bu, büyük ölçekte   hatırlatan bir hikaye. Gecikmeyi, maliyeti ve personel sayısını birinci sınıf gereksinimler olarak ele aldığınızda, ortaya çıkan mimari daha karmaşık değil, daha basit olma eğilimindedir. kısıtlamaların engel değil, tasarım girdileri olduğunu  Amaç etkileyici bir şey inşa etmek değildi. Amaç, ayakta kalabilecek bir şey inşa etmekti.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Bu ses hikayenin orijinal dilinde üretilmiştir!

2 Milyar Talep, 100 Milisaniye Son Teslim Tarihleri, Aylık 10.000 Dolar: Yalın Bir Küresel Gerçek Zamanlı Teklif Verme Sisteminin Mühendisliği

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Bu 18 Geliştirici Aracıyla Üretkenliğinizi Artırın 🚀🔥

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Dijital Göçebeler Dinleyin: Tayland'ın Yeni DTV Vizesi Hakkında Bilmeniz Gerekenler

Benzersiz Bir Ekosistemi Güçlendiren Bitcoin UTXO Modeli

Bu 18 Geliştirici Aracıyla Üretkenliğinizi Artırın 🚀🔥

İş Akışınızı 10 Kat Nasıl İyileştirirsiniz: 17 Temel Uygulama

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps