AWS üzerinde Fault Tolerant ve High Available Sistem Mimarisi
Merhaba herkese bu yazımız ile birlikte “AWS-Amazon Web Servislerini” kullanarak hata toleransı yüksek olan ve yüksek erişilebilir bir sistemi nasıl kurguladığımız konusunda küçük bir örnek çalışma paylaşmış olacağım. Bu senaryo “AWS Well- Achitected” demolarında sıkça kullanılan bir POC çalışması baz alınarak anlatılacaktır. “AWS Well- Achitected” ile ilgili genel bilgilendirmeyi offical sayfası üzerinden detaylı inceleyebilirsiniz.
Fault Tolerance ve High Availability nedir ?
Fault Tolerance : Türkçe karşılığı olarak “Hata Toleransı” olarak çevirebiliriz. Bir uygulamada, bölümlerden herhangi birinin çalışmamasına rağmen (herhangi bir nedenle çökmesi veya geç cevap vermesi) uygulamanın düzgün çalışmaya devam edebilme özelliğidir.
High Availability : Türkçe karşılığı olarak “Yüksek Erişebilirlik” olarak çevirebiliriz. Çalışmış olduğumuz uygulamalarımızı, servislerimizi birden fazla server üzerine yayarak, herhangi bir server üzerinde oluşabilecek hatadan dolayı , çalışan sistemin etkilenmemesi için kullanılmaktadır.
Yüksek Erişilebilir Uygulama Senaryosu
Senaryomuzu kısaca açıklamak gerekir ise bir wordpress haber-blog sitemiz olduğunu varsayalım. Web uygulamamızı artık bulut tabanlı teknolojiler üzerine taşımak istiyoruz. Bu taşıma sırasında yüksek erişilebilir ve hata toleransı yüksek olan bir mimari altyapı ile kurgulamak istiyoruz. Bu kısıma kadar bir çok çözüm üretilebilir fakat aynı zamanda uygulamamızın belirli viral dönemlerde darboğazları rahat atlatabilmesi , bir anda yoğunlaşan kullanıcı isteklerine çabuk yanıt verebilmesi, yüklenen resimlerin lokasyona göre belirli bölgelerden gösterilerek sitemizin hızlı çalışmasını istiyoruz. Aynı zamanda site ve veritabanı yedeklerimizin herhangi bir felaket senaryosu karşısında katlanılabilir seviyede olmasını ve güvenlik anlamında yeterli seviyede olmasını istiyoruz.
Çalışmanın temelini anlayabilmek adına https://cloudcraft.co sitesi üzerinden diagramını çıkardığım mimari yapıyı aşağıdaki resimden inceleyebilirsiniz.
Bu senaryomuzu “AWS Management Console” üzerinden oluşturmaya başlamadan önce işleyişini kısaca açıklamak gerekecektir. Kullanıcılar web sitemizi browserları üzerinden görüntülemek istediklerinde istek gönderdikleri URL adresine göre Amazonun DNS hizmeti ( AWS — Route53 ) üzerinden yönlendirmeye tabii tutulacaklardır. Yapılan istek “dış kullanıcı” adresi ise bir CDN ( AWS - CloudFront ) sunucusu üzerinden en yakın lokasyondaki ( AWS — S3 ) ile sakladığımız resimleri ve siteyi yükleyecek ya da bir “admin” adresi ise, amazon’un bir load balancer hizmetine ( AWS - ELB ) ulaşacak , belirlediğimiz kurallar doğrultusunda en uygun sunucu ( AWS- EC2 ) üzerinden uygulama kodlarını çalıştıracak ve ilişkisel veritabanlarından ( AWS -RDS MySQL ) gerekli verileri çekerek, sitemizi istedikleri doğrultuda kullanacaklar ve veri girişi yapabileceklerdir. Bu kısımdan sonra manuel olarak oluşturduğumuz dar boğazlar ve felaket senaryoları ile hata toleransı konusunda ne kadar yüksek erişilebilir bir sistem geliştirmiş olduğumuzu test edeceğiz.
AWS Servisleri ve Mimarisi
AWS üzerindeki kurgumuzu gerçekleştirirken kullandığımız servisleri kısaca aşağıda açıklamaya çalışacağım.
- Amazon VPC : Amazon Bulut ortamında size özel sanal veri merkezi oluşturmanızı sağlayacak network ayarlarınızı yapabiceğiniz servis hizmetidir.
- Amazon EC2 : Amazon Bulut ortamında istenen ölçekte ve adette sanal makine oluşturabilme imkanı veren bir servis hizmetidir.
- Amazon Simple Storage Service S3 : Internet’te her yerden, her boyutta veri almak ve depolamak için oluşturulmuş bir nesne depolama hizmetidir.
- Amazon RDS : Bulutta bir ilişkisel veritabanını kurmayı, çalıştırmayı ve ölçeklendirmeyi kolaylaştıran bir yönetilen hizmettir.
- Amazon Auto Scaling : Amazon üzerinde uygulama erişilebilirliğini korumanıza yardımcı olan ve EC2 bulut sunucularını tanımladığınız koşullara göre otomatik olarak eklemenize veya kaldırmanıza olanak tanıyan bir servis hizmetidir.
- Amazon CloudFront : Uygulamalarımız için hızlı, güvenli ve programlanabilir CDN (Content Delivery Network) hizmetidir.
- Amazon Route 53 : Yüksek oranda erişilebilir ve ölçeklenebilir bir bulut Etki Alanı Adı Sistemi (DNS) web hizmetidir.
- Amazon Elastic Load Balancing ELB : Gelen uygulama trafiğini otomatik olarak Amazon EC2 bulut sunucuları, container’lar, IP adresleri ve Lambda işlevleri gibi birden çok hedefe dağıtan bir servis hizmetidir.
AWS üzerinde daha bir çok ihtiyaca yönelik servis bulunmakta. Gerekli servisleri aşağıdaki link üzerinden daha detaylı inceleyebilirsiniz.
AWS Hizmet Bileşenlerini Oluşturma
Artık AWS konsolu üzerinde gerekli bileşenleri oluşturmaya başlayabiliriz. Aşağıda sırası ile bir çok bileşen oluşturucağız. Genellikle free tier içindeki hizmetleri tüketmeye çalışsak da bu demo üzerinde bazı kısımlarda kredilerimizden belirli miktarlar kullanacağız.
- S3 Bucket : Konsol üzerindeki “Services ” sekmesi üzerinden “Storage” başlığı altındaki S3 hizmetini seçerek işlemlerimizi başlatıyoruz.
Burada dikkat edilmesi gereken isim S3 başlığı altında açacağımız object tipinde dosyaları tutmamıza yarayan “Bucket” isimdeki yapıların hepsinini isimlendirmelerinde benzersiz bir değerler kullanılması gerektiğidir. Ben burada “srknbngl-code” ve “srknbngl-media” isimli 2 adet bucket oluşturuyorum.
Daha detaylı S3 bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- CloudFront : Konsol üzerindeki “Services ” sekmesi üzerinden “Network & Content Delivery” başlığı altındaki CloudFront hizmetini seçerek işlemlerimize devam ediyoruz.
Burada “Create Distribution” diyerek aslında AWS Bulut altyapısına ait bir çok bölgedeki data centerları kullanarak tüm dünya üzerinde lokasyon bazlı bir data center kümesi oluşturmuş oluyoruz.Bundan dolayı CloudFront servisi globalde çalışan bir hizmet olmaktadır. Herhangi bir regiona ait değildir. 2 çeşidi bulunmaktadır. Statik dosyaları lokasyon bazlı cachlemek için “Web” ayrıca lokasyon bazlı Adobe Flash Streaming yapabilmek adına “RTMP” kullanılmaktadır. Biz sitemizin imajlarını yayınlamak adına “Web” tipinde bir distribution kullanacağız
Distribution üzerinde S3 bucket içindeki resimleri cachelemek adına origin Domain name olarak önceden tanımladığımız “srknbngl-media” bucketını kullanıyoruz ve diğer ayarları pass geçerek CloudFront hizmetinin oluşmasını bellirli bir süre bekliyoruz.
Daha detaylı CloudFront bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- VPC ve Security Group: Konsol üzerindeki “Services ” sekmesi üzerinden “Network & Content Delivery” başlığı altındaki VPC hizmetini seçerek işlemlerimize devam ediyoruz.
VPC daha önce bahsettiğimiz tanımlar doğrultusunda kendimize ait bir sanal bulut ortamı oluşturmamıza olanak tanır. VPC içinde bulunan “Security Group” alanı ile , iç ve dış ağlar üzerinden bu ortamımıza hangi kurallar çerçevesinde ulaşılacağını belirleriz. Inbound ve Outbound kurallara göre gerekli kısıtlamalar ve izinleri belirlenir.
Burada 2 adet security group oluşturmak istedim. WebDMZ-SG dış networke açık bir alanı , RDS-SG ise iç network üzerinden ulaşılabilecek bir alanı göstermektedir. WebDMZ-SG için HTTP için IPv4 ve IPv6 için 80 portunu ayrıca SSH için 22 portunu dış networke açık hale getirecek kuralları tanımladık.
RDS-SG için ise MySQL portu olan 3306 portuna sadece WebDMZ-SG üzerinden gelen istekler için ulaşılabilecek şekilde kurallarımızı tanımladık.
Daha detaylı Security Group bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- RDS : Konsol üzerindeki “Services ” sekmesi üzerinden “Database” başlığı altındaki RDS hizmetini seçerek işlemlerimize devam ediyoruz.
Burada RDS hizmeti üzerinden MYSQL veritabanı seçip t2.micro free tiera ait bir EC2 tipi seçerek gerekli ayarlamaları yapıyoruz. Önemle dikkat edilmesi gereken bir durum yüksek erişilebilir bir mimari yapı için veritabanlarını “Multi-AZ” şekilde tasarlayarak felaket senaryolarına karşı önlemlerimizi almış olmamız gerekmektedir. Ayrıca RDS-SG security group içinde tutarak sadece bizim belirlediğimiz koşullara göre veritabanına ulaşım sağlanacaktır.
Bu ayarlamalardan sonra kalan ayarlamaları olduğu gibi bırakıyorum. Toplamda standar 8gb lık bir disk ile bu veritabanı barındırma ve ölçeklendirme işlemi bir maliyet doğurmaktadır. Dolayısı ile herhangi bi,r backup işlemi için extradan bir ayar gerçekleştirmiyoruz. Ve veri tabanımızı “Multi-AZ” yani bir felaket anında birebir aynı yedeği bulunur şekilde ayarlamış oluyoruz.
Daha detaylı RDS bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- IAM: Konsol üzerindeki “Security,Identity ve Compliance” sekmesi üzerinden “IAM” başlığı altındaki IAM hizmetini seçerek işlemlerimize devam ediyoruz.
IAM giriş sayfası içinde groups , users ve roles bileşenleri üzeinden gerekli ayarlamaları yapmadan önce AWS tarafından üzerinde çok sıkça ve önem verilerek durulan Security Status kısmındaki 5 maddeyi tamamlamış olmanız gerek konsole üzerinden gerekse AWS servisleri içinde kullanacağınız credentiallar için önem oluşturmaktadır.
Bu kısımda sunucu olarak kullanacağımız EC2 makinelerimizin oluşturmuş olduğumuz S3 Bucketlara güvenli şekilde ulaşması adına bir S3 üzerinde full yetkiye sahip role oluşturarak işlemlere devam ediyoruz. “Roles” alanı üzerinden EC2 servisini seçip gelen ekranda “Filter Policy” arama alanına S3 diyerek “AmazonS3FullAccess” yetkisini seçiyoruz ve kayıt işlemini gerçekleştirerek rolümüzü oluşturmuş oluyoruz.
Daha detaylı IAM bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- EC2 Instances Images: Konsol üzerindeki “Services ” sekmesi üzerinden “Compute” başlığı altındaki EC2 hizmetini seçerek işlemlerimize devam ediyoruz.
Karşımıza çıkan ekran üzerinden uygulamamızı yayınlamak adına bir free tier Linux EC2 oluştırmak adına “Launch Instance” diyerek “Amazon Linux 2 AMI” imajı seçiyoruz. Burada free tier için bize izin verilen t2 micro modelini seçerek ilgili imaj üzerinden EC2 instance’ imizin ayarlarını yapmaya başlıyoruz.
Burada dikkat edilmesi gereken il durum ayarlar içinden IAM role kısmında daha önceden S3 için oluşturduğumuz “Full Access” yetkisisnin verilmesi ve bu imaj üzerinden oluşturulacak tüm sunucularda gerekli hazırlıukların yapılması adına advanced details altındaki user data alanında bir bash scriptin çalıştırılması olmalıdır. Bu scripte bu link üzerinden ya da yazının sonundaki kaynak dosyaların linkleri üzerinden ulaşabilirsiniz. Kısaca scripten bahsetmek gerekirse her seferinde bu imaj üzerinden bir EC2 instance oluşturulurken linux üzerinde tüm updatelerin alınması, httpd php ve mysqllerin kurulması,wordpressin indirilmesi gerekli file izinlerinin cverilmesi ve httpd servisinin start edilmesini sağlamaya çalışıyoruz.
Daha sonrasında bu EC2 üzerinde block Storage olarak 8 gb lık standard SSD diski seçip, daha sonra bu instance üzerinden bazı farklı EC2lar oluşturacağımız için bu EC2 instancen’a “WpBaseImage” ismini vererek, dış networke açılarak bu makineye dışarıdan ulaşabilmek adına “WebDMZ-SG” security grubuna dahil ediyoruz, bu aşamada yada daha sonrasında oluşturabileceğimiz bir SSH key (Key Pair) ile güvenli bağlantıyı sağlamak için gerekli işlemleri yapıp bu key pairi downlad ediyoruz ve oluşan EC2 instance’ımızın çalıştığını konsol üzerinden takip edebiliyoruz.
Daha detaylı EC2 bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- Application Load Balancer : Konsol üzerindeki “Services ” sekmesi üzerinden “Compute” başlığı altındaki EC2 hizmetini seçerek işlemlerimize bir yük dengeleyici oluşturmak üzere devam ediyoruz.
Ulaştığımız ekranlar üzerinde create load balancer üzerinden 3 farklı bileşen kurabiliriz. Bu mimaride HTTP ve HTTPS isteklerini gerekli EC2 instancelarına yönlendirmek için “Application Load Balancer” türünde bir ELB hizmeti kullanıyoruz.
Gerekli configurasyonları yaparken kullandığımız VPC altındaki tüm AZ leri seçtiğimizden veload balancerin dış networke açık olmasını sağlamak adına WebDMZ-SG security group içine dahil ettiğimizden emin olarak “Routing” ayarlarına geçiyoruz.
Routing ayarları ile birlikte burada hangi bileşenler üzerine yönlendirme yapabileceğimizi belirlemek adına bir hedef grubu yani “Target Group” belirlememiz gerekiyor. İsimlendirmezi yapıp burada EC2 instancelarımız üzerindeki healthy.html olarak oluşturduğumuz dosyalara göre eldeki kaynakların ulaşılabilirlik bilgisini kontrol edip bir sorun varsa buna göre bir yönlendirme yapacağımızı ve bu kontrolün ne aralıklarla yapılması gerektiğini belirliyoruz. Sonrasında “Register Target” alanı ile bu EC2 instance ‘ı load balancera register ederek ulaşılabilirlik durumuna göre yönlendirme işlemini hangi instancelar üzerinde yapabileceğini belirtiyoruz.
Gerekli işlemleri tamamlıyarak ilgili yük dengeleyicimizide oluşturarak ileride kullanmak adına mimari tasarım içine dahil etmiş oluyoruz.
Daha detaylı ELB bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
- Domain Oluşturma ve Route 53 : Konsol üzerindeki “Services ” sekmesi üzerinden “Network & Content Delivery” başlığı altındaki Route 53 hizmetini seçerek işlemlerimize devam ediyoruz.
Bu hizmeti kullanmak tamamen tercih meselesidir. Burada ben sitemizi yayınlayacak bir domain adı olmadığını var sayarak gerekli işlemleri yapıyorum.Sitemizi yayınlamak adına srknbngl.com domain alan adını register ederek gerekli kayıt işlemini tamamlıyorum. Route 53 üstündeki “Domain Registration” alanı ile gerekli işlemleri yönlendirmelere göre tamamlıyorum.
Gerekli işlemler tamamlandıktan sonra ilgili domainin kayıt altına alınmasını onaylamak adına mailimize gelen onayı tamamlıyoruz ve işlemin tamamlandığına dair bize gelecek olan bildirmi bekliyoruz.Bu bekleme süresi 3 güne kadar sürebilmekte fakat genellikle 1–2 saat içinde tamamlanmış olmaktadır. Aşağıdaki resimden tamamladndığında hizmetin durumunu takip edebileceğiniz ekranı inceleyebilirsiniz.
Daha detaylı Route 53 bilgileri için yukarıda servislerin tanıtımları içinde vermiş olduğum linkler üzerinden gerekli araştırmalarınızı yapabilirsiniz.
AWS management console üzerinden temel kullanacağımız servisleri oluşturma işlemlerini tamamladıktan sonra tekrar bu ekranlara geri döneceğimizi belirterek oluşan linux makinamız üzerinde bazı ayarlamaları yapıp wordpress tabanlı sitemizi oluşturmaya başlayabiliriz.
Wordpress Sitesi Konfigürasyonları ve CloudFront-Route 53-DNS ve Load Blancer Ayarları
Burada indirmiş olduğumuz .pem uzantılı key pair dosyasını kullanarak lokal makinemizden güvenli bağlantı ile 52.18.232.217 ip’li EC2 Linux instance’ına ulaşabiliyoruz. Burada hemen admin yetkisi ile “$ sudo su” kullanarak “var/www/html” klasörü altında wordpress yapısının kurulup kurulmadığını kontrol ediyoruz. Ayrıca .htaccess dosyasını kontrol edip ne olur ne olmaz diye httpd servisimizi “$ service httpd start” ile çalıştırıp “$ service httpd status” komutu ile kontrol etmiş oluyoruz.
Browser üzerinden 52.18.232.217 adresine ulaştığımızda wordpress kurulum sayfasına ulaşmış bulunmaktayız. Burada bizden istenilen bilgileri olabildiğince basit tuttum fakt production ortamlarında her türlü güvenlik riskini kapatbilmek adına daha kompleks parametreler belirlemek daha doğru olacaktır. Önemli bir husus ise wordpressin veritabanını oluşturmuş olduğumuz RDS veri tabanına bağlamak için amazon konsol üzerinden ilgili RDS connection end pointini biliyor olmamız ve veri tabanı yolu olarak bu adresi kullanıyor olmamız hususunda olacaktır.
İlgili işlemi tamamladıktan sonra bir sonraki adımda WP kurulumu bizi wp-config.php dosyasını bulamadığı ile ilgili bir bildirim ile karşılayacaktır. Burada bize verilen içeriği kopyalayıp, EC2 instance’ına bağlanarak html klasörü altında bir wp-config.php dosyasını oluşturup içine kopyaladığımız içeriği yapıştırarak gerekli konfigurasyon dosyasını oluşturuyoruz.
Daha sonra browser üzerinden devam ederek wordpress uygulaması yönetim paneli için admin bilgilerimizi oluşturup kurulumu tamamlıyoruz. “52.18.232.217/wp-admin” adresi üzerinden yönetim paneline ulaşabilmekteyiz.
Aşağıdaki video üzerinden ilk postumuzu oluşturduğumuzu ve yayına alabildiğimizi takip edebilirsiniz.
Burada yüklediğimiz resmin sisteme kayıt olduğunu EC2 üzerinden wp-content/uploads/2019/07 klasöründen takip edebilmekteyiz.
İlgili EC2 makinası AWS CLI kurulu olarak geldiği için AWS CLI komutlarını burada kullanıp bu EC2 içinde uploads klasöründeki içerikleri oluşturduğumuz “srknbngl-media” s3 bucketina tüm wordpress kodlarını ise “srknbngl-code” s3 bucketine yedekleme işlemlerini yapacağız. Bu işlemler için “aws s3 cp — recursive [EC2 klasör yolu] [s3 bucket Yolu]” komutunu kullanmamız gerekmektedir. Sonrasında “aws s3 ls [s3 bucket Yolu]” komutu ile ilgili s3 içeriğini terminal üzerinden kontrol edebilmekteyiz. S3 bucketlarımızı görmek adına “aws s3 ls” komutunu kullanabiliriz.
Aktarmış olduğumuz bu resimleri CloudFront servisini kullanarak lokasyon bazlı cachelemek ve kullanmak adına EC2 instance üzerinde bulunan html kalörü içindeki .htaccess dosyasında bir UrlRewrite işlemi gerçekleştirmemiz gerekmektedir. Burada ilgili dosyayı vim editör kullanarak açıp ”wp-content/uploads/(.*)” uzantısındaki tüm dosyaların oluşturmuş olduğumuz CloudFront domain name üzerinden yayınlanmasını sağlamak adına gerekli değişikliği yapıyoruz.
Bu değişikliğin uygulanabilmesi adına öncelikli olarak EC2 instance üzerinde /etc/httpd/conf klasörü altındaki “httpd.conf” dosyasının bir yedeğini “cp httpd.conf httpd-backup.conf” komutu ile httpd-backup adı altında oluşturuyorum. Daha sonra httpd.conf dosyasını vim editör ile açarak “AllowOverride None” kısmını “AllowOverride All” olarak güncelliyoruz ve kayıt işlemini gerçekleştirip vim editörümüzden çıkıyoruz.
Burada S3 baucket oluşurken sadece içeride kullanılmak üzere açıldığı için ve biz CloudFront hizmeti kullanarak tüm edge lokasyonlarından bu bucketa ulaşılmasını istediğimiz için gerekli ayarlamaları yapmaya başlıyoruz. Amazon konsolu üzerinden S3 servisindeki “srknbngl-media” bucketimiza giderek permission sekmesi altındali tüm blockları kaldırıyoruz.
Aynı zamanda permission sekmesi altında bu bucket için bir getObject policy yazmamız için “Bucket Policy” sekmesinde editörü kullanarak ilgili tanımlamaları JSON formatında yapıyoruz. Bucket policy kullanımı ile ilgili detaylı bilgiye bu link üzerinden ulaşabiliriz. Ayrıca ilgili kod bloğuna bu link üzerinden ya da yazının sonundaki kaynak dosyaların linkleri üzerinden ulaşabilirsiniz.Burada dikkat edilmesi gereken husus ilgili kod bloğu içinde resources alanına yukarıda bize verilen ARN linkinin karşılığı yazılmasıdır.
Artık tüm işlemler bittikten sonra ( CloudFront yapılandırılması ve S3 bucket’in public hale getirilmesi işlemi ) sitemize upload edilen resimlerin CloudFront üzerinden bize en yakın edge lokayon üzerinden cachlenerek hızlı yüklenmesini test edebiliriz. Bunun için aşağıdaki video üzerinden gerekli işlemleri takip edebilirsiniz.
Sitemizi yayınlamak istediğimiz domain (srknbngl.com) adresi register olduktan sonra DNS management ayarları üzerinden gerekli işlemleri yapmaya başlıyoruz.
Burada “Hosted Zones” alanı altında bulunan srknbngl.com adresi için record set oluşturuyoruz. Bu record set için oluşturmuş olduğumuz application load balancerı “Alias Target” olarak tanımlayıp routing policy simple tipini seçiyoruz. Burada simple seçmemizin nedeni herhangi bir yüzde dağılımı , yada gelen url kontrolü olmadığı için.Daha detaylı bir ayarlama yapmak istiyorsak bu link üzerinden routing policyleri inceleyebilirsiniz.
Srknbngl.com üzerine gelen istekleri application load balancerımız üzerine yönlendirdiğimize göre load balancer üzerinde gerekli EC2 ayarlamalarını yapmaya başlayabiliriz. Load balancer alanı içindeki target groups içinde ( WpEC2Instances ) ilgili EC2 instance’ımızı ( WpBaseInstance ) register ederek status durumu “healthy” durumuna gelene kadar bekliyoruz. Burada bildiğiniz üzere load balancer kurgusunu yaparken health checkleri ELB üzerinden yapacağımızı daha önce belirtmiştik.
Artık srknbngl.com adresi yönlendirmesi, load balancer ve EC2 registration işlemleri tamamlandığına göre yönlendirme işlemini test edebiliriz.Aşağıdaki video üzerinden bu işlemi takip edebilirsiniz.
Genel olarak dns, cdn, load balancer, EC2, RDS gibi AWS hizmetlerini birbirleri ile entegre ederek wordpress sitemizi ayaklandırmayı başardık. Artık yazımızın ana konusu olan yüksek erişilebilirlik ve hataya toleransı gibi kavramları sistemimize dahil ederek mimari tasarımı tamamlamak üzere bir sonraki adıma başlayabiliriz.
Wordpress Site İçin Fault Tolerance Mimarisi , Esneklik ve Ölçeklendirilebilirlik Ayarları
Bu kısım içinde wordpress sitemizin herhangi bir felaket durumu senaryosu içinde hata toleransı yüksek ve yüksek erişilebilir bir durumda olmasını sağlamaya çalışacağız. Burada herhangi bir EC2 makinemiz kullanılamaz duruma geldiği takdirde , veritabanımız ulaşılamaz durumda olduğundan yada Amazonun hizmetini kullandığımız herhangi bir AZ bölgesinde sorun yaşandığı takdirde sistemimizin hala çalışır olması , resimlerin ve statik içeriklerin her an için yedeklenebilir olması yeni ayağa kalkan makinelerde bu içeriklerin hazır olarak bulunması gibi kavramları halletmeye çalışacağız. Ayrıca kullanıcıların yapmak istediği işlemlere göre farklı EC2 makinelerine farklı URL ler üzerinden ulaşmalarını sağlıyacağız ve veri kaydetme ve veri yayınlama sunucularını birbirinden izole hale getirmiş olacağız.
Sistemi görsel olarak hazırlamış olduğum aşağıdaki diagram üzerinden takip etmek gerekir ise kullanıcı yetkisine göre veri kaydetmek isteyen kullanıcılar 52.18.232.217 makinesi üzerinden Write EC2 makinesi olan makinaya ulaşacak ve buraya girmiş olduğu tüm veriler kısa süreli periyotlar ile S3 bucketa (PUSH) yedeklenecek . Siteyi görüntülemek isteyen kullanıcılar ise srknbngl.com adresi üzerinden bir load balancer aracılığı ile birkaç node şeklinde çalışan bir grup ( fleet ) Read EC2 makinesine ulaşacak. Bu makineler herhangi bir felaket durumu için ayağa kalker iken ve belirli periyodlar halinde S3 bucket üzerinden tüm verileri kendi üzerlerinde bulunan klasör alanı üzerine ( PULL ) çekeceklerdir. Burada URL üzerinde makine yönlendirme işlemini AWS Route 53 ile yapacağız.
Öncelik olarak daha önceki EC2 makinemiz üzerinde bir cron job çalıştırmak adına etc klasörü içinde crontab servisini vim editör aracılığı ile açıyoruz ve burada her 1 dakika periyotlar ile çalışması ve “srknbngl-code” isimli S3 bucket üzerindeki verileri kendi içinde bulunan html klasörüne çekmesi için “*/1 * * * * root aws s3 sync — delete s3://srknbngl-code /var/www/html” satırını yazıp bu EC2 makinesi içine S3 üzerindeki wordpress sitesi uygulama kodlarımızı çekmeyi amaçlıyoruz.İşlem gerçekleştikten sonra cron servisini yeniden başlatarak jobun süre geçmeden çalışmasını sağlıyoruz.
Bu işlemin nasıl çalıştığını aşağıdaki video üzerinden takip edebilirsiniz. Burada S3 servisi üzerinden srknbngl-code bucket üzerine bir deneme dosyası ekliyoruz ve EC2 makinesi üzerinde cron job sayesinde bu dosyanın S3 üzerinden pull edilerek oluştuğunu görebilmekteyiz.
Şimdiki adımımızda daha önceki oluşturduğumuz EC2 instance üzerinden ölçeklendirilebilirlik adına her daim kullanılacak ve çöken Read Nodelarımız için bir temel imaj oluşturacak EC2 AMI oluşturma işlemini gerçekleştiriyoruz.Bunun için EC2 servisi altında bulunan instances alanından WpBaseImage instanceni seçip “Actions” altından Image ve Create Image diyerek bir WpReadNode isimli yemi AMI oluşturuyoruz.
Bu işlem gerçekleşirken EC2 makinemiz üzerindeki SSH bağlantıkmızın koptuğunu göreceksiniz. Çünkü bu işlem sırasında ilgili EC2 instance durdurulup tekrardan başlatılıyor.İşlem bittikten sonra WpReadNode imajımızın oluştuğunu konsol üzerinden “available” durumda olarak görebiliriz.
Burada artık hem read node hem write node oluşturacağımız için 52.18.232.217 EC2 makinesini write node olarak adminlerin kullanımına sınarak sadece veri girişleri için kullanmak istiyorum. Bunun için tekrardan SSh bağlantısı ile makineye ulaşıp crontab servisini güncellemem gerekiyor. Çünkü artık burada bu makineye girilen tüm veriler S3 üzerindeki srknbngl-media ve srknbngl-code isimli bucketlara yedeklenecek. Bu işlem için vim editör üzerinden crontab açarak eski kod satırını silip onun yerine “*/1 * * * * root aws s3 sync — delete /var/www/html s3://srknbngl-code ” ve “*/1 * * * * root aws s3 sync — delete /var/www/html/wp-content/uploads s3://srknbngl-media” kod satırlarını ekliyorum. Bu sayede hem uygulama kodları hem de yüklenen resimler gerekli S3 bucketlara push edilerek yedekleme işlemi sağlanacaktır. Ayrıca bu işlemi test etmek adına EC2 makinesi üzerinde “test_2.txt” uzantılı bir dosya oluşturup dosyanın S3 üzerinde oluştuğunu kontrol ediyorum.
Writer node için gerekli işlemleri yaptıktan sonra Read Nodelarımız için ölçeklendirilebilir yapı adına AWS Auto Scaling Group oluşturmaya başlayabiliriz.Bir auto scaling group oluştururken ilk önce launch configuration oluşturmak için gerekli yönlendirmeleri takip ediyoruz ve oluşturduğumuz reader AMI üzerinden t2.micro tipinde bir Instance oluşturuyoruz.
Configure details kısmında EC2 her oluşturulurken S3 üzerinden gerekli yedekleri çekebilsin diye IAM role olarak S3 full access rolü için oluşturduğumuz S3ForWordPress rolünü tanımlıyoruz ve user data kısmında updateleri yapmak adına ve yedekleri çekmek adına bu link üzerinden ulaşabileceğiniz bash scripti yazıyoruz. Standart 8 GB bir gp1 ssd seçerek i Security group olarak WebDMZ-SG seçerek makinelerein dış networklere açık olmasını sağlıyoruz ve ilgili instance ssh bağlantısını oluşturmak için .pem uzantılı keypair dosyamızı indiriyoruz.Launch configuration ayarlarımızı bu şekilde tamamlamış oluyoruz.
Launch Configuration için gerekli ayarlamaları yaptıktan sonra Auto Scaling Grubu oluşturma işlemimize her seferinde 2 adet instance üzerinde çalışcak şekilde ve 3 avalibity zone kullanılacak şekilde yapıp tüm health check işlemleri ELB ile birlikte 1 er dakikalık periyotlar olacak şekilde konfigure ediyoruz.
Sonrasında default ayarları ve yönlendirmeleri izleyerek Auto Scaling grubunu oluşturuyoruz.Aşağıdaki ekranlardan bu yönlendirmeleri takip edebilirsiniz.
Load balancer üzerinde WpEC2Instances target group altında daha öceden tek node ile çalıştığımız için hala registered target olarak Write node’ muz bulunmakta. ELB üzerinde Auto Scaling için Target Group değişikliği yapmak durumundayız. Dolayısı ile bu target group içinde write node ‘u çıkarıp yeni oluşturmuş olduğumuz 2 adet read nodu ekliyoruz.
Aşağıdaki ilk video üzerinden öncelikli olarak EC2 makinemizin uploads klasörünü kontrol ediyoruz. burada sadece adet cloudwars.jpg resmi olduğunu görmekteyiz. Sonra Route 53 üzerinden gerekli yönlendirmeler yapılmış mı onu test etmek amaçlı srknbngl.com adresi uzerinden reader nodelara ulaştığımızı fakat srknbngl.com/wp-admin.php sayfasına yani yönetim paneline ulaşmak istediğimizde 52.18.232.17/wp-admin adresine yönlendirildiğimizi görmekteyiz. Burada bir post olışturma işlemini yaptığımızda ve resim eklediğimizde ilgili postun oluştuğunu , writer node olan EC2 üzerindeki uploads klasörü içinde oluştuğunu ve S3 tarafında srknbngl-media bucket üzerinde yedeklendiğini gördük. Fkat burada post üzerindeki resim bizler için bir kırık resim linki gibi gözükmekte bunun nedeni CloudFront Tarafında herhangi bir cacheleme işleminin henüz yapılmadığı ve istek gönderildikten sonra edge lokasyon bazlı CloudFront cacheleme işleminin s3 bucket tarafında yapılacağı doğrultusundadır.
Aşağıdaki 2. videoda ise belirli bir süre sonra srknbngl.com adresine bir istek gönderildiğinde CloudFront tarafında gerekli cacheleme işleminin yapılması nedeni ile resimlerin artık yayına alındığını görebilmekteyiz.
Artık tüm gerekli ayarlamaları yaptığımıza göre bir felaket senaryosu testi yapabiliriz.
Felaket Senaryosu ve Yüksek Erişilebilirlik Test Senaryosu
ilk senaryomuzda amazon servislerini kullandığımız bir availability zone üzerinde sanki bir sorun oluştuğunu gösterebileceğimiz şekilde bir reader nodumuzu terminate ediyoruz ve CDN, Route53, ELB ve Auto Scaling Group bileşenlerinin işlerini nasıl yerine getirdiklerini takip ediyoruz. Olmasını istediğimiz senaryo tek node kalmasına rağmen resimlerin hala CloudFront üzerinden yayınlanması, ELB nin sağlıklı çalışan EC2 instance’ına gerekli yönlendirmeyi yapması ve terminate olan makinenin yerine auto scale group ve launch configuration üzerinden yeni bir sunucunun ayağa kaldırılması yönünde olacaktır.
İkinci senaryomuzda ise Multi AZ olarak tasarladığımız RDSlerin birinin failover olması durumunda sitemizin en kısa sürede tekrardan gerekli verileri kullanarak yayına dönebilmesi üzerine olacaktır. Burada RDS üzerinden bir reboot işlemi yaparken bunu failover kullanarak yapmasını sağlayarak gerçekleştireceğiz.
SONUÇ
Uzun süren bir konfigurasyon ve entegrasyon sürecinden sonra AWS üzerinde yüksek erişilebilir bir mimari tasarımı gerçekleştirmiş bulunmaktayız. Umarım faydalı bir yazı olmuştur. Yakın zamanda birkaç serilik bir webinar ile bu mimariyi canlı olarak sizler ile birlikte oluşturuyor olacağız. Bir dahaki yazıda görüşmek dileği ile.
