n Mimari Evrimi

Abstract

Özet. Mobil cihazlarÕn ve uygulamalaÕnr yaygÕnla ú masÕyla birlikte mobil reklamcÕkO sektörünün önemi de son y Õllarda artm rWÕú. Mobil reklamc ÕOk iú inin merkezinde yazÕOm sistemleri bulunmaktad Õr. Performans gibi kalite özellikleri gereksinimleri zorla yÕF hale gelen mobil reklamcÕkO sektöründeki yaz ÕOm sistemleri için bu deúL÷ imlere paralel olarak çözümler üretilmesi gerekmektedir. Bu bildiride bir reklam aracÕV yaz ÕOnQP de úL÷ en iú levsel ve kalite özellikleri gereksinimleri do÷ rultusunda mimarisinin nasÕ l evrildi÷ i anlatÕlmaktad Õr. Ortaya oÕ kan, performans baOÕú÷ alt Õnda sfÕQland UÕ labilecek problemlere literatürde bulunan mimari tasarÕm desenleri ve tasaÕ mr taktikleri kullanÕlarak çözümler üretilmiú tir.

Keywords

• Software Architecture Evolution
• Software Architecture Design
• Quality Attribute
• Mobile Advertising

Giriú

Gerek dünyada gerekse Türkiye’de son birkaÕ çlday mobil cihazl aÕnr kulla nPÕ oldukça yaygÕ nlaWPÕú r. Bu cihazlarÕ n kullanÕF lar tarafÕ ndan benimsenmesinin temel nedenlerinden biri bu cihazlar üzerinde Õú çaanl uygulamalarÕn sa yÕQV n artmasÕ, çeú itlenmesi ve ku lÕFlaarn Õ n birçok gereksinimini Õú lkaamralarÕ na ya rÕdmcÕ olmalarÕG r. Mobil uygulamalaÕrn kullanQPÕ n artma sÕyla da çevrimiçi reklam cOkÕ sektöründe mobil kanallara ÷Õ arlÕk verilmeye baúlanmWÕú r. Bu b÷alamda mobil uygulamada reklam gösterimini destekleyen çok saÕ yda reklam a÷Õ ortaya çÕkmÕúW r. Bu reklam ÷ alarQnÕ temel amac Õ reklam verenler ile reklam Õ nyalayyanlar (bu durumda mobil uygulamalar) aÕrnadsa bir köprü kurmÕ ark.t Reklam ÷laar QÕ n sayÕQV n artmasÕyla birlikte de çok sÕdaay reklam aÕ÷ ile reklam yayÕnlayanlar arasÕ nda köprü kurma görevini reklam aracÕ larÕ üstlenmeye baú lamÕúW r.

Mobil çevrimiçi reklamcOÕk sektörü tamamen yaz ÕmO üzerinde yap Õland UÕ lmWÕú r. Çevrimiçi reklam a÷larÕ, reklam aracÕ larÕ ve reklam ya yÕnc Õ larÕ yazÕOm sistemleri aracOy÷Õla bu sektör içindeki görevlerini yerine getirmektedir. Dolay ÕV yla yazÕO m mühendisli÷ i kapsamÕndaki tüm temel etkinlikler mobil çevrimiçi reklam aO÷Õrac yazÕOmlar Õ nda da gerçekleú tirilmelidir.

Bu çalÕú mada Kokteyl ú irketinin reklam aracÕO k yazQPÕO n mimari evrimi yazmÕO mühendisli÷ i literatüründeki çalÕú malarla ba÷ lantÕ kurularak anlat Õ lmWÕú r.

ø kinci bölüm Kokteylú irketi, mobil çevrimiçi rekla mOÕck sektörü veú irketin reklam aracÕV yaz PÕO hakk Õ nda genel bir bilgi vermektedir. Üçüncü bölümde reklam aracÕV yaQPÕO z n mimari evrimi ve bu evrim sürec÷irnedneilen ö dersler anlatÕ lmaktadÕ r. Dördüncü ve son bölümde elde edilen sonuçlar ve gelecek çaÕú l malar sunulmuú tur. 2

Arka Plan

Bu bölümde reklam arac÷ÕO yazQPÕO geliú tiren ve iú leten Kokteyl ú irketi hakkÕ nda genel bilgi verilmú i, ú irketin yer ald÷Õ mobil reklam sektörü vúeirketin ya zÕO m ürünleri ta nlÕWmWÕú r. Son alt bölümde ise yÕmOaz mimarisi evrimi çalÕú ma ala nÕ hakkÕ nda kÕ saca bilgi verilmiú tir. 2.1

