AWS serisi : AWS Lambda ile “Serverless Architectures” – Sunucusuz çok katmanlı uygulama mimarisi.
May 18, 2016 yazilimgunlugu2 CommentsAWS, Cloud/Bulut
Genelde AWS(amazon web services) bulut yapısının git gide etki ve kullanım alanını artırması ve özelde bu yazının konusu olan AWS Lambda servisinin 2014 de yayınlandığı tarihden itibaren “çok ciddi kullanım” oranlarına ulaşması ve “ciddi anlamda başarılı” örneklerin artmasıyla birlikte muhtemelen sizinde çok ca duymaya başladığınız ;
“Serverless Architectures” yada genel olarak “Sunucusuz uygulama mimarisi”
diye türkçeye çevirebileceğimiz kavramı AWS Lambda alt yapısı ile genel olarak tanımaya çalışacağız.
“Serverless Architectures / Sunucusuz Mimariler” konusunu teorik olarak çok konuşmadan pratikde AWS Lamda ile tanımaya çalışacağımız bu yazıda, aşağıdaki konulara beraberce bakarak AWS Lamda yı tanıyalım.
Yazının genel başlıklarını şu şekilde sıralayabiliriz;
Genel olarak Serverless Multi-Tier Architectures – Sunucusuz mimari nedir?
AWS Lambda nedir?
Genel Olarak, AWS Lambda ile “Serverless Architectures” in bize getirdiği kazanımlar nelerdir?
AWS Console üzerinde Lambdaya Bakış
Örnek geliştirme ortamı ve yardımcı araçlar
AWS Lambda alternatifleri (IBM OpenWhisk , Azure Functions ve Google Cloud Functions)
Serverless Architectures – Sunucusuz mimari nedir?
Sunucumuzun tüm hatlarıyla gizli kaldığı, bize sadece run-time/çalışma zamanı alt yapısının gözükdüğü ( .NET, Node.js Java vs. gibi. Bunlarıda kurmak yada yönetmek zorunluluğumuzun olmadığı) etki tepki diyebileceğimiz (event / handler) bir yapı ile, belirli şartlarlada çalışacak fonksiyonları yazmamıza imkan veren yapıya genel olarak Serverless Architechure / Sunucusuz Mimari diyebiliriz.
Buradaki en önemli nokta, “bir event/olayın gerçekleşmesi ile çalışacak fonksiyonlar” kısmı diyebiliriz. Böylece tüm bir uygulamayı host etmek yerine, sadece iligli iş yükünü yerine getirecek fonksiyonlar yazma imkanımızın olması bize ciddi kazanımlar ve kolaylıklar getirmekte. Aşağıdaki örnek senaryoya bakarak devam edelim;
Kullanıcımızın bir formu doldurması gereken bir senaryomuz olsun;
Kullanıcı, ilgili formu talep eder (yada biz kullanıcıdan doldurmasını isteriz.)
Bu ilk olayımız için, bir fonksiyonumuz çalışır, kullanıcıya formu sunar
Kullanıcı formu doldurur ve gönder tuşuna basar
Bu olayımız için , yazdığımız diğer fonksiyonumuz, formu alır ve DB ye kaydeder
DB ye kaydolan her form girdisi için “otomatik çalışmasını ” istediğimiz diğer fonksiyon otomatik olarak tetiklenir
Otomatik olarak tetiklenen fonksiyon, db den bu girdiyi alır ve örneğin “ilgili departmana” email yollar
Aynı zamanda formu dolduran kullancıyada onay e-maili yollar
Yukarıdaki senaryoda dikkat ettiyseniz, aşağıdaki kavramlardan hiç biri yok;
Runtime yada framework kurulumu.(.NET/MVC yada Node/Express gibi)
Sunucu ayarlama, konfigürasyon, ölçeklendirme vs. gibi çetrefilli işler yok
Fonksiyonlarımız için “çalışmadıkları sürece” sistem kaynakları için ücret ödeme durumumuz yok. (teknik olarak, bir server olsada ve bu server sürekli RAM ve işlemci kullanımı yapsada, biz sadece fonksiyonlarımızın çalışmaları durumun da bu kaynakları kullanmış sayılacagız.)
Gördüğünüz gibi yaşam döngüleri çok basit bir yapıda, bir olay olur yada siz tetiklersiniz bir fonksiyon çalışır ve gerekli iş yükü yerine getirilir. Arada “bizim yazdığımız yada yönettiğimiz” bir middleware, server yada application layer katmanı bulunmaz. Genel olarak hepsi bu diyebiliriz.
Daha şematik ve tarihi gelişim açısından ve Cloud/bulut bilişim içndeki yerini anlamak adına aşağıdaki resime bakarak devam edecek olursak;
IAAS(Sanallaştırılmış donanım), PAAS (Uygulama yada run-time), serverless (sunucusuz mimari) şeklinde bir süreçten geçtiğimizi söyleyebiliriz.
Data Centre (Fiziki sunucu kiralama) : En klasik ve bilinen yol. Bir data centre içinde bir sunucu kiralama. Bu yöntemle, kabaca “Fiziki network alt yapısı ile olan ilişkimizi” soyutlamıştık. Ama donanım(kısmen soyutlanmış) , işletim sistemi, çalışan run-time lar ve uygulamalar soyutlanmamış ve ölçeklenme birimi olarak hala hardware in baz alındığı yapı.
IAAS (Infrastructure as a Service) ilk donanım bazlı soyutlamaya geçtiğimiz nokta. hem network, hem donanım ın sanallaştırıldığı alt yapılar.
PAAS (Platform-as-a-Service) Sanallaştırmanın bir sonraki noktası Uygulama bazında ölçeklendirme. İşletim sistemininde soyutlandığı yapı.
Serverless , sadece çalışacak fonksiyonların yazıldığı, yukarıdakilere ek oalrak “run-time” ın da soyutlandığı yeni mimari.
Aws altında sunulan Lambda servisi, genel olarak sunucular, büyük frameworkler , uygulama alt yapısı vs gibi konularla uğraşmak yerine (bunları AWS bizim için otomatik olarak yapacak) iş yükümüz için gerekli işlemleri yerine getirecek “fonksiyonlar” yazmamıza imkan veren bir alt yapı sunmakta.
Execute your code to response an event. and it does fast, it scales millions parallel of your functions
Yazacağımız fonksiyonların belirli şartlar altında otomatik olarak çalışmasını sağlayıp , uygulamamızın iş ve mantık yükünü bu fonksiyonlarla çözmemize imkan veren bu alt yapı sayesinde, sadece kod yazarak(kurulumlara, frameworklere, uygulamanın ölçeklendirilmesine vs. zaman harcamadan) uygulamamızı geliştirme imkanına kavuşmuş olmaktayız.
Başka bir deyişle, uygulamamızda “event-based / etki-tepki” diyebileceğimiz bir döngü ile, her olay için otomatik tetiklenecek yada kendi kendimize çağırabileceğimiz fonksiyonlar yazacağız. Bu fonksiyonlar işlerini yapacak , bizde sadece fonksiyonları yazmaya yani “tek bir sorunu çözmeye” ve “tek bir şeyle uğraşamaya(kodlama)” odaklanabileceğiz. Başta “ölçeklenebilirlik / Scaling” olmak üzere bir çok “zor kısım” bizim için AWS Lambda serivisi tarafından otomatik olarak karşılanacak.
Fonksiyonlar yazacağımız için, uygulamalarımızı istersek iç içe geçmiş mikro servis benzeri bir yapı ile isterseniz bir birlerinden tamamen bağımsız tekil iş üniteleri olarak yazma imkanımız da söz konusu. Ayrıca, uygulamamızın sadece bir kısmını yada bir kısım iş yükünü Lambdaya taşıma imkanınıda kullanabiliriz. Buradaki en önemli nokta olarak ;
İş yükünü alt parçalara “otomatikleştirerek” atamak veya dilerseniz uygulamanızı tamamını yada uygulamanın ana iş yükü dışındaki herşeyi bu şekilde fonksiyonlara taşımak diyebiliriz.
Bu arada son günlerde çokca duyulan “Micro Services” kavramyla Lambda yı karıştırmamak lazım. Biri (Micros Services) Bir tasarım yada uygulama geliştirme düzenini/yaklaşımını ifade ederken, Lambda servisinin kendisi “Micro service ” ler de oluşturabileceğiniz bir iş kanalı yada başka bir değişle pratikde karşılığı olan , sorun çözme birimleri diyebiliriz. Lambda ile fonksiyonlarımızı, Micro Service mimariye uygun olarak da yapılandırabileceğimiz gibi, hiç bir tasarım kalıbına uymayacak şekilde sadece “fonksiyonlar ” olarakda kullanabilmekteyiz.
AWS Lambdanın getirdiği en önemli kolaylıklardan biride şüpesiz AWS üzerindeki diğer servislerle çok kolay bir entegrasyon imkanı diyebiliriz. Örneğin, S3 ye yüklediğiniz her dosyadan sonra otomatik olarak çalışacak fonksiyonlar yazıp, yüklenen her dosyayı otomatik olarak bir işleme tabi tutmaktan tutunda, DynamoDB ye eklenen bir kayıttan sonra otamatik bir başka işlem yapmaya kadar çok geniş bir yelpazede bir entegrasyon imkanı vermekte.
Bir başka avantajda, her bir fonksiyon hem “stateless-durum takipsiz” hemde “izole” olduğu için otomatik olarak ihtiyaca göre kendi kendisini ölçekleyebilmesi diyebiliriz.
Maliyet/Tasarruf: Şüphesiz ilk akla geleni maliyet adına bize kazandırdıkları, Pay-Per-Use Pricing – Kullanım başına ödeme diyebiliriz. Yukarıda kısaca bahsetmeye çalıştım tekrar edecek olursak, sunucunun RAM ve İşlemci kullanımına göre ödeme yaptığımız modelden, sadece foksiyonlarınız çalıştığı zaman ücret ödeme modeline geçmiş olacağız.
Operasyon Kolaylığı: Lambda fonksiyonları stateless ve izole oldukları için istediğiniz gibi organize etme kolaylığı sunmaktalar. Örneğin monolithic(tüm bir uygulama), microservices, yada nanoservices gibi bir çok “süslü” tasarım kalıbıyla çalışmaya uygunlar. Yada hiç birini kullanmayıp, yaz ve çalıştır kolaylığına. Ayrıca Yönetecek, server vb. bir alt yapı da olmadığı için çok daha hızlı bir geliştirme süreci sunmaktalar.
AWS Lambda yazdığımız kodların ihtiyacı olan alt yapıyı bizim yerimize oluşturacak, bakım, güncelleme, güvenlik yamaları, dahili loglama vs bir çok ihtiyacı bizim yerimize gerçekleştirecek.
Ölçeklenebilirlik ve Kararlılık: Aws lambda ihtiyaç duyulması durumunda otomatik olarak kendi kendini ölçeklendirme yeteneğine sahip. Bu yapı syesinde, en az fonksyion çalışma sayısından, günde 1 milyon kere çalışan çok yoğun kullanımlı bir fonksiyona kadar ihtiyacınız ne ise ona göre kendi kendini trafiğe/yoğunluğa adapte edecektir.
Lambda, dahili olarak “high availability / yüksek erişilebilirlik” ve “ built-in fault tolerance / hata-çökme telafi edicisi ” dediğimiz ve genel olarak AWS in en önemli iki artısı olan yapı ile kararlı bir sisteme sahip olma imkanı vermekte. Örneğin, siz kodunuzu “x” bölgesinde ki “y” data center da bulunan bir bilgisayara yüklediğinizde, AWS Lambda otomatik olarak farklı noktalarda sizin için “her hangi bir sorun olması halinde” çalışacak kopyalarını hazır tutacaktır. Bir servis kullanılamaz olursa hemen diğeri çlaışmaya başlayacaktır.
Dahili Güvenlik Sistemi: AWS Identity and Access Management (IAM) sayesinde, diğer AWS servisleri ile iletişimi güvenli bir şekilde yönetmek ve hemen hemen diğer her ihtiyaca cevap verecek bir alt yapı sunmakta.
Yukarıdaki listeye başka maddelerde ekleyebiliriz şüphesiz ama bukadarı yeterli deyip, AWS Lambda yı nasıl kullanabileceğimize geçelelim.
Lambda servisini , diğer AWS servisleri gibi AWS Console üzerinden yada AWS CLI ile kendi bilgisayarımızdan(komut satırından yönetebilmekteyiz.) Öncelikle ilk ve daha kolay alternatif olan AWS Console ile başlayalım.
Tüm AWS servislerini yönetebileceğimiz ve bir yönüyle “AWS yönetici paneli” diyebileceğimiz web arayüzü olan “AWS Console” üzerinden Lamdaya bakarak devam edelim;
AWS console üzerinde, “Compute” bölümü altında bulabileceğimiz Lambda servisini çalıştırdığımızda aşağıdakine benzer bir görüntüyle karşılaşmaktayız;
Bu ekranda bizim için AWS Lambda servisi tarafından önceden hazırlanmış kullanmaya hazır “template” diyebileceğimiz bir çok Lambda Function örneği mevcut. Bu templatelerden birini seçecerek hemen fonksiyonumuzu yazmaya başlayabileceğimiz gibi, sıfırdan kendi fonksiyonlarımızı yazmakda mümkün. Şimdilik “microservice http-endpoint” template ini seçelim ve devam edelim.
İsmindende anlaşılacağı gibi, bu template “http-endpoint” bize yazdığımız fonksiyonu bir http end point olarak çalıştırma imkanı vermekte. Başka bir değişle, bir URL ile tetikleme yapmamıza imkanı vermekte.
Sonraki ekranda, fonksiyonumuzu yazıp bazı ayarlamaları yapabileceğimiz aşağıdaki ekranla karşılacağız;
Bu ekran biraz büyük olduğu için iki parça olarak üzerinde konuşalım. Yukarıdaki ilk kısımda, Fonksiyonumuz için bir isim , açıklama, Runtime, fonksiyonu yazım şeklimiz ve son olarak fonksiyonumuzun kendisi gelmekte.
isim ve açıklama kısmı ile lambda fonksiyonumuza bir isim ve dilersek bir açıklama veriyoruz
Runtime seçimi (bizim örneğimizde, Node.js, dolayısıyla Javscript ile yazacağımızı belirtiyoruz)
Code entry type ile fonksiyonu inline mı (hemen bu ekranda) yazacağız, yada önceden yazdığımız bir fonksiyonumu yükleyeceğiz onu belirtiyoruz.
inline : fonksiyonu hemen bu ekranda yazmak için kullanacağımız seçenek. Bu seçeneğin bir dez avantajı eğer fonksiyonunuz büyükse veya kodu yazarken daha fazla editör desteği istiyorsanız(Visual studio veya Webstorm gibi yetenekli bir editör ile yazmak gibi) inline yerine diğer seçenekleri düşünebilirsiniz. Birde, eğer fonksiyonunuz AWS servislerinin dışında başka SDK ler yada NPM paketlerine ihtiyaç duyuyorsa, inline editör bunları eklemenize izin vermemekte.
Upload zip ve Upload file from S3 ise inline seçeneğinin ihtiyacınızı karşılayamadığı durumlarda kullanılacak iki seçenek. Örneğin fonksiyonlarınızı kendi bilgisayarınızda yazıp, ihtiyacı olan diğer sdk ler paket vs i ekleyip Lamdaya yükleyebilmek gibi.
Lambda Function Code ise tahmin edebilecğeiniz gibi, fonksiyonumuzun kendisini temsil etmekte.
Ekranın ikinci kısmı ise şu şekilde bir görnüme sahip;
Bu kısımda, fonksiyonumuzun nelere(hangi AWS servislerine) erişebileceğine dair güvenlik ve yetki ayarlamasını yapabileceğimiz bir kısım (Role) ve eğer fonksiyonumuzda, birden fazla `entry point`export.* varsa hangisinin çalışacağını beliritiyoruz. (bu kısım biraz node.js e özel, örnekde daha iyi anlaşılacaktır.) Diğer önemli iki kısım ise , fonksiyonumuzun ne kadar RAM kullanacabileceğini seçeceğimiz alan(Memory) ve Azami çalışma süresini ayarlayabileceğimiz “Timeout” kısmı gelmekte. Bir örnek yazacağımız için, burada daha fazla detaya girmeden next ile bir sonraki ekrana geçelim;
Biz fonksiyonumuzu oluştururken http-endpoint template ini seçtğimiz için, bir sonraki ekranımızda, Configure endpoints seçeneklerini göreceğiz. Kısacası bu Lambda Function, bir url i çağırmamızla tetiklenecek. Örnek de bu kısımı daha rahat anlaşılacaktır.
Şimdilik varsayılan ayarları kabul edip devam edelim ve fonksiyonumuzuz hazır hale getirelim. Bir sonraki ekranımız özet ekranımız olacak; Bu ekranda Create Function butonu ile işlemimizi tamamladıktan sonra fonksiyonumuz çalışmaya hazır hale gelecek ve aşağıdaki ekranla karşılaşacağız;
Fonksiyonumuz oluşturuldu ve kullanıma hazır, ” API endpoint URL” altındaki adres ise bizim için oluşturulan tetikleme adresimiz. Bu ekran üzerinden fonksiyonumuzu yönetebileceğiz (düzenleme, silme, raporlama vs.).
Buraya kadar genel olarak Lambda Function oluşturma süreci için gerekli olan adımlara baktık.(Lambda Console kullanarak) Şimdilik fonksiyonumuz herhangi bir şey yapmamakta.
Bir sonraki yazı ile gerçekten çalışan bir kaç örnek yapalım. Örneklerimizden biri API end point olarak çalışsın diğeri ise Otomatik olarak harekete geçsin. Birini Console üzerinden yazalım, diğerinide kendi bilgisayarımızda yazıp Lambda ya yükleyelim.
Bir sonraki yazıda görüşmek üzre.
Sunucusuz uygulamalar dünyasına hoşgeldiniz
Architechure, aws, Azure Functions, lambda, Serverless
Node.js ile Uygulama Geliştirme – 6 : REST Mimarisi ve RESTful Servisler Geliştirme [Sequelize, SQL ve veri modellerimiz]
Meteor.js Serisi : [Ara yazı] Bir Meteor Uygulamasının Temel Parçaları
2 thoughts on “AWS serisi : AWS Lambda ile “Serverless Architectures” – Sunucusuz çok katmanlı uygulama mimarisi.”
Metin Kocamış says:
Elinize sağlık, örnekleri içeren yazıyı ne zaman yayınlarsınız tahminen?
Teşekkürler. İnş hafta sonu örnekleri içeren yazıyıda ekleyeceğim.