AWS Elastic Beanstalk ile Web Application Kurulumu 2

There are lots of documentation(blog posts etc.) about AWS in English that’s why I have been writing in Turkish. I hope this will be informative for Turkish readers.
Regards.

Merhaba,

Yazımın ilk bölümünde; relational database servisi olarak MySQL yapılandırmasını,Elastic Beanstalk ile wordpress web uygulamamızın ilk sürümünün kurulumunu tamamlamıştık. Geldiğimiz noktayı aşağıdaki şekilde ifade edebiliriz.

  • Ziyaretçi web adresini Internet Browser ile açmaya çalışır
  • DNS sağlayıcısı, web adresinin ip adresine yönledirme yapar(AWS Elastic IP)
  • Elastic Load Balancer, listener’a gelen talebi içeride çalışan sağlıklı instance’a aktarır
  • Sağlıklı instance’ın kaynakları yetersiz kaldığında üretilecek alarm’dan dolayı auto-scaling devreye girerek VPC içine yeni bir instance açar. Mevcut instance ve yeni açılacak instance’lar Elastic Block Storage’de tutulurlar
  • Sistem yatay olarak(horizontal) genişleme eğilimindedir.(auto-scaling)
  • Horizontal genişleme için web application’ın stateless mimaride çalışması gerekir.

WordPress web uygulaması Elastic Beanstalk ile kurulurken en az bir instance açılır. Yapılan tüm konfigürasyon bu instance üzerinde tutulmaktadır. Auto-scaling’den dolayı ortama yeni instance’lar eklenirse ve/veya yine auto-scaling’den dolayı mevcut instance terminate edilirse yapılandırma kaybolur.

Auto-scaling ile birden çok sunuculu sistemin avantajından faydalanmak için web server’ların stateless mimaride çalışması gerekir. Varsayılan yapılandırması ile wordpress, kullanıcıların upload ettiği veriyi(image vb.) lokal dosya sisteminde saklar. Dolayısıyla bu açıdan stateless değildir. Yazının ilerleyen aşamalarında static content(image,javascript dosyaları,style sheet vb.)’in AWS S3 üzerinde tutulması ve CloudFront ile hizmete açılmasından bahsediyor olacağım.

Veritabanı perspektifinden yaklaştığımızda; veritabanı yükünün yoğun olduğu ortamlar için okuma ağırlıklı iş yükünün optimize edilmesi ve geçikmenin düşmesi için kullanabileceğiniz bir başka servisten, AWS ElastiCache’den, bahsedeceğim.

Bu aşamaya kadar bir kaç farklı servisten bahsetmiş oldum.

  • Cloudfront
  • ElastiCache
  • S3 (static content’in için kullanacağımız amazon web servisi)

Elastic Beanstalk ile önceki yazımda tamamladığım wordpress uygulaması kurulumu üstteki sistemle entegre etmek için W3 Total Cache plugin’i kullanılıyor. Yazının sonuna geldimde bahsettiğim entegrasyonu sağlamış ve web application’ı stateless mimaride çalıştırmış olacağız.

ElastiCache yapılandırması ile başlayayım.ElastiCache’e genel bakış için kaynaklar kısmında youtube adresi paylaştım.AWS’nin blog’unda yaınlanmış başarı bir anlatım!

ElastiCache istenen bilgiyi daha hızlı olan in-memory cache’den alan, disk tabanlı veritabanı sisteminden veri almaya göre web uygulamasının performansını arttıran amazon web servisidir. Yapılandırılması genel olarak aşağıdaki gibidir. Bu yazımda Memcached cluster ile ilerliyorum.

ElastiCache Cluster kurulumuna geçmeden önce Subnet Group yapılandırınız. ElastiCache Cluster kurulumunda subnet group seçmeniz gerekiyor.ElastiCache cluster ve detaylarının yapılandırılması için aşağıdaki menüden giriş yapıyoruz.

clip_image001[4]

Subnet group için aşağıdaki adımlar ile devam edebilirisiniz.

clip_image003[4]

Cache Subnet Group detayları üstteki gibidir. İçinde çalıştığınız VPC’deki subnet’lere bağlı kalarak availability zone’ları seçiyorsunuz. Ardından cluster kurulumuna geçelim.

clip_image005[4]

Memcached seçimi ile devam ediyorum.

clip_image006[4]

Cluster ismini belirledim. Sayıca iki adet cluster node olacak. Node type kısmında seçtiğim instance type’ına dikkat ediniz. Free Tier usage kapsamından çıkmış oldum. Yani bu elasticache cluster’ı çalıştırdığım sürece ücret ödeyeceğim 🙂

clip_image007[4]

Daha önce yapılandırmış olduğum security group’u seçtim. Bu grupta inbound yönde tcp 11211 portu izinlidir.