iùrket Hakk Õ nda Genel Bilgi Kokteyl ú irketi 2002 ÕO ynda web tabÕanl uygulamalara odaklanmak üzere kurulmuú tur. SonransdÕ a mobil uygula mÕnalar ve bulut teknolojilerinin yaygÕnla ú masÕyla birlikte ú irketin oda÷Õ web, mobil ve bulut uygulamalaÕnra do÷ ru evrilmiú tir. ù irket çok sayÕda yaz ÕO m ürününü gel iú tirmiú ve hizmete sunm uútur. Bu ürünlerden en önemlisi mackolik uygulamasÕG r. Bu uygulama web ve mobil kanallar üzerinden spor etkinlikleriyle ilgili bilgiler ve istatistiksel veriler sunma kÕrt.adBu uygulamanÕ n bir kÕ smÕ 2012’de geri kalanÕ da 2016 yÕO nda øngiltere’deki bir medya ú irketi tar aÕnfdan satÕn aÕnlmWÕú r. 2008 ÕO yndan bú alayarak ú irket çevrimiçi reklamcOÕk sektörüne girmúi ve zaman içinde bir rekla mÕV yarzacPÕO geliú tirmiú tir. ù irket 2016 ÕO yndan geliú tirilmesine ve iú letilmesine yo÷ unlaWÕPú bu yana bu reklam ÕV n 2.2

Mobil Reklam Sektörü Çevrimiçi reklam sektöründeki ana paydúlaar ù ekil 1’de gösterilmektedir.Reklam verenler, reklam a÷ larÕ na ürünleri ve/veya hizmetleri haÕ knkda tüketicilere bilgi vermek için reklam vermektedirlerY.ayÕ ncÕ lar, reklam a÷lar Õ ndan reklam talep etmekte ve reklam a÷lar Õ yaÕ yncÕ ya mevcut durumdaki en uygun Õ reklam sa÷lamaktad Õ r. Uygunluk konusundaki karar birçok ÷Lú dkeene (ya yÕncQÕ n hangi uygulama oldu÷u, son kullan ÕF hakkÕ ndaki bilgiler, uygulamanÕ n çal÷ÕúW cihaz gibi) ba÷OÕ olarak de÷Lú mektedir. YayÕ ncÕ larÕ n reklam a÷ larÕ ndan do÷ rudan reklam alma sÕ durumunda bazÕ problemler ortaya Õ çkmaktadÕ r. Teknik açÕndan yayÕ ncÕ uygulama reklam talep edece÷i tüm reklam a÷lar Õ yla entegre olmak zorundaÕ dr. úø amaçla rÕ açÕV ndan bakÕ ldÕ÷ nda bir yayÕ ncÕ QÕ n birçok reklam a÷Õ ndan optimum reklamÕ (en fazla geliri getirecek reklam) alamamasÕ durumunda gelir kaybÕ yaú ayacaktÕ r. Reklam aracÕ larÕ birçok reklam a÷Õ ile entegre olarak optimum rekla mÕsa ÷ lama konusunda uzmanlaú maktadÕ r. Böylece yayÕ ncÕ larÕ n reklam gelirlerini aÕrmtt asÕ na yar dÕmcÕ olmaktadÕ r. Teknik a çÕdan ise çok saÕyda reklam aÕ÷ ile entegre olmaÕnn getird i÷ i karmaÕkúlÕk reklam aracÕV tara fÕndan yönetilmekte ve yayÕ ncÕ larÕ n sadece reklam aracÕV ile entegre olmÕ alaryeterli olmakt aÕrd. Son kullanFÕ lar ise yayÕ ncÕ uygulamalarÕ kullanarak reklamlaÕ r görüntülemekte ve bu reklamlara Õkúar zaman zaman bir davra nÕú (reklama Õtklama, uygulama indirme ve kurma, ürün sÕ ant alma gibi) sergilemektedir. Bu tür davranÕú lar yayÕ ncÕ lara gelir sa÷ lamaktadÕ r.

Reklam Veren reklam verir reklam talep eder reklam saŒ lar davranƔŦ sergiler (reklama tŦ klama, uygulama indirme ve kurma, ürün satŦ n al ma, vs.)

Son KullanŦĐ ù ekil 1. Çevrimiçi reklamcÕO k sektöründeki ana paydaú lar.

