Canary Deployment Nedir? SRE'ler İçin Pratik Rehber

Canary deployment nedir? Yeni bir sürümü üretim trafiğinin küçük bir kısmına gönderip, çalışan sürümle karşılaştırmak ve sayılar tutarsa yayılımı genişletmek için kullanılan bir yayınlama tekniğidir. Değişiklik önce kullanıcıların yüzde 1 ila 5'ine ulaşır. Ardından bir metrik kontrolü, sürecin devam edip etmeyeceğine ya da geri alınıp alınmayacağına karar verir. Yani canary, kendi içinde bir karar noktası olan bir deploy'dur.

Bu rehberde yöntemin nasıl çalıştığını, nerede başarısız olduğunu ve neyi otomatize etmeniz gerektiğini ele alıyoruz.

Saat 03:00 çağrısı, bir canary ile Slack mesajına dönüşebilirdi

Perşembe günü saat 16:40'ta bir deploy çıkıyor. Checkout servisinde hata oranı yüzde 0,2'den yüzde 4'e yükseliyor. Bunu kimse fark etmiyor, iki saat sonra bir destek talebi geliyor. O zamana kadar her kullanıcı yeni sürümü çalıştırmış oluyor. Migration yarım uygulandığı için geri alma 25 dakika sürüyor.

Aynı değişikliği yüzde 5'lik bir canary olarak çalıştırsaydınız hasar sınırlı kalırdı. Kullanıcıların yaklaşık 20'de biri hatayı görürdü, kontrol grubuna karşı yapılan karşılaştırma birkaç dakika içinde başarısız olur ve pipeline durdurulurdu. Post-mortem, canary'nin neyi kaçırdığını değil, neyi yakaladığını anlatırdı.

Adı kömür madenlerinden gelir: hava öldürücü hale gelmeden önce kanaryanın ötmeyi bıraktığı yerlerden. Küçük kohortunuz aynı rolü oynar. Kötü sürümü engellemez, kimin onu soluyacağını sınırlar.

Canary deployment adım adım ne yapar?

Google SRE Workbook'un "Canarying Releases" bölümü canary'yi, bir değişikliğin kısmi ve zamanla sınırlı biçimde yayılması ile yayılımın devam edip etmeyeceğine karar veren bir değerlendirme olarak tanımlar. Değişikliği çalıştıran alt küme canary, geri kalan filo ise kontrol grubudur. Bu çerçeve önemlidir, çünkü canary'yi yavaş bir deploy olmaktan çıkarıp kendi güvenilirliğiniz üzerinde bir A/B testine dönüştürür.

Tipik bir akış şöyle ilerler:

• Yeni sürümü, henüz trafik almadan, kararlı sürümün yanına deploy edin.

• Trafiğin küçük bir yüzdesini ona yönlendirin (Workbook örneğinde yüzde 5).

• Canary ile kontrol grubunu karşılaştırırken sabit bir pencere bekleyin (aynı örnekte 30 dakika).

• Bir sonraki adıma geçin, örneğin yüzde 25, sonra yüzde 50, sonra yüzde 100. Ya da durdurun ve trafiği eski sürüme geri çevirin.

Döngü basittir. Zor kısım karşılaştırma adımıdır ve çoğu ekip bunu "birinin dashboard'a bakması" olarak uygular. Bu yüzden canary'nin değeri, karşılaştırmanın ne kadar otomatik ve ne kadar dürüst olduğuna bağlıdır.

Canary, blue-green ve rolling: hata modunuza hangisi uyar?

Bu üçü sürekli karıştırılır, o yüzden seçim yaparken önemli olan farkı netleştirelim.

• Rolling update: örnekleri kademeli olarak değiştirir. Ucuzdur ve her orkestratörde yerleşiktir. Ama kontrol grubuyla karşılaştırma yoktur ve temiz bir trafik bölümü sunmaz. Eski ve yeni sürüm sona kadar yükü paylaşır.

• Blue-green: iki tam ortam vardır ve tüm trafik tek seferde geçer. Geri alma anlıktır, ama geçiş anındaki etki alanı kullanıcıların yüzde 100'üdür. Çift kapasite ödersiniz.

• Canary: canlı trafiğin kontrollü bir kısmı yeni sürümde çalışır ve eskisine karşı değerlendirilir. En küçük etki alanına sahiptir, ama operasyonel karmaşıklığı en yüksek olanıdır.

Riskiniz bir smoke test ile tespit edip saniyeler içinde geri alabileceğiniz bozuk bir deploy ise blue-green seçin. Riskiniz yalnızca gerçek trafiğin ortaya çıkardığı ince bir regresyon ise canary seçin: bir p99 gecikme artışı, yavaş bir bellek sızıntısı ya da üretim verisinin şekline çöken bir sorgu planı gibi.

