Canary Deployment Nedir? Geliştirici İçin Pratik Rehber

Canary deployment nedir? Yeni bir sürümün uygulamanızı kullanan gerçek kullanıcıların küçük bir yüzdesine, örneğin yüzde 1 ila yüzde 5'ine önce sunulması ve geri kalan herkesin eski sürümde kalmasıdır. Bu dilimde hata oranını ve gecikmeyi izlersiniz. Her şey sağlıklı görünürse dilimi genişletirsiniz. Kötü görünürse trafiği eski sürüme geri alırsınız ve neredeyse kimse fark etmez. Fikir bu kadar basit. Aşağıdaki bölümler ise bunun pratikte nasıl çalıştığını anlatıyor.

Neden canary adı verildi?

Kömür madenciler, zehirli gazlara insandan önce kanaryaların tepki verdiğini bildikleri için yeraltına kanarya götürürdü. Şarkısını kesen kuş, çıkma zamanının geldiğinin işaretiydi. Deployment'taki mantık da aynı. Yeni kodu küçük bir kullanıcı grubu önce kullanır ve bu grup erken uyarı sistemi görevi görür. CNCF sözlüğü bunu, canlı trafiği sunan bir ortam ile güncellenmiş kodu çalıştıran bir ortam olarak tarif eder. Trafik, yüzde 1 gibi küçük bir paydan başlayarak kademeli olarak kaydırılır.

Pratikte asıl sorun şu: canary kullanıcıları gerçek kullanıcılardır ve staging ortamı bunu size veremez. Üretimde tuhaf tarayıcılar, eski önbellekler ve tek bir müşterinin 40 MB'lık içe aktarma dosyası vardır. Canary, hatanızla herkes karşılaşmadan önce bu durumlarla tanışmanın yoludur.

Canary deployment tam olarak nasıl işler?

Dört parça var, egzotik hiçbiri yok.

• Yan yana çalışan iki sürüm. Eski sürüm (stable) ve yeni sürüm (canary). İkisi de aynı anda istek karşılayabilmeli.

• Bir trafik dağıtıcı. Yük dengeleyici, ingress denetleyici, service mesh ya da CDN kuralı; yapılandırılabilir bir yüzdeyi canary'ye yönlendirir.

• Güvendiğiniz metrikler. Hata oranı, gecikme ve en az bir iş sinyali, örneğin ödeme başarısı ya da kayıt sayısı.

• İlerleme veya geri alma kuralı. Deploy'dan önce yazılmış olmalı, gece yarısı grafiklere bakarken uydurulmamalı.

Tipik bir artış yüzde 1, 5, 25, 50 ve 100 şeklinde ilerler ve her adımda bir bekleme olur. Google Cloud Deploy da aynı yapıyı belgeler: bir dizi yüzde tanımlarsınız ve araç trafiği bunlara göre dağıtır. Belgedeki örnekte son stabil sürümden önce yüzde 25, 50 ve 75 aşamaları yer alır. Cloud Deploy canary dokümantasyonu ayrıca her aşamada bir doğrulama işi ve analiz adımı çalıştırılarak ilerlemeye karar verilebileceğini gösterir.

Bu mükemmel bir kurulum değil, ama yapılabilir bir kurulum. Kubernetes'e ihtiyacınız yok. nginx'te ağırlıklı bir route, bir cookie'yi çeviren bir Cloudflare worker'ı ya da tek bir proxy'nin arkasındaki iki Fly.io makinesi de bu işi görür.

Trafik bölüşümü bir yapılandırmada nasıl görünür?

En küçük işe yarar örnek, ağırlıklı bir nginx upstream tanımı. On istekten dokuzu stable'a, biri canary'ye gider.

upstream app {
    server 10.0.0.10:3000 weight=9;   # stable
    server 10.0.0.11:3000 weight=1;   # canary
}

Bilmeniz gereken bir kusuru var: bölüşüm istek bazında yapılır, yani aynı kullanıcı ardışık tıklamalarda iki sürüm arasında gidip gelebilir. Yeni sürüm bir API yanıt yapısını ya da bir veritabanı kolonunu değiştirdiyse bu kullanıcının işi zorlaşır. Cookie ya da kullanıcı kimliğine göre sabit yönlendirme bu sorunu çözer ve temel bölüşüm çalıştıktan sonra eklenmesi gereken ilk şeydir.

Canary çalışırken neleri izlemelisiniz?

Canary'yi geçen haftanın verisiyle değil, aynı anda çalışan stabil sürümle karşılaştırın. Geçen hafta farklı bir trafik vardı. Sorunun cevabı her zaman şu: canary, şu an diğer yüzde 95'i sunan sürümden daha mı kötü?

• Hata oranı. Sürüm etiketine göre ayrılmış HTTP 5xx hataları ve yakalanmamış istisnalar.

