Dağıtım Stratejileri Diyagramı: Rolling, Blue-Green ve Canary

Kesintilerin çoğu bir dağıtımla başlar. Kod incelemeden ve testlerden geçmiştir, sonra gerçek trafikle, gerçek veriyle ve gerçek bağımlılıklarla karşılaşır. Bir dağıtım stratejisi, trafiğinizin ne kadarının yeni sürümle aynı anda karşılaşacağını, bir sorunu ne kadar çabuk fark edeceğinizi ve onu ne kadar hızlı geri alabileceğinizi belirler.

Bu yazı ekiplerin çoğunun arasında seçim yaptığı üç stratejiyi karşılaştırıyor: rolling update, blue-green ve canary sürümleri. Her birinde trafiğin nasıl kaydığını ve geri almanın neye benzediğini gösteriyor; sonunda da devam etme ya da geri alma kararının otomatikleştirildiği bir canary sürümünün diyagramıyla bitiyor.

Rolling update

Eski sürümün örneklerini yenisiyle birkaçar birkaçar değiştirin. Kubernetes Deployment'ları bunu varsayılan olarak yapar: RollingUpdate stratejisinde maxSurge ve maxUnavailable, dağıtım sırasında kaç fazla ve kaç eksik pod'a izin verildiğini belirler; ikisinin de varsayılanı %25'tir.

• Trafik: dağıtım boyunca iki sürüm de, sahip oldukları pod sayısıyla orantılı olarak aynı anda istek karşılar.
• Geri alma: eski sürüme doğru bir rolling update daha. Saniyeler değil, dakikalar.
• Maliyet: neredeyse hiç ek maliyet yok; en fazla surge kapasitesi.
• Risk: her kullanıcı yeni sürüme erkenden denk gelebilir ve tek otomatik kapı readiness probe'larıdır. Sorunsuz başlayıp yük altında çöken bir sürüm tamamen dağıtılır.

Rolling update, düşük riskli değişiklikler ve iyi testleri ve probe'ları olan iç servisler için doğru varsayılandır. Readiness probe'unun yalnızca sürecin ayakta olduğunu değil, servisin çalışmak için neye ihtiyaç duyduğunu kontrol etmesini sağlayın; yoksa dağıtım sağlıklı pod'ları gönül rahatlığıyla bozuk olanlarla değiştirir.

Blue-green

İki eksiksiz ortam çalıştırın. Blue üretime hizmet verir; green yeni sürümü alır ve yerinde test edilir. Ardından yük dengeleyici ya da DNS tüm trafiği blue'dan green'e tek seferde geçirir. Martin Fowler'ın blue-green dağıtım açıklaması klasik kaynaktır.

• Trafik: önce tamamı blue'da, sonra tamamı green'de. Hiçbir zaman ikisinde birden, en azından uzun süre değil.
• Geri alma: hâlâ çalışan blue'ya geri geçin. Saniyeler.
• Maliyet: ikisi de ayaktayken iki kat kapasite.
• Risk: geçiş kullanıcıların %100'ünü tek seferde taşır; bu yüzden yalnızca gerçek trafikte ortaya çıkan bir sorun herkesi vurur. Veritabanı ortaktır, dolayısıyla şema değişiklikleri iki sürümle de çalışmalıdır.

Canary

Gerçek trafiğin küçük bir payını, örneğin %5'ini, yeni sürüme gönderin, onu kararlı sürümle karşılaştırın ve düzgün davranıyorsa payı adım adım artırın. Ad, kömür madenindeki kanaryadan gelir; Fowler'ın sitesindeki canary release yazısına bakın.

• Trafik: ağırlığa, header'a ya da kullanıcı segmentine göre bölünür.
• Geri alma: canary'nin ağırlığını sıfıra çekin. Saniyeler; üstelik kullanıcıların yalnızca yüzde birkaçı etkilenmiştir.
• Maliyet: birkaç ek pod, artı trafik bölme ve analiz araçları.
• Risk: doğru metrikleri izlerseniz üçünün en düşüğü. Kimsenin izlemediği bir canary, yavaş bir rolling update'tir.

Yan yana

Son satırın her yerde aynı olmasının bir nedeni var: her stratejide, kodun iki sürümü bir noktada aynı veritabanıyla karşılaşır. Expand-and-contract migration'ları kullanın: önce yeni sütunları ve tabloları ekleyin, iki şekille de çalışan kodu dağıtın ve eski şekli sonraki bir sürümde kaldırın.

Canary'den önce gölge trafik

Bazı ekipler canary'den önce bir adım ekler: üretim isteklerinin bir kısmını yeni sürüme kopyalar ve yanıtlarını çöpe atar. Envoy ve Istio trafiği bu şekilde yansıtabilir. Bu, çökmeleri ve gecikme gerilemelerini kullanıcıya hiç dokunmadan yakalar, ama yalnızca okumalar ve idempotent istekler için. Yansıtılan yazmalar e-postalar, ödemeler ve stok değişiklikleri gibi yan etkilerini tekrarlar; bu yüzden onları yansıtmanın dışında tutun ya da gölgeyi korumalı alandaki (sandbox) bağımlılıklara yönlendirin.

Canary kararını otomatikleştirmek