Servisiniz çok düşük trafikliyse canary'den vazgeçin. Saatte birkaç yüz istek varken yüzde 5'lik bir dilim birkaç örnek verir ve sinyal üretmez. Workbook bunu açıkça söyler: çok az sorgu, çeşitli iş yükleri için anlamlı bir sinyal sağlamaz.

Yüzde 1'lik canary muhtemelen size yalan söylüyor

İlk üç ayda ekipleri vuran hata tam olarak budur. Canary trafiğin yüzde 5'ini alır ve isteklerinin yüzde 20'sini başarısız kılar. Servis genelindeki hata oranı 0,2'den yaklaşık 1,2'ye çıkar. Alarm eşiğiniz yüzde 2'dir. Hiçbir şey tetiklenmez.

Toplu izleme canary hatalarını gizler. Aynı aritmetik SRE Workbook'ta da geçer: trafiğin yüzde 5'inde istekleri yüzde 20 hatalı çalışan bir canary, genel hata oranında yalnızca yüzde 1 olarak görünür. Metrikleri popülasyon bazında, canary ve kontrol olarak ayırmazsanız sinyal paydanın içinde kaybolur.

Bilmeye değer üç tuzak daha var:

• Öncesi-sonrası karşılaştırmaları. Canary penceresini bir önceki saatle kıyaslamak, değişikliği zamanla karıştırır. Yalnızca hafta içi ile hafta sonu trafiği farkı bile gerçek bir regresyonu gölgeleyebilir. Bunun yerine eşzamanlı bir kontrol grubuyla karşılaştırın.

• Ortak bağımlılıklar. Canary ve kontrol aynı cache ya da veritabanına gidiyorsa, bozuk bir canary ikisini de yavaşlatabilir ve karşılaştırma bir şey göstermez. Hata alanlarınızı kontrol edin.

• Gürültülü metrikler. CPU kullanımı zayıf bir kapıdır. Hata kodları ve gecikme ise kullanıcının hissettiklerini izler. Workbook, aday metrikleri kullanıcıya görünen sorunları ne kadar yansıttıklarına göre sıralayıp yalnızca en iyi birkaçını, en fazla on ikiyi tutmayı önerir.

Gate metriklerini incident sırasında değil, yayından önce seçin

Başlangıç noktanız SLI'lardır. Servis için zaten bir erişilebilirlik SLI'si ve bir gecikme SLI'si varsa, bunlar ilk iki kapınızdır. İstek odaklı bir servis için makul bir başlangıç seti şöyle görünür:

• Bekleme penceresi boyunca canary ve kontrolde 5xx hata oranı

• Canary ve kontrolde p99 gecikme

• Değişikliğe atfedilebilir bir doygunluk sinyali, örneğin pod başına bellek artışı

• Kohort bazında izole edilebiliyorsa bir iş metriği, örneğin checkout tamamlanma oranı

Eşikler, ekiplerin haftalarını kaybettiği yerdir. Çok sıkı tutarsanız her canary gürültüden dolayı durur ve mühendisler kapıyı atlamayı öğrenir. Çok gevşek tutarsanız kötü bir build sorunsuz geçer. Eşikleri düzenli aralıklarla gözden geçirin. Altı aydır hiçbir şeyi durdurmamış bir kapı ya mükemmeldir ya da süstür, hangisi olduğunu öğrenmelisiniz.

Metrik toplama aralığını da canary penceresini aşmayacak şekilde tutun. Beş dakikalık bir canary üzerinde on dakikalık bir toplama her şeyi bulanıklaştırır.

Argo Rollouts'ta canary config'i nasıl görünür?

Kubernetes üzerinde Argo Rollouts canary spesifikasyonu sıralamayı bir adım listesi olarak ifade eder. Dokümanların tarif ettiği biçimde, kısaltılmış bir örnek:

strategy:
  canary:
    steps:
      - setWeight: 5
      - pause: { duration: 30m }
      - analysis:
          templates:
            - templateName: error-rate-vs-baseline
      - setWeight: 25
      - pause: { duration: 30m }
      - setWeight: 50
      - pause: {}

Dokümanlardan iki ayrıntıya dikkat etmek gerekir. Trafik yönlendiricisi yoksa ağırlık, pod sayısına göre en iyi çabayla yaklaşık hesaplanır: 10 replika ve yüzde 10, bir canary pod ile dokuz kararlı pod demektir. Bu istek matematiği değil, replika matematiğidir. Ayrıca süresiz pause: {} adımı, biri kubectl argo rollouts promote çalıştırana kadar bekler. Bu, istediğiniz ya da istemediğiniz bir insan kapısıdır.

Analiz adımı başarısız olursa rollout durur. Asıl yatırım yapmanız gereken kısım budur.

Feature flag'ler ve sürüm bazlı telemetri: güvenli canary'nin iki yarısı

