Hibrit Bulut Dönüşümü — AWS & Azure

Bundan yaklaşık 6 ay kadar önce bir karar verdik.

Bulut hizmetleri sağlayıcıları arasında gelişen ve artan rekabetin getirdiği yeni fırsatlar üzerinden kendimize bir vazife çıkardık. Böylece, Amazon AWS hizmetlerini uzun zamandır tüketen Otelz.com olarak altyapımızın kritik bileşenleri ile çeşitli türden iş yüklerinin (RDS, Kubernetes, Redis, PostgreSQL vb.) önemli bir kısmının Microsoft Azure ’a taşınacağı “hybrid cloud” çözüm ve dönüşüm projesini hayata geçirdik.

İyi sonuçlar aldığımız bu dönüşüm projesinde;
Tecrübe ettiğimiz kritik aşamaları, veri tabanı ve iş yüklerini, kesinti optimizasyonunu, çeşitli senaryolar ile performans ve yük testlerini nasıl yerine getirdiğimizden bahsetmeye çalışacağım.

Bu tip dönüşüm projelerinde tercih edilen enstrümanlar, yöntemler ve ürünler çeşitlilik gösterebilir. AWS’ nin ve Azure’ un sunduğu ve sunamadığı (limitations) servisler ile teknik ürün özelliklerinin bu dönüşüm projesinin metot ve yöntemlerinde belirleyici rol oynadıklarını hatırlatarak başlamak isterim.

Bir altyapının taşınabilir (portability) olması en az kod taşınabilirliği kadar mühim bir prensip. Büyük kümeler halinde çalışan servisler ve uygulamalar; Docker ve Kubernetes gibi bulut uyumlu — “Cloud Native” çözümler, “Helm & Charts”, “Container Registry” ve “Infrastructure as Code” gibi yardımcı özellikler ile genişletildiğinde taşınabilirlik seçeneklerinin bir hayli genişlediğini elbette söylemek mümkün.

Tabii gerek iç gerekse dış ağ DNS kayıtlarının da taşınabilir ve yönetiliyor olması esnekliğe bir seviye daha katkı sağlayabiliyor. Örneğin yönetilen servislerinizi (SQL, Redis, PostgreSQL vb.) de bulut ağınızda (VPC | VNET) “private” DNS ile yapılandırdığınızda (redis.productz.net, postgresql.productz.net vb.) konforlu bir kurulum — taşınma süreci elde etmiş oluyorsunuz. Böylece kod tabanınız da doğal olarak bu konfigürasyonlar ya da ortam değişkenlerine uyumlu hale gelmiş oluyor.

Veri Tabanı (Database)

En önemli bileşen — bağımlılık olmasından ötürü veri tabanı ile başlamayı uygun buldum.

Amazon Relational Database Service (RDS — SQL Server) bulut istikametine doğru birçok seçenek sunarken aksi yöndeki (EC2, on-premises, VM vb.) kısıtlar, izinler, yedekleme (full | differential | point-in-time recovery) kaynaklı tercihler veri katmanın aktarımında uygulayacağımız yöntemin belirlenmesinde kritik rol oynadı. Yedek alınıp dosya aktarımı ve “restore” süresi kadar uzunca kesinti yaşatacak senaryo yerine güvenli, tekrarlı test ve daha az kesinti imkanı sunabilen seçeneği şöyle detaylandıralım.

AWS DMS (Data Migration Service) ile iş yüklerinin oluşturduğu işlemlerin tamamını depolayan tabloları bir nevi replikasyon yöntemi diyebileceğimiz tanımlamalar ile EC2' da ayaklandırılmış yeni bir SQL Server örneğine gerçek zamanlı ve devamlı (ongoing) aktarımını sağladık. Yüzlerce tablo için elbette bu süreci otomatize eden IaC (Infrastructure as Code) araçlarından ve “bash” den bir hayli fayda sağladığımızı söyleyebilirim. DMS sayesinde basit şekilde konfigüre edilebilen kaynak ve hedef sistemler arasındaki veri senkronizasyonunu, şeffaf bir şekilde izleyebilir ayrıca panelden kritik log kayıtlarına göre aksiyon alabilirsiniz. Biz de tam olarak bu yolu izledik.

