Giriş: Deploy’da Kesintisizliğin Önemi
Deploy süreçleri, modern yazılım geliştirmenin ve operasyonların kritik bir parçası. Kullanıcılarımıza kesintisiz hizmet sunmak, iş sürekliliğini sağlamak ve yeni özelliklerimizi hızlı bir şekilde devreye almak için güvenilir deploy stratejilerine ihtiyacımız var. Peki, en iyi strateji hangisi? Bu yazıda, en popüler iki kesintisiz deploy yaklaşımını, Blue/Green ve Canary modellerini derinlemesine inceleyeceğim. Hangi senaryoda hangisinin daha uygun olduğunu, avantajlarını, dezavantajlarını ve gerçek dünya uygulamalarındaki trade-off’larını kendi deneyimlerimden yola çıkarak anlatacağım.
Deploy süreçleri genellikle göz ardı edilen ama en az kodlama kadar önemli bir alan. Bir kereye mahsus yapılan bir deploy işlemi bile, tüm sistemin performansını ve kullanıcı deneyimini doğrudan etkileyebilir. Özellikle kurumsal uygulamalarda veya kritik servislerde, deploy sırasında yaşanabilecek herhangi bir kesinti, ciddi finansal kayıplara ve marka itibarı zedelenmesine yol açabilir. Bu nedenle, deploy stratejilerini doğru seçmek ve uygulamak, bir mühendislik zorunluluğu haline gelmiştir.
Blue/Green Deploy: İki Ortam Arasında Geçiş
Blue/Green deploy, adından da anlaşılacağı gibi, birbirinin aynısı olan iki ayrı üretim ortamı kullanma prensibine dayanır. Bir ortam (“Blue” olarak adlandıralım) mevcut canlı trafik için kullanılırken, diğer ortam (“Green” olarak adlandıralım) yeni sürümün deploy edilmesi ve test edilmesi için hazırlanır. Yeni sürüm Green ortamına deploy edilip stabil olduğu doğrulandıktan sonra, trafik aniden Blue ortamından Green ortamına yönlendirilir. Bu yönlendirme genellikle bir load balancer veya DNS değişikliği ile yapılır.
Bu yaklaşımın en büyük avantajı, rollback (geri alma) işleminin inanılmaz derecede hızlı olmasıdır. Eğer Green ortamında bir sorunla karşılaşılırsa, trafik sadece saniyeler içinde tekrar Blue ortamına geri yönlendirilebilir. Bu, kullanıcılar için kesintiyi minimuma indirir veya tamamen ortadan kaldırır. Ayrıca, Green ortamı tamamen izole olduğu için, canlı trafik üzerindeki testler sırasında herhangi bir risk taşımaz.
Bu modelde, kaynak maliyeti bir diğer önemli faktör. İki tam üretim ortamı gerektirdiği için, özellikle büyük ölçekli sistemlerde maliyetler artabilir. Ancak, çoğu bulut sağlayıcısının sunduğu esnek ölçeklendirme ve kaynak yönetim araçları ile bu maliyetler optimize edilebilir. Örneğin, kullanılmayan Green ortamı düşük kapasitede çalıştırılabilir veya deploy tamamlandıktan sonra hemen kapatılıp yeniden kullanılmak üzere hazır tutulabilir.
Örnek Durum: Bir e-ticaret platformunda gece yarısı yeni bir ödeme gateway entegrasyonunu deploy etmemiz gerekiyordu. Mevcut sistemimiz (Blue) çalışırken, yeni entegrasyonu hazırladığımız ayrı bir sunucu kümesine (Green) deploy ettik. Tüm entegrasyon testlerini, güvenlik taramalarını ve performans ölçümlerini Green ortamında gerçekleştirdik. Her şey yolunda gidince, load balancer ayarlarıyla trafiği saniyeler içinde Green ortama yönlendirdik. Kısa süre sonra yeni ödeme seçeneğiyle başarılı işlemlerin geldiğini gördük. Herhangi bir sorun olsaydı, tek tuşla trafiği tekrar Blue ortama çevirebilirdik.
Canary Deploy: Adım Adım Yeni Sürüme Geçiş
Canary deploy, adını maden ocaklarındaki kanarya kuşlarından alır. Eskiden madenciler, havadaki zehirli gazları tespit etmek için yanlarında kanarya taşırlardı. Eğer kanarya ölürse, madenciler tehlikeyi anlardı. Yazılım dünyasında ise, Canary deploy, yeni sürümü önce küçük bir kullanıcı grubuna sunarak başlar. Bu küçük grup, genellikle rastgele seçilir veya belirli özelliklere sahip kullanıcılardan oluşur.
Yeni sürüm bu küçük kullanıcı grubunda stabil çalışırsa, kullanıcı yüzdesi kademeli olarak artırılır. Örneğin, önce %1’e, sonra %5’e, ardından %20’ye ve nihayetinde %100’e çıkarılır. Bu süreç boyunca sistem performansı, hata oranları ve kullanıcı geri bildirimleri yakından izlenir. Eğer herhangi bir aşamada bir sorun tespit edilirse, deploy hemen durdurulur ve trafik eski sürüme geri yönlendirilir.
Canary deploy’un en büyük avantajı, riskleri çok daha ince taneli bir şekilde yönetebilmesidir. Eğer yeni sürümde bir hata varsa, bu hata sadece küçük bir kullanıcı kitlesini etkiler. Bu, büyük çaplı kesintilerin önüne geçer ve sistemin genel kararlılığını korur. Ayrıca, gerçek kullanıcı trafiği üzerinden yapılan testler sayesinde, daha önce fark edilmeyen sorunlar ortaya çıkarılabilir.
Bu yöntemin dezavantajı ise, yönetiminin daha karmaşık olabilmesidir. Kademeli geçişi sağlamak için gelişmiş trafik yönlendirme mekanizmalarına ve detaylı izleme araçlarına ihtiyaç duyulur. Ayrıca, bazı durumlarda rollback işlemi Blue/Green kadar hızlı olmayabilir, çünkü trafiğin sadece bir kısmının eski sürüme yönlendirilmesi gerekebilir.
Özellikle güvenlik protokolü gibi kritik bir değişiklikte Canary yaklaşımı işe yarar: yeni protokolü tüm kullanıcılara aynı anda sunmak yerine, önce küçük bir kullanıcı yüzdesine deploy edip işlem sürelerini, uygulama çökme oranlarını ve hata loglarını yakından izlemek; oran kabul edilebilir kaldıkça her aşamada stabilliği doğrulayıp bir sonrakine geçmek mantıklıdır. Bu sayede, protokolde bir sorun olsa bile yalnızca küçük bir azınlık etkilenir.
Trade-off Analizi: Blue/Green mi, Canary mi?
Her iki deploy stratejisinin de kendine özgü avantajları ve dezavantajları bulunuyor. Hangi stratejinin sizin için daha uygun olduğunu belirlemek, projenizin gereksinimlerine, risk toleransınıza ve mevcut altyapınıza bağlıdır.
Hız ve Basitlik: Eğer acil bir rollback ihtiyacınız varsa ve operasyonel karmaşıklığı minimumda tutmak istiyorsanız, Blue/Green deploy daha iyi bir seçenek olabilir. Trafik yönlendirmesi genellikle daha basittir ve rollback saniyeler içinde gerçekleşir.
Risk Yönetimi ve Geri Bildirim: Eğer önceliğiniz riskleri en aza indirmek, yeni sürümü gerçek kullanıcılarla kontrollü bir şekilde test etmek ve detaylı geri bildirim toplamak ise, Canary deploy daha uygun olacaktır. Bu strateji, özellikle büyük ve karmaşık sistemlerde veya kritik güncellemelerde tercih edilir.
Bir diğer önemli trade-off ise maliyettir. Blue/Green stratejisi, iki tam üretim ortamı gerektirdiği için başlangıçta daha maliyetli olabilir. Canary ise, trafiği kademeli olarak yönlendirdiği için başlangıçta daha az kaynak gerektirebilir, ancak uzun vadede karmaşık trafik yönetimi ve izleme altyapısı maliyetlerini artırabilir.
Gerçek Dünya Örneği: Bir finansal teknoloji şirketinde çalışırken, yoğun işlem gören bir servisin deploy’unu yönetiyorduk. Bu serviste yaşanacak kısa bir kesinti bile ciddi zarara neden olabilirdi. Bu nedenle, her deploy’umuzda Canary stratejisini kullandık. Yeni sürümü önce küçük bir kullanıcı grubuna sunup, işlem başarı oranlarını, gecikmeleri ve hata oranlarını yakın aralıklarla izleyerek oranı kademeli artırıyorduk. Bir keresinde, küçük bir dilimde beklenmedik bir performans düşüşü fark ettik. Hemen deploy’u durdurup trafiği eski sürüme yönlendirdik. Sorun, yeni sürümün belirli bir sorguyu çok daha fazla sayıda kez çalıştırmasından kaynaklanıyordu. Eğer Blue/Green yapsaydık ve sorun sadece küçük bir kullanıcı grubunda değil, tüm sistemde ortaya çıksaydı, geri dönüş o kadar hızlı ve risksiz olmayabilirdi.
Teknik Uygulama Detayları
Hem Blue/Green hem de Canary deploy stratejileri, çeşitli altyapı araçları ve teknolojileri kullanılarak uygulanabilir. Kubernetes gibi container orkestrasyon platformları, bu stratejileri desteklemek için yerleşik mekanizmalara sahiptir.
Kubernetes ile Blue/Green: Kubernetes’te Blue/Green deploy, genellikle iki farklı Deployment objesi ve bir Service objesi ile gerçekleştirilir. Service objesi, trafiği mevcut sürümü çalıştıran Deployment’a yönlendirir. Yeni sürüm için ikinci bir Deployment oluşturulur ve test edildikten sonra, Service’in selector’ı yeni Deployment’ı işaret edecek şekilde güncellenir. Bu güncelleme, trafiği anında yeni sürüme yönlendirir.
# Mevcut sürüm için Service
apiVersion: v1
kind: Service
metadata:
name: my-app-service
spec:
selector:
app: my-app # Mevcut sürümün label'ı
ports:
- protocol: TCP
port: 80
targetPort: 8080
---
# Yeni sürüm için Deployment (Green)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app-green
spec:
replicas: 3
selector:
matchLabels:
app: my-app-green # Yeni sürümün label'ı
template:
metadata:
labels:
app: my-app-green
spec:
containers:
- name: my-app
image: my-registry/my-app:v2.0.0 # Yeni imaj
ports:
- containerPort: 8080Yeni sürüm hazır olduğunda, trafiği yönlendiren Service’i güncellemeniz gerekir. Bu, manuel veya bir otomasyon script’i ile yapılabilir.
Kubernetes ile Canary: Canary deploy için Kubernetes’te Service’in yanı sıra bir Ingress controller (örneğin Nginx Ingress veya Traefik) veya Service Mesh (örneğin Istio veya Linkerd) kullanmak yaygındır. Bu araçlar, trafiği farklı Deployment’lar arasında belirli oranlarda bölebilir. Örneğin, Ingress veya Service Mesh, trafiğin %90’ını mevcut sürüme (my-app-blue Deployment’ı) ve %10’unu yeni sürüme (my-app-green Deployment’ı) yönlendirecek şekilde yapılandırılabilir.
Service Mesh’ler, özellikle trafiği yönetme, izleme ve bölme konusunda daha gelişmiş özellikler sunar. Örneğin, Istio ile bir VirtualService objesi tanımlayarak trafiği kolayca farklı sürümler arasında paylaştırabilir ve yüzde oranlarını dinamik olarak ayarlayabilirsiniz.
# Istio VirtualService ile Canary Deploy örneği
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app-virtualservice
spec:
hosts:
- my-app.example.com
http:
- route:
- destination:
host: my-app
subset: v1 # Mevcut sürüm (Blue)
weight: 90
- destination:
host: my-app
subset: v2 # Yeni sürüm (Green)
weight: 10Bu yapılandırma, my-app servisinin trafiğinin %90’ını v1 alt kümesine (mevcut sürüm) ve %10’unu v2 alt kümesine (yeni sürüm) yönlendirir. Yüzdeleri artırmak için weight değerlerini güncelleyebilirsiniz.
Gerçek Dünya Sorunları ve Çözümleri
Her iki deploy stratejisi de kusursuz değildir ve kendi içinde zorluklar barındırır. Bu zorlukların üstesinden gelmek, başarılı bir kesintisiz deploy için kritik öneme sahiptir.
Ortam Tutarlılığı: Blue/Green deploy’da en büyük zorluklardan biri, iki ortamın da tam olarak aynı olduğundan emin olmaktır. Veritabanı şeması değişiklikleri, konfigürasyon farklılıkları veya altta yatan altyapıdaki küçük ayrıntılar bile sorunlara yol açabilir. Bu durumu önlemek için, altyapı kodunu (Infrastructure as Code - IaC) kullanarak her iki ortamın da tutarlı bir şekilde oluşturulmasını sağlamak önemlidir. Terraform veya CloudFormation gibi araçlar bu konuda yardımcı olabilir.
Veritabanı Geçişleri: Hem Blue/Green hem de Canary deploy’da veritabanı geçişleri özel dikkat gerektirir. Eğer yeni sürüm geriye dönük uyumlu olmayan bir veritabanı şeması değişikliği gerektiriyorsa, bu durum karmaşıklığı artırır. Geriye dönük uyumluluk, deploy süresince her iki sürümün de aynı veritabanı şemasıyla çalışabilmesini sağlamak için hayati önem taşır. Alternatif olarak, “expand and contract” (genişlet ve daralt) gibi veritabanı geçiş stratejileri kullanılabilir. Bu stratejide, önce geriye dönük uyumlu yeni şema eklenir, ardından yeni sürüm deploy edilir ve son olarak eski şema kaldırılır.
Monitoring ve Alerting: Her iki stratejide de, deploy sırasında ve sonrasında sistemin sağlığını izlemek için kapsamlı monitoring ve alerting mekanizmalarına ihtiyaç vardır. Hata oranları, işlem süreleri, kaynak kullanımı gibi metriklerin yakından takip edilmesi, olası sorunların erken tespit edilmesini sağlar. Örneğin, bir Canary deploy sırasında, yeni sürümün hata oranı %0.5’in üzerine çıktığında otomatik bir alarm tetiklenmesi ve trafiğin eski sürüme geri yönlendirilmesi gibi bir kural tanımlanabilir.
Rollback Stratejileri: Bir rollback işlemi her zaman planlanmalıdır. Blue/Green’de bu genellikle trafik yönlendirmesini eski ortama çevirmek kadar basittir. Canary’de ise, trafiğin tamamının eski sürüme yönlendirilmesi gerekebilir. Rollback’in ne kadar süreceği ve hangi adımları içereceği önceden belirlenmiş olmalıdır. Pratikte, manuel bir rollback komutunun trafiği eski sürüme döndürmesi beklediğinizden uzun sürebilir; bu süre zarfında kullanıcılar hâlâ sorunlu sürümle etkileşimde kalır. Bu nedenle rollback süreçlerini önceden otomatikleştirmek ve test etmek, ilk trafik yönlendirmesiyle birlikte rollback’in de başlamasını sağlamak kritik önemdedir.
Sonuç: Doğru Stratejiyi Seçmek
Kesintisiz deploy, modern yazılım geliştirme pratiklerinin temel taşlarından biridir. Blue/Green ve Canary deploy stratejileri, bu hedefe ulaşmak için güçlü yöntemler sunar. Blue/Green, hız ve basitlik arayanlar için idealdir; özellikle hızlı rollback ihtiyacı olan durumlarda öne çıkar. Canary ise, riskleri minimize etmek, yeni özellikleri kontrollü bir şekilde sunmak ve gerçek kullanıcı geri bildirimlerini toplamak isteyenler için daha uygundur.
Hangi stratejiyi seçerseniz seçin, altyapınızın bu stratejileri destekleyecek şekilde tasarlanmış olması, kapsamlı monitoring ve alerting mekanizmalarının kurulmuş olması ve rollback süreçlerinin net bir şekilde tanımlanmış ve test edilmiş olması kritik öneme sahiptir. Deneyimlerime göre, doğru stratejiyi seçmek ve uygulamak, deploy süreçlerinizin güvenilirliğini ve başarısını doğrudan etkiler. Unutmayın, deploy süreci sadece bir teknoloji meselesi değil, aynı zamanda operasyonel mükemmellik arayışının bir parçasıdır.
Daha önceki CI/CD pipeline optimizasyonu yazımda bahsettiğim gibi, deploy süreçlerini otomatikleştirmek ve optimize etmek, genel verimliliği artırır. Bu iki stratejiyi de kendi projelerinizde deneyerek, hangisinin sizin ihtiyaçlarınıza en iyi şekilde uyduğunu keşfedebilirsiniz.