YAZDIR

Cloud Computing: Mimari ve Kullanım Senaryoları

Sun Microsystems Türkiye Kurumsal IT Mimarı Orhan Alkan'ın 'Cloud Computing' ile ilgili merak edilenleri ele aldığı makale dizisinin ikinci yazısı.

07 Eylül 2009

İlk yazısında Cloud Computing'in Genel Görünümüne değinen Alkan, ikinci makalesinde ise Cloud computing'de öne çıkan iki desen ve bu desenlerin fonksiyonları ile kullanım senaryolarını mercek altına alıyor.

Orhan Alkan / Sun Microsystems Türkiye

Henüz oluşum aşamasında olması nedeniyle, Cloud Computing’in en iyi uygulama (best practices), yapı taşları (building blocks) ve detay planları (blueprints) henüz netleşmiş değil. Bu gri ortamda, istikrarlı, kendini farklı kullanım alanlarında tekrar eden bazı desenlerin ortaya çıktığını görüyoruz. Bu makelede ortaya çıkan bu desenler üzerinde durarak onları tanımlamaya ve anlamaya çalışacağım.
Belirginleşen bu desenleri iki açıdan, mimari yapıyı fonksiyonlar açısından ve kullanım senaryolarına bakarak inceleyeceğim.
Karmaşık yapıya sahip sistemleri incelemenin zorluklarında biri çok boyutlu olmaları ve bu nedenle bakan kişi, durduğu yer ve bakış açısına göre farklı görünümleri olmasıdır. Bu güçlük Cloud Computing için de geçerlidir. Cloud Computing’in mimari yapısına bakarken fonksiyonlara odaklanmayı, bu sayede detaylarda kaybolmadan, teknoloji bağımsız, genelgeçer temel yapı taşlarını anlamayı umuyorum. Daha farklı çalışmalar Internet üzerinde bulunabilir (1,2).

Yandaki şekilde temel aktörler (Tüketici, Servisi Sağlayıcı ve Servis Geliştirici), bunların talep ettiği ya da yerine getirdiği fonksiyonlar ve birbirleri ile etkileşimi gösterilmektedir. Şimdi her bir bileşeni tek tek inceleyelim:


Tüketici:
Servis sağlayıcının sunduğu hizmetleri (yazılım, platform ya da altyapı servisleri) tüketen kurum ya da bireylerdir.
Genellikle abone oldukları servisleri “kullandıkça öde” modeline göre kullanırlar. Abonelik, sağlanan web arabirimi ya da programlama arayüzleri (API) ile program içerisinde gerçekleştirilir.
Tüketici, servis sağlayıcı ile hizmet seviyesi anlaşması (SLA) ya da kontrat esasına göre çalışıyor olabilir.
Tüketici gerçekleştireceği fonksiyona ya da role bağlı olarak farklı kullanıcı arabirimi ya da programlama arayüzü kullanıyor olabilir. Örneğin, kullandığı sanal makinayı çalıştırmak, durdurmak, silmek gibi yönetsel işler için web arabirimini kullanabileceği gibi uygulama içerisinden API kullanıyor olabilir. Servis sağlayıcı tüketiciye servisin kullanımı hakkında detaylı analitik bilgi sunabilmelidir.
Servis sağlayıcı kullanıcıya servisi kullanabilmesi ve kullanırken oluşan problemleri giderebilmesi için gerekli yardımı sağlar.
Tüketici; abonelik, yönetim, yardım, servisin tüketimi işlemlerini erişim katmanı üzerinden gerçekleştirir. Erişim katmanı, web arayüzü ve API’lerdir.

Servis Sağlayıcı:
Servis sağlayıcı, servisi planlayıp kurar ve tüketiciye ulaştırır.
Sunduğu servisler temel olarak, altyapı (IaaS), platform (PaaS), yazılım (SaaS) servisleridir. Servis geliştiricilerin geliştirdiği uygulama ve servisler bunların üzerine kuruludur. Uygulama katmanı ile gösterilen budur.
Çizimin en altında görülen donanım katmanı, servislerin üzerinde koştuğu fiziksel donanımı göstermektedir. Sunucular, veri saklama cihazları, iletişim ekipmanları bunlardan bazılarıdır. Sunucular genellikle x64 tabanlı, düşük maliyetli ekipmanlardır.


