Kademeli yayın uygulaması: canary dağıtım adım adım

Canary dağıtımın amacı ve çalışma mantığı

Canary dağıtımda yeni sürüm bütün kullanıcılara bir anda verilmez. Önce üretim trafiğinin küçük bir bölümü yeni sürüme yönlendirilir, geri kalanı eski sürümle çalışmaya devam eder. Yeni sürüm bu küçük kesitte sağlıklı davranırsa pay kademeli olarak büyütülür; sorun görülürse trafik eski sürüme döndürülür ve etkilenen kullanıcı sayısı sınırlı kalır.

Bu yaklaşımın değeri, test ortamının yakalayamadığı sorunları gerçek trafikte, ama düşük risk altında görmesidir. Gerçek veri hacmi, gerçek istemci çeşitliliği ve gerçek bağımlılık davranışı yalnızca üretimde ortaya çıkar. Canary, bu bilgiyi toplamanın kontrollü yoludur. Adını, madenlerde zehirli gazı önce fark eden kanarya kuşundan alır: küçük bir grup erken uyarı verir.

Başlamadan önce hazır olması gerekenler

Canary dağıtım bir araç kurulumundan önce bir ölçüm disiplinidir. Yeni sürümün iyi mi kötü mü olduğuna karar verecek sinyaller olmadan trafiği bölmek yalnızca yayını yavaşlatır. Hazırlık listesi şöyledir:

• Her sürümün metriklerini ayrı görebilmek: istekler, hata oranı ve gecikme değerleri sürüm etiketiyle ayrıştırılmalı.
• Temel çizgi (baseline): eski sürümün normal davranışı belli olmalı ki yeni sürümle karşılaştırılabilsin.
• İş metrikleri: ödeme tamamlama, sepete ekleme gibi ürün sinyalleri teknik metriklerle birlikte izlenmeli. Sunucu hatasız çalışırken iş akışı bozulabilir.
• Eski ve yeni sürümün aynı anda yaşayabilmesi: veritabanı şeması, mesaj formatları ve API sözleşmeleri geriye uyumlu olmalı. Canary süresince eski ve yeni kod aynı veriyi okur ve yazar.
• Net bir geri dönüş yolu: trafiği eski sürüme çevirmek tek komut ya da tek yapılandırma değişikliği olmalı.

Bu maddelerden biri eksikse önce onu tamamlamak, canary altyapısı kurmaktan daha değerlidir.

Canary yayını adım adım

Genel akış hemen her araçta aynıdır:

• Yeni sürüm, eskisinin yanında çalışan ayrı bir dağıtım olarak ayağa kaldırılır; henüz trafik almaz.
• Sağlık kontrolleri ve temel duman testleri geçince, trafiğin çok küçük bir payı yeni sürüme yönlendirilir.
• Bir gözlem penceresi boyunca yeni sürümün metrikleri eski sürümle karşılaştırılır. Pencere, trafiğin anlamlı bir örnek oluşturacağı kadar uzun olmalıdır; sakin saatlerde çok kısa bir bekleme kanıt sayılmaz.
• Metrikler eşiklerin içindeyse pay bir kademe artırılır ve gözlem tekrarlanır.
• Son kademede yeni sürüm bütün trafiği alır, eski sürüm bir süre yedek olarak bekletilir, ardından kapatılır.
• Herhangi bir kademede eşik aşılırsa trafik anında eski sürüme döner ve sorun incelenir.

Örneğin bir ödeme servisinin yeni sürümünde, ilk kademede yalnızca dahili çalışanların ya da belirli bir bölgenin trafiği yönlendirilebilir. Böylece ilk gerçek hata, en az zararla yakalanır.

Trafik nasıl bölünür: kullanılan yöntemler ve araçlar

Trafik bölmenin birkaç yaygın yolu vardır ve seçim altyapınıza bağlıdır.

Yük dengeleyici ağırlıkları: bulut sağlayıcılarının yük dengeleyicileri birden fazla hedef grubunu farklı ağırlıklarla besleyebilir. Kurulumu basittir, ama karar verme ve geri alma işini yine sizin otomasyonunuz yapar.

Kubernetes ve ingress katmanı: ingress denetleyicilerinin ağırlıklı yönlendirme özellikleri vardır. Sade bir yaklaşım, aynı servisin arkasında farklı sayıda kopya çalıştırmaktır; ancak bu yöntemde pay, kopya sayısıyla sınırlı ve kaba kalır.