Altyapı canary'leri trafiği instance ya da pod bazında böler. Flag tabanlı canary'ler ise kullanıcıya, hesaba ya da hedeflenebilen herhangi bir özelliğe göre böler. İkisi farklı sorulara cevap verir. Birincisi yeni build'in sağlıklı olup olmadığını sorar. İkincisi yeni davranışın kabul edilebilir olup olmadığını sorar ve yeniden deploy etmeden kapatmanıza izin verir.

Flag tabanlı yayınlarda araç seçimi önemlidir. LaunchDarkly, en olgun hedefleme kurallarına ve denetim izine sahiptir, ekosistem genişliğinde de öndedir. Kurumsal ölçekteki fiyatlandırması ise platform liderlerinin sık yakındığı konudur.

Statsig flag'leri deneylerle birleştirir. Aynı platformda metrik tabanlı değerlendirme isteyen ekiplere uygundur. Yalnızca bir kill switch'e ihtiyacınız varsa daha az uygundur.

Dürüst bir değiş tokuş var: bir flag platformu yüzde bazlı yayın verir, ama çoğu SLO'nuzu kendi başına okumaz. Metriği karara bağlayan bağlantıyı yine biri kurmalıdır.

Rollout'u hangi araç yönetirse yönetsin, karar telemetrinizden gelir. Bu, her metriğin bir sürüm ya da kohort etiketi taşıması ve backend'in bunu 10 dakikalık bir gecikme olmadan sorgulayabilmesi demektir.

Datadog bunu etiket bazlı kırılımlarla iyi yapar. Deployment takibi de release'leri hata artışlarıyla ilişkilendirir. Her şeyi etiketlemeden önce yüksek kardinalitedeki maliyeti modellemeniz gerekir.

Grafana ve Prometheus zaten çalışıyorsa ve metrikleri rollout revizyonuna göre etiketliyorsanız işe yarar. Tam kontrol sizdedir, bakımı da sizin üzerinizdedir.

Abort'u otomatize edin, programınızı ölçün ve bu hafta başlayın

Manuel canary analizi zor ölçeklenir. Günde on deploy varsa kimse her seferinde 30 dakika dashboard'a bakmaz ve kapı sessizce "iyi görünüyor"a döner. Güvenilir desen otomatik bir hakemdir: SLO'yu tanımlarsınız, karşılaştırmayı tanımlarsınız ve canary kontrol grubundan daha hızlı hata bütçesi harcadığında bir controller'ın durdurup geri almasına izin verirsiniz.

upstreamapi'nin AI Pilot'u tam olarak bu sorunu hedefler. Rollout sırasında SLO sinyalini okur ve hata oranı sizin belirlediğiniz eşiği aştığında otomatik geri almayı tetikler. Hata oranını ve gecikmeyi kararlı kohortla karşılaştırır, bundan fazlasını yapmaz. Argo Rollouts analiz şablonlarını iyi bir Prometheus sorgusuyla zaten kullanıyorsanız aynı yeteneğin büyük kısmına sahipsiniz. Barındırılmış bir pilotun değer kattığı yer, her ekibin kendi analiz şablonlarını tutmak zorunda kalacağı heterojen stack'lerdir.

Sık görülen bir hata var: ekipler promote adımını otomatize eder ama abort'u hiç otomatize etmez. Yalnızca ileri gitmeyi bilen bir pipeline, bir konveyör bandıdır.

Bir canary programının kendi metrikleri de vardır. Bir çeyrek boyunca şunları izleyin:

• Canary durdurma oranı: kapı tarafından durdurulan canary'lerin payı. Sıfır, kapının kör olduğu anlamına gelir. Yüzde 20 ila 30'un üzerindeki oranlar genellikle dalgalı eşikleri ya da zayıf merge öncesi testleri gösterir.

• Canary'de tespit süresi: ilk kötü istekten durdurmaya kadar geçen dakika. Sürümler için gerçek MTTD budur.

• Kaçan regresyonlar: canary'den geçmiş bir sürüme bağlanan olaylar. Her biri bir kapıyı değiştirmelidir.

• Geri alma süresi: durdurma kararından trafiğin yüzde 100'ünün kararlı sürümde olmasına kadar geçen süre.

Servis başına aynı anda yalnızca bir canary çalıştırın. Workbook bunu güçlü biçimde önerir ve nedeni pratiktir: iki çakışan değişiklik atıf yapmayı imkansız kılar ve hangisinin zarar verdiğini bilemezsiniz.

Bu hafta için somut bir başlangıç: 15 dakika içinde sinyal üretecek kadar trafiği olan, durumsuz tek bir servis seçin. Hata ve gecikme metriklerine bir sürüm etiketi ekleyin. Canary ile kontrolü karşılaştıran tek bir sorgu yazın. Manuel promote ile yüzde 5'lik bir canary çalıştırın ve son üç olayda neyi yakalayabileceğinizi kaydedin.

Sonra zor soruyu sorun: canary saat 02:00'de başarısız olsaydı, uyanık bir insan olmadan bunu durduracak bir şey var mıydı?