• Gecikme. Ortalama değil p95 ve p99. Ortalama, regresyonların saklandığı yavaş kuyruğu gizler.

• Doygunluk. CPU, bellek, veritabanı bağlantıları. Bir bellek sızıntısı eğim olarak görünür, bu yüzden ona zaman tanıyın.

• Bir iş metriği. Hata oranı sabit kalırken canary'de ödeme başarısı düşüyorsa, sessiz bir hata yayınlamışsınız demektir.

Küçük ekiplerde en sık görülen hata, artışı zamanlayıcıya göre yapmak: yüzde 1'de beş dakika, grafikler ne derse desin ardından yüzde 25. Düşük trafikte yüzde 1'de beş dakika belki altı istek demektir ve bu hiçbir şey söylemez. Dakika sayısı yerine minimum istek sayısını bekleyin.

Bir pratik ipucu: her metrik panosunda canary ve stabil sürümü yan yana gösterin. İki çizgi aynı ekranda üst üste bindiğinde farkı görmek saniyeler alır. Metrikleri sürüm etiketi olmadan toplamak ise canary'nin hangi isteklere ait olduğunu bilmeden toplam hata oranına bakmak demektir. Bu durumda kötü bir canary toplam rakamların içinde kaybolur ve siz yalnızca genel bir yavaşlama görürsünüz.

Bu işi daha az elle yapılan hale getiren araçlara, gerçek trafiğiniz olduğunda bakmaya değer.

Canary mi, blue-green mi: hangisini seçmelisiniz?

Blue-green iki tam ortam tutar ve tüm trafiği tek seferde çevirir. Geri almak, çeviriyi tersine çevirmek kadar hızlı ve temizdir. Bedeli, geçiş anında kullanıcıların tamamının yeni sürümde olması ve geçiş süresince iki katı altyapı parası ödemektir.

Canary yalnızca bir dilimi maruz bırakır, bu yüzden etki alanı daha küçüktür. Bedeli karmaşıklıktır: trafik ağırlıklandırması, sürüm bazlı metrikler ve bir karar kuralı gerekir. Geri alma, canary'nin ağırlığını sıfıra çekmek demektir. Bağlantıların boşaltılması gerekiyorsa bu hızlıdır ama anlık değildir.

Canary'yi seçmek için üç neden var, ona karşı bir neden var. Üretimdeki bir hatanın maliyeti yüksekse, küçük bir dilimin anlamlı olacak kadar trafiğiniz varsa ve metrikleri sürüm bazında karşılaştırabiliyorsanız canary'yi seçin. Günde birkaç düzine kullanıcınız varsa atlayın: canary dilimi istatistiksel olarak boş kalır ve tahmin yürütürsünüz. Bu ölçekte dürüst cevap blue-green ya da hızlı geri alma betiği olan sade bir deploy'dur.

Rolling update'ler ortada durur. Örnekleri teker teker değiştirirler, bu nazik bir yöntemdir ama kontrollü bir deney değildir: yeni sürümü kimin göreceğini seçemezsiniz ve kullanıcı gruplarını karşılaştıramazsınız.

Maliyet tarafına bakarken bir ayrıntıyı unutmamak gerekir. Blue-green'de iki ortamı aynı anda ayakta tutmak, geçiş sırasında kaynak faturanızı kabaca ikiye katlayabilir. Canary'de ise ek kapasite genellikle küçüktür, çünkü yeni sürüm yalnızca dilimin trafiğini alır. Bu fark, bütçesi sınırlı yan projelerde kararı çoğu zaman belirler.

Feature flag'ler nerede devreye girer?

Canary deployment, trafiği kodun sürümleri arasında böler. Feature flag ise tek bir sürümün içindeki davranışı böler. İnsanlar bu ikisini karıştırır ve bu karışıklık pahalıya patlar.

Yeni kodu herkese, kapalı duran bir flag'in arkasına deploy edin. Sonra flag'i önce kullanıcıların yüzde 1'i, sonra yüzde 10'u, sonra herkes için açın. Bu genellikle özellik düzeyinde bir canary release olarak anılır. Avantajı: geri almak bir flag'i çevirmek demektir, yeniden deploy gerekmez. Dezavantajı: kullanılmayan kod yolu herkes için üretimde durur ve geride bırakılan flag'ler teknik borca dönüşür.

Tek başına çalışan bir geliştirici için flag'ler genellikle daha ucuz ilk adımdır. Bir yapılandırma tablosundaki boolean ve kullanıcı kimliğinin hash'i size değerin yüzde 80'ini verir. Bunu aşarsanız hedefleme, denetim kayıtları ve kademeli yüzde yayınlarını yöneten bir servis işi üstlenir.