Canary'nin değeri karşılaştırmadan gelir ve insanlar bir saat boyunca pano izlemekte kötüdür. Argo Rollouts ve Flagger gibi araçlar bunu Kubernetes'te otomatikleştirir: trafiği adım adım kaydırır, adımlar arasında metrik sağlayıcınızı sorgular ve tanımladığınız eşiklere göre yükseltir ya da iptal eder.

İyi analiz metrikleri az sayıdadır ve kullanıcıya yakındır:

• Canary'nin hata oranı (5xx yanıtları), kararlı sürümle karşılaştırmalı.
• p99 gibi yüksek bir yüzdelikte gecikme.
• Mümkünse bir iş sinyali; örneğin dakikada tamamlanan ödeme sayısı.

Canary'yi sabit bir sayıyla değil, kararlı sürümle karşılaştırın; böylece bir bağımlılığın kötü bir gecesi her sürümü başarısız kılmaz.

Mimari diyagram

Nasıl okunur:

• Üst, trafik yolu: kullanıcılar ingress'e ulaşır; ingress isteklerin %95'ini kararlı ReplicaSet'e, %5'ini canary'ye gönderir. İkisi de metriklere raporlar.
• Alt, kontrol döngüsü: CI yeni imajı rollout denetleyicisine verir. Denetleyici ingress ağırlıklarını ayarlar (kesikli kenar), iki sürüm için hata oranını ve p99 gecikmesini okur ve karar verir.
• Karar: eşikler içindeyse bir sonraki adıma geçilir; dışındaysa iptal edilir ve tüm trafik v1'e geri gönderilir.
• Markdown bloğu adımları ve iptal kuralını listeler; bunlar her servisin rollout yapılandırmasının incelemesinde yer almalıdır.

Feature flag'ler dördüncü stratejidir

Bir dağıtım stratejisi, yeni kodu hangi sunucuların çalıştıracağını kontrol eder. Bir feature flag ise dağıtımlardan bağımsız olarak yeni bir davranışı hangi kullanıcıların göreceğini kontrol eder. Sık sürüm çıkaran ekipler ikisini birleştirir: rolling update ya da canary ile dağıtır, riskli özellikleri bir flag'in arkasında tutar ve flag'i kademeli olarak açar. Flag daha hızlı geri alma yoludur, çünkü hiçbir şeyin yeniden dağıtılması gerekmez.

Dağıtım diyagramına ne konmalı

• Kenarlarda trafik yüzdeleri. Dağıtım sırasında değişirler; ilk adımı gösterin.
• Ağırlıkları kimin değiştirdiği. Bir denetleyici, bir pipeline ya da bir insan.
• İptal kriterleri. "Kötü görünürse" değil, sayılar.
• Veritabanı, ve şema değişikliklerinin expand-and-contract yöntemiyle yapıldığına dair bir not.

CI/CD pipeline diyagramı bundan önce gelen derleme ve test aşamalarını gösterir, Kubernetes mimari diyagramı cluster'ı ele alır, gözlemlenebilirlik mimari diyagramı ise metriklerin nereden geldiğini gösterir.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. Kullanıcılar için bir Kişi, Kubernetes paketinden bir Ingress ve kararlı sürüm ile canary için iki ReplicaSet düğümü ekleyin.
3. DevOps paketinden Metrikler ve bir İş hattı, rollout denetleyicisi için de C4 Modeli paketinden bir Konteyner ekleyin.
4. Yükseltme ve iptal için Akış Şeması paketinden bir Karar, bir Süreç ve bir Başla / Bitir düğümü ekleyin.
5. Ingress kenarlarını trafik ağırlıklarıyla etiketleyin, ağırlık değişikliklerini kesikli bir kenar olarak çizin ve adımları içeren, Temel paketinden bir Markdown bloğu ekleyin.

Örnek 11 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Hangi dağıtım stratejisi en iyisidir? Riske ve araçlara bağlıdır. Rolling update düşük riskli değişikliklerin çoğuna uyar; canary, kötü bir sürümün pahalıya patladığı kullanıcıya dönük servislere uyar; blue-green ise anlık ve eksiksiz geçiş gerektiren ve iki kat kapasiteyi karşılayabilen sistemlere uyar.

Blue-green ile canary arasındaki fark nedir? Blue-green tüm trafiği tek seferde geçirir ve anında geri alma için eski ortamı tutar. Canary önce trafiğin küçük bir payını taşır ve payı ancak yeni sürüm kendini kanıtladığında genişletir.

Dağıtım sırasında veritabanı migration'larını nasıl ele alırım? Her şema değişikliğini geriye dönük uyumlu yapın: önce genişletin, iki şekille de çalışan kodu dağıtın, sonra daha sonraki bir sürümde daraltın.

Canary analizi hangi metrikleri kullanmalı? Kararlı sürümle karşılaştırılan hata oranı ve yüksek yüzdelik gecikme, artı hızlıca ölçebiliyorsanız bir iş metriği.

Feature flag'ler bir dağıtım stratejisi midir? Bir sürüm (release) stratejisidir. Bir özelliği açmayı kodu dağıtmaktan ayırırlar ve üç dağıtım stratejisinin herhangi biriyle iyi birleşirler.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.