AWS App Runner — Fully Managed Container Service
AWS’in servis ailesine yeni katılan üyesi AWS App Runner’dan bahsedeceğimiz bu yazıda;
- ilgili bu servis ile birlikte potansiyel kullanım alanları,
- “fully managed” tabirinin ne anlama geldiği ve bu servisin ne kadar “managed” olduğu,
- App Runner ile birlikte kullanılan diğer servisler (ECR, Route53, Certificate Manager)
- Serverless bir servis mi, değil mi ve neye ne zaman Serverless diyoruz gibi konuları,
- son olarak tabii ki uçtan uca kurulum.
Öncelikle belirtmekte fayda var; App Runner servisinin CloudFormation desteği henüz bulunmadığından ötürü herhangi bir IaC framework’üyle -AWS CDK, Terraform vb.- geliştirme yapamıyoruz. Bu sebeple ilgili kurulumları AWS Console üzerinden gerçekleştireceğiz.
İkincil olarak da, bu servisin hangi bölgelerde desteklendiğini belirtelim.
* Europe (Ireland)
* Asia Pacific (Tokyo)
* US East (N. Virginia)
* US East (Ohio)
* US West (Oregon)
Bu demektir ki eğer siz “Europe (Frankfurt)” bölgesinde AWS hizmetinizi kullanıyorsanız, AWS App Runner kullanımı için yukarıda listelenen herhangi bir bölgeyi seçerek, servisi bu bölge üzerinde kullanabilirsiniz. Servis kullanımı tüm bölgelerde aktif olduğunda yazı tekrardan güncellenecektir. Biz bu yazıda Europe (Ireland) bölgesini kullanacağız.
Kullanım Alanları
Her container servisinde olduğu gibi, AWS App Runner’ı da backend microservis uygulamaları, web uygulamaları gibi amaçlar için kullanmamız mümkün.
App Runner servisi minimum 1 vCPU ve 2 GB RAM, maksimum ise 2 vCPU 4 GB RAM’de çalışabildiğini de belirtelim. Bu demektir ki çok büyük ve oldukça fazla bağımlılığı bulunan backend servisleri -yani monolith- uygulamalar için kullanımı uygun değildir.
Microservice gözüyle bakacak olursak da, günümüzde microservice olarak lanse edilen fakat birer küçük monolithçikler olan uygulamalar için de kullanımı uygun değildir. Bu uygulamalar da oldukça fazla CPU ve RAM tüketimi yapacaktır. Bu uygun olup olmama durumunu da fiyat/performans/fayda olarak göz önünde bulundurabilirsiniz.
Yukarıdaki iki maddenin dışında kalan tüm lightweight uygulamalar için kullanımı uygundur. Aslında tam burada, AWS Lambda’nın, fonkiyon olarak değil de container olarak sunulmuş hali dersek yanlış bir tabir kullanmış olmayız. — Serverless spoiler :) -
Fully Managed — 1
Geliştiriciler olarak en sevdiğimiz kavramlardan birisi şüphesiz ki “fully managed” kavramıdır. Şimdi bu fully managed sistemlerden konuştuğumuzda anladığımız şeye bakalım; bağımsız, kendi kendine yetebilen ve tamamen servis sağlayıcısının -burada AWS- kontrolünde olan sistemler.
Bizim yerimize bir şeyler yapan bir sistem! Tam otomatize, kontrolsüz, ayarsız, şıkır şıkır. Şimdiden gözlerimiz kamaştı.
Ücretlendirme Molası
Herhangi bir şeyi yönetmek zorunda olmamak güzel, fakat yine de biri veya bir şeyler tarafından yönetiliyor olduğunu bilmemiz gerekiyor. Bu durumda yönetici sisteme de tabii ki çalıştığı süre boyunca ekstra ücret ödememiz gerekiyor.
Bu ekstra ücretlerin içerisinde;
* automatic build ve deploy,
* automatic scaling
* kullanımın basit, anlaşılır ve kolay olması
gibi maddeler bulunmakta. Bu yönleriyle belki AWS ailesinde bulunan diğer container servisleri olan EKS/ECS’e göre daha maliyetli bir fatura ile karşılaşabiliriz. Size uygun kullanım senaryosu ve fiyat/fayda dengesini kurduğunuz taktirde bunlar sizi üzmeyecek rakamlar olacaktır.
AWS’in fiyat polikalarına aşina olanlarımız bilecektir, servis ücretleri ilgili servisin çıkısından sonraki her zaman aşağı doğru bir grafik çizer. Bu da ilerleyen dönemde, yönetme ihtiyacımızın olmadığı, oldukça performanslı ve ciddi anlamda ucuz bir servis hizmeti almamıza olanak sağlayacaktır. Ücretlendirme kısmını böylesine çok yeni bir servis için daha da detaylandıramayacağım. Kullandıkça öğrenilecek bir durum olarak görebiliriz.
Fully Managed — 2
Asıl konumuza dönecek ve bağlayacak olursak; AWS App Runner, uygulamanızın herhangi bir özelliğini ya da yeni bir versiyonunu test etmek, herhangi bir uygulama PoC’inizi (proof of concept) denemek, geliştirmek; büyük ölçekli dağıtık mimarinizin tüm deployment/scaling konularını hiç düşünmeden rahatça hareket edebilmeniz için yaratılmış “fully managed” yani yönetimin kendisi bir servis :)
Birlikte Kullanımda Olan Servisler
App Runner’ın fully managed olması beraberindeki servis kullanımlarını kısıtlamıyor. Aksine birtakım servislere özel olarak ayaralama ihtiyacımız var. Bunların başında ise servisimizi hazır bir Docker Image üzerinden kullanmak istersek ECR servisini kullanmamız mecburi.
Bununla birlikte, hazır imaj kullanmak yerine Github bağlantısı gerçekleştirerek, içerisinde Dockerfile bile bulunmayan bir repository’miz üzerinden App Runner uygulamımızı yayına alabiliyoruz.
Servisimizin deploy işlemi bittikten sonra, aynı şekilde CloudFront ve API Gateway servislerindeki olduğu gibi otomatik olarak bir domain ataması gerçekleşiyor. İster bu domain üzerinden, istersek custom domain tanımlaması yaparak servisimize anlamlı bir domain ismi atayabiliyor ve yönetebiliyoruz. Bunun için ise Certificate Manager ve Route53 servislerinin kullanımı zorunlu.
Serverless mı değil mi?
Her zaman söylediğimiz gibi, eğer bir servis veya bir sistem üzerinde çalışıyorsanız ve bu servis hizmeti için makina tipi seçimi yapıyorsanız o servis Serverless değildir.
AWS App Runner servisinde herhangi bir makina tipi seçimi bulunmaması, bu servisi Serverless kategorisine alabileceğimiz anlamına geliyor. Bununla beraber, App Runner servisini hiç kullanmadığımız zaman ödeme yapmaya devam etmemizden dolayı diğer Serverless kategorisindeki servislerin “kullandığın kadar öde” özelliğiyle önemli bir eksiklik olarak ayrılıyor.
AWS App Runner içerisinde, EC2 servisinde olduğu gibi bir “Stop action” -durdurma aksiyonu- bulunmakta ve sistem atıl hale alınıp, atıl makina fiyatları üzerinden ücretlendirilmekteyiz.
Bildiğimiz üzere AWS’in aynı şekilde Serverless container çözümü olarak ECS Fargate kullanımı mevcut. Fakat bu servisi kurmak, yönetmek ve sürdürülebilir bir sistem elde etmek için oldukça fazla geliştirme maliyeti ve bakım maliyeti gerekmekte.
AWS App Runner’ı da şu anki bilgimiz dahilinde Serverless container servisi olarak konumlandırabilir, “fully managed” olması sebebiyle kurulum ya da karışık konfigürasyonlar gerektirmeden kullanıma hazır hale getirebiliriz. Yazının en başında belirttiğimiz gibi AWS Lambda, Serverless function as a service bir servis konumundayken AWS App Runner burada Serverless container as a service konumunda yer alıyor. AWS Fargate’e ise Serverless container service diyebiliriz.
Managed ile managed olmayan (tam karşılığını bulamadım) herhangi iki servis arasındaki tek farkı “as a service” ibaresini gördüğümüz yerde ayırabiliriz.
Kurulum
Öncelikle yazının başında belirttiğimiz gibi AWS Console üzerinden Europe (Ireland) bölgesine geçiş yapıyoruz. Daha sonrasında search bar üzerinden App Runner servisini aratarak ilgili servise ulaşım sağlayabiliriz.
İlk defa servis yaratıyorsanız önünüze gelen ekrandaki “Create an App Runner service” butonuyla birlikte servis yaratma işlemine geçebiliriz. Aşağıdaki görselde servisin şu anki kullanım ücretleri de yer alıyor.
Kaynak ve Deployment Stratejisini Belirleme
Bu kısımda yazıda bahsettiğimiz gibi hazır bir Docker imajınız mevcut ise ECR servisi üzerinden bu imajı seçerek ya da “Source code repository” seçeneğiyle Github bağlantısı yaparak devam edebilirsiniz. İmajınız ECR üzerindeyse, deployment yapmak istediğiniz servis için ECR’daki ilgili repository’e erişip buradaki imajı alabilecek bir IAM rolünü “ECR access role” kısmında belirtmeniz gerekmekte.
Deployment ayarlarında ise Manuel ve Automatic olmak üzere iki seçeneğimiz bulunuyor. Manuel seçimde, servisimizin deployment’ını konsol üzerinden tetikleyerek, Automatic seçeneğinde ise Github için belirlemiş olduğunuz repository ve branch’e göre her push aksiyonu geldiğinde otomatik olarak deployment işlemi gerçekleştirmiş olacaksınız.
Build Konfigürasyonu
Bu kısımda ise servisimizin ne şekilde build edileceği hakkındaki bilgileri giriyoruz. Github kaynağınızda Dockerfile dosyasına ihtiyaç duymadan, AWS belirlemiş olduğunuz build komutlarına göre otomatik olarak kaynak kodu Dockerize edecek ve sonrasında “Start command” kısmındaki komut ile birlikte uygulamamızı başlatacaktır.
Managed bir servis olması sebebiyle Github kaynağı üzerinden kullandığımız servislerde Runtime olarak şu an için sadece Nodejs 12 ve Python 3 bulunmakta. ECR kullanımı yaparak custom runtime belirleyebilirsiniz.
Birden fazla build komutu kullanmak için, komutlar arası iki and operatörüyle “&&” birlikte istediğiniz kadar komut girebilirsiniz.
Uygulama portumuzu da belirttikten sonra bir sonraki ekrana geçiş yapabiliriz.
Servis Konfigürasyonu
Bu kısımda servimizin genel memory/cpu, scaling kurallarını ve uygulama ortam değişkenlerimizi belirliyoruz.
Burada maksimum concurrency limitimiz instance başına 200 request olacak şekilde ayarlanabiliyor. Aynı şekilde instance sayısını da minimum ve maksimumda en düşük değer olarak 1 atayabiliyoruz. Bu da servisimizin “sürekli olarak” ayakta ve koşuyor olması anlamına geliyor.
Bununla beraber servisimizi yarattıktan sonra herhangi bir zamanda, servis listemizden ilgili servisi seçerek “Stop” aksiyonuyla birlikte bu servisin çalışması durdurulabiliyor.
Health Check & Security
Bu kısımda ise servisimizin health check kurallarını ve eğer servis içerisinde herhangi bir başka AWS servisine erişim sağlayıp, işlem yapacak isek AWS IAM rolü atayarak bu işlemleri de opsiyonel gerçekleştirebiliyoruz.
Bu ekrandan sonra servisimiz yaratılmış olarak listemizde sunulacaktır.
Bahsettiğimiz gibi bir default domain ataması gerçekleşti ve bu domain ile API’ımız kullanıma hazır duruma geldi.
Bu aşamadan sonra ilgili servisin “Custom domains” sekmesinden özel bir domain belirleyebilirsiniz. Bunun için bulunduğunuz region (bölge) üzerinde Certificate Manager‘dan almış olduğunuz bir SSL sertifikanızın olması ve Route53’ye ilgili CNAME kayıtlarını yapmış olmanız gerekmekte.
Ekstralar
Servis içirerisinde Activity, Logs, Configration, Metrics ve Custom domains sekmeleri bulunmakta. Bu komponentlerle servisinizin üzerindeki herhangi bir aksiyonu monitör edebilir ve yönetebilirsiniz. Metrics kısmında ise detaylı olarak servis üzerindeki “request count” ve 4xx, 5xx, 2xx vb. HTTP kodlarının dağılım grafiği gösterilmekte.
Umarım keyifle okuyup, herhangi bir yönetim ihtiyacı duymadan kendi backend servisinizi ya da web uygulamanızı çok kısa bir süre içerisinde yayına alabilmişsinizdir.
Bir sonraki yazılarda görüşmek üzere!