Reklam AŒŦ r e d e p e l a t m a l k e r r a Œla s m a l k e r ù irketin yazÕO m ürünleri ve bu ürünlerin sektördeki d÷eri payda ú larla olan iliú kileri ù ekil 2’de gösterilmektedir. ù irketin reklam ara cÕV yaz QPÕO oluú turan iki bil eú en ú ekilde yeúil renk ile gösteril mútir. Reklam AraÕV c Yaz QPÕO n (RAY) sunucu uygulamasÕ , reklam ÷alarQÕ n yazÕOm geli ú tirme kitlerini (YKG) içermektedir. Bu YKG’ler aracÕO÷ yla sunucu uygulama sÕ reklam a÷lar Õ ndan reklam talep etmekte ve reklam almakta dÕr. Ya yÕncÕ uygulamalar ise RAY’nin YKG’sini uygulamaQÕlanr içine yerl eútirerek RAY’den reklam talep etmekte ve almaÕrklatar.d Bir önceki bölümde anlatÕld Õ÷ gibi, teknik açÕdan RAY birçok reklam aÕ÷ ile entegre olman Õ n getirdi÷ i karmaÕkúl Õ÷ yayÕnc Õ uygulamalara saydam hale getirmektedir. øú amaçlarÕ açÕV ndan ise RAY birçok reklam Õ÷ andan sa÷ ladÕ÷ reklamlar arasÕndan en uygun reklamÕ yaÕnyc Õ uygulamaya göndererek reklam gelirlerin iUÕn lmasaQÕrtt sa÷lamaktadÕ r.

Reklam Ara cÕV Uygulamas Õ birçok iú levsel gereksinimi belirli kalite özelliklerini sa÷ layarak ve bazÕ k ÕVtlar alt Õ nda karÕúlamaktad Õ r. RAY’nin mevcut mimarisi zaman içinde birçok nedenden dolayÕ (de ÷Lú iklik istekleri, yaú anan problemler gibi) evrilerek bugünkü halini almWÕú r. 3

Reklam AracÕV

YazÕOPQ

n Mimari Evrimi Bir yazÕO m sisteminin mimarisini belirleyen gereksinimler birçok biçimde kaPÕú r za Õkomaktad Õ r: metinler, modeller, mevcut sistemler, kullÕamn senaryola rÕ, kullanÕ m hikayeleri vs. Bu gereksinimler içinde mimari aÕdçan önemli gereksinimler mimari kararlarÕ etkilemektedir. Gereksinimler, biçimlerinden ve kaynakÕ lnadran ba÷Õ msÕ z olarak üç ana sQÕ fta incelenebilmektedir [ 2 ]: 1. øú levsel gereksinimler: Sistemin ne yapmasÕ gerekti÷ ini, sistemin nasÕl davranmas Õ gerekti÷ini ya da bir girdiye nas Õ l bir tepki vermesi gerekti÷ ini tanÕ mlar. 2. Kalite özellikleri gereksinimleri (iú levsel olmayan gereksinimler): úø levsel gereksinimlerin ya da ÕO yamz sisteminin niteliklerini belirtir. Búliervseil gereksinimin niteli÷ i o iú levin ne kadar zamanda gerçekl eútirilmesi gerekti÷ ini ya da hatalÕ bir veri giriú ine karÕú ne kadar dirençli olaca Q÷Õ belirtebilir. Bir yazÕmO sisteminin niteili÷ ise sistemin ne kadar zamÕ anda ortamcaanl konuú landUÕ labilece÷ ini ya da ilú etim maliyetleri için bir ÕQ s r olarak kaPÕúr za Õkoabilir. 3. .ÕtVlar: Tas aÕrm yaparken mutlaka uyulÕmasgereken srQÕlamalara ú iaret etmektedir. Örne÷in, belli bir programlama dilini kullanma zorunlul u÷ , mevcut bir modülün kullanÕ lma zorunlulu÷u gibi.

YazOÕ m mimarisi tasaPÕr ve gerçekúletirimi üzerinde derin etkileri olan yokluklarÕ durumunda mimarinin çok farklÕ olabilece ÷ i gereksinimler mimari a çÕdan önemli gereksinimler olarak ÕtamnlanmaktadÕ r [ 2 ]. RAY’nin mimari tQÕPasar etkileyen gereksinimler aÕD÷ú daki gibidir: x G1. Ara cÕO k ile ilgili gereksinimler: Hangi rekla mÕ÷ ndaan hangi Õ srada reklam istenece÷ ini belirleyen optimize edilmiú karar a÷ acQÕ n oluú turulmasQÕ ve reklam gösterim istatistiklerini istemcilerden t oQÕplanmiaçseren gereksinimler.

