MLOps Canary ve Shadow Deployment: Model Rollout Stratejisi 2026

Model canary deployment, yeni eğitilmiş bir makine öğrenmesi modelini üretim trafiğinin küçük bir yüzdesine (genellikle %1-%5) yönlendirip metrikleri ölçtükten sonra kademeli olarak yüzde yüze çıkaran rollout stratejisidir. Shadow deployment ise modelin yanıtlarını kullanıcıya göstermeden, mevcut prodüksiyon modeliyle paralel çalıştırarak gölge trafiğinde davranışı doğrular. Bu iki desen, 2026 itibarıyla MLOps platformlarının (Vertex AI, SageMaker, Databricks Model Serving) önerdiği standart rollout güvenlik mekanizmasıdır. Big tech şirketlerin model performans regresyonlarını ürünleştirme öncesi yakalama oranı, Google’ın 2024 ML Engineering Survey’ine göre canary+shadow kombinasyonuyla yaklaşık %78’e ulaşıyor; tek başına blue-green deployment’ta bu oran %41 civarında kalıyor. Bu yazı; canary’nin trafik yönlendirme katmanı, shadow’un payload mirroring mantığı, drift tespit metrikleri, otomatik rollback eşikleri ve gerçek platform implementasyonlarını sayısal verilerle ele alıyor.

1. ML Modelinin Web Hizmetinden Farkı: Neden Klasik Canary Yetmez?

Geleneksel mikroservis canary’sinde başarı ölçütleri sade ve deterministiktir: HTTP 5xx oranı, p99 latency, CPU kullanımı. Bir ML modelinde ise iki yeni katman devreye girer. Birincisi, modelin çıktı kalitesi (örneğin sınıflandırma doğruluğu, sıralama NDCG, üretken modelde toxicity skoru) ground-truth gecikmesi nedeniyle anlık ölçülemez. İkincisi, veri kayması (data drift) trafik karakteristiğine bağlıdır; canary penceresi kısa olursa istatistiksel anlamlılık sağlanamaz. Bu yüzden canary, ML için sadece bir altyapı tekniği değil; bir istatistiksel deney tasarımı sorunudur.

Stanford AI Index 2024 raporu, üretime alınan modellerin yaklaşık %38’inin ilk 90 gün içinde önemli bir performans regresyonu yaşadığını bildiriyor. Bu regresyonların yarıdan fazlası rollout öncesi A/B testi yapılmamış veya yetersiz trafik penceresinde test edilmiş modellerden kaynaklanıyor. Yani sorun çoğunlukla model kalitesi değil; rollout sürecinin disiplinsiz işletilmesi.

Katman	Klasik Mikroservis	ML Modeli
Başarı sinyali	HTTP 2xx oranı, p99 latency	Doğruluk, AUC, NDCG, drift skoru
Ölçüm gecikmesi	Saniyeler	Saatler-günler (ground truth gelene kadar)
Proxy metrik	Genelde gerekmez	Tıklama, satın alma, dwell time
Rollback tetik	Hata oranı eşiği	Drift + iş metriği + altyapı
Risk profili	Hata = 500	Hata = sessiz yanlış cevap

Tabloda görülen “sessiz yanlış cevap” problemi MLOps’un canary tasarımını domine eder. Bir öneri modeli yanlış öneriler verdiğinde 200 OK döner; kullanıcı satın almayı bırakır, sistem hiçbir alarm üretmez. İşte bu yüzden shadow deployment ve proxy metrikler kritik tamamlayıcılardır.

2. Shadow Deployment: Trafik Aynalama Mimarisi

Shadow deployment’ta gelen istek hem üretimdeki mevcut modele (champion) hem de yeni modele (challenger) gönderilir. Sadece champion’ın yanıtı kullanıcıya döner; challenger’ın çıktısı asenkron olarak bir log/sink’e yazılır ve karşılaştırılır. Bu desen, kullanıcıya hiçbir risk yansıtmadan yeni modelin gerçek üretim trafiği altında nasıl davrandığını ölçmeye olanak verir.

Mimarinin üç tipik bileşeni:

• Traffic mirror: Istio VirtualService mirror alanı, Envoy request_mirror_policy veya AWS ALB’nin mirror özelliği. Mirrored istek arka planda “fire-and-forget” gönderilir; kullanıcı latency’sine etki etmez.
• Async inference sink: Challenger model yanıtları doğrudan kullanıcıya değil; Kafka veya Kinesis topic’ine yazılır. Bu yapıyı stream processing pipeline’ı üzerine kurarak gerçek zamanlı diff hesaplama yapabilirsiniz.
• Comparator job: Champion vs challenger çıktılarını eşleştirip diff hesaplayan bir Flink/Spark işi. Klasik metrikler: Jensen-Shannon divergence, KL divergence, kategorik dağılım farkı.

