Deployment Stratejileri: Blue-Green ve Rolling Karşılaştırması

Doğru deployment stratejileri seçimi, bir yazılımı yayına alırken kullanıcıların kesinti yaşayıp yaşamayacağını belirleyen en kritik kararlardan biridir. Bir e-ticaret sitesi, bir oyun sunucusu ya da bir Discord botu fark etmez; her güncelleme aslında çalışan bir sistemi, çalışmaya devam ederken değiştirmek anlamına gelir. Bu yazıda iki yaygın yaklaşımı, blue-green ve rolling deployment'ı, gerçek senaryolar üzerinden karşılaştıracağım ve hangi durumda hangisini seçmeniz gerektiğini netleştireceğim.

Neden bir stratejiye ihtiyaç var?

En basit yöntem olan "sunucuyu durdur, kodu değiştir, başlat" yaklaşımı küçük bir kişisel proje için yeterli olabilir. Ancak trafik aldığınız andan itibaren her saniyelik kesinti gelir kaybı, kötü kullanıcı deneyimi ve arama motoru sıralamasında düşüş demektir. Modern deployment stratejilerinin ortak hedefi sıfır kesinti (zero-downtime) sağlamaktır. Bunun yanında üç temel beklenti daha vardır:

• Hızlı geri alma (rollback): Yeni sürüm sorunluysa eski haline saniyeler içinde dönebilmek.
• Güvenli doğrulama: Yeni sürümü gerçek trafiğe açmadan önce sağlık kontrolünden geçirmek.
• Öngörülebilirlik: Her dağıtımın aynı, tekrarlanabilir adımlarla yapılması.

Blue-Green deployment nasıl çalışır?

Blue-green yaklaşımında iki ayna ortam tutarsınız: blue şu an canlı olan sürüm, green ise bir sonraki sürümü hazırladığınız özdeş ortam. Yeni kodu green ortamına kurar, migration'ları çalıştırır ve sağlık kontrollerini yaparsınız. Her şey yolundaysa load balancer ya da reverse proxy trafiği tek bir hamlede blue'dan green'e çevirir. Artık green canlıdır; blue ise dokunulmamış bir yedek olarak bekler.

Trafiği bir Nginx upstream'i ile yönlendirdiğinizi düşünün. Geçiş kabaca şuna benzer:

upstream app {
    # server 127.0.0.1:8001;  # blue (eski)
    server 127.0.0.1:8002;    # green (yeni)
}

Yapılandırmayı değiştirip nginx -s reload komutunu çalıştırdığınızda yeni istekler green'e gider. Bir sorun çıkarsa satırları geri alıp tekrar reload etmek, yani anında rollback yapmak mümkündür çünkü eski ortam hâlâ ayakta durur.

Rolling deployment nasıl çalışır?

Rolling deployment, aynı uygulamanın birden fazla kopyasını (instance) çalıştırdığınız ortamlar için tasarlanmıştır. Tüm kopyaları aynı anda güncellemek yerine, onları gruplar halinde sırayla yenilersiniz. Örneğin dört kopyanız varsa: birini trafikten çekersiniz, yeni sürümü kurarsınız, sağlık kontrolü geçince tekrar havuza alırsınız, sonra bir sonrakine geçersiniz. Süreç bittiğinde tüm kopyalar yeni sürüme geçmiş olur ve hiçbir an sistem tamamen kapanmaz.

Kubernetes bu modeli yerleşik olarak sunar. Bir Deployment'ı güncellediğinizde varsayılan strateji zaten rolling'dir:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1

Burada maxUnavailable aynı anda en fazla kaç pod'un kapalı olabileceğini, maxSurge ise geçici olarak fazladan kaç pod oluşturulabileceğini belirler. Bu iki değer, hız ile kapasite güvenliği arasındaki dengeyi ayarlamanızı sağlar.

İki strateji yan yana

Aralarındaki farkları net görmek için temel boyutları karşılaştıralım:

