Azure'da bir ASP.NET Projesinin Anatomisi (SDK2.2)

0 dakikada yazıldı

17961 defa okundu

Düzenle

Visual Studio'ya açıp ilk Azure projenizi yaratmaya başladığınız anda
karşınıza hemen bir seçim ekranı gelecektir. Bu seçim ekranı epey
kalabalık bir ekran gibi dursa da aslında özünde iki seçenek var :)

İlk Azure projemizi yaratırken...
İlk Azure projemizi yaratırken...

Seçeneklerden ilki "Web Role" ikincisi ise "Worker Role". Geri
kalan tüm diğer seçenekler öyle veya böyle bu rollerin biraz daha
değiştirilmiş, içi dolu halleri.

Web Role ile Worker Role arasındaki fark aslında çok basit. Web Role
içerisinde bir web sitesi bulundurabildiğiniz bir role yaratıyor. Tabi
bu arada unutmamak gerek ki her "role" azure deyimi ile bir sanal makine
demek. Hatta Role'lerin kaç kopya (instance) olacağı da o rol başına
yaratılacak sanal makine sayısını değiştirecektir. Worker Role ise
varsayılan ayarlarında herhangi bir input veya output endpoint'i olmayan
ve sadece işlem yapmak üzerine kurulu C#/VB kodu olarak düşünebilir.

Hızlı bir örnek vermek gerekirse; bir e-ticaret sitesinin site kısmı web
role, arka plandaki sipariş işlemlerini yürüten kısmı ise worker role
olarak düşünebilir. Sipariş işlemlerinin yürütülmesi, bankadan ödeme
onayı, stok düşülmesi, kargolama işlemlerinin başlatılması gibi işlemler
aslında doğrudan web sitesi ile alakalı işlemler değiller. Bu işlemlerin
sonuçları web sitesinde gösterilse de bu işlemlerin yapılması web
sitesinin değil arka planda çalışan bir başka kodun görevi olabilir. Bir
anlamda background processing için de kullanabilirsiniz Worker
Role'leri.

Bir azure projesinde birden çok web role veya worker role olabilir.
Genelde tüm bu roller beraber bir azure service'ini temsil ederler. Web
ile Worker role arasında ayrım yapmamızın bir nedeni de bu işlemleri ve
role'leri ayrı ayrı ölçeklendirebiliyor olmak. Örneğin web sitenize
gelen çok ziyaretçi varsa web role'ünüzden 10 instance (kopya / sunucu)
alabilirken arkaplandaki işlemleri yürüten worker role sadece 2 instance
olabilir. Çok farklı bir örnek olarak youtube'u ele alırsak. Sitenin ana
yapısını, yani dışarıyla iletişimi sağlayan kısmı için belli 4000
instance (Server) tutulurken arka planda videoları işleyen kısım için
2000 instance alınabilir. Tüm bu ölçeklenebilirliliği bir de uygulamanız
çalışırken kendi yüküne bakarak dinamik olarak yapabilirse "yeme de
yanında yat" şeklinde süper bir Cloud çözümü oluşturmuş olursunuz. Tüm
bunları ümit ediyorum ki zamanla yeni makalelerle blogda inceleyeceğiz
:)

Şimdilik hızlı bir başlangıç için hemen ASP.NET Web Role'ü seçerek
ilerleyelim. Projenizi yarattığınız gibi Visual Studio'da Solution
Explorer'da aşağıdaki manzarayı göreceksiniz.

Solution'da bir Azure projesi var.
Solution'da bir Azure projesi var.

Solution içerisinde hemen bir azure projesi bir de asp.net projesi
kendini gösterecektir. İşte buradan sonraki adımlarda Azure'daki ASP.NET
projesinin normal bir ASP.NET projesinden farkına bakacağız :)

ASP.NET tarafındaki farklılıkları bulun :)
ASP.NET tarafındaki farklılıkları bulun :)

Yukarıdaki ekran görüntüsünden çok büyük olduğunun farkındayım :) Ama
yapacak birşey yok. Gördüğünüz üzere farklılıklar alenen kendini
gösteriyor :) Dört adet referans ve bir de ilginç C# dosyası. Şimdi
nedir bu arkadaşlar tek tek onları inceleyelim.

WindowsAzure.Diagnostics