DMS ile AWS EC2' da konumlu tüm özellikleri ile aktif bir SQL Server örneğine tutarlı ve devamlı veri akışı sağlamayı başardık. İşte bu SQL Server örneğindeki veri tabanlarını Azure Link Feature (https://docs.microsoft.com/en-us/azure/azure-sql/managed-instance/managed-instance-link-feature-overview?view=azuresql) özelliğini kullanarak bir nevi iki bulut sağlayıcısı arasında veri tabanlarımızı “Always-On” çalışma şekline kavuşturduk. SSMS üzerinden bir eklenti olarak sunulan bu özellik geçişin hayati — “mission critical” kısmını sırtladığını gönül rahatlığıyla söyleyebilirim. Tabii geçiş tarihimize çok yakın bir sürede “preview” olarak çıkmış olmasına da bizim şansımız diyelim :)

İş yüklerinin birebir eşleniğinin (Kubernetes Cluster, DNS kayıtları, yük dengeleyiciler vb.) Azure’ da hazır olmasıyla birlikte (detaylı değineceğiz) birçok kez canlı ortam verileri ve işlemlerine göre Azure Managed Instance SQL Server Link özelliği sayesinde gelişigüzel “failover” senaryoları tetikleyip yeni bulut ortamımızda birçok kez kapsamlı testlerimizi yapma şansımız oldu. Yük testleri, otomatik testler (TestOps) ve iş kurallarının tamamının net bir şekilde ve sorunsuz işlediğini gördüğümüz günün gecesi de nihai “failover” u yaparak geçişi tamamladık.

PostgreSQL veri tabanlarının taşınması için ise Azure Database Migration servisini kullandık. Amazon Aurora PostgreSQL tarafında replikasyon özelliğini açarak tabloları sorunsuz şekilde senkronlayabildik. Nihai geçiş için kritik konu ise “postgres sequences” değerlerinin yeniden güncellenmesi gereğiydi!

İş Yükleri & Servisler (Workloads & Services)

Azure AKS tarafında yönetilen hizmet olarak yapılandırdığımız Kubernetes (v1.22) i AWS de kops(v1.15) ile tamamen kendimiz yönetiyorduk. Azure AKS hizmet ve bileşenlerini gayet kullanışlı bulduğumu söylemek isterim. Aşina olduğumuz ön tanımlar, konfigürasyonlar içeren kurulum ve ayaklandırma sürecini bir hayli kolay şekilde tamamladık. Ağ, “ingress” ve yük dengeleyici (public + internal) kurulum adımlarını en başında itinayla ve iş yüklerimize uygun şekilde yapmak; VNET, Subnet ve IP ayarlarına özen göstermek devasa bulut hizmetleri ağında kaynaklarımızı daha etkin yönetmemize imkan sağladı.

Tamamen dışa kapalı ve özel bir ağ üzerinde hizmet veren iş kümeleri, yük dengeleyiciler ile sadece gerektiği kadar yol ve erişimleri dış dünyaya açarlar. AWS’de yük dengeleyicinin IP adresiyle bağlı “ingress controller” ile verilen “Load Balancer” hizmetinin bir benzerini Azure AKS tarafında da güncel “deployments & charts” tanımlarıyla bu bağlantıdaki https://docs.microsoft.com/en-us/azure/aks/ingress-basic adımları takip ederek kolayca yerine getirdik.

“Internal” ve “Public” olarak, servisler ve yüklerin erişim izin türlerine göre iki tip “ingress-controller (ingressClassName)” kullanmayı tercih ettik. Yazılım geliştirme ekibimizin VPN (Azure VPN) ile erişim sağlayabildiği ve “Private IP” aralığına göre konfigüre edilmiş VNET + Private DNS + Azure DNS Resolver + Gateway bileşenlerinden oluşan güvenli erişim katmanını kullandık. Böylece; ELK Stack + APM, Grafana, Redis, SQL, PostgreSQL vb. geliştirme ve canlı ortam bağımlılıklarına olan tüm erişimleri kolayca yönetmeyi başardık.