• Kaynak kullanımı: Blue-green iki tam ortam gerektirir, yani geçici olarak iki katı altyapı maliyeti. Rolling ise mevcut kapasiteyi kullanır, sadece küçük bir tampon ister.
• Rollback hızı: Blue-green'de geri dönüş anlıktır; trafiği eski ortama çevirmek yeterli. Rolling'de geri almak için ters yönde yeni bir rollout başlatmanız gerekir, bu da zaman alır.
• Karışık sürüm durumu: Rolling sırasında bir süre eski ve yeni sürüm aynı anda canlı kalır. Geriye dönük uyumlu olmayan API ya da veritabanı değişiklikleri bu yüzden sorun çıkarabilir.
• Basitlik: Rolling, orkestrasyon araçlarında genellikle hazır gelir. Blue-green ise yönlendirme ve ortam yönetimi açısından biraz daha fazla kurulum ister.

Veritabanı: asıl zor kısım

Her iki stratejide de en sık tökezlenen nokta veritabanı şema değişiklikleridir. Hem eski hem yeni kodun bir süre aynı veritabanına yazacağını unutmayın. Bu yüzden geriye dönük uyumlu (backward-compatible) migration'lar yazmak şarttır. Pratik kural şudur: önce kolon ekle, kodu güncelle, sonra eski kolonu kaldır; tek bir adımda hem kolon silme hem kod değiştirme yapma.

Örneğin bir kolonu yeniden adlandırmak istiyorsanız, tek hamlede RENAME yerine üç aşamalı bir yol izleyin: yeni kolonu ekleyin, iki kolonu da dolduran kodu yayınlayın, ardından bir sonraki dağıtımda eski kolonu düşürün. Bu yaklaşım, dağıtım sırasında çakışan sürümlerin birbirini bozmasını engeller.

Hangisini ne zaman seçmeli?

Tek bir doğru cevap yoktur; bağlama bağlıdır. Blue-green, anlık rollback'in kritik olduğu, riskli sürümlerde ve fazladan altyapıyı geçici olarak karşılayabildiğiniz durumlar için idealdir. Rolling ise çok sayıda instance çalıştıran, maliyeti düşük tutmak isteyen ve değişiklikleri zaten geriye dönük uyumlu yazan ekipler için daha doğaldır. Birçok olgun ekip ikisini birleştirir: trafiğin küçük bir yüzdesini yeni sürüme yönlendiren canary yaklaşımı, aslında rolling'in dikkatli bir varyasyonudur ve blue-green'in güvenliğiyle harmanlanabilir.

Sık Sorulan Sorular

Blue-green deployment iki katı maliyet mi demek?

Geçiş anında evet, iki ortam birden ayakta durur. Ancak bu genellikle yalnızca dağıtım penceresi boyunca sürer; geçiş tamamlanınca eski ortamı küçültebilir ya da bir sonraki sürüme kadar kapatabilirsiniz. Bulut ortamlarında dakika bazlı ücretlendirme sayesinde bu ek maliyet çoğu zaman düşük kalır.

Küçük bir projede bu stratejilere gerek var mı?

Trafiği az olan kişisel bir projede basit "durdur-güncelle-başlat" yöntemi yeterli olabilir. Ancak kullanıcılarınız kesintiyi fark etmeye başladığı anda en azından sağlık kontrollü, geri alınabilir bir akışa geçmek değerlidir.

Canary deployment bunların yerine geçer mi?

Canary bir alternatif değil, tamamlayıcıdır. Yeni sürümü küçük bir trafik dilimine açıp metrikleri izler, sorun yoksa kademeli olarak genişletirsiniz. Genellikle rolling ya da blue-green altyapısının üzerine kurulur.

Projeniz için doğru dağıtım akışını kurmak mı istiyorsunuz? İster sıfır kesintili bir yayın hattı, ister güvenli migration stratejisi olsun, birlikte planlayalım. Benimle iletişime geçin ve ihtiyacınıza uygun çözümü konuşalım.