o G1.1. ø stemcilerden gelen talepler d÷ orultusunda optimize edilmú i karar a÷ acQÕ n istemcilere gönderilmesi o G1.2. Reklam gösterim istatistiklerinin sunucu

saklanmasÕ x G2. Analitik gereksinimler: Reklam gösterim istatistiklerinin kullanÕF(mobil cihaz) ba zÕnda gruplanma sQÕ ve kullaÕlFnar/cihazlar hakk Õ ndaki bilgilerin saklanmasQÕ içeren gereksinimler.

o G2.1. KullanÕF /cihaz yaratÕ lmasÕ ya da güncellenmesi o G2.2. KullanQÕF n uygulama içinde yapÕ÷ t sat Õ n alma iúlemlerinin izlenmesi o G2.3. KullanÕF dan/cihazdan reklam isteklerinin gelmesi x G3. Kampanya izleme gereksinimleri: o G3.1. Bir iste÷ in ilgili kayna÷ a yönlendirilmesi o G3.2. Bir istek yönlendirildikten sonra gerekli

güncellenmesi

Birçok y aÕOmz sisteminin mimarisi, yeni istekler, yeni kalit e÷ i gereksinimleri, teknolojideki de÷Lú imler ya da baú ka nedenlerle de÷Lú ikli÷e u ÷ rar [ 1 ]. Nedeni ne olursa olsun ÕOmyaz sektöründeki projelerde mimarinin evrilmesi ola÷ andÕ r. uygÕ unldaamas

ve istatistiklerin özelli 3.1

AracÕO k Bileú eninin Mimarisinin Evrimi

Yekpare bileú enden mimariye sahip bir yÕmOaz sistemi tüm iú levleri yerine getiren tek bir ol uúur. Sistemde yaÕlpacak her de÷Lú iklikte sistemin tama mQÕ n yeni versiyonu tasarlanmÕú programlama istemcilere kullanÕ lmWÕú konú ulandUOÕ r. ù ekil 3’te RAY’nin yekpare mimari úÕP yaykllaa ilk mimarisi gösterilmektedir. Bu mimaride tümú leivler bir uygulama

arayüzü (UPA – API: Application Programming Interface) sunulm uútur. Veri saklama için ú kiliisel bir veritabaÕ n (PostgreSQL) r. ile

Yekpare mimarinin bir avantajÕ , de÷Lú ikliklerin canlÕ sistemde devreye alÕ nmasQÕ n görece kolay olmaÕG s r (bir UPA’Õnn kon uú landUÕ lmasÕ). Bunun yanÕ nda ya zÕO m sisteminin a nÕúlalmasQÕ n kolay oÕlmas da haÕ tnalar bulunmQÕ as da kolaylaWÕú rmaktadÕ r. Di÷ er taraftan istemcilerden gelen isteklerin artma sÕyla ve belirli zaman araÕkllarÕ nda y÷uonla ú masÕ yla birlikte yekpare mimarinin performans açÕV ndan problemleri ortaya Õkçmaya ba ú lamWÕú r. G1.1 ve G1.2 gereksinimlerinin gerektirdi÷ i çözümler birbirinden farÕ klolmasÕ na r a÷ men (ilkinde veritabaÕnndan okuma, ikincisinde veritaba nÕna yazma úilemleri yo÷ un) yekpare mimari nedeniyle aynÕ mimari çözüm uygulanmak zorunda ÕknamlÕúW r. UPA’nÕ n sÕk güncellenmesi gereken durumlarda hangi iú levde güncelleme yapÕO rsa yapÕls Õ n tüm UPA’nÕ n belirli bir süre devre Õú d kalma sÕ söz konusu olmaktaÕ dr. Bunun yanÕnda zaman zaman reklam gösterim istatistiklerinin saklanmasÕ için veritaban Õ na gelen yazma isteklerinin sunucuda oluú turdu÷u yo ÷unluk nedeniyle karar a ÷ac Õ gönderim taleplerine de cevap verilememe durumu ortaya çÕkm WÕú r.

