Canary Deployment (Kanarya Dağıtımı)

#MLOps #ModelDağıtımı #RiskYönetimi #KademeDağıtım #YazılımMühendisliği

Canary Deployment, yeni bir yapay zeka modelinin riski azaltmak için önce küçük bir trafik dilimine sunulduğu kademeli dağıtım stratejisidir.

Canary Deployment (Kanarya Dağıtımı), yeni bir yazılım sürümü veya yapay zeka modelinin tam olarak yayına alınmadan önce küçük bir kullanıcı grubuna veya trafik dilimine sunulduğu kademeli bir dağıtım stratejisidir. Bu yaklaşım, adını tarihsel olarak madenlerde zehirli gaz tespiti için kullanılan kanarayalardan almaktadır: tıpkı kanaryanın tehlikeyi ilk hisseden olması gibi, test grubundaki kullanıcılar da yeni sürümün olası sorunlarını geniş kullanıcı kitlesine yayılmadan önce ortaya çıkarır. MLOps bağlamında canary deployment, yeni bir makine öğrenimi modelini veya ML pipeline'ının yeni bir versiyonunu üretim ortamında kademeli olarak devreye almak için kullanılır. Örneğin yeni bir öneri sistemi modeli önce yalnızca yüzde beş trafiğe sunulur; doğruluk, gecikme süresi ve kullanıcı memnuniyeti gibi metrikler izlenir ve sorun yoksa trafik payı kademeli biçimde artırılarak tam rollout'a ulaşılır. Bu strateji, büyük patlama (big-bang) dağıtımlarında karşılaşılan riskleri minimize eder. Tam bir rollout yerine küçük bir segment üzerinde test edildiği için olası bir model regresyonu veya performans düşüşü yalnızca küçük bir kullanıcı grubunu etkiler. Hata tespit edildiğinde trafik anında eski modele yönlendirilebilir (rollback), böylece iş sürekliliği korunur. Canary deployment, özellikle A/B testi ile birlikte kullanıldığında daha da güçlü bir araç haline gelir. A/B testinde iki sürüm deneysel olarak yan yana karşılaştırılırken, canary deployment birincil olarak risk yönetimine odaklanır: yeni sürüm iyi çalışıyorsa yavaş yavaş genişletilir, sorun çıkarsa hızla geri alınır. Kubernetes, AWS SageMaker, Seldon Core ve BentoML gibi modern MLOps araçları canary deployment'ı yerel olarak destekler. Bu araçlar, trafik bölme (traffic splitting), metrik izleme ve otomatik rollback mekanizmalarını sağlar, böylece ML mühendisleri yüksek riskli güncellemeleri güvenle ve kontrollü biçimde yayına alabilir. Platform desteği açısından Kubernetes ekosistemi canary deployment için zengin araçlar sunar: Argo Rollouts, Flagger ve Istio service mesh trafik bölümünü otomatikleştirerek metrik eşiği aşıldığında otomatik geri alım (automated rollback) uygular. Öte yandan feature flag araçları (LaunchDarkly, Unleash) canary mantığını altyapı yerine uygulama katmanına taşıyarak daha ince taneli kontrol sağlar. Başarılı bir canary stratejisi için gözlemlenebilirlik altyapısı (metrikler, loglar, izler) ve net başarı kriterleri önceden tanımlanmış olmalıdır.

Canary Deployment Nasıl Çalışır?

Canary deployment sürecinde yük dengeleyici (load balancer) veya servis ağı (service mesh), gelen trafiği iki farklı model sürümüne böler: büyük çoğunluk stabil (eski) modele, küçük bir dilim ise yeni (canary) modele yönlendirilir. Tipik bir başlangıç oranı %1-5 civarındadır.

Yeni model bu sınırlı yükleme altında izlenir: hata oranı, yanıt gecikmesi, model skoru ve iş metrikleri (tıklama oranı, dönüşüm, kullanıcı şikayeti) gerçek zamanlı olarak takip edilir. Metrikler referans değerlerin içinde kalıyorsa trafik payı kademeli olarak artırılır: %5 → %20 → %50 → %100. Herhangi bir anomali tespit edildiğinde trafik sıfıra çekilir ve rollback otomatik olarak tetiklenir.

Bu mekanizma sayesinde ekipler, yeni modelin gerçek üretim trafiği altındaki davranışını laboratuvar ortamında ölçemeyecekleri koşullarda gözlemleyebilir.