clip_image008[4]

ElastiCache Memcached Cluster hazırlandı. Detayları üstteki gibidir.Nodes linkine tıklarsanız cluster node’larınızı görebilirsiniz. O node’ların isimleri(web url) ileride w3 total cache plugin’ini yapılandırırken kullanılacak!

ElastiCache Cluster yapılandırması tamamlandı. CloudFront servisinin yapılandırması ile devam edeceğim. Amazon CloudFront içerik dağıtım servisidir.Diğer amazon servisleri ile entegre çalışır, içeriğin son kullanıcıya düşük geçikme ve yüksek aktarım hızı ile dağıtılmasını sağlar. CloudFront; AWS EC2,S3,ELB,Route 53 servisleri ile optimize şekilde çalışır. Yazımda Route 53 servisini kullanmadım. Godaddy DNS yönetim konsolundan faydalandım.

clip_image010[4]

CloudFront için bir distribution(dağıtım noktası diyebiliriz) oluşturuyorum. Bu konsole’da yaptığınız değişikliklerin geçerli hale gelmesi en az 15 dakika sürüyor! Distribution oluşturuken origin kısmına ElasticBeanstalk web adresini ve Elastic Load Balancer adresini yazdım. Daha sonra S3 bucket’ın web adresini yazacağım.

clip_image012[4]

AWS whitepaper’ları arasında bu konuyu ele alan güzel dokumlar var. CloudFront distribution’ın detayları için oradaki dokumanları inceleyebilirsiniz. Kaynaklar kısmında paylaştım.

ELB: awseb-e-w-AWSEBLoa-1JSXNRZEV7RIA-1259909768.eu-west-1.elb.amazonaws.com

Elastic Beanstalk: barisbeansappwp-env.elasticbeanstalk.com

clip_image014[4]

Oluşturduğunuz distribution’ın özelliklerinden cache behavior ekliyorsunuz. CloudFront belirlediğiniz pattern’leri belirlediğiniz origin ile eşleştiriyor. CloudFront distribution’ının oluşturulup devreye girmesi 15+ dakika sürecektir. Ardından CloudFront domain ismi ile wordpress uygulamanıza erişebilirsiniz.Önceki yazımda bıraktığım noktaya gelmiş oldum 🙂

Artık wordpress’i yapılandıralım/kuralım.

clip_image016[4]

Yetkili kullanıcı ismi,parola vb. bilgileri belirleyerek kurulumu tamamlayınız.

clip_image017[4]

WordPress admin paneline giriş yapalım ve w3 total cache plugin’ini kurup yapılandıralım. W3 total cache plugin’i ile S3,ElastiCache,CloudFront entegrasyonu yapacağımızı belirtmiştim. Özetle stateless web uygulaması mimarisini sağlamış olacağız.

Öncelikle wordpress web sitemizin URL’ini değiştirelim. URL’i cloudfront domain name ile değiştirdim.

clip_image019[4]

Web site url’ini daha sonra değiştirebilirsiniz. W3 total cache plugin’ini yüklüyoruz.

clip_image020[4]

Plugin’in ayarlarından gerekli işlemleri yapaıyoruz. Database cache özelliğini devreye alıyoruz.

clip_image022[4]

Aşağıdaki kısmından da görüleceği üzere memcached cluster node’larının isimlerini ilgili kutucuğa yazıyoruz. Hatırlarsanız iki node’lu cluster kurmuştum.

clip_image024[4]

clip_image025[4]

Content Delivery Network’ü devreye alıyoruz.

clip_image026[4]

CDN type olarak Amazon CloudFront seçtim.CloudFront distribution’ını daha önce yapılandırmıştım! Static content’ın barınacağı yeri yapılandırma aşamasına geldik. Static content S3 üzerinde barınacak. S3 üzerinde barınacak bu içerik için bir bucket açmıştım. Bucket’ın ismi bcakova001 ’dir. Bucket’a erişim için AWS IAM user belirlemiştim. User’ın Access key ID’sinin bir kısmı aşağıda görünüyor.User’a ait Secret key ise ikinci kutudadır.

clip_image028[4]

Bucket’a erişim için cloudfront domain ismini ayarladım. W3 total cache plugin’inde yaptığınız her işlemden sonra “save” etmeyi unutmayınız. Plugin’in özelliğini kullanarak ilgili içeriği S3’e export ediniz.

clip_image030[4]

Theme file için export işlemini üstte görüldüğü üzere geçrekleştirdim.S3 üzerinde açtığınız bucket’ın içine baktığınızda plugin ile export ettiğiniz content’i görebilirsiniz.

clip_image031[4]