Performans problemlerini çözmek için ilgilerin aÕO÷ yr(separation of concerns) ilkesi [ 5 ] do÷ rultusunda veritabanÕ ndan okuma ve veritaba nÕna yazma iú lemleri ayrÕ UPA ile yaÕlpmaya baú lanmWÕú r. Okuma ú ilemlerinde performan sÕ arttÕ rmak için içerik dW÷Õ a m Õ÷ a ( ø ÇA – CDN: Content Delivery Network) Õ lmkuayllaan baú lanmWÕú r [ 3 ]. ø ÇA kullanPÕ ile birlikte istemci taleplerine dönü ú performan sÕ artmÕú ve okuma ilúemlerinin er iú ilebilir olma yüzdesinde, literatürdeki bulgularla paralel olarak [ 4 ], yükselme gözlemlenmú itir. AyrÕca hem okuma iú lemleri hem de yazma úi lemleri için gelen istekler yük dengeleyiciler (load balancer) ileÕ farkl sunuculara d aW÷Õ lmaya b aú lanmÕúW r. ù ekil 4’te yekpare biúlenin iki sorumlulua÷ sahip iki ayrÕ bile ú en haline getirildi÷ i mimari gösterilmektedir.

UPA (Okuma Ɣŝ lemleri)

UPA (Yazma Ɣŝ lemleri) ù ekil 4.ø kinci aú amadaki iki ana bileú enli mimari.

Okuma ve yazma sorumluluklaQÕ r n ayrÕ bile ú enlere verilmesinden sonra yazma Lú lemlerinde sistemin ÷ yuon kullaÕ nld÷Õ zamanlarda performans problemleri yaú anmaya baú landÕ÷ görülm üú tür. Her yazma talebi verita bÕanyönetim sistemi tarafÕ ndan karÕú landÕ ktan sonra istemcilere cevap dönülmesi, tepki süresini veritabanÕ sunucusunun performansÕna b a÷OÕ kÕlmÕúW r. Dola yÕV yla veritaba nÕ sunucusundaki problemlerde ya da yaOÕúkvlarda istemcilerin taleplerine tepki süresi artmaya baú lamWÕú r. VeritabanÕ nda saklanan verinin her an tutarÕ lolma gereksinimi olmadÕ÷ için gelen yazma isteklerinin bir kuyrukta biriktirilmesi v eúçiler tara fÕndan belirli aralÕklarla veritaban Õ na yazÕlmas Õ tercih edilmiú tir. Web-Kuyruk -øú çi mimari stiline [ 3 ] kaÕOúr k gelen bu mimari tÕamsar sonucunda sistemin mimari sùiekil 5’te gösterilmektedir.

7 stemci 7 çerik DaŦƚŒ m ŦŒ (CDN)

UPA (Okuma Ɣŝ lemleri)

UPA (Yazma Ɣŝ lemleri)

Kuyruk Ɣ7 çi (Worker) 7 liƔ kisel VeritabanŦ ù ekil 5. Üçüncü aú amadaki kuyruk ve iú çi bileú enleri eklenmiú ekliyle mimari.

Bu mimarinin gerçekú letirimi için kúout zamanÕ l programlamayÕ destekleyen Golang [ 6 ] dili kul lÕalmnWÕú r. Yazma lieúmlerinden sorumlu UPA gelen talebi kuyru÷a ekler ve istemciye cevap dönmektedir. Bir veri birlú etirici kuyru÷u kontrol eder; veriyi biriktirir ve belirli bir sürede ya da veri belirli bir hacme uÕ÷Wú la zaman veriyi úiçiye gönderir. øú çi birikmiú veriyi kuyruktan Õ ra;l geçici bir veritabÕ an tablosuna bu veriyi yazar; geçici tablodaki veriyi kalÕF tabloya ekler ve geçici tabloyu temizler. øú çi, veri transferi ve ortak tablolara veri yazma iú iyle u÷ raWÕ÷ú için olas Õ bir kilitlenmeyi (deadlock) engellemek için tek bir ú çii kullanÕ lmaktadÕ r. Bu mimarinin olumsuz taraÕf ise iúçinin kuyr u÷ a eklenen veriyi yeterince ÕzlhÕ biçimde kalÕF tablolara taÕyúamamas Õ durumunda biriken verinin bellek ve ú liemci kaynaklarÕ nda darbo÷az olu ú turmasÕ durumuyla sonuçlanmakta dÕr. Bu problemi gidermek için ise veriyi kuyruktan geçici tablolara aktarmaú ii ve geçici tablodan kaÕFl tabloya veri yazma iú i farkÕl süreçlere payl aUWÕú lmWÕú r. Bu tasaÕ mrda veriyi kuyruktan geçici tablolara aktarma úiini birden fazla süreç üstlenebilmektedir. Geçici tablodan kÕFal tabloya veri aktaPÕr ise yine bir süreç ile s÷alanmaktadÕ r. Mimarinin bu son Dú amadaki haliyle reklam gösterim isteklerinin sorunsuz biçim dÕúelankmaarsÕ sa÷lanmaktad Õ r. 3.2