Ağ (Network)

Özellikle altını çizmek istediğim bir konu da bulut ağ yapılarının kritik bileşenler olduğudur. Bu kapsamlı domaini anlamak ve yönetmek, kaynakların uygun seviyede iletişimi ve performans için önemlidir.

AWS de VPC, Azure da ise VNET olarak adlandırılan ağ servislerine ait konfigürasyonları ve CIDR (Classless Inter-Domain Routing) bloklarını dikkatli ve uygun şekilde düzenlemek gerekir. Büyük IP aralıkları yerine servislere özel ayrıştırdığımız (Kubernetes, SQL, PostgreSQL, Redis vb.) alt ağlar ile güvenlik kurallarını (Network Security Group — hemen hemen AWS nin Security Group hizmetine benzer şekilde) bu dizilime göre belirlemek işleri kolayladığı gibi sonradan yapılan genişletmeler (yeni servisler, güvenlik ayarları vs.) içinde esneklik sağladı.

AWS de iş yükleri ve veri katmanı arasındaki “VPC Peering” den dolayı ağ maliyetinin (hem maddi hem de latency olarak) oluştuğunun farkındaydık. Azure tarafında yeni ağ inşası ve bu dönüşümden fırsatla; “production” ve “development” ortamlarının ayrımı ile daha uygun şekilde ve performanslı bir ağ yapısı oluşturma fırsatı yakaladık. Ayrıca Kubernetes iş yüklerini ve veri tabanı alt ağlarını (subnet) aynı VNET çatısı altında birleştirdik. Azure AKS için sanal ağ ve alt ağlar bileşenlerini “AzureCNI” seçeneği ile yapılandırdık. AKS tarafındaki “kubenet” kısıt ve değerlendirmelerini “pod” sayımız ile referans dokümanını da göz önünde bulundurarak belirledik. (latency, additional hop, subnet vb. Ref: https://docs.microsoft.com/en-us/azure/aks/configure-kubenet#limitations--considerations-for-kubenet)

Ağ ve servis trafik metriklerini Azure Monitor, Load Balancer ve Grafana gibi araçları kullanarak gözlemlemeyi sürdürdük.

Neredeyse hata yapma şansınızın olmadığı bu gibi devasa ve kritik altyapısal dönüşümlerde; ekipçe tam bir odaklanmaya ihtiyaç duyulduğu gibi muhtemel sorunlar içinde alternatifler üretebilecek şekilde titizlikle yapılan planlamalar işin başarı yüzdesini arttıracağına inanıyorum.

Geçmişte paylaştığım bir yazımdan alıntı yaparak toparlamak isterim.

“Failure is not an option; It’s included with the software”

Elbette elinizden geleni yaptınız! Stresli durumların ve teknik sorunların bu işin bir parçası olduğunu unutmadan yapılan hazırlıkların; size, her zaman yeni bir çıkış kapısı ve alternatif sunabileceğine inanıyorum.

Bir sonraki yazıda Otelz.com’ un yeni arayüzü, modern teknolojik altyapısı (NextJS + React + TypeScript + APIs) ile önyüz dönüşüm ve geliştirme süreçlerini aktarmaya çalışacağım.

Faydalı olması dileğiyle…

Teşekkürler

Öncelikle bu projede her koşulda bizleri destekleyen Otelz.com’ un değerli kurucularına,
Kıymetli ekip ve tüm çalışma arkadaşlarıma,
Microsoft Türkiye’ ye,
Arena Bilgisayar’ a ve
DMC Bilgi Teknolojileri’ ne
desteklerinden ötürü teşekkürü borç bilirim.

--

--

v1/coder/solution-architect/manager

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store