Flag kullanırken bir kural koymakta fayda var: her flag'in bir sahibi ve bir son tarihi olsun. Özellik herkese açıldıktan sonra flag'i silmek için bir hatırlatıcı kurun. Aksi halde üç yıl sonra kodunuzda kimsenin neden var olduğunu bilmediği dallar kalır.

Gerçek projelerde canary'de ne ters gider?

Bunlar gerçekten ısıran hatalar. Aşağıdaki hatalar hem küçük hem büyük ekiplerde tekrar tekrar görülür. Çoğu, canary kavramından değil paylaşılan durumu hafife almaktan doğar. Bu yüzden canary öncesinde, her sürümün hangi veritabanı, önbellek ve kuyruk durumunu okuyup yazdığını bir liste olarak çıkarmak iyi bir alışkanlıktır.

• Veritabanı migration'ları. İki sürüm aynı veritabanına aynı anda erişir. Canary bir kolonu silerse ya da yeniden adlandırırsa stabil sürüm çöker. Çözüm expand and contract desenidir: önce yeni kolonu ekleyin, iki yapıyı da destekleyen kodu yayınlayın, eski kolonu yalnızca sonraki bir sürümde kaldırın.

• Durum tutan oturumlar. Oturumlar tek bir instance'ın belleğinde duruyorsa, iki sürüm arasında gidip gelen kullanıcı oturumundan çıkar. Canary denemeden önce oturum durumunu paylaşılan bir depoya taşıyın.

• Önbellek zehirlenmesi. Farklı bir önbellek formatı yazan yeni sürüm, eski sürümün okuduğu veriyi bozabilir. Önbellek anahtarlarınıza sürüm bilgisi ekleyin.

• Arka plan işleri. Canary kuyruk mesajlarını da tüketir. Hatalı bir worker işleri tam hızda yiyebilir, çünkü trafik yüzdesi kuyruk tüketimini sınırlamaz. Canary'ye kendi kuyruğunu ya da consumer ağırlığını verin.

• Bağlanmamış uyarılar. Canary, kimsenin açmadığı bir panoda yüksek sesle başarısız olabilir. Eşik aşıldığında otomatik durdurma, bir insanın izlemesinden iyidir, özellikle de deploy'u yapan kişinin tek uyanık kişi olduğu gece saatlerinde.

Yan proje için canary'ye nasıl başlarsınız?

Olması gerektiğinden daha küçük başlayın. Siz bir platform ekibi değil, tek bir geliştiricisiniz.

1. Her metriği bir sürümle etiketleyin. Git SHA'yı bir header'a ve loglarınıza koyun. Bu olmadan canary ile stabil sürümü hiç karşılaştıramazsınız.

2. Tek bir durdurma kuralı seçin. Örneğin: canary'deki hata oranı beş dakika boyunca stabil sürümün iki katını aşarsa geri alın. Tek kural, yazılı olarak.

3. Ağırlıklı bir route ekleyin. Nginx ağırlıkları, bir Cloudflare kuralı ya da hosting sağlayıcınızın trafik bölme özelliği. Çoğu yönetilen platform artık ek araç gerektirmeden yüzde bazlı yönlendirme sunuyor.

4. Önce sıkıcı bir şey yayınlayın. Bir metin değişikliği, fiyatlandırma sayfasının yeniden yazımı değil. Ortada risk yokken artışı ve geri almayı pratik edin.

5. Geri almayı zamanlayın. Bir kez gerçekten çalıştırın. Geri alma on dakikalık bir uğraşsa, düzeltilmesi gereken şey artış değil o olur.

Bu listenin hiçbir maddesi bir hafta sürmez. Asıl amaç, ilk gerçek artışınızı yaptığınızda sürecin sizi yalnız bırakmamasıdır.

Projeniz hâlâ kimin ödeyeceğini bulma aşamasındaysa bu muhtemelen erken. Sade bir deploy yapın, bir geri alma betiği tutun ve bir kesintinin gerçek müşterilere mal olacağı noktaya gelince canary'lere dönün. Zaten o noktadaysanız, ağırlıklı route ve tek bir durdurma kuralı bir haftasonu işidir ve kötü bir sürüm yüzde 100'de değil yüzde 1'de öldüğünde kendini öder.

Her şeyi canary'den mi geçirmeli?

Hayır. Konfigürasyon değişiklikleri, metin düzeltmeleri ve footer'daki bir yazım hatasının düzeltilmesi artış gerektirmez. Canary'yi, yanlış olmanın para ya da güven kaybettirdiği değişikliklere ayırın: ödemeler, kimlik doğrulama, veri modelleri ve sıcak yolu etkileyen her şey. Her commit için bir saat süren bir artış hattı, biri acele ettiğinde ilk seferde atlanır ve atlanan bir süreç hiç olmamasından daha kötüdür.

Peki bir sonraki sürümünüzdeki en riskli değişiklik hangisi ve onu önce kullanıcıların yüzde 1'ine göndermek neler gerektirir?