Analitik Bileú eninin Mimarisinin Evrimi

Analitik bileú eninin temel görevi kulla nÕF bazlÕ verinin istemcilerden toplanmas Õ ve saklanmasÕG r. Bu temel görev yeni kulÕFlanlarÕ n ka yÕtlarQÕ n yaratÕlmasÕ (G2.1), gerekti÷ inde bilgilerinin güncellenmesi (iú letim sistemi, ülke, vs gibi) (G2.2), yayÕnc Õ uygulamada yapÕ÷ t satnÕ alma verisinin toplan mÕasve uygulamada gösterilen reklamlarÕ n verisinin toplanmQÕ as kapsamaktaÕdr. AraÕO c k bilú eeninde reklam gösterim verisi reklam ÷ alarÕ ba zÕnda sakla nÕrken analitik bilú eende bu verilerin kullanÕF bazÕ nda saklanmasÕ gerekmektedir. Bu gereksinim, mimarinin yo÷ un bir veri yazma ú iyle bú aa Õ çkabilecek ú ekilde tasarlanm aQÕs ve gerçeúktlierilmesini gerektirmektedir. Bu gereksinimi kúÕ arlayabilmek için NoSQL bir verita bÕan[ 7 ] kullanÕ lmWÕú r.

Bu bil eúenin yazma görevini yerine getirmesi için kuyruk ú çvie biil eúenleri kullanÕ lmWÕú r. Gelen istekler bir kuyrukta biriktirilmekte ve toplu halde bir NoSQL veritabanÕ olan MongoDB’ye [ 14 ] yÕ alzmaktadÕ r. Bu çözüm yeni kullÕF ankaydÕ yaratÕ lmasÕ, kullanÕF bilgilerinin güncellenmesi gibi görevler için gereksinimi karÕúlamWÕú r. Ancak Õnyca yÕ uygulamada yÕlanp saÕ tn alma le miú lerinin do÷ rulanmasÕ görevinin yerine getirilmesi noktasÕ nda bu mimaride problemler ortaya Õkom WÕú r.

Bir satÕ n alma iú leminin, bir kullanÕF adÕ na veritabanÕ na kaydedilmeden önce bu satÕ n alma ú ileminin sahte olup olmaQ÷Õd n kontrol edilmesi gerekmektedir. Bu kontrolü yapmak için Õ nApple’ve GoÕ ongle’ sun÷udu servislerden faydalanÕ lmaktadÕ r. Ancak sistemin genel performansÕ bu servislerin performanÕ sna do÷ rudan baOÕ÷ hale gelmúi tir. BazÕ durumlarda bu servislerdeki yav aOÕúktan dolay Õ sistemin genel performanÕsnda düú gözlemlenm iú tir. Bunu engellemek için sÕant alma iú leminin kontrolünü gerçekleútiren iú lev ay rÕ bir bileú en haline getirilmú itir. Böylece istemciden Õ anlan veriler geçici olarak saklanmakta, istemciye dönülmekte ve bkaaú bir bú ielen tar aÕnfdan s aÕnt alma leimúinin kontrolü yapÕ lmaktadÕ r. Bu kontrolden cevap geldikten sonra hem ú kiliisel hem de NoSQL veritabanÕ nda gerekli alanlar güncellenmektedir. Senkron olarak yapÕlúalenrin i asenkron hale getirilmesi performans artÕú na neden olmuú tur.

Analitik bileú eninin karÕúlad Õ÷ bir baú ka gereksinim yayÕnc Õ uygulama sahiplerine uygulamalarQÕ belirli bir süre içerisinde aktif olarak kullanan tekil kullaÕF nsay ÕQV vermektir. Mobil reklam cÕO k sektöründe de bu sayÕlar genellikle 1, 7, 14 ve 30 gün için sa÷ lanmaktadÕ r. Bu sayÕlar Õ sa ÷ lamak için gerekli veriyi saklayan MongoDB’deki bilgi sorgularken karÕú laúÕ lan zorluklardan dolayÕ son 30 günlük tüm verinin i lúikisel bir veritaba nÕna ya zÕlmasÕ na karar verilmú itir. Bu da kull aÕFn bazÕl verinin hem MongoDB’ye hem de iúlkiisel veritabanÕ na ya zÕlma gereklili÷ ini d o÷ urdu. Ancak iliú kisel veritabanÕna yazma sürelerinin uzu÷nulu nedeniyle y÷oun istek gelen zamanlarda sistem performans gereksinimlerini karÕú layamadÕ .