Service mesh: Istio gibi araçlarda trafik yüzdeleri sürüm etiketlerinden bağımsız, ağırlık kurallarıyla tanımlanır. Başlığa (header), kullanıcı grubuna ya da çerezlere göre yönlendirme de yapılabilir. Böylece pay küçük tutulurken belirli bir kullanıcı kesiti hedeflenir.

İlerleme otomasyonu: Argo Rollouts ve Flagger gibi araçlar kademeleri, bekleme sürelerini ve metrik analizini tanımlamaya, eşik aşılınca kendiliğinden geri dönmeye izin verir.

Özellik bayrakları (feature flag): kodun yeni davranışı dağıtımdan ayrılır; sürüm herkese yayılmış olsa bile özellik yalnızca belirli kullanıcılarda açılır. Canary ile tamamlayıcıdır, onun yerine geçmez.

Otomatik analiz ve karar kriterleri

Kademe geçişlerinin insan gözüne bırakılması küçük ekiplerde işe yarar, ama ölçek büyüdükçe otomatik analiz gerekir. Analiz için her metriğe bir eşik ve bir karşılaştırma kuralı tanımlanır: yeni sürümün hata oranı eski sürümün belirli bir toleransından fazla sapmamalı, gecikme dağılımının üst yüzdelikleri bozulmamalı, kaynak tüketimi (işlemci, bellek) beklenen aralıkta kalmalı.

Birkaç ayrıntı kararı doğru yönde tutar. Ortalama gecikme yerine üst yüzdelikleri izleyin; ortalama, az sayıdaki yavaş isteği gizler. Karşılaştırmayı sabit bir eşiğe değil, aynı anda çalışan eski sürüme göre yapın; böylece günün saatinden kaynaklanan dalgalanma her sürümü eşit etkiler. İş metriklerinde istatistiksel anlamlılık için yeterli örnek birikmeden karar vermeyin.

Analiz sonucu belirsizse varsayılan davranış geri dönmek olmalıdır. Sürümü ilerletmek için kanıt gerekir; geri almak için şüphe yeterlidir.

Sık yapılan hatalar ve önlemleri

• Gözlem penceresini kısa tutmak: Yavaş gelişen bellek sızıntıları ya da yalnızca belirli saatlerde çalışan işler kısa pencerede görünmez. Pencereyi, sürümün risk profiline göre belirleyin.
• Yalnızca teknik metriğe bakmak: Sunucu hatası vermeyen bir sürüm, yanlış hesap yaparak iş sonuçlarını bozabilir. İş metriklerini analize dahil edin.
• Şema değişikliğini kod ile aynı adımda yapmak: Veritabanı değişikliği önce geriye uyumlu şekilde yapılmalı, kod sonra yayılmalı, eski yapı en son temizlenmeli. Aksi halde geri dönüş, veriyi bozar.
• Oturum ve önbellek etkisini unutmak: Kullanıcı bir istekte yeni, sonraki istekte eski sürüme düşerse tutarsız deneyim yaşar. Gerekli yerlerde oturum yapışkanlığı ya da kullanıcı bazlı yönlendirme kullanın.
• Geri dönüşü hiç denememek: Geri alma yolu ilk kez üretim krizinde denenmemeli. Düzenli tatbikat yapın.
• Çok küçük trafikte anlamlı sonuç beklemek: Düşük trafikli servislerde pay oranı yerine süreyi uzatın ya da sentetik yük ekleyin.

Öğrenme yolu ve Mindset programlarındaki yeri

Başlangıçta temel şu: sürekli teslimat hattını, ortam yönetimini ve izleme mantığını anlamak. Ardından mavi-yeşil ve kademeli (rolling) dağıtımla canary arasındaki farkı küçük bir deneme servisinde uygulamak gelir. İleri aşamada service mesh ile ağırlıklı yönlendirme, metrik tabanlı otomatik terfi ve özellik bayraklarının birlikte kullanımı çalışılır.

Mindset kataloğunda Istio ile Service Mesh Uygulamaları eğitiminin müfredatında Trafik Yönetimi Temelleri ve Canary ve İleri Yönlendirme Senaryoları modülleri yer alır; ağırlıklı yönlendirmeyi çalışmak isteyen platform ve altyapı ekipleri için uygundur. CI/CD Pipeline Tasarımı (GitHub Actions) eğitiminde Çok Ortamlı Deployment Stratejileri modülü bulunur. DevOps Temelleri ise Sürekli Teslimat ve Dağıtım ile İzleme ve Geri Bildirim Döngüsü modülleriyle bu pratiğin kültürel ve süreçsel tarafını kapsar. Kurumsal ekipler bu başlıkları kendi dağıtım hattı üzerinde birlikte çalışacak şekilde ele alabilir.