=Paper=
{{Paper
|id=Vol-2201/UYMS_2018_paper_105
|storemode=property
|title=Bir Reklam Aracisi Yaziliminin Mimari Evrimi(Architectural Evolution of an Ad Mediation Software)
|pdfUrl=https://ceur-ws.org/Vol-2201/UYMS_2018_paper_105.pdf
|volume=Vol-2201
|authors=Omer Kirkagaclioglu,Gorkem Giray,Arif Ersin,Cem Catikkas,Sena Kocer,Tolga Seremet,Murat Osman Unalir
}}
==Bir Reklam Aracisi Yaziliminin Mimari Evrimi(Architectural Evolution of an Ad Mediation Software)==
https://ceur-ws.org/Vol-2201/UYMS_2018_paper_105.pdf
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.