Bu problemi gidermek için hemÕ zlÕ h yazma imk aÕn veren hem de verinin raporlanmasÕ için gerekli yetenekleri ÷ lasya n Redis veritabÕ an [ 8 ] sisteme eklenmiú tir. Redis veritab aÕn kulla nÕF bazÕl verileri gün içinde saklamakta gün sonunda ise bu veriler iliú kisel veritabanÕ na aktarÕlmaktad Õ r. Bu de÷Lú iklik ile birlikte hem kullaÕF n bazÕl verinin saklan mÕas hem de ist÷eindie raporlanm aÕs gereksinimleri karÕú lanmWÕú r. 3.3

Kampanya ø zleme Bileú eninin Mimarisi

Bu bileú en, kritik müú terilerin (yayÕnc Õ uygulamalar) RAY’den ald Õ÷ linkler ile kendi uygulamalarQÕ n reklamlarÕ ndan aldÕ klarÕ tÕ klamalarÕ takip ederek hangi kaynaktan ne tür kullanÕF ald Õklar QÕ analiz etmelerini ÷ lsaamaktadÕ r. Reklam verenin para ödeyerek verd÷i i reklamlara Õktland Õ÷ nda öncelikle bu biúleenin sund u÷ u servis ça÷UÕO r. DolayÕV yla bu bil eú enin yüksek oranda kulla nÕlabilir olmasÕ gerekmektedir. Bu servis tetiklendikten sonra takip için gerekli bilgiler toÕprlanve Google veya Apple uygulama dükkanlarÕndaki uygulama sayfa sÕna yönlendirme ya pÕO r. Servisin çalÕú r durumda olmama sÕ durumunda bu yönlendirme yapÕlamaz ve reklam verenin kullanÕF kazanmak için yapt Õ÷ reklam búoa gitmiú olur. Bu önemli gereksinimi karúÕ layan servis Google Cloud’da bÕ anrdUÕ lmaktadÕ r. Bu servise gelen isteklerin yerine getirilmesi için ilgili verinin sürekli tuÕ taorlmasÕ gerekmektedir. Bundan dolayÕ bir iste÷e gerekli tüm adÕ mlardan geçildikten sonra cevap dönülmektedir. 4

Sonuçlar ve Gelecek ÇalúÕ malar

Yekpare bir mimari tasaÕmr ile búalayan RAY sunucu uygulam aÕ,s üç farkÕ l ana bileú en ve üç yan süreç olarak búötlüürn.müHer búileende gereksinimlerin farklÕO klarÕ ve servislerin bu farklÕO klarÕ na uygun tasarÕ m yapma fikri bulunmaktadÕ r. Trafik y o÷unlu ÷u artt Õ kça ana bilú eenlerin daha küçük parçalara aÕylmra ihtiya cÕ gündeme gelecektir. Bu da aslÕnda yekpare mimariden mikroservis mimarisine d o÷ ru bir evrim [ 13 ] anlamÕ na gelmektedir. Mikroservislerin içinde barÕndÕ rdÕ÷ takip etme (loglama), performans ölçümü, bir ist÷ei fark lÕ servisler arasÕ nda izleyebilme, hata ayÕklama ve yayÕmlama konusundaki zorluklaQÕ r çözmek için bir tÕamk araçlar gerekmektedir. Mevcut mimaride log dosyalarQÕ farklÕ sunuculardan ortak bir yerde toplayÕ p iú lemek bir sorun haline gel mútir. Önümüzdeki dönemde trafik daha da arttÕ kça performan sÕ izlemek ve log dosyaQÕlar analiz ederek sorun olan yerleri bulabilmek daha kritik hale gelecektir. Bu sorunlarÕ çözmek için ELK (Elastic Search, Logstash, Kibana) altyapÕQV [ 12 ] sistemimize entegre etmeyi planlanmaktadÕ r.