Netflix’in 2023’te yayınladığı “Reliable Machine Learning at Scale” teknik notunda shadow deployment, “model regression önleme stack’inin temel taşı” olarak tanımlanır. Netflix önerideki her yeni modeli en az 7 gün shadow modda çalıştırır; metrik sapması %2’den büyükse canary’ye geçmez. Latency açısından mirror trafiği user-facing path’a etki etmediği için p99’da gözlemlenen artış yaklaşık %0.3 düzeyindedir; ancak GPU maliyeti yaklaşık iki katına çıkar çünkü her istek iki kez inference’a gider.

Shadow Mod Çeşidi	Trafik Yönü	Latency Etkisi	Maliyet Çarpanı	Kullanım Senaryosu
Full mirror (%100)	Her istek aynalanır	~%0.3 artış	~2x	Yüksek kritiklik, büyük model değişikliği
Sampled mirror (%10)	İstek başına dice roll	İhmal edilebilir	~1.1x	Maliyet hassas durumlarda smoke test
Cohort mirror	Sadece belirli kullanıcı segmenti	İhmal edilebilir	~1.05x	Hipotez doğrulama (örn. yeni dil modeli sadece TR kullanıcılarda)
Offline replay	Loglardan oynatılır	0	1x (batch)	İlk gün doğrulama, regression suite

Sampled mirror, küçük ekipler için makul bir başlangıçtır. Istio resmi belgesinde tanımlanan mirrorPercentage alanı bu örnekleme oranını saniyeler içinde ayarlamanıza olanak tanır; deploy yapmadan trafiğin %1’ini %50’ye çekebilirsiniz.

3. Canary Trafik Yönlendirme: Yüzde Eğrileri ve Saat Pencereleri

Canary’de seçilecek üç parametre vardır: başlangıç yüzdesi, artış adımları, her adımda bekleme süresi. Bu üçlü, modelin güven derecesi ve trafik hacmiyle birlikte tasarlanır. Google’ın Site Reliability Workbook’ündeki rollout şablonu, hata oranı kabul edilebilir seviyenin altına düştüğünde dakikalar yerine saatler bekleyen, %5’ten başlayan ve trafiğin %50’sine 6-8 saatte ulaşan bir eğri önerir. ML modelleri için bu süre, ground-truth gecikmesi nedeniyle çoğu zaman 24-72 saate uzar.

Risk Seviyesi	Başlangıç %	Adımlar	Adım Beklemesi	Toplam Süre	Tipik Kullanım
Düşük (bug fix, retrain)	10%	10→25→50→100	30 dk	~2 saat	Aynı mimari, küçük dataset güncellemesi
Orta (feature ekleme)	5%	5→10→25→50→100	2 saat	~10 saat	Yeni feature’lar veya hiperparametre değişikliği
Yüksek (mimari değişiklik)	1%	1→5→10→25→50→100	8 saat	~48 saat	Yeni model ailesi (örn. XGBoost → Transformer)
Kritik (öneri/sıralama core)	0.5%	0.5→2→5→10→25→50→100	12 saat	~84 saat	Ana gelir kanalını yöneten model

Pratikte trafik yönlendirme katmanı, model serving platformuna göre değişir. Kubernetes tabanlı stack’te Istio ya da Linkerd; managed servislerde ise Vertex AI Endpoint trafficSplit, SageMaker Endpoint ProductionVariants ve Azure ML Online Endpoint traffic alanı kullanılır.

• Vertex AI: gcloud ai endpoints update --traffic-split=0=95,1=5 komutu ile mevcut model ID 0’a %95, yeni model ID 1’e %5 yönlendirilir. Resmi Vertex AI deployment dokümanı trafficSplit değişikliğini 30 saniyede uygulamalı olarak işler.
• SageMaker: Endpoint UpdateEndpointWeightsAndCapacities API’si ile DesiredWeight alanı runtime’da değiştirilebilir; deploy gerektirmez.
• Databricks Model Serving: “Served Models” bölümünde her sürüm için traffic_percentage alanı UI’dan veya REST API ile ayarlanır.
• Open-source (KServe): KServe canary rollout dokümanı gereği InferenceService kaynağındaki canaryTrafficPercent alanı bu işlevi sağlar.