Azure üzerindeki bir ASP.NET uygulamasının artık birden çok sunucuda
çalıştığı fikrine alıştık :) Bu sunuculardaki farklı performance
counter'lar olsun trace loglarınız olsun farklı datalara ulaşmak
istediğinizde işiniz zor olacaktır. Neden mi? :) Eh malum her sunucu
logunu kendisi tutar. Peki sizin için tek tek sunucuların logları mı
önemli yoksa uygulamanızın logları mı? Büyük ihtimal ile uygulamanızın
loglarını almak isteyeceksiniz. Artık uygulamanızın kaç sunucuda
çalıştığının önemli olmadığına alışmamız gerek :) Sunucu başına log
almanın hiçbir anlamı yok çünkü eğer bir sunucuda problem varsa %99
ihtimal diğerlerinde de var. Bu sunucuların hepsi aynı şekilde
yaratıldılar, aynı VHD'lerden oluşuyorlar ve sizin aynı uygulamanız
üzerlerinde çalışıyor. O nedenle instance'larla ayrı ayrı uğraşmanın
anlamı yok. CPU yükünü merak ediyorsanız 15 sunucuya yayılmış
uygulamanızı 15 sunucudaki ortalama yükünü merak ediyorsunuzdur. Tekrar
aynı konuya geri döneceğim fakat bunu netleştirmek çok önemli. Konsept
olarak uygulamanızı bugün 15 sunucuya yaymak zorunda kalmanıza aslında
yazılım geliştiricinin umrunda bile olmamalı çünkü bu durum tamamen
bugünkü teknolojinin sınırları yüzünden ortaya çıkıyor. Yani bugün 15
sunucuda olan uygulama yarın 5 sunucuda olabilir :) Özetle instance
sayısına göre hareket edemeyiz.

İşte tam da bu noktada :) tüm diagnostic bilgilerini alacak, merkezi bir
yere koyacak bir ne? evet :) doğru tahmin ettiniz Agent gerekiyor.
Diagnostics Agent Windows Azure'daki her base.VHD'de var. Makinede zaten
kurulu olan Diagnostics Agent ile konuşup istediğiniz bilgileri
toplamasını sağlamak, onları merkezi bir yere atmasını sağlamak için....
özetle Diagnostics Agent ile konuşmak için.... WindowsAzure.Diagnostics
:) referansımızı kullanacağız. İşte bu kadar :) Diagnostics konusunun
detaylarını ileride inceleyeceğiz ;)

ServiceRuntime ve Configuration

Uygulamanız artık normal bir ASP.NET projesi değil. Bu bir azure
projesi. Aradaki fark ne? İsterseniz daha önceki yazılarda incelediğimiz
Fabric Controler Host Agent hikayemize geri döneli. Fabric Controller
Host Agent bizim uygulamayı IIS üzerine yerleştirip çalıştırmak ve
sağlığını garanti etmekle sorumluydu. Yeri geldiğinde uygulamaya restart
atıp recycle edicek olan da yine FC Host Agent. Peki ya biz FC Host
Agent ile konuşmak istersek? Yani uygulamamı IIS'e attın ama başlatmadan
önce haber ver bana.... veya uygulamamı IIS'e atmadan önce haber ver
bana benim sana yaptırmak istediğim ek işler var.. gibi şeyler söylemek
istersek FC Host Agent'a? :) Nasıl yapacağız? ServiceRuntime sayesinde!
Artık Azure ortamında host edilen bir ASP.NET projemize var. Yani IIS
üzerinde duran bir ASP.NET projesinin dışında bir kabuk daha var özünde,
onun adı da WebRole :) Role'ün açılışı, kapanışı gibi eventler söz
konusu. Daha gerçekçi bir örnek vermek gerekirse... diyelim ki ASP.NET
projenizin arkasında bir windows servisi olması gerekiyor. ASP.NET
projeniz başlamadan önce bu Windows Servisi'nin makineye kurulup
çalıştırılması şart. İşte bunu doğrudan ServiceRuntime üzerinden FC Host
Agent ile konuşarak yaptırabiliyorsunuz :) Nasıl mı? Detayları şimdilik
ileri bir zamana bırakacağım ama ufak bir ipucunu bu yazının sonunda
paylaşacağım ;) Sabır.

ServiceRuntime ile beraber Configuration sınıfı da çok önemli. CSCFG ile
ilgili tüm operasyonlarımızı da kütüphane ile yapacağız. Malum normal
şartlarda ASP.NET'in CSCFG'nin varlığından bile haberi yok :)

StorageClient