Mimarinin evrim sürecinde ilgilerin ay r÷ÕO ilkesiyle ve tutar lÕkO gereksinimlerine göre yapÕlan, iú lemlerin istemci isteklerinin yo÷ unlu÷ undan ba÷Õ msÕ z hale getirilmesi Golang dili kullanÕ larak yapÕ lmWÕú r. Her ne kadar bu bileúenler yüksek performansla çalÕú abilseler de Golang’in özelliklerinden kaynaklanan ba zÕgüvenilirlik problemleri bulunmaktadÕ r. Örne÷in Golang’de bir kuyruktan okunan bir mesaj okund÷u anda silinmekte ve mesaÕ jn iú lenmesi sÕrasÕ nda bir sorun o lúutu÷unda bu mesaja tekrar eriú ilememektedir. Benzer ú ekilde çalÕú ma zamanÕ nda zaman aÕPú hatasÕ oldu÷ unda o hata yÕ iú leyerek bir mesaj göndermek, oú i i kolayca durdurmak gibi özellikler mevcut de÷ ildir. Kuyruk-iú çi mimarisi içeren kritik bilúeenlerin gelecekte Erlang ile geliú tirilmesi planlanmaktadÕ r. Erlang’da bulunan OTP kütüphanesi bu problemler için çözüm içermesinin yaÕ nnda yüksek oranda kullaÕ nlabilir durumda olma ve ú e zamanlÕ iú lem yapabilme konularÕ nda da çeú itli avantajlar sa÷lamaktad Õ r [ 9 ][ 10 ].

Daha güvenilir kÕF al kuyruklar için de Kafka servisinin entegre edilmesi planlanmaktadÕ r. Bir publish/subscribe servisi olan Kafka [ 11 ], bellQÕ i sftaki iú leri takip eden iú çiler ve bu sÕQ flara yayÕn yapan da WF÷Õ mimarisini, kuyruktaki mesajlar üzerinde Golang’de olmayan birçok özellik ekleyerek s÷laamaktad Õ r. Bunun yanÕ nda Kafka’ya yazÕlan mesajlar, servisin yeniden ba ú latÕ lmasÕ veya çökmesi s Õras Õ nda diske yazÕlarak veri kaybÕ önlenmi ú olmaktadÕ r. Golang’in kuyruklaÕr bellekte saklandÕ÷ için servislerin istem Õú dnda yeniden búalatÕ lmasÕ gibi durumlarda veri kaÕyb yaú anabilmektedir.

Kaynakça

13: 649. the and Data

References

1. Barnes , J.M. , Garlan , D. & Schmerl , B. Softw Syst Model ( 2014 ) https://doi.org/10.1007/s10270-012-0301-9

2. Len Bass , Paul Clements, and Rick Kazman . 2012 . Software Architecture in Practice (3rd ed .). Addison-Wesley Professional .

3. Cloud Application Architecture Guide , Mike Wasson, Masashi Narumoto and Microsoft Patterns and Practices team , 2017 , Microsoft Corporation .

4. Balachander Krishnamurthy , Craig Wills, and Yin Zhang . 2001 . On the use performance of content distribution networks . In Proceedings of the 1st ACM SIGCOMM Workshop on Internet measurement (IMW '01) . ACM, New York, NY, USA, 169 - 182 . DOI: https://doi.org/10.1145/505202.505224

5. Hürsch , Walter L., and Cristina Videira Lopes. Separation of concerns. ( 1995 ).

6. https://golang.org/ref/spec Eriú im tarihi: 18 Haziran 2018 .

7. Rick Cattell . 2011 . Scalable SQL and NoSQL data stores . SIGMOD Rec . 39 , 4 (May 2011 ), 12 - 27 . DOI: https://doi.org/10.1145/1978915.1978919

8. Jing Han, Haihong E , Guan Le and Jian Du , " Survey on NoSQL database," 2011 6th International Conference on Pervasive Computing and Applications , Port Elizabeth, 2011 , pp. 363 - 366 . doi: 10 .1109/ICPCA. 2011 .6106531

9. S. Vinoski , "Concurrency with Erlang," in IEEE Internet Computing , vol. 11 , no. 5 , pp. 90 - 93 , Sept .-Oct. 2007 . doi: 10 .1109/MIC. 2007 .104

10. Jim Larson . 2009 . Erlang for concurrent programming . Commun. ACM 52 , 3 (March 2009 ), 48 - 56 . DOI: https://doi.org/10.1145/1467247.1467263

11. Kreps , Jay, Neha Narkhede , and Jun Rao . "Kafka: A distributed messaging system for log processing . " Proceedings of the NetDB . 2011 .

12. J. Bai , "Feasibility analysis of big log data real time search based on Hbase and ElasticSearch," 2013 Ninth International Conference on Natural Computation (ICNC) , Shenyang , 2013 , pp. 1166 - 1170 . doi: 10 .1109/ICNC. 2013 .6818154

13. Villamizar , Mario , et al. "Evaluating the monolithic and the microservice architecture pattern to deploy web applications in the cloud . " Computing Colombian Conference (10CCC) , 2015 10th. IEEE, 2015 .

14. Chodorow , Kristina. MongoDB: The Definitive Guide: Powerful and Scalable Storage. " O'Reilly Media , Inc." , 2013 .