4. Drift Tespit ve Otomatik Rollback Eşikleri

Canary’nin durdurulması veya tersine sarılması için kullanılan eşikler, üç ana eksende tanımlanır: altyapı sinyalleri (latency, error rate), model çıktı dağılımı (prediction drift) ve iş metriği (CTR, conversion, return rate). En yaygın istatistiksel testler:

• Population Stability Index (PSI): Tahmin dağılımındaki kayma için. PSI <0.1 kabul, 0.1-0.25 dikkat, >0.25 alarm.
• Kolmogorov-Smirnov (KS) testi: Champion ve challenger tahmin dağılımlarını karşılaştırır. p-value <0.01 ise dağılımlar farklı kabul edilir.
• Jensen-Shannon divergence: Olasılık vektörleri (softmax çıktıları) için sembol-simetrik mesafe. 0.1 üzeri sapma dikkat eşiği.
• Wasserstein mesafesi: Sürekli skorlar (regresyon, recommendation score) için.

Otomatik rollback’te dikkat edilmesi gereken bir nokta: tek metriğe bağlı rollback “flapping”a (ileri-geri salınım) yol açar. AWS SageMaker Deployment Guardrails bu sorunu çözmek için baking period (ısınma süresi) kavramını tanıttı: yeni varyant alarm üretmeden en az X dakika çalışmadan trafik artırılmaz. Tipik baking period 10-30 dakikadır.

Metrik	Yeşil Bölge	Sarı Bölge	Kırmızı Bölge (Auto-Rollback)
p99 latency artışı	<%10	%10-25	>%25
5xx oranı	<%0.1	%0.1-1	>%1
Prediction PSI	<0.1	0.1-0.2	>0.25
CTR sapması (rel.)	±%2	±%2-5	>%5 düşüş
Conversion (rel.)	±%1	±%1-3	>%3 düşüş
Toxicity (LLM)	<%0.05	%0.05-0.15	>%0.15

Bu eşikleri belirlerken modelin iş etkisini bilmek şart. 1 milyar dolarlık e-ticaret sitesinde CTR’daki %1’lik kalıcı düşüş yıllık ~6 milyon dolar gelir kaybı demektir; dolayısıyla %1 eşiği “sarı” değil “kırmızı” olabilir. Doğru eşiklerin belirlenmesi pratik bir iş analizi konusudur; üzerinde Ömer Önal danışmanlık görüşmeleri sırasında sıkça konuşulan başlıklardandır.

5. Multi-Armed Bandit ve A/B Test ile Canary Karşılaştırması

Canary, A/B test ve multi-armed bandit (MAB) sıklıkla karıştırılır. Üçü de trafik bölme yapar ama amaçları farklıdır.

Yöntem	Amaç	Trafik Tahsisi	İstatistiksel Çerçeve	Süre	Riskli mi?
Canary	Güvenli rollout	Tek yönlü artış (%1 → %100)	Eşik tabanlı, hipotez testi opsiyonel	Saatler-günler	Asıl amaç riski sınırlamak
A/B test	Karar verme	Sabit %50/%50 veya N’li	Hipotez testi, frequentist	1-4 hafta	Test süresince her grup gerçek trafik alır
MAB (Thompson sampling, UCB)	Maksimum kümülatif ödül	Dinamik, gözleme bağlı	Bayesyen veya regret-bounded	Sürekli	İyi varyantı hızla öne çıkarır; istatistiksel güç düşebilir

Pratik öneri: Canary’yi rollout güvenlik mekanizması olarak, A/B testi karar mekanizması olarak, MAB’ı sürekli optimizasyon mekanizması olarak kullanın. Birini diğerinin yerine geçirmeyin. Microsoft Research ExP Platform üzerinde yapılan binlerce deneyin yaklaşık %30’u canary aşamasında elendi; A/B’ye geçenlerin de yaklaşık üçte ikisi metrik iyileştirmedi. Yani canary, A/B’den önce gelen bir filtredir, alternatifi değildir; iki yöntemi de aynı rollout’ta sıralı şekilde kullanmak, sessiz regresyon riskini ciddi ölçüde düşürür.

Veri katmanı tarafında canary metrikleri çoğunlukla geniş tablolarda toplanır. dbt analytics engineering ile tanımlanan transformasyon katmanı bu metrik tablolarının versiyonlanmasını ve test edilmesini kolaylaştırır.