Storage hikayesi çoook uzun bir hikaye :) Her zamanki gibi detayları
ileri bir yazıya bırakacağız. Peki bu referans da neyin nesi o zaman?
Uygulamamızın artık birkaç sunucuya dağıldığını biliyoruz. Load Balancer
üzerinden gelen talepler belki de 5 instance olarak ayarladığımız 5
farklı sanal makineye dağıtılıyor. Eh bu durumda o makinelerin
disklerini kalıcı veri saklamak için kullanamıyoruz. Bunun birinci
nedeni diskler sync edilmiyor birbiri ile. İkincisi ise.... tamamen
atıyorum, network seviyesinde datacenter'da bir hata olduğunda FC'nin
uygulamamı başka bir fiziksel sunucuya taşıması ihtimalinde tamamen var
olan diskimi kaybedecek olmam. Tüm bunlar kötü gizi gözükse de normal
dağıtık bir uygulamada yaşanan senaryolar. Allah'tan en azından Azure
ortamında tüm bunları FC yönetiyor da :) uğraşmak zorunda kalmıyoruz.
Yoksa malum bugün ne yaparsanız yapın 1000 instance'lık (sunuculuk) bir
datacenter'a yayılan uygulamanız varsa, eninde sonunda donanım hataları
da alırsınız :) Bunların başında disk sonra RAM gelir :) Neyse, konumuza
dönelim.

İşte tüm bu senaryo çerçevesinde Azure'da ayrı bir servis olarak sunulan
uygulamanız Azure'da olmasa bile kullanabileceğiniz Storage (kalıcı veri
ambarı) servisleri var. Bu servislerin hepsi REST API'leri ile açılmış
durumda. Kimsenin REST call'larla uğraşmak, retrypolicy'leri HTTP
seviyesinde implemente etmek için can atmadığının Microsoft da farkında
:) İşte tam da o nedenle tüm bu REST API'lerinin etrafında güzel bir
wrapper olarak StorageClient sınıfı yetişiyor. Özetle :) bir yerlere bir
dosya kaydedecekseniz bu assembly şart.

WebRole.CS

Ekran görüntüsünün en altlarındaki kalan WebRole.CS dosyasını
unutmadınız değil mi? Sıra ona geldi. Aslında tüm bunlar arasında en
basiti o. ASP.NET'teki Global.asax'ı bilirsiniz. Uygulama geneli
event'leri vs yakalamamıza yardımcı olur. İşte WebRole.CS de onun Azure
versyonu :) Özellikle ServiceRuntime ile ilgili konuşurken üzerinden
geçtiklerimizi hatırlarsanız ASP.NET'in kendi yaşam döngüsü (lifecycle)
üzerinde ayrıca bir de role yaşam döngüsü olduğundan bahsetmiştik. İşte
WebRole.cs'de servis yaşam döngüsünün Global.asax'ı :)

[Webrole.cs]

namespace OrnekWebRole
{
    public class WebRole : RoleEntryPoint
    {
        public override bool OnStart()
        {
            // For information on handling configuration changes
            // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

            return base.OnStart();
        }
    }
}

İlk yarattığımız projedeki webrole.cs yukarıdaki şekilde olacaktır.
Basit hali ile sadece Role'ün başlangıcında birşeyler yapmak
istiyorsanız kod yazabileceğiniz bir alan sunuyor :) Burada neler
yapılabileceğine ileride bakarız ;)

İşte bu kadar :) Normal bir ASP.NET projesi ile Azure'daki bir ASP.NET
projesinin farkları bunlar... desem de inanmayın :) Şaka bir yana
özellikle migration senaryoları düşünülürse daha birçok farklılık
kendini gösterecektir. Tüm bunları yavaş yavaş .. zamanla .. :)
inceleyeceğiz. Fakat Visual Studio içerisindeki bir proje gözü ile
bakarsanız normal bir ASP.NET projesi ile azure'daki ASP.NET projesi
arasındaki farklılıklar bunlar.

Varolan projelerle nasıl ilerleriz?

Elinizde hali hazırda var olan bir ASP.NET projesini bir Azure projesine
çevirmek istiyorsanız hemen Solution Explorer içerisinde efsane bir
komut var :) "Add Windows Azure Cloud Service Project" :) Komutu
verdiğiniz anda Solution içerisine bir Azure projesi eklenecek, web
projeniz Azure projesine Web Role olarak tanımlanacak, Web projenize
Azure referansları eklenecek ve işlem tamamlanmış olacak.

Var olan bir ASP.NET Role'e çevirmek.
Var olan bir ASP.NET Role'e çevirmek.

Bu noktada kesinlikle tekrar etmek gerek; herşey bu kadar tos pembe
değil :) "Ekledim bitti, artık azure oldu" gibi bir sonuç kesinlikle
çıkaramayız. Daha bu işin ciddi ciddi migration kısmı var. Şu an için
yapının Visual Studio içerisindeki duruşuna ve neyin ne olduğuna
bakıyoruz :)

Bir sonraki yazıda görüşmek üzere....