Donanımın hemen üstünde çekirdek yazılım ile ifade edilen kısım, işletim sistemi ya da sanal makina yönetim katmanıdır. Sanallaştırma bu aşamada başlamaktadır.
Çekirdek yazılımın üstünde bilgi işleme, veri saklama, iletişim ağları gibi sanallaştırılmış kaynaklar bulunmaktadır. Sanallaştırma Cloud Servislerinin (otomatik provizyonlama, kullandıkça öde ve elastikiyet ile beraber) en belirgin özelliğidir.
Bu yapının sorunsuz çalışabilmesi için servis sağlayıcının temel yönetim servislerini oluşturması gerekmektedir. Bunlar sağ tarafta Yönetim başlığı altında gösterilmektedir. Kullanıcının aboneliğinden kaynakların atanmasına, sisteme eklenen yeni donanımın kullanıma hazır hale getirilmesine kadar tüm provizyon süreçlerinin otomatik iş akışları halinde hayata geçirilmiş olması en önemli fonksiyonlardan biridir. Kapasite planlamasında yetkinlik,  kaynakların kullanıcının talebi durumunda verilip alınabilmesi (elastiklik) için önemlidir.
Servis sağlayıcının hizmet destek başlığı altındaki ITIL süreçlerini (konfigürasyon yönetimi, değişiklik yönetimi, problem yönetimi, v.d.) başarıyla uygulaması bir diğer gerekliliktir. Buna bağlı olarak etkin bir izleme ve ölçümleme yapısı kurulmuş olmalıdır. Faturalandırma ölçümleme verisi üzerine dayanmaktadır ve kullandıkça öde modeli için ölçümleme hayatidir. Aksi takdirde servis sağlayıcı para ya da müşteri, bazen de her ikisini birden kaybedebilir.
SLA yönetimi tüketici beklentilerinin karşılandığından emin olmak için gereklidir.
Servis Sağlayıcı her katmandaki gerekli güvenliği, servis geliştiricilerin ve tüketicilerin ihtiyaç duyduğu güvenlik servislerini sağlamalıdır. Bu nedenle güvenlik dikey olarak her katmanla ilişkili gösterilmiştir.
Son olarak servis sağlayıcı tüketici ve geliştiriciler için gerekli erişim katmanını sağlamalıdır. Erişim katmanı standart protokoller üzerinde kurulu kullanıcı arayüzleri ve API’lardan oluşur. Kullanılan API’lar konusunda ne yazık ki benzer servisler için bile bir standart oluşmamıştır. Bu durum Open Cloud Manifestosu’nunda çıkış noktasıdır(3).


Servis Geliştirici:
Servis geliştirici, servis sağlayıcının sunmuş olduğu temel servisleri alıp yeni uygulama ya da servisler oluşturur. Bunun için servis oluşturma, yayınlama ve izleme fonksiyonlarının servis sağlayıcı tarafından sağlanmasına gereksinim duyar. Oluşturduğu servis ile ilgili analitik bilgi geliştirici için önemlidir ve servis sağlayıcı tarafından sağlanmalıdır.
Servis geliştirici için fırsatlar hayal gücü ile sınırlıdır. Tamamen yeni bir servis geliştirebileceği gibi, var olan servisi kendi markasını oluşturarak niş bir alana pazarlıyor da olabilir.
Aktörler ve fonksiyonel mimariye böylece değindikten sonra kullanım modellerini inceleyebiliriz.

Kullanım Senaryoları:

1- Bireysel Kullanım: Bu senaryoda tüketici bireysel son kullanıcıdır ve Cloud servislerini kullanır. Tüketici arka planda servisin nasıl oluşturulduğu ya da nasıl çalıştığı ile ilgilenmez. Kullandıkça öde en yaygın kullanılan iş modelidir. Bu türden servislere “Amazon S3” servisi iyi bir örnektir.
2 – Kurumsal Kullanım: Bu senaryo içerisinde birden çok alt senaryo barındırmaktadır:
Bu senaryoların ilkinde, kurum son kullanıcılara kullandırmak üzere (çalışanlar, iş ortakları, müşteriler, v.b.) Cloud servislerinden faydalanır. Elektronik posta ya da veri paylaşımı servisleri örnek olarak verilebilir.
İkinci senaryoda, BT fonksiyonlarının bazılarının Cloud servislerine aktarıldığını görürüz. Veri saklama, yedekleme (özellikle yedekleme kopyalarının kurum dışında saklanması) ve veri tabanı servisleri ilk anda verebileceğim örneklerdir. Kurum BT servislerini birbirinden bağımsız hale getirebildiği ölçüde Cloud servislerinden yararlanma oranı artacaktır. Servis Odaklı Mimari’nin kurum içerisindeki adaptasyonu/uygulanması belirleyicidir.
Üçüncü sernaryoda, kurum BT altyapısını tamamen Cloud üzerine aktrarır. Bu radikal senaryoda birinci ve ikinci senoryaları da uygulamak mümkündür. Bir ve ikinci seraryolar dışında kalan herşey Cloud üzerindeki sanal bilişim kaynaklarına aktarılır. Bir tür sanal veri merkezi oluşturmak söz konusudur.
Dördüncü senaryoda ise kurum verimliliğini artırmak maliyetlerini düşürmek için servis sağlayıcı mimarisini kendi veri merkezinde hayata geçirir. Bir ve ikinci senaryolar yine bu senaryo ile kombine edilebilir. Kurumlarının Cloud servislerinden hangi senaryoları kullanarak ve hangi oranda yararlanabilecekleri, kurum stratejisine ve kurum BT altyapısının esnekliğine bağlıdır. Bunun için bir tür Servis Odaklı Mimari olgunluk modeli oluşturulabilir!


3 – Tekil Sağlayıcılı Cloud Servisi: Bu senaryoda servis sağlayıcı tüm BT altyapısını, yani altyapı, uygulama platformu ve yazılım servislerini tek elden sunar. Google Apps ve Microsoft Office Live örnek olarak alınabilir(4).
4 – Çoğul Sağlayıcılı Cloud Servisi: Cloud Computing yaklaşımının ne kadar esnek olduğunu göstermesi açısından son derece ilginç olan bu senaryoda; servis aldığımız servis sağlayıcı servisini bir ya da daha çok servis sağlayıcının sunduğu servisler üzerine kurar. Örneğin; fotoğraf paylaşım servisi olan SmugMug veri saklama hizmetini Amazon S3 den almaktadır. Ama bu servisi kullanan tüketici yalnızca SmugMug ile muhattab olur, gerisinden haberi olmaz. 
5 – Servis Geliştirici:  Bu senaryoda servis geliştirici (bu kurum ya da birey olabilir) servis sağlayıcı tarafından sağlanan geliştirme ortamı ile belli servis sağlayıcı çalıştırma ortamı (runtime) için uygulamasını ya da servisi geliştirir. Yalnız bu uygulama/servis arka planda birden çok servis sağlayıcının sunduğu servis ya da altyapıyı kullanabilir. Örneğin; Google Apps Engine için geliştirme yapan bir geliştiriciyi düşünelim. Bu geliştiricinin büyük miktarda saklama alanına ve ilişkisel veritabanına ihtiyacı olduğunu varsayalım. Google Apps Engine bu gereksinimleri karşılayamaz ama Amazon S3 ve EC2 karşılayabilir. Sonuçta Google Apps Engine üzerinde çalışan uygulama/servis aynı zamanda Amazon servislerini de kullanıyor olur.
Daha farklı senaryoları da düşünmek mümkündür, örneğin Cloud servisleri arasında uygulama ve verinin taşınması. Bu tür senaryolara yeri geldikçe değinmeye, bazılarını detaylı olarak ele almaya çalışacağım. Bir sonraki yazıma veri saklama servislerine yakından bakıyor olacağım. Görüşmek üzere.

Kaynakça
1. http://sites.google.com/site/cloudarchitecture/">http://sites.google.com/site/cloudarchitecture/
2. Cloud Computing Use Cases White Paper, 31 Temmuz 2009
3. http://www.opencloudmanifesto.org/">http://www.opencloudmanifesto.org
4. Burton Group, Cloud Computing: Transforming IT, 20 Nisan 2009

YAZDIR