6. Feature Store ve Online/Offline Tutarlılığı

Canary sırasında ortaya çıkan en sinsi hata, training-serving skew’dir. Model offline eğitildiği feature’ı online inference sırasında biraz farklı hesaplarsa, kullanıcının gördüğü çıktı eğitimdekinden farklı olur ve canary metrikleri açıklanamaz şekilde sapar. Feature store (Feast, Tecton, Vertex AI Feature Store, Databricks Feature Engineering) bu skew’i azaltır.

• Avantaj: Aynı feature tanımı online ve offline pipeline’da kullanılır; entity-key bazlı point-in-time correctness sağlanır.
• Dezavantaj: Yeni bir altyapı katmanı; küçük ekiplerde overhead getirir.
• Ne zaman seç: 10’dan fazla model üretimde, 100’den fazla feature paylaşılıyor veya birden fazla ekip aynı feature’ı kullanıyor.
• Ne zaman pas geç: 1-2 modelle başlangıç aşamasındaki ekipler için FeatureGroup seviyesinde Spark/SQL view’leri yeterlidir.

Tecton’un 2024 müşteri raporu, feature store adoption’ından sonra training-serving skew kaynaklı incident sayısının ortalama %62 azaldığını bildiriyor. Açık kaynak Feast (feast-dev/feast) deposundaki örnek pipeline’lar, feature versiyonlamanın point-in-time correctness için neden vazgeçilmez olduğunu gösterir. Feature versiyonlama, feature store’un altın özelliğidir; canary’de yeni modelin yeni feature versiyonunu, eski modelin eski versiyonu görmesini sağlar. Bu izolasyon olmadan canary sonuçları karışır; sapma feature kaymasından mı, model değişikliğinden mi geldiği ayırt edilemez.

7. LLM ve Üretken Model Canary’sinin Özellikleri

Klasik ML modellerinin canary’si sayısal metriklere (accuracy, RMSE, AUC) yaslanırken üretken modellerde (LLM, image, audio) durum farklıdır. Çıktı serbest metindir; ground truth yoktur. Bu yüzden 2024-2026 dönemi LLMOps pratikleri canary için proxy ve LLM-as-a-judge kombinasyonunu öne çıkardı.

Metrik Sınıfı	Örnek	Ölçüm Şekli	Gecikme
Altyapı	Tokens/sec, p99 TTFT, GPU saturasyonu	Servis taraflı log	Anlık
Üretim kalite proxy	Yanıt uzunluğu dağılımı, perplexity, refusal rate	Stream parser	Saniyeler
Güvenlik	Toxicity, jailbreak başarısı, PII sızıntısı	Detoxify/PII scanner	Anlık
LLM-as-a-judge	Helpfulness, faithfulness puanı (1-5)	Bağımsız LLM’e değerlendirme prompt’u	Saniye-dakika
İnsan geri bildirim	Thumbs up/down, regenerate rate	UI event	Saatler
İş metriği	Session uzunluğu, paid conversion	Analytics	Günler

OpenAI’ın 2024’te yayınladığı “Deploying Frontier Models” tartışması, GPT-4o’nun rollout’unda en az 14 gün shadow deployment ve 21 gün canary uygulandığını ima ediyor. Anthropic’in Claude 3.5 Sonnet duyurusu da yeni sürümün öncelikle “canary cohort” üzerinde test edildiğini belirtir. Üretken modellerde “regenerate rate” (kullanıcının çıktıyı yeniden ürettirme sıklığı) çok güvenilir bir kalite proxy’sidir; %5 üzerindeki ani artış neredeyse her zaman model regresyonuna işaret eder.

LLM canary’sinin RAG (retrieval-augmented generation) pipeline’ları olan sistemlerdeki ek katmanı, vektör veritabanı katmanıdır. Retrieval kalitesi (recall@k) ve embedding modeli versiyonu da canary’nin değerlendireceği değişkenler arasındadır.

8. Veri Katmanı: Canary Metriklerinin Toplanması ve Analizi

Canary kararı, çiğ ham veriden değil, agregat metriklerden alınır. Bu agregatları üreten katman, MLOps’tan çok veri mühendisliğinin alanıdır. Tipik bir pipeline:

1. Event capture: Inference servisi her isteği (model versiyon, latency, predicted class, gerçek event sonrasında label) bir Kafka topic’ine yazar.
2. Stream aggregate: Flink veya Spark Structured Streaming, model versiyon başına 1 dakikalık pencerelerde count, p99 latency, prediction histogramı üretir.
3. OLAP store: Toplulaştırılmış metrikler Druid/Pinot/ClickHouse’a yazılır; saniyeler içinde sorgulanır.
4. Decisioner: Bir cron veya Argo Workflow eşikleri kontrol eder; rollback gerekiyorsa traffic split API’sını çağırır.

OLAP katmanını seçerken Druid, Pinot ve Trino karşılaştırması referans bir okuma; canary panellerinde p50/p99 latency 100ms altında sorgulanabilen bir motor seçilmelidir. Snowflake veya BigQuery gibi MPP motorları interaktif dashboard’lar için bazen yetersiz kalır; canary için saniyelik tepki şart.

Düşük hacimli (örn. günde <100K istek) modellerde sadece offline replay yeterli olabilir; veri katmanı yüksek hacimli pipeline’da kritikleşir. Spark/Kafka big data pipeline’ı bu metrik akışının omurgasını oluşturur.

9. Maliyet, Risk ve Karar Matrisi

Canary ve shadow deployment bedava değildir. Shadow için ikinci bir inference kümesi gerekir (CPU veya GPU); canary için ek monitoring ve alerting; her ikisi için de ekip eğitimi. Maliyet-fayda analizi yapmadan “her model shadow + canary” politikası küçük ekipleri bunaltır.

Senaryo	Shadow	Canary	A/B	Tahmini Ek Maliyet
Düşük trafik, düşük risk model	Hayır	Basit (10→50→100)	Opsiyonel	+%5
Orta trafik, orta risk	Sampled (%10)	5 adımlı, 2 saat bekleme	Önemli kararlarda	+%15
Yüksek trafik (öneri, sıralama)	Full mirror (%100)	0.5→2→…→100, 12 saat bekleme	Evet, 2 hafta	+%80-120
Frontier LLM	Full + LLM-judge	Cohort tabanlı, 7-21 gün	Sürekli	+%150-200

• Avantaj: Shadow + canary kombinasyonu, üretim incident’larını yaklaşık %78 oranında erken yakalar.
• Dezavantaj: Shadow için GPU maliyeti, canary için süre uzaması (release velocity düşer).
• Ne zaman seç: Modelin yanlış cevabı doğrudan iş metriğine (gelir, güvenlik) yansıyorsa.
• Ne zaman atla: Düşük trafiğe sahip, kolayca rollback’e uygun, etkisi sınırlı internal araçlarda offline test + simple blue-green yeterli olabilir.

Bir başka kritik katman da veri yönetişimi: Shadow mod log’larında PII ve hassas veri çoğalır. GDPR/KVKK uyumlu veri yönetişimi çerçevesinde retention ve maskeleme politikaları shadow log’lara da uygulanmalıdır.

10. Sık Sorulan Sorular (SSS)

Sonuç

Model rollout’u 2026 itibarıyla artık “bir konteyner deploy’u” değil; istatistiksel tasarım, trafik mühendisliği ve iş analizi ihtiva eden çok katmanlı bir disiplindir. Shadow deployment, kullanıcıya hiçbir risk yansıtmadan modelin gerçek trafik altında davranışını gözlemler; canary, kontrollü ve geri alınabilir biçimde gerçek kullanıcılara açılmayı sağlar. İkisini birlikte uygulayan ekipler, sessiz model regresyonlarının yaklaşık dörtte üçünü üretime sızdırmadan yakalıyor. Bu, milyonlarca isteği yöneten sistemlerde doğrudan gelir koruması demek.

Karar çerçevesi olarak şunu öneririm: Düşük risk + düşük trafik = basit canary (10→50→100). Orta risk + orta trafik = sampled shadow + 5 adımlı canary. Yüksek risk veya core gelir kanalı = full shadow + cohort tabanlı yavaş canary + A/B test. Frontier LLM’lerde bu üçü artı LLM-as-a-judge ile insan geri bildirim. Yatırım yaptığınız her ek katman, regression’ı erken yakalama olasılığını artırırken release velocity’yi düşürür; doğru denge ekibinizin olgunluğu ve modelin iş etkisine göre belirlenir.

Üretim ML sisteminizin rollout disiplinini olgunlaştırmak için adım adım bir plana ihtiyacınız varsa iletişim sayfası üzerinden değerlendirme görüşmesi planlayabiliriz; mevcut pipeline’ınızı inceleyip canary ve shadow için somut bir yol haritası çıkarabiliriz.