Öyle görünüyor ki, çevrimiçi reklamcılık alanının teknolojik açıdan mümkün olduğu kadar gelişmiş ve otomatikleştirilmiş olması gerekiyor. Tabii ki, çünkü Yandex, Mail.Ru, Google ve Facebook gibi kendi alanlarındaki devler ve uzmanlar orada çalışıyor. Ancak ortaya çıktı ki mükemmelliğin sınırı yok ve her zaman otomatikleştirilecek bir şeyler var.
İletişim grubu Dentsu Aegis Ağı Rusya dijital reklamcılık pazarının en büyük oyuncusudur ve teknolojiye aktif olarak yatırım yaparak iş süreçlerini optimize etmeye ve otomatikleştirmeye çalışmaktadır. Çevrimiçi reklamcılık pazarının çözülmemiş sorunlarından biri, farklı İnternet platformlarından reklam kampanyalarına ilişkin istatistik toplama görevi haline geldi. Bu sorunun çözümü sonuçta bir ürünün yaratılmasıyla sonuçlandı. D1.Dijital (DiVan olarak okuyun), gelişiminden bahsetmek istediğimiz şey.
Neden?
1. Projenin başlangıcında piyasada reklam kampanyalarına ilişkin istatistiklerin toplanmasının otomatikleştirilmesi sorununu çözen tek bir hazır ürün yoktu. Bu, kendimizden başka hiç kimsenin ihtiyaçlarımızı karşılayamayacağı anlamına gelir.
Improvado, Roistat, Supermetrics, SegmentStream gibi hizmetler platformlar, sosyal ağlar ve Google Analytics ile entegrasyon sunar ve ayrıca reklam kampanyalarının uygun analizi ve kontrolü için analitik kontrol panelleri oluşturulmasını mümkün kılar. Ürünümüzü geliştirmeye başlamadan önce bu sistemlerden bazılarını sitelerden veri toplamak için kullanmayı denedik ancak maalesef sorunlarımıza çözüm bulamadılar.
Asıl sorun, test edilen ürünlerin veri kaynaklarına dayanması, yerleşim istatistiklerini siteye göre göstermesi ve reklam kampanyalarına ilişkin istatistikleri toplama olanağı sağlamamasıydı. Bu yaklaşım, farklı sitelerden alınan istatistikleri tek bir yerde görmemize ve kampanyanın durumunu bir bütün olarak analiz etmemize olanak vermedi.
Diğer bir faktör ise ilk aşamalarda ürünlerin Batı pazarını hedef alması ve Rus siteleriyle entegrasyonu desteklememesiydi. Entegrasyonun uygulandığı siteler için gerekli tüm ölçümler her zaman yeterli ayrıntıyla indirilmiyordu ve entegrasyon, özellikle sistem arayüzünde olmayan bir şeyin alınması gerektiğinde her zaman kullanışlı ve şeffaf olmuyordu.
Genel olarak üçüncü taraf ürünlere uyum sağlamamaya karar verdik, ancak kendi ürünlerimizi geliştirmeye başladık...
2. Çevrimiçi reklamcılık pazarı yıldan yıla büyüyor ve 2018 yılında reklam bütçeleri açısından geleneksel olarak en büyük TV reklamcılığı pazarını geride bıraktı. Yani bir ölçek var.
3. Ticari reklam satışının tekelleştirildiği TV reklam pazarının aksine, internette kendi reklam hesaplarıyla faaliyet gösteren, çeşitli boyutlarda reklam envanterinin çok sayıda bireysel sahibi vardır. Bir reklam kampanyası kural olarak birkaç sitede aynı anda yürütüldüğünden, reklam kampanyasının durumunu anlamak için tüm sitelerden raporları toplamak ve bunları tüm resmi gösterecek büyük bir raporda birleştirmek gerekir. Bu, optimizasyon potansiyeli olduğu anlamına gelir.
4. Bize öyle geldi ki, İnternet'teki reklam envanteri sahipleri, istatistiklerin toplanması ve reklam hesaplarında görüntülenmesi için altyapıya zaten sahipler ve bu veriler için bir API sağlayabilecekler. Bu, uygulamanın teknik olarak mümkün olduğu anlamına gelir. Hemen diyelim ki o kadar basit olmadığı ortaya çıktı.
Genel olarak projenin hayata geçmesi için gereken tüm ön koşullar bizim için açıktı ve projeyi hayata geçirmek için koştuk...
Büyük Plan
Başlangıç olarak ideal bir sistem vizyonu oluşturduk:
- 1C kurumsal sistemindeki reklam kampanyaları, çeşitli platformlardaki adları, dönemleri, bütçeleri ve yerleşimleriyle birlikte otomatik olarak yüklenmelidir.
- Bir reklam kampanyasındaki her yerleşim için, gösterim sayısı, tıklama sayısı, görüntüleme sayısı vb. gibi olası tüm istatistikler yerleşimin gerçekleştiği sitelerden otomatik olarak indirilmelidir.
- Bazı reklam kampanyaları, Adriver, Weborama, DCM vb. gibi reklam sunma sistemleri tarafından üçüncü taraf izleme kullanılarak izlenir. Rusya'da Mediascope şirketi olan endüstriyel bir İnternet sayacı da var. Planımıza göre bağımsız ve endüstriyel izlemeden elde edilen veriler de ilgili reklam kampanyalarına otomatik olarak yüklenmelidir.
- İnternetteki çoğu reklam kampanyası, Google Analytics kullanılarak izlenen ve kampanyanın durumunu anlamak için de önemli olan istatistikler belirli hedef eylemlere (satın alma, arama, test sürüşüne kaydolma vb.) yöneliktir ve aracımıza yüklenmelidir.
İlk gözleme topaklı
Yazılım geliştirmenin esnek ilkelerine (çevik, her şey) olan bağlılığımız göz önüne alındığında, önce bir MVP geliştirmeye ve ardından tekrarlanarak amaçlanan hedefe doğru ilerlemeye karar verdik.
Ürünümüze dayanarak MVP oluşturmaya karar verdik DANBo (Dentsu Aegis Ağ Kartı)müşterilerimizin reklam kampanyaları hakkında genel bilgiler içeren bir web uygulamasıdır.
MVP için proje uygulama açısından mümkün olduğunca basitleştirildi. Entegrasyon için sınırlı sayıda platform listesi seçtik. Bunlar Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB gibi ana platformlar ve ana reklam sunma sistemleri Adriver ve Weborama idi.
API aracılığıyla sitelerdeki istatistiklere erişmek için tek bir hesap kullandık. Bir reklam kampanyasında istatistiklerin otomatik olarak toplanmasını kullanmak isteyen bir müşteri grubu yöneticisinin, öncelikle sitelerdeki gerekli reklam kampanyalarına erişimi platform hesabına devretmesi gerekiyordu.
Sırada sistem kullanıcısı var DANBo Yerleşim (reklam kampanyası, platform, format, yerleştirme dönemi, planlanan göstergeler, bütçe vb.) ile ilgili tüm bilgileri ve ilgili reklam kampanyalarının tanımlayıcılarını içeren belirli bir formattaki dosyayı Excel sistemine yüklemek zorundaydı. reklam sistemlerindeki siteler ve sayaçlar.
Açıkçası korkunç görünüyordu:
İndirilen veriler bir veritabanına kaydedildi ve ardından ayrı hizmetler, sitelerdeki kampanya tanımlayıcılarını topladı ve bunlara ilişkin istatistikler indirdi.
Her site için, günde bir kez sitenin API'sindeki bir hizmet hesabının altına giren ve belirtilen kampanya kimlikleri için istatistikler indirilen ayrı bir Windows hizmeti yazıldı. Aynı şey adserving sistemlerinde de oldu.
İndirilen veriler arayüzde küçük, özel bir kontrol paneli biçiminde görüntülendi:
Bizim için beklenmedik bir şekilde MVP çalışmaya başladı ve internetteki reklam kampanyalarına ilişkin güncel istatistikleri indirmeye başladı. Sistemi birkaç istemciye uyguladık ancak ölçeklendirmeye çalışırken ciddi sorunlarla karşılaştık:
- Asıl sorun, verileri sisteme yüklemeye hazırlamanın karmaşıklığıydı. Ayrıca yerleştirme verilerinin yüklenmeden önce kesinlikle sabit bir formata dönüştürülmesi gerekiyordu. İndirme dosyasına farklı sitelerden varlık tanımlayıcılarının dahil edilmesi gerekiyordu. Teknik olarak eğitimsiz kullanıcıların bu tanımlayıcıları sitenin neresinde bulacağını ve dosyanın neresine girilmesi gerektiğini açıklamalarının oldukça zor olduğu gerçeğiyle karşı karşıyayız. Sitelerde kampanya yürüten departmanlardaki çalışan sayısı ve ciro göz önüne alındığında bu durum tarafımıza çok büyük bir destek sağladı ve bundan kesinlikle memnun değildik.
- Diğer bir sorun ise tüm reklam platformlarının, reklam kampanyalarına erişimi diğer hesaplara devredecek mekanizmalara sahip olmamasıydı. Ancak bir yetki verme mekanizması mevcut olsa bile, tüm reklamverenler kampanyalarına üçüncü taraf hesaplara erişim izni vermeye istekli değildi.
- Önemli bir faktör, 1C muhasebe sistemimize zaten girdikleri tüm planlı göstergelerin ve yerleştirme ayrıntılarının yeniden girmeleri gerektiği gerçeğiyle kullanıcılar arasında uyandırılan öfkeydi. DANBo.
Bu bize, yerleştirmeyle ilgili birincil bilgi kaynağının, tüm verilerin doğru ve zamanında girildiği 1C sistemimiz olması gerektiği fikrini verdi (burada önemli olan, faturaların 1C verilerine göre oluşturulmasıdır, dolayısıyla verilerin 1C'ye doğru girilmesidir) herkesin KPI'sı için bir önceliktir). Böylece yeni bir sistem anlayışı ortaya çıktı...
Kavram
Yapmaya karar verdiğimiz ilk şey, İnternet'teki reklam kampanyalarına ilişkin istatistik toplama sistemini ayrı bir ürüne ayırmaktı - D1.Dijital.
Yeni konseptte şunu yüklemeye karar verdik: D1.Dijital 1C'den reklam kampanyaları ve bunların içindeki yerleşimler hakkında bilgi alın ve ardından sitelerden ve Reklam Sunma sistemlerinden bu yerleşimlere ilişkin istatistikleri alın. Bunun kullanıcılar için hayatı önemli ölçüde basitleştirmesi (ve her zamanki gibi geliştiricilere daha fazla iş eklemesi) ve destek miktarını azaltması gerekiyordu.
Karşılaştığımız ilk sorun organizasyonel nitelikteydi ve farklı sistemlerden varlıkları 1C'deki kampanyalar ve yerleşimlerle karşılaştırabileceğimiz bir anahtar veya işaret bulamamamızla ilgiliydi. Gerçek şu ki şirketimizdeki süreç, reklam kampanyalarının farklı sistemlere farklı kişiler tarafından (medya planlayıcıları, satın alma vb.) girilmesi şeklinde tasarlanmıştır.
Bu sorunu çözmek için, farklı sistemlerdeki varlıkları birbirine bağlayacak ve indirilen veri kümelerinde oldukça kolay ve benzersiz bir şekilde tanımlanabilecek benzersiz bir karma anahtar olan DANBoID'yi icat etmemiz gerekiyordu. Bu tanımlayıcı, her bir yerleşim için dahili 1C sisteminde oluşturulur ve tüm sitelerdeki ve tüm Reklam Sunma sistemlerindeki kampanyalara, yerleşimlere ve sayaçlara aktarılır. DANBoID'i tüm yerleşimlere yerleştirme uygulamasını uygulamak biraz zaman aldı ama biz bunu başardık :)
Daha sonra, tüm sitelerin otomatik olarak istatistik toplamak için bir API'ye sahip olmadığını ve bir API'ye sahip olanların bile gerekli tüm verileri döndürmediğini öğrendik.
Bu aşamada entegrasyon platformlarının listesini önemli ölçüde azaltmaya ve reklam kampanyalarının büyük çoğunluğunda yer alan ana platformlara odaklanmaya karar verdik. Bu liste, reklam pazarındaki (Google, Yandex, Mail.ru), sosyal ağlardaki (VK, Facebook, Twitter), büyük Reklam Sunumu ve analiz sistemlerindeki (DCM, Adriver, Weborama, Google Analytics) ve diğer platformlardaki en büyük oyuncuların tümünü içerir.
Seçtiğimiz sitelerin çoğunda ihtiyacımız olan ölçümleri sağlayan bir API vardı. API'nin olmadığı veya gerekli verileri içermediği durumlarda, veri yüklemek için ofis e-postamıza günlük olarak gönderilen raporları kullandık (bazı sistemlerde bu tür raporları yapılandırmak mümkündür, diğerlerinde ise bu tür raporların geliştirilmesi konusunda anlaştık) bizim için).
Farklı sitelerden gelen verileri analiz ederken, varlık hiyerarşisinin farklı sistemlerde aynı olmadığını gördük. Üstelik bilgilerin farklı sistemlerden farklı detaylarda indirilmesi gerekiyor.
Bu sorunu çözmek için SubDANBoID konsepti geliştirildi. SubDANBoID'in fikri oldukça basittir, sitedeki kampanyanın ana varlığını oluşturulan DANBoID ile işaretliyoruz ve tüm iç içe geçmiş varlıkları benzersiz site tanımlayıcılarıyla yüklüyoruz ve DANBoID prensibi + birinci seviye tanımlayıcıya göre SubDANBoID'i oluşturuyoruz iç içe geçmiş varlık + ikinci düzey iç içe varlığın tanımlayıcısı +... Bu yaklaşım, reklam kampanyalarını farklı sistemlere bağlamamıza ve bunlarla ilgili ayrıntılı istatistikler indirmemize olanak sağladı.
Farklı platformlardaki kampanyalara erişim sorununu da çözmemiz gerekiyordu. Yukarıda yazdığımız gibi, bir kampanyaya erişimi ayrı bir teknik hesaba devretme mekanizması her zaman uygulanabilir değildir. Bu nedenle tokenlar ve bu tokenlerin güncellenmesine yönelik mekanizmalar kullanarak OAuth üzerinden otomatik yetkilendirme için bir altyapı geliştirmemiz gerekiyordu.
Yazının devamında çözümün mimarisini ve uygulamanın teknik detaylarını daha detaylı anlatmaya çalışacağız.
Çözüm mimarisi 1.0
Yeni bir ürünün uygulanmasına başladığımızda, yeni sitelere bağlanma olasılığını hemen sağlamamız gerektiğini anladık ve bu nedenle mikro hizmet mimarisi yolunu izlemeye karar verdik.
Mimariyi tasarlarken, tüm harici sistemlere (1C, reklam platformları ve reklam sistemleri) yönelik konnektörleri ayrı hizmetlere ayırdık.
Ana fikir, sitelere yönelik tüm bağlayıcıların aynı API'ye sahip olması ve site API'sini bizim için uygun bir arayüze getiren bağdaştırıcılar olmasıdır.
Ürünümüzün merkezinde, kolayca hizmetlere ayrılabilecek şekilde tasarlanmış monolit bir web uygulaması bulunmaktadır. Bu uygulama, indirilen verilerin işlenmesinden, farklı sistemlerden istatistiklerin toplanıp sistem kullanıcılarına sunulmasından sorumludur.
Bağlayıcılar ile web uygulaması arasında iletişim kurmak için Bağlayıcı Proxy adını verdiğimiz ek bir hizmet oluşturmamız gerekiyordu. Hizmet Keşfi ve Görev Zamanlayıcı işlevlerini yerine getirir. Bu hizmet, her gece her bağlayıcı için veri toplama görevlerini çalıştırır. Bir hizmet katmanı yazmak, bir mesaj aracısına bağlanmaktan daha kolaydı ve bizim için sonuca mümkün olduğunca çabuk ulaşmak önemliydi.
Basitlik ve geliştirme hızı açısından tüm hizmetlerin Web API'leri olmasına da karar verdik. Bu, hızlı bir şekilde kavram kanıtını oluşturmayı ve tüm tasarımın çalıştığını doğrulamayı mümkün kıldı.
Ayrı, oldukça karmaşık bir görev, farklı hesaplardan veri toplamak için erişimi ayarlamaktı ve karar verdiğimiz gibi, bunun kullanıcılar tarafından web arayüzü aracılığıyla gerçekleştirilmesi gerekiyordu. İki ayrı adımdan oluşur: İlk olarak kullanıcı, OAuth aracılığıyla hesaba erişmek için bir jeton ekler ve ardından istemci için belirli bir hesaptan veri toplanmasını yapılandırır. OAuth aracılığıyla token almak gereklidir çünkü daha önce de yazdığımız gibi sitede istenen hesaba erişim yetkisi vermek her zaman mümkün değildir.
Sitelerden hesap seçmek için evrensel bir mekanizma oluşturmak amacıyla, bağlayıcılar API'sine, değiştirilmiş bir JSONEditor bileşeni kullanılarak bir forma dönüştürülen JSON Şemasını döndüren bir yöntem eklememiz gerekiyordu. Bu şekilde kullanıcılar veri indirecekleri hesapları seçebiliyorlardı.
Sitelerde mevcut olan istek sınırlarına uymak için ayar isteklerini tek bir belirteçte birleştiriyoruz ancak farklı belirteçleri paralel olarak işleyebiliriz.
Hem web uygulaması hem de bağlayıcılar için yüklü veriler için depolama alanı olarak MongoDB'yi seçtik; bu, uygulamanın nesne modelinin günaşırı değiştiği geliştirmenin ilk aşamalarında veri yapısı hakkında çok fazla endişelenmememizi sağladı.
Kısa sürede tüm verilerin MongoDB'ye uymadığını ve örneğin günlük istatistikleri ilişkisel bir veritabanında saklamanın daha uygun olduğunu öğrendik. Bu nedenle veri yapısı ilişkisel veritabanına daha uygun olan konnektörler için depolama olarak PostgreSQL veya MS SQL Server kullanmaya başladık.
Seçilen mimari ve teknolojiler, D1.Digital ürününü nispeten hızlı bir şekilde oluşturup piyasaya sürmemize olanak sağladı. İki yıllık ürün geliştirme süreci boyunca, siteler için 23 bağlayıcı geliştirdik, üçüncü taraf API'lerle çalışırken çok değerli deneyimler kazandık, her birinin kendine ait olduğu farklı sitelerin tuzaklarından kaçınmayı öğrendik, en az 3 site için API'lerin geliştirilmesine katkıda bulunduk 15'e yakın kampanya ve 000'den fazla yerleşime ilişkin bilgileri otomatik olarak indiren, kullanıcılardan ürünün işleyişine ilişkin çok sayıda geri bildirim toplayan ve bu geri bildirimlere dayanarak ürünün ana sürecini birkaç kez değiştirmeyi başaran bir firma.
Çözüm mimarisi 2.0
Geliştirmenin başlangıcından bu yana iki yıl geçti D1.Dijital. Sistem üzerindeki yükün sürekli artması ve giderek daha fazla yeni veri kaynağının ortaya çıkması, mevcut çözüm mimarisindeki sorunları giderek ortaya çıkarmıştır.
İlk sorun sitelerden indirilen veri miktarıyla ilgilidir. En büyük sitelerden gerekli tüm verileri toplamanın ve güncellemenin çok fazla zaman almaya başladığı gerçeğiyle karşı karşıya kaldık. Örneğin, çoğu yerleşime ilişkin istatistikleri takip ettiğimiz AdRiver reklam sunma sisteminden veri toplamak yaklaşık 12 saat sürer.
Bu sorunu çözmek için sitelerden veri indirmek için her türlü raporu kullanmaya başladık, çalışma hızının ihtiyaçlarımızı karşılaması için API'lerini sitelerle birlikte geliştirmeye ve veri indirmeyi mümkün olduğunca paralelleştirmeye çalışıyoruz.
Diğer bir sorun ise indirilen verilerin işlenmesiyle ilgilidir. Artık yeni yerleşim istatistikleri geldiğinde, ham verilerin yüklenmesini, her site için toplu metriklerin hesaplanmasını, farklı kaynaklardan gelen verilerin birbirleriyle karşılaştırılmasını ve kampanya için özet metriklerin hesaplanmasını içeren çok aşamalı bir metrik yeniden hesaplama süreci başlatılıyor. Bu, tüm hesaplamaları yapan web uygulamasına çok fazla yük gelmesine neden olur. Yeniden hesaplama işlemi sırasında uygulama, sunucudaki tüm belleği (yaklaşık 10-15 GB) birkaç kez tüketti ve bu, kullanıcıların sistemle çalışması üzerinde en zararlı etkiye sahipti.
Belirlenen sorunlar ve ürünün daha da geliştirilmesine yönelik iddialı planlar, bizi uygulama mimarisini yeniden gözden geçirme ihtiyacına yöneltti.
Konektörlerle başladık.
Tüm bağlayıcıların aynı modele göre çalıştığını fark ettik, bu nedenle bir bağlayıcı oluşturmak için yalnızca adımların mantığını programlamanız gereken bir boru hattı çerçevesi oluşturduk, gerisi evrenseldi. Bazı bağlayıcıların iyileştirilmesi gerekiyorsa, bağlayıcı geliştirilirken aynı zamanda bunu hemen yeni bir çerçeveye aktarırız.
Aynı zamanda bağlayıcıları Docker ve Kubernetes'e dağıtmaya başladık.
Kubernetes'e geçmeyi uzun süredir planladık, CI/CD ayarlarını denedik, ancak yalnızca bir konektör bir hata nedeniyle sunucuda 20 GB'tan fazla bellek tüketmeye başladığında ve diğer işlemleri neredeyse sonlandırdığında taşınmaya başladık. . Araştırma sırasında bağlayıcı bir Kubernetes kümesine taşındı ve hata düzeltildikten sonra bile orada kaldı.
Kubernetes'in kullanışlı olduğunu çok kısa sürede fark ettik ve altı ay içinde en fazla kaynak tüketen 7 bağlayıcıyı ve Konektör Proxy'sini üretim kümesine aktardık.
Konektörlerin ardından uygulamanın geri kalan kısmının mimarisini değiştirmeye karar verdik.
Asıl sorun, verilerin konektörlerden proxy'lere büyük gruplar halinde gelmesi, ardından DANBoID'ye ulaşması ve işlenmek üzere merkezi web uygulamasına gönderilmesiydi. Çok sayıda metrik yeniden hesaplaması nedeniyle uygulamaya büyük bir yük binmektedir.
Ayrıca bireysel veri toplama işlerinin durumunu izlemenin ve bağlayıcılarda meydana gelen hataları merkezi bir web uygulamasına raporlamanın oldukça zor olduğu ortaya çıktı; böylece kullanıcılar neler olduğunu ve verilerin neden toplanmadığını görebiliyordu.
Bu sorunları çözmek için mimari 2.0'ı geliştirdik.
Mimarinin yeni sürümü ile arasındaki temel fark, hizmetler arasında mesaj alışverişi yapmak için Web API yerine RabbitMQ ve MassTransit kütüphanesini kullanmamızdır. Bunu yapmak için, Konektör Proxy'sini neredeyse tamamen yeniden yazmak zorunda kaldık ve onu Konektör Hub'ı haline getirdik. Hizmetin ana rolünün artık istekleri bağlayıcılara iletmek ve geri göndermek değil, bağlayıcılardan metrik koleksiyonunu yönetmek olması nedeniyle ad değiştirildi.
Merkezi web uygulamasından, sitelerdeki yerleşimler ve istatistiklerle ilgili bilgileri ayrı hizmetlere ayırdık; bu, gereksiz yeniden hesaplamalardan kurtulmayı ve yalnızca önceden hesaplanmış ve toplanmış istatistikleri yerleşim düzeyinde saklamayı mümkün kıldı. Ayrıca ham verilere dayalı temel istatistikleri hesaplama mantığını da yeniden yazdık ve optimize ettik.
Aynı zamanda çözümün ölçeklendirilmesini kolaylaştırmak ve yönetimini daha kolay hale getirmek için tüm hizmet ve uygulamaları Docker ve Kubernetes'e taşıyoruz.
Şu an neredeyiz
Kavram kanıtlama mimarisi 2.0 ürünü D1.Dijital Sınırlı sayıda konektörle test ortamında hazır ve çalışıyor. Geriye kalan tek şey, yeni bir platforma 20 konnektör daha yazmak, verilerin doğru şekilde yüklendiğini ve tüm ölçümlerin doğru şekilde hesaplandığını test etmek ve tasarımın tamamını üretime geçirmek.
Aslında bu süreç kademeli olarak gerçekleşecek ve her şeyin çalışır durumda kalması için eski API'lerle geriye dönük uyumluluktan vazgeçmemiz gerekecek.
Acil planlarımız arasında yeni bağlayıcıların geliştirilmesi, yeni sistemlerle entegrasyon ve bağlı sitelerden ve reklam sistemlerinden indirilen veri kümesine ek ölçümler eklenmesi yer alıyor.
Ayrıca merkezi web uygulaması dahil tüm uygulamaları Docker ve Kubernetes'e aktarmayı planlıyoruz. Yeni mimariyle birleştirildiğinde bu, tüketilen kaynakların dağıtımını, izlenmesini ve kontrolünü önemli ölçüde kolaylaştıracak.
Başka bir fikir, şu anda MongoDB'de saklanan istatistikleri depolamak için veritabanı seçimini denemektir. Zaten birkaç yeni bağlayıcıyı SQL veritabanlarına aktardık, ancak fark neredeyse fark edilmiyor ve keyfi bir süre için talep edilebilecek günlük toplu istatistikler için kazanç oldukça ciddi olabilir.
Genel olarak planlar görkemli, hadi devam edelim :)
Ar-Ge Dentsu Aegis Network Rusya makalesinin yazarları: Georgy Ostapenko (), Mikhail Kotsik ()
Kaynak: habr.com