MLOps'ta Kullanım Senaryoları

  • check_circle Model güncellemeleri: Daha iyi doğruluk iddiasıyla yeniden eğitilen bir modelin üretimde gerçekten daha iyi performans gösterip göstermediğini doğrular.
  • check_circle Öneri sistemleri: Yeni sıralama algoritması küçük bir kullanıcı dilimine sunularak tıklama ve dönüşüm metrikleri karşılaştırılır.
  • check_circle NLP model sürüm geçişleri: Büyük dil modeli sürüm yükseltmelerinde regresyon riskini minimize eder; eski model güvenli liman olarak bekler.
  • check_circle Altyapı değişiklikleri: Model servis altyapısındaki değişiklikler (yeni donanım, çerçeve güncellemesi) önce küçük trafikle test edilir.

Canary Deployment ve A/B Testi: Fark Nedir?

Canary Deployment

Birincil amaç risk yönetimidir. Yeni sürüm küçük trafikle izlenir; sorun çıkmazsa kademeli genişleme yapılır, çıkarsa hızla geri dönülür.

A/B Testi

Birincil amaç deneysel karşılaştırmadır. İki sürüm istatistiksel anlamlılık elde edilene kadar paralel çalışır; kazanan sürüm tam rollout alır.

Birlikte Kullanım

Her iki teknik de aynı anda uygulanabilir: canary deployment rollout'u güvende tutarken, A/B testi hangi sürümün daha iyi olduğunu belirler.

Uygulama Araçları ve Platform Desteği

  • check_circle Kubernetes + Argo Rollouts: Kubernetes'te canary deployment'ı otomatikleştiren Argo Rollouts, trafik ağırlığını kademeli olarak artırır ve metrik eşiği aşılırsa otomatik geri alım yapar.
  • check_circle AWS CodeDeploy: AWS ortamında EC2 veya Lambda için canary trafik bölümü tanımlanabilir; CloudWatch alarm tetiklenince deployment otomatik durdurulur.
  • check_circle Istio / Service Mesh: Servis ağı (service mesh) katmanında VirtualService kurallarıyla trafik %5-%95 gibi oranlarla bölünür; sidecar proxy'ler gözlemlenebilirlik sağlar.
  • check_circle Feature Flags: LaunchDarkly veya Unleash gibi araçlar altyapı değişikliği olmadan belirli kullanıcı segmentlerine yeni özelliği gösterir; canary mantığını uygulama katmanına taşır.

Riskler ve Dikkat Edilmesi Gerekenler

Canary deployment güçlü bir strateji olsa da bazı riskler içerir. Veri şeması uyumsuzluğu: Yeni sürüm farklı bir veritabanı şeması kullanıyorsa, eski ve yeni sürümlerin aynı anda çalışması veri bozulmasına yol açabilir; bu durumda önce geriye dönük uyumlu şema değişikliği gerekir. Gözlemlenebilirlik eksikliği: Canary'nin başarısızlığını erken tespit etmek için yeterli metrik, log ve alarm tanımlı olmalıdır; eksik izleme, sorunun fark edilmesini geciktirir. Trafik örnekleme yanlılığı: Canary grubuna yönlendirilen kullanıcılar rastgele değil belirli bir segment (örn. belirli coğrafya) ise sonuçlar yanıltıcı olabilir. Uzun süreli canary: Haftalar boyu küçük bir yüzde ile canlıda kalan bir canary, teknik borç ve operasyonel karmaşıklık yaratır — canary süresi sınırlı tutulmalıdır.

Sık Sorulan Sorular

  • check_circle Canary deployment ile blue-green deployment arasındaki fark nedir? Blue-green deployment'ta iki tam ortam paralel çalışır ve trafik bir anda yüzde yüz geçiş yapar; canary deployment'ta ise tek bir ortamda trafik kademeli olarak bölünür ve artırılır.
  • check_circle Canary trafik payı ne kadar olmalı? Genellikle %1-5 ile başlanır. Düşük trafikli uygulamalarda yeterli istatistiksel sinyal elde edilebilmesi için oran biraz daha yüksek tutulabilir; yüksek trafikli sistemlerde %1 bile binlerce istek anlamına gelir.
  • check_circle Canary rollback tetikleyicileri neler olabilir? Hata oranının eşiği aşması, P99 gecikme süresi artışı, model güven skoru düşüşü veya iş metriklerinde (tıklama oranı, dönüşüm) anlamlı düşüş otomatik rollback tetikleyicileri olarak yapılandırılabilir.
  • check_circle Hangi MLOps platformları canary deployment'ı destekler? Kubernetes Argo Rollouts, AWS SageMaker Deployment, Seldon Core, BentoML, KServe ve Kubeflow bu stratejiye yerel destek sağlayan başlıca araçlardır.