Theme klasörü wp-content içinde olduğu için ayrıca bir klasör şeklinde görünmüyor. Bu yapılandırmadan beklentimiz şudur:

  • CloudFront’a gelen static content talebi S3(Simple Storage Service)’deki bucket’a aktarılsın.
  • Web sitesinde tıklanan image’lar S3’teki bucket’tan alınsın,upload edilen image’lar S3’teki bucket’a aktarılsın.
  • Tabii ElastiCache’in(in-memory cache’den dolayı) performans artımı sağlayacağını da hatırlatmakta fayda var.

Bu amaca yönelik son bir işlem kaldı 🙂 CloudFront’daki distribution’a bir adet origin ve cache behavior eklemek!

Yapılandırmalar aşağıdaki gibidir.

clip_image033[4]

Eklediğim Cache behavior’lar üstteki gibidir.

clip_image035[4]

Eklediğim origin(bcakova001.s3.amazonwa.com) de üstteki gibidir. CloudFront distribution’ının doğru ayarlanması konusunda bazı denemeler yapmanız yada bir kaç dokuman incelemeniz gerekebilir.

Topolojik ve mimari açıdan geldiğimiz nokta aşağıdaki gibidir.

clip_image036[4]

Üstteki şemada görülen servislerden route 53 dışındakileri kullanmış olduk. wp-content/* ve wp-include/* içerikleri S3’te barınıyor.Upload edilen içeriğin bir kısmı aşağıdaki gibidir.

clip_image037[4]

wp-admin/* , wp-login.php , default(*) pattern’ları ile eşleşen içerik ELB’den geçerek AWS EC2 instance’larında(web tier’a) barınacak. Web uygulaması yapısı stateless hale geldiği için auto-scaling’den de faydalanmış oluyoruz.

WordPress admin panelinde w3 total cache plugin’inde bazı değişiklik yaptık. Bu değişiklikler henüz sadece çalışmakta olan EC2 instance’ında(sanal sunucusunda) mevcut. Auto-Scaling sistemi yeni bir sunucu açtığı zaman bu değişiklikler o sunucuya aktarılmayacak. Çünkü değişiklikleri içeren wordpress dosyalarını yeni sürüm şeklinde Elastic Beanstalk ile update/deploy etmedim. Elastic Beanstalk’da önceki yazımda deploy ettiğim sürüm mevcut!

WinSCP yazılımı ile çalışan EC2 instance’ına bağlanarak aşağıdaki dosyaları ve klasörleri local sisteminize aktarınız. Zip dosyası şeklinde paketleyiniz.

clip_image038[4]

Paketlediğiniz dosyayı Elastic Beanstalk ile sisteme yükleyiniz.

Dosya, sisteme yüklendikten sonra web uygulamanızın yeni değişikleri içeren ikinci sürümü çalışmaya başlamış oldu 🙂 Dolayısıyla auto-scaling’den dolayı yeni açılacak instance’larda bu ayarlar geçerli olacak.Elastic Beanstalk kontrol panelinden gerekli hallerde web application’ın önceki sürümlerine geri dönebilirsiniz.Sürümler aşağıdaki gibidir.

clip_image040[4]

Şu an çalışan sürüm bilgisi aşağıdaki gibidir.

clip_image041[4]

Auto-scaling’i test etmek için çalışan instance’a stress testi uygulamıştım. Aşağıda görüldüğü üzere iki adet yeni instance açıldı. Daha sonra yük azaldığı için biri kapanıyor. Daha sonra diğeri de kapanacak. “desired state” olan bir instance çalışmaya devam edecek. Kaynak yetersizliği anında bu döngü devam edecek.

clip_image043[4]

Yapılandırdığımız EC2, ElastiCache, CloudFront, Elastic Beanstalk, Elastic Load Balancer servislerinin gözlemi için Amazon Cloudwatch servisini kullanarabilirsiniz. Bu ve bir önceki yazımı göz önüne aldığımda AWS bulutunda; elasticache,cloudfront ve elastic beanstalk ile stateless web application konfigürasyonunu test ederek bir eğlenceli bir proje yapmış olduk. İncelemek isteyenler için aws whitepaper’ları arasında bu ve buna benzer bir çok uygulama örneği mevcut.

Herkese sorunsuz ve neşeli günler dilerim.

Kaynaklar:

http://aws.amazon.com/whitepapers/

http://www.cyberciti.biz/faq/stress-test-linux-unix-server-with-stress-ng/

https://www.youtube.com/watch?v=8eD2eNljURE

http://www.memcached.org

http://aws.amazon.com/cloudfront

http://aws.amazon.com/elasticache

http://www.cyberciti.biz/faq/mysql-command-to-show-list-of-databases-on-server

https://www.pantz.org/software/mysql/mysqlcommands.html

http://aws.amazon.com/elasticbeanstalk/

Leave a Reply

Your email address will not be published. Required fields are marked *