Bir Reklam Arac Yaz n Mimari Evrimi Ömer K rka açl lu1, Görkem Giray1, Arif Ersin1, Cem Çat kka 1, Sena Koçer1, Tolga eremet1, Murat Osman Ünal r2 Kokteyl A. ., stanbul, Türkiye 1 omer.kirk@kokteyl.com, gorkem.giray@kokteyl.com, arif.ersin@kokteyl.com, cem.catikkas@kokteyl.com, sena.kocer@kokteyl.com, tolga.seremet@kokteyl.com 2 Ege Üniversitesi, Bilgisayar Mühendisli i Bölümü, zmir murat.osman.unalir@ege.edu.tr Özet. Mobil cihazlar n ve uygulamalar n yayg nla mas yla birlikte mobil reklamc k sektörünün önemi de son y llarda artm r. Mobil reklamc k i inin merkezinde yaz m sistemleri bulunmaktad r. Performans gibi kalite özellikleri gereksinimleri zorlay hale gelen mobil reklamc k sektöründeki yaz m sistemleri için bu de imlere paralel olarak çözümler üretilmesi gerekmektedir. Bu bildiride bir reklam arac yaz n de en i levsel ve kalite özellikleri gereksinimleri do rultusunda mimarisinin nas l evrildi i anlat lmaktad r. Ortaya kan, performans ba alt nda s fland labilecek problemlere literatürde bulunan mimari tasar m desenleri ve tasar m taktikleri kullan larak çözümler üretilmi tir. Anahtar Kelimeler: Yaz m Mimarisi Evrimi, Yaz m Mimari Tasar , Kalite Özelli i, Mobil Reklamc k. Architectural Evolution of an Ad Mediation Software Abstract. With the widespread adoption of mobile devices and applications, the importance of mobile advertising industry has also increased in recent years. Software systems are at the heart of mobile advertising business. For software systems in the mobile advertising industry, where quality requirements such as performance are becoming more demanding, solutions must be produced in parallel with these changes. This paper describes how the architecture of an ad mediation software evolves to meet the changing functional and quality attrib- ute requirements. The problems that can be classified under the heading of per- formance have been solved by using architectural design patterns and design tactics found in the literature. Keywords: Software Architecture Evolution, Software Architecture Design, Quality Attribute, Mobile Advertising. 1 Giri Gerek dünyada gerekse Türkiye’de son birkaç y lda mobil cihazlar n kullan oldukça yayg nla r. Bu cihazlar n kullan lar taraf ndan benimsenmesinin temel nedenlerinden biri bu cihazlar üzerinde çal an uygulamalar n say n artmas , çe itlenmesi ve kullan lar n birçok gereksinimini kar lamalar na yard mc olmalar r. Mobil uygulamalar n kullan n artmas yla da çevrimiçi reklamc k sektöründe mobil kanallara a rl k verilmeye ba lanm r. Bu ba lamda mobil uygulamada reklam gösterimini destekleyen çok say da reklam a ortaya ç km r. Bu reklam a lar n temel amac reklam verenler ile reklam yay nlayanlar (bu durumda mobil uygulamalar) aras nda bir köprü kurmakt r. Reklam a lar n say n artmas yla birlikte de çok say da reklam a ile reklam yay nlayanlar aras nda köprü kurma görevini reklam arac lar üstlenmeye ba lam r. Mobil çevrimiçi reklamc k sektörü tamamen yaz m üzerinde yap land lm r. Çevrimiçi reklam a lar , reklam arac lar ve reklam yay nc lar yaz m sistemleri arac yla bu sektör içindeki görevlerini yerine getirmektedir. Dolay yla yaz m mühendisli i kapsam ndaki tüm temel etkinlikler mobil çevrimiçi reklam arac yaz mlar nda da gerçekle tirilmelidir. Bu çal mada Kokteyl irketinin reklam arac k yaz n mimari evrimi yaz m mühendisli i literatüründeki çal malarla ba lant kurularak anlat lm r. kinci bölüm Kokteyl irketi, mobil çevrimiçi reklamc k sektörü ve irketin reklam arac yaz hakk nda genel bir bilgi vermektedir. Üçüncü bölümde reklam arac yaz n mimari evrimi ve bu evrim sürecinde ö renilen dersler anlat lmaktad r. Dördüncü ve son bölümde elde edilen sonuçlar ve gelecek çal malar sunulmu tur. 2 Arka Plan Bu bölümde reklam arac yaz geli tiren ve i leten Kokteyl irketi hakk nda genel bilgi verilmi , irketin yer ald mobil reklam sektörü ve irketin yaz m ürünleri tan lm r. Son alt bölümde ise yaz m mimarisi evrimi çal ma alan hakk nda k saca bilgi verilmi tir. 2.1 irket Hakk nda Genel Bilgi Kokteyl irketi 2002 y nda web tabanl uygulamalara odaklanmak üzere kurulmu tur. Sonras nda mobil uygulamalar n ve bulut teknolojilerinin yayg nla mas yla birlikte irketin oda web, mobil ve bulut uygulamalar na do ru evrilmi tir. irket çok say da yaz m ürününü geli tirmi ve hizmete sunmu tur. Bu ürünlerden en önemlisi mackolik uygulamas r. Bu uygulama web ve mobil kanallar üzerinden spor etkinlikleriyle ilgili bilgiler ve istatistiksel veriler sunmaktad r. Bu uygulaman n bir k sm 2012’de geri kalan da 2016 y nda ngiltere’deki bir medya irketi taraf ndan sat n al nm r. 2008 y ndan ba layarak irket çevrimiçi reklamc k sektörüne girmi ve zaman içinde bir reklam arac yaz geli tirmi tir. irket 2016 y ndan bu yana bu reklam arac yaz n geli tirilmesine ve i letilmesine yo unla r. 2.2 Mobil Reklam Sektörü Çevrimiçi reklam sektöründeki ana payda lar ekil 1’de gösterilmektedir. Reklam verenler, reklam a lar na ürünleri ve/veya hizmetleri hakk nda tüketicilere bilgi vermek için reklam vermektedirler. Yay nc lar, reklam a lar ndan reklam talep etmekte ve reklam a lar yay nc ya mevcut durumdaki en uygun reklam sa lamaktad r. Uygunluk konusundaki karar birçok de kene (yay nc n hangi uygulama oldu u, son kullan hakk ndaki bilgiler, uygulaman n çal cihaz gibi) ba olarak de mektedir. Yay nc lar n reklam a lar ndan do rudan reklam almas durumunda baz problemler ortaya ç kmaktad r. Teknik aç ndan yay nc uygulama reklam talep edece i tüm reklam a lar yla entegre olmak zorundad r. amaçlar aç ndan bak ld nda bir yay nc 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 reklam sa lama konusunda uzmanla maktad r. Böylece yay nc lar n reklam gelirlerini artt rmas na yard mc olmaktad r. Teknik aç dan ise çok say da reklam a ile entegre olman n getirdi i karma kl k reklam arac taraf ndan yönetilmekte ve yay nc lar n sadece reklam arac ile entegre olmalar yeterli olmaktad r. Son kullan lar ise yay nc uygulamalar kullanarak reklamlar görüntülemekte ve bu reklamlara kar zaman zaman bir davran (reklama t klama, uygulama indirme ve kurma, ürün sat n alma gibi) sergilemektedir. Bu tür davran lar yay nc lara gelir sa lamaktad r. Reklam reklam reklam talep eder Reklam A Veren verir reklam sa lar reklam talep eder reklam sa lar Yay nc Reklam reklam talep eder Arac optimum reklam sa lar davran sergiler (reklama t klama, uygulama indirme ve kurma, Son ürün sat n alma, vs.) Kullan ekil 1. Çevrimiçi reklamc k sektöründeki ana payda lar. 2.3 irketin Yaz m Ürünleri irketin yaz m ürünleri ve bu ürünlerin sektördeki di er payda larla olan ili kileri ekil 2’de gösterilmektedir. irketin reklam arac yaz olu turan iki bile en ekilde ye il renk ile gösterilmi tir. Reklam Arac Yaz n (RAY) sunucu uygulamas , reklam a lar n yaz m geli tirme kitlerini (YKG) içermektedir. Bu YKG’ler arac yla sunucu uygulamas reklam a lar ndan reklam talep etmekte ve reklam almaktad r. Yay nc uygulamalar ise RAY’nin YKG’sini uygulamalar n içine yerle tirerek RAY’den reklam talep etmekte ve almaktad rlar. Bir önceki bölümde anlat ld gibi, teknik aç dan RAY birçok reklam a ile entegre olman n getirdi i karma kl yay nc uygulamalara saydam hale getirmektedir. amaçlar aç ndan ise RAY birçok reklam a ndan sa lad reklamlar aras ndan en uygun reklam yay nc uygulamaya göndererek reklam gelirlerinin artt lmas sa lamaktad r. Yay nc Reklam Arac RAY Reklam Arac Yaz mackolik YKG reklam sa lar (RAY) Sunucu RAY Uygulamas Mobil oyunlar YKG RAY reklam talep eder Reklam A n Di er yay nc lar YKG’si YKG reklam reklam talep eder sa lar Reklam A ekil 2. irketin yaz m ürünleri. Reklam Arac Uygulamas birçok i levsel gereksinimi belirli kalite özelliklerini sa layarak ve baz k tlar alt nda kar lamaktad r. RAY’nin mevcut mimarisi zaman içinde birçok nedenden dolay (de iklik istekleri, ya anan problemler gibi) evrilerek bugünkü halini alm r. 3 Reklam Arac Yaz n Mimari Evrimi Bir yaz m sisteminin mimarisini belirleyen gereksinimler birçok biçimde kar za kmaktad r: metinler, modeller, mevcut sistemler, kullan m senaryolar , kullan m hikayeleri vs. Bu gereksinimler içinde mimari aç dan önemli gereksinimler mimari kararlar etkilemektedir. Gereksinimler, biçimlerinden ve kaynaklar ndan ba ms z olarak üç ana s 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 yaz m sisteminin niteliklerini belirtir. Bir i levsel gereksinimin niteli i o i levin ne kadar zamanda gerçekle tirilmesi gerekti ini ya da hatal bir veri giri ine kar ne kadar dirençli olaca belirtebilir. Bir yaz m sisteminin niteli i ise sistemin ne kadar zamanda canl ortama konu land labilece ini ya da i letim maliyetleri için bir s r olarak kar za kabilir. 3. tlar: Tasar m yaparken mutlaka uyulmas gereken s rlamalara i aret etmektedir. Örne in, belli bir programlama dilini kullanma zorunlulu u, mevcut bir modülün kullan lma zorunlulu u gibi. Yaz m mimarisi tasar ve gerçekle tirimi üzerinde derin etkileri olan ve yokluklar durumunda mimarinin çok farkl olabilece i gereksinimler mimari aç dan önemli gereksinimler olarak tan mlanmaktad r [2]. RAY’nin mimari tasar etkileyen gereksinimler a daki gibidir: G1. Arac k ile ilgili gereksinimler: Hangi reklam a ndan hangi s rada reklam istenece ini belirleyen optimize edilmi karar a ac n olu turulmas ve reklam gösterim istatistiklerini istemcilerden toplanmas içeren gereksinimler. o G1.1. stemcilerden gelen talepler do rultusunda optimize edilmi karar a ac n istemcilere gönderilmesi o G1.2. Reklam gösterim istatistiklerinin sunucu uygulamas nda saklanmas G2. Analitik gereksinimler: Reklam gösterim istatistiklerinin kullan (mobil cihaz) baz nda gruplanmas ve kullan lar/cihazlar hakk ndaki bilgilerin saklanmas içeren gereksinimler. o G2.1. Kullan /cihaz yarat lmas ya da güncellenmesi o G2.2. Kullan n uygulama içinde yapt sat n alma i lemlerinin izlenmesi o G2.3. Kullan dan/cihazdan reklam isteklerinin gelmesi G3. Kampanya izleme gereksinimleri: o G3.1. Bir iste in ilgili kayna a yönlendirilmesi o G3.2. Bir istek yönlendirildikten sonra gerekli istatistiklerin güncellenmesi Birçok yaz m sisteminin mimarisi, yeni istekler, yeni kalite özelli i gereksinimleri, teknolojideki de imler ya da ba ka nedenlerle de ikli e u rar [1]. Nedeni ne olursa olsun yaz m sektöründeki projelerde mimarinin evrilmesi ola and r. 3.1 Arac k Bile eninin Mimarisinin Evrimi Yekpare mimariye sahip bir yaz m sistemi tüm i levleri yerine getiren tek bir bile enden olu ur. Sistemde yap lacak her de iklikte sistemin tamam n yeni versiyonu konu land r. ekil 3’te RAY’nin yekpare mimari yakla yla tasarlanm ilk mimarisi gösterilmektedir. Bu mimaride tüm i levler bir uygulama programlama arayüzü (UPA – API: Application Programming Interface) ile istemcilere sunulmu tur. Veri saklama için ili kisel bir veritaban (PostgreSQL) kullan lm r. stemci UPA li kisel Veritaban ekil 3. Birinci a amadaki yekpare mimari. Yekpare mimarinin bir avantaj , de ikliklerin canl sistemde devreye al nmas n görece kolay olmas r (bir UPA’n n konu land lmas ). Bunun yan nda yaz m sisteminin anla lmas n kolay olmas da hatalar n bulunmas da kolayla rmaktad r. Di er taraftan istemcilerden gelen isteklerin artmas yla ve belirli zaman aral klar nda yo unla mas yla birlikte yekpare mimarinin performans aç ndan problemleri ortaya ç kmaya ba lam r. G1.1 ve G1.2 gereksinimlerinin gerektirdi i çözümler birbirinden farkl olmas na ra men (ilkinde veritaban ndan okuma, ikincisinde veritaban na yazma i lemleri yo un) yekpare mimari nedeniyle ayn mimari çözüm uygulanmak zorunda kal nm r. UPA’n n s k güncellenmesi gereken durumlarda hangi i levde güncelleme yap rsa yap ls n tüm UPA’n n belirli bir süre devre d kalmas söz konusu olmaktad r. 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 r. Performans problemlerini çözmek için ilgilerin ayr (separation of concerns) ilkesi [5] do rultusunda veritaban ndan okuma ve veritaban na yazma i lemleri ayr UPA ile yap lmaya ba lanm r. Okuma i lemlerinde performans artt rmak için içerik da m a ( ÇA – CDN: Content Delivery Network) kullan lmaya ba lanm r [3]. ÇA kullan ile birlikte istemci taleplerine dönü performans artm ve okuma i lemlerinin eri ilebilir olma yüzdesinde, literatürdeki bulgularla paralel olarak [4], yükselme gözlemlenmi tir. Ayr ca hem okuma i lemleri hem de yazma i lemleri için gelen istekler yük dengeleyiciler (load balancer) ile farkl sunuculara da lmaya ba lanm r. ekil 4’te yekpare bile enin iki sorumlulu a sahip iki ayr bile en haline getirildi i mimari gösterilmektedir. çerik UPA Da m (Okuma lemleri) (CDN) stemci UPA (Yazma lemleri) li kisel Veritaban ekil 4. kinci a amadaki iki ana bile enli mimari. Okuma ve yazma sorumluluklar n ayr bile enlere verilmesinden sonra yazma lemlerinde sistemin yo un kullan ld zamanlarda performans problemleri ya anmaya ba land görülmü tür. Her yazma talebi veritaban yönetim sistemi taraf ndan kar land ktan sonra istemcilere cevap dönülmesi, tepki süresini veritaban sunucusunun performans na ba k lm r. Dolay yla veritaban sunucusundaki problemlerde ya da yava klarda istemcilerin taleplerine tepki süresi artmaya ba lam r. Veritaban nda saklanan verinin her an tutarl olma gereksinimi olmad için gelen yazma isteklerinin bir kuyrukta biriktirilmesi ve i çiler taraf ndan belirli aral klarla veritaban na yaz lmas tercih edilmi tir. Web-Kuyruk- çi mimari stiline [3] kar k gelen bu mimari tasar m sonucunda sistemin mimarisi ekil 5’te gösterilmektedir. çerik UPA Da m (Okuma lemleri) (CDN) stemci UPA Kuyruk çi (Worker) (Yazma lemleri) li kisel Veritaban ekil 5. Üçüncü a amadaki kuyruk ve i çi bile enleri eklenmi ekliyle mimari. Bu mimarinin gerçekle tirimi için ko ut zamanl programlamay destekleyen Golang [6] dili kullan lm r. Yazma i lemlerinden sorumlu UPA gelen talebi kuyru a ekler ve istemciye cevap dönmektedir. Bir veri birle tirici kuyru u kontrol eder; veriyi biriktirir ve belirli bir sürede ya da veri belirli bir hacme ula zaman veriyi i çiye gönderir. çi birikmi veriyi kuyruktan al r; geçici bir veritaban tablosuna bu veriyi yazar; geçici tablodaki veriyi kal tabloya ekler ve geçici tabloyu temizler. çi, veri transferi ve ortak tablolara veri yazma i iyle u ra için olas bir kilitlenmeyi (deadlock) engellemek için tek bir i çi kullan lmaktad r. Bu mimarinin olumsuz taraf ise i çinin kuyru a eklenen veriyi yeterince h zl biçimde kal tablolara ta yamamas durumunda biriken verinin bellek ve i lemci kaynaklar nda darbo az olu turmas durumuyla sonuçlanmaktad r. Bu problemi gidermek için ise veriyi kuyruktan geçici tablolara aktarma i i ve geçici tablodan kal tabloya veri yazma i i farkl süreçlere payla lm r. Bu tasar mda veriyi kuyruktan geçici tablolara aktarma i ini birden fazla süreç üstlenebilmektedir. Geçici tablodan kal tabloya veri aktar ise yine bir süreç ile sa lanmaktad r. Mimarinin bu son amadaki haliyle reklam gösterim isteklerinin sorunsuz biçimde kar lanmas sa lanmaktad r. 3.2 Analitik Bile eninin Mimarisinin Evrimi Analitik bile eninin temel görevi kullan bazl verinin istemcilerden toplanmas ve saklanmas r. Bu temel görev yeni kullan lar n kay tlar n yarat lmas (G2.1), gerekti inde bilgilerinin güncellenmesi (i letim sistemi, ülke, vs gibi) (G2.2), yay nc uygulamada yapt sat n alma verisinin toplanmas ve uygulamada gösterilen reklamlar n verisinin toplanmas kapsamaktad r. Arac k bile eninde reklam gösterim verisi reklam a lar baz nda saklan rken analitik bile ende bu verilerin kullan baz nda saklanmas gerekmektedir. Bu gereksinim, mimarinin yo un bir veri yazma i iyle ba a ç kabilecek ekilde tasarlanmas ve gerçekle tirilmesini gerektirmektedir. Bu gereksinimi kar layabilmek için NoSQL bir veritaban [7] kullan lm r. Bu bile enin yazma görevini yerine getirmesi için kuyruk ve i çi bile enleri kullan lm r. Gelen istekler bir kuyrukta biriktirilmekte ve toplu halde bir NoSQL veritaban olan MongoDB’ye [14] yaz lmaktad r. Bu çözüm yeni kullan kayd yarat lmas , kullan bilgilerinin güncellenmesi gibi görevler için gereksinimi kar lam r. Ancak yay nc uygulamada yap lan sat n alma i lemlerinin do rulanmas görevinin yerine getirilmesi noktas nda bu mimaride problemler ortaya km r. Bir sat n alma i leminin, bir kullan ad na veritaban na kaydedilmeden önce bu sat n alma i leminin sahte olup olmad n kontrol edilmesi gerekmektedir. Bu kontrolü yapmak için Apple’ n ve Google’ n sundu u servislerden faydalan lmaktad r. Ancak sistemin genel performans bu servislerin performans na do rudan ba hale gelmi tir. Baz durumlarda bu servislerdeki yava ktan dolay sistemin genel performans nda dü gözlemlenmi tir. Bunu engellemek için sat n alma i leminin kontrolünü gerçekle tiren i lev ayr bir bile en haline getirilmi tir. Böylece istemciden al nan veriler geçici olarak saklanmakta, istemciye cevap dönülmekte ve ba ka bir bile en taraf ndan sat n alma i leminin kontrolü yap lmaktad r. Bu kontrolden cevap geldikten sonra hem ili kisel hem de NoSQL veritaban nda gerekli alanlar güncellenmektedir. Senkron olarak yap lan i lerin asenkron hale getirilmesi performans art na neden olmu tur. Analitik bile eninin kar lad bir ba ka gereksinim yay nc uygulama sahiplerine uygulamalar belirli bir süre içerisinde aktif olarak kullanan tekil kullan say vermektir. Mobil reklamc 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 ili kisel bir veritaban na yaz lmas na karar verilmi tir. Bu da kullan bazl verinin hem MongoDB’ye hem de ili kisel veritaban na yaz lma gereklili ini do urdu. Ancak ili kisel veritaban na yazma sürelerinin uzunlu u nedeniyle yo un istek gelen zamanlarda sistem performans gereksinimlerini kar layamad . Bu problemi gidermek için hem h zl yazma imkan veren hem de verinin raporlanmas için gerekli yetenekleri sa layan Redis veritaban [8] sisteme eklenmi tir. Redis veritaban kullan bazl verileri gün içinde saklamakta gün sonunda ise bu veriler ili kisel veritaban na aktar lmaktad r. Bu de iklik ile birlikte hem kullan bazl verinin saklanmas hem de istendi inde raporlanmas gereksinimleri kar lanm r. 3.3 Kampanya zleme Bile eninin Mimarisi Bu bile en, kritik mü terilerin (yay nc uygulamalar) RAY’den ald linkler ile kendi uygulamalar n reklamlar ndan ald klar t klamalar takip ederek hangi kaynaktan ne tür kullan ald klar analiz etmelerini sa lamaktad r. Reklam verenin para ödeyerek verdi i reklamlara t kland nda öncelikle bu bile enin sundu u servis ça r. Dolay yla bu bile enin yüksek oranda kullan labilir olmas gerekmektedir. Bu servis tetiklendikten sonra takip için gerekli bilgiler toplan r ve Google veya Apple uygulama dükkanlar ndaki uygulama sayfas na yönlendirme yap r. Servisin çal r durumda olmamas durumunda bu yönlendirme yap lamaz ve reklam verenin kullan kazanmak için yapt reklam bo a gitmi olur. Bu önemli gereksinimi kar layan servis Google Cloud’da bar nd lmaktad r. Bu servise gelen isteklerin yerine getirilmesi için ilgili verinin sürekli tutarl olmas 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 tasar m ile ba layan RAY sunucu uygulamas , üç farkl ana bile en ve üç yan süreç olarak bölünmü tür. Her bile ende gereksinimlerin farkl klar ve servislerin bu farkl klar na uygun tasar m yapma fikri bulunmaktad r. Trafik yo unlu u artt kça ana bile enlerin daha küçük parçalara ayr lma ihtiyac gündeme gelecektir. Bu da asl nda yekpare mimariden mikroservis mimarisine do ru bir evrim [13] anlam na gelmektedir. Mikroservislerin içinde bar nd rd takip etme (loglama), performans ölçümü, bir iste i farkl servisler aras nda izleyebilme, hata ay klama ve yay mlama konusundaki zorluklar çözmek için birtak m araçlar gerekmektedir. Mevcut mimaride log dosyalar farkl sunuculardan ortak bir yerde toplay p i lemek bir sorun haline gelmi tir. Önümüzdeki dönemde trafik daha da artt kça performans izlemek ve log dosyalar analiz ederek sorun olan yerleri bulabilmek daha kritik hale gelecektir. Bu sorunlar çözmek için ELK (Elastic Search, Logstash, Kibana) altyap [12] sistemimize entegre etmeyi planlanmaktad r. Mimarinin evrim sürecinde ilgilerin ayr ilkesiyle ve tutarl k gereksinimlerine göre yap lan, i lemlerin istemci isteklerinin yo unlu undan ba ms z hale getirilmesi Golang dili kullan larak yap lm r. Her ne kadar bu bile enler yüksek performansla çal abilseler de Golang’in özelliklerinden kaynaklanan baz güvenilirlik problemleri bulunmaktad r. Örne in Golang’de bir kuyruktan okunan bir mesaj okundu u anda silinmekte ve mesaj n i lenmesi s ras nda bir sorun olu tu unda bu mesaja tekrar eri ilememektedir. Benzer ekilde çal ma zaman nda zaman a hatas oldu unda o hatay i leyerek bir mesaj göndermek, o i i kolayca durdurmak gibi özellikler mevcut de ildir. Kuyruk-i çi mimarisi içeren kritik bile enlerin gelecekte Erlang ile geli tirilmesi planlanmaktad r. Erlang’da bulunan OTP kütüphanesi bu problemler için çözüm içermesinin yan nda yüksek oranda kullan labilir durumda olma ve e zamanl i lem yapabilme konular nda da çe itli avantajlar sa lamaktad r [9][10]. Daha güvenilir kal kuyruklar için de Kafka servisinin entegre edilmesi planlanmaktad r. Bir publish/subscribe servisi olan Kafka [11], belli s ftaki i leri takip eden i çiler ve bu s flara yay n yapan da mimarisini, kuyruktaki mesajlar üzerinde Golang’de olmayan birçok özellik ekleyerek sa lamaktad 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 kuyruklar bellekte sakland için servislerin istem d nda yeniden ba lat lmas gibi durumlarda veri kayb ya anabilmektedir. Kaynakça 1. Barnes, J.M., Garlan, D. & Schmerl, B. Softw Syst Model (2014) 13: 649. 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 the Microsoft Patterns and Practices team, 2017, Microsoft Corporation. 4. Balachander Krishnamurthy, Craig Wills, and Yin Zhang. 2001. On the use and 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 Data Storage. " O'Reilly Media, Inc.", 2013.