Canary Deployment Stratejisi

Test ortamında her şey yeşildi, birim testler geçti, staging'de bir hafta bekledi. Sonra canlıya aldın ve on dakika içinde bellek tüketimi tavan yaptı, çünkü gerçek kullanıcıların ürettiği veri hacmi test verinden iki kat büyüktü. Canary deployment tam olarak bu boşluğu kapatmak için vardır: yeni sürümü tüm kullanıcılara değil, önce trafiğin küçük bir yüzdesine açarsın, metrikleri izlersin ve sadece iyi görünüyorsa yüzdeyi kademeli olarak yükseltirsin.

Bu rehberde canary deployment'ın mantığını, trafiği yüzde bazında bölmenin Nginx tarafındaki somut yapılandırmasını, hangi metrikleri hangi eşiklerle izlemen gerektiğini, oturum yapışkanlığı gibi kolay gözden kaçan tutarlılık sorunlarını ve otomatik geri dönüşün nasıl kurulacağını anlatacağım. Amacım, yayın kararını "içime sinmedi" hissiyle değil, ölçülebilir bir eşikle verebilmen.

Canary Deployment Nedir ve Neyi Çözer#

Adı, madencilerin zehirli gaz olup olmadığını anlamak için ocağa soktuğu kanaryadan gelir: kanarya önce girer, tehlike varsa önce o etkilenir, madenciler geri çıkar. Yazılımda kanarya, yeni sürümü çalıştıran küçük bir örnek grubudur. Trafiğin diyelim %5'i ona gider, %95'i eski sürümde kalır. Bir sorun varsa yalnızca kullanıcıların yirmide biri etkilenir ve sen bunu metriklerde eski sürümle karşılaştırarak dakikalar içinde görürsün.

Canary'nin blue-green'den farkı, kararın ikili olmamasıdır. Blue-green deployment ya herkesi eski ya herkesi yeni sürüme yönlendirir; bu, geri dönüşü basitleştirir ama hataları gerçek trafikle kademeli keşfetme şansını vermez. Canary ise yeni sürümü üretim koşullarında, gerçek kullanıcı davranışıyla ve sınırlı hasar yarıçapıyla sınamanı sağlar. Bedeli, iki sürümü aynı anda üretimde tutmanın getirdiği karmaşıklıktır: veritabanı şeması, önbellek anahtarları ve API sözleşmeleri iki sürümle de uyumlu olmak zorundadır.

Trafiği Yüzde ile Bölmek#

Ağırlıklı yönlendirme, Nginx'in upstream bloğundaki weight parametresiyle yapılır. Ağırlıklar oransaldır: weight=19 ve weight=1 yazarsan trafiğin yirmide biri kanaryaya gider. Aşağıdaki yapılandırma, blue-green'de olduğu gibi aktif hedefi ayrı bir dosyada tutar; kanarya yüzdesini değiştirmek tek satırlık bir düzenlemeye iner.

# /etc/nginx/conf.d/upstream-canary.conf
upstream app_pool {
    # Kararlı sürüm (v1.4) — trafiğin %95'i
    server 127.0.0.1:8081 weight=19 max_fails=3 fail_timeout=10s;
    # Kanarya (v1.5) — trafiğin %5'i
    server 127.0.0.1:8082 weight=1  max_fails=3 fail_timeout=10s;
}

server {
    listen 443 ssl http2;
    server_name firmaniz.com;

    location / {
        proxy_pass http://app_pool;
        proxy_set_header Host            $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        # Hangi sürümün cevap verdiğini loglara ve tarayıcıya yaz
        add_header X-App-Upstream $upstream_addr always;
    }
}

add_header X-App-Upstream satırını atlama; kanarya çalışırken "bu hatayı hangi sürüm üretti" sorusunun cevabı budur. Ağırlık yerine belirli kullanıcıları hedeflemek istiyorsan, split_clients yönergesiyle istemci IP'sine ya da bir çereze göre tutarlı bir bölme de yapabilirsin.

# Aynı ziyaretçi her istekte aynı gruba düşsün diye çerez tabanlı bölme
split_clients "${cookie_visitor_id}" $app_target {
    5%     "127.0.0.1:8082";  # kanarya
    *      "127.0.0.1:8081";  # kararlı
}

Kademeli Yayın Planı: Yüzdeleri Nasıl Seçersin#

Yüzdeleri rastgele seçme; her adımın bir gözlem süresi ve bir çıkış kriteri olsun. Genel olarak izlediğim ve çoğu ekibe önerdiğim plan şudur:

1. %1 – 15 dakika. Amaç, "hiç çalışmıyor" sınıfı hataları yakalamak. Beş yüz hatası, açılmayan sayfa, patlayan bağımlılık burada görünür.
2. %5 – 30 dakika. İlk anlamlı istatistiksel kıyas. Hata oranı ve gecikme kararlı sürümle karşılaştırılabilir hale gelir.
3. %25 – 1 saat. Kaynak tüketimi, bağlantı havuzu doygunluğu ve veritabanı yükü gibi ölçek etkileri burada ortaya çıkar.
4. %50 – 2 saat. Bu adım, trafiğin bir günlük tepe noktasına denk gelecek şekilde planlanmalı.
5. %100 – kalıcı. Eski sürümü hemen kapatma; en az bir gün ayakta bırak.

Düşük trafikli bir sitede %1 adımını atlaman gerekebilir: saatte 200 istek alan bir uygulamada %1, on beş dakikada tek haneli istek demektir ve hiçbir şey ölçemezsin. Kural şu: bir adımın anlamlı olması için o adımda en az birkaç yüz istek toplanmalı. Ölçemeyeceğin bir yüzdede beklemek, yalnızca yayını geciktirir.

Hangi Metrikleri, Hangi Eşiklerle İzlersin#

Canary'nin tüm değeri karşılaştırmadadır. Kanaryanın mutlak hata oranına değil, kararlı sürümle arasındaki farka bakarsın; çünkü uygulamanın taban hata oranı zaten sıfır olmayabilir. İzlemen gereken dört temel sinyal şunlardır: hata oranı, gecikme, doygunluk (CPU, bellek, bağlantı sayısı) ve iş metrikleri. Sonuncusu en çok atlanandır: teknik olarak sağlıklı görünen bir sürüm, sepete ekleme oranını yarıya düşürüyor olabilir.

# Nginx erişim loglarından son 5 dakikadaki 5xx oranını üst sunucu bazında çıkar
awk -v since="$(date -d '5 minutes ago' '+%d/%b/%Y:%H:%M')" '
  $4 > "["since {
    split($0, a, "\"");
    total[$NF]++;
    if ($9 ~ /^5/) err[$NF]++;
  }
  END {
    for (u in total)
      printf "%s  istek=%d  5xx=%d  oran=%.2f%%\n", u, total[u], err[u], (err[u]/total[u])*100;
  }' /var/log/nginx/access.log

Eşikleri önceden yaz ve tartışmaya açma; canlı bir olay sırasında "biraz daha bekleyelim" demek insan doğasıdır ve tam da bu yüzden eşikler önceden belirlenir. Pratikte işe yarayan bir başlangıç seti: kanaryanın 5xx oranı kararlı sürümün oranından mutlak olarak 0,5 puandan fazla yüksekse dur; p95 yanıt süresi %20'den fazla artmışsa dur; bellek kullanımı sabit trafikte sürekli artıyorsa (sızıntı işareti) dur. Bu eşiklerin nereden geldiğini ve hizmet seviyesi hedefleriyle ilişkisini SRE, SLO ve error budget yazısında ayrıntılı ele aldım.

Oturum Yapışkanlığı ve Tutarlılık#

Ağırlıklı yönlendirmenin sinsi bir yan etkisi vardır: aynı kullanıcı arka arkaya iki istekte iki farklı sürüme düşebilir. Sayfayı yeni sürümden alıp içindeki API çağrısını eski sürüme yapan bir tarayıcı, alan adları uyuşmayan bir yanıt alır ve arayüz bozulur. Bu, canary'de en sık karşılaştığım "sürüm karışması" hatasıdır ve testte asla görünmez.

Çözüm, bölmeyi istek başına değil kullanıcı başına yapmaktır. Nginx tarafında sticky (yapışkan) oturum ya da yukarıdaki split_clients yaklaşımı bunu sağlar: bir kez kanaryaya düşen ziyaretçi, çerez değişene kadar kanaryada kalır.

# Kullanıcıya bir kez kimlik çerezi ver; bölme bu çerez üzerinden yapılsın
map $cookie_visitor_id $needs_id {
    ""      1;
    default 0;
}

server {
    location / {
        if ($needs_id) {
            add_header Set-Cookie "visitor_id=$request_id; Path=/; Max-Age=86400; HttpOnly; SameSite=Lax";
        }
        proxy_pass http://$app_target;
    }
}

İkinci tutarlılık kuralı, iki sürümün paylaştığı her şeyin ileri ve geri uyumlu olmasıdır. Önbellek anahtarlarını sürüm numarasıyla ayır, aksi halde yeni sürümün yazdığı biçimi eski sürüm okuyamaz. Veritabanı şemasını genişlet-daralt düzeninde değiştir. Kuyruğa yazılan mesajların şeması değişiyorsa, eski tüketicinin bilmediği alanları görmezden gelebildiğinden emin ol.

Otomatik Geri Dönüş Kurmak#

Elle izlenen bir canary, gece yarısı çalışmayan bir canary'dir. Adımlar arasında ilerlemeyi ve eşik aşıldığında geri dönmeyi bir betiğe devretmek, yöntemin gerçek faydasını ortaya çıkarır. Aşağıdaki basit denetleyici, hata oranını yoklar ve eşik aşılırsa kanaryayı sıfırlar.

#!/usr/bin/env bash
set -euo pipefail
UPSTREAM=/etc/nginx/conf.d/upstream-canary.conf
STEPS=(1 5 25 50 100)          # kanarya yüzdeleri
WAIT=(900 1800 3600 7200 0)    # her adımda beklenecek saniye

set_weight() {  # $1 = kanarya yüzdesi
  local canary=$1 stable=$((100 - $1))
  cat > "$UPSTREAM" <<CONF
upstream app_pool {
    server 127.0.0.1:8081 weight=${stable};
    server 127.0.0.1:8082 weight=${canary};
}
CONF
  nginx -t && systemctl reload nginx
}

rollback() {
  echo "EŞİK AŞILDI — kanarya kapatılıyor."
  set_weight 0
  exit 1
}

for i in "${!STEPS[@]}"; do
  set_weight "${STEPS[$i]}"
  echo "Kanarya %${STEPS[$i]} — ${WAIT[$i]} sn gözlem"
  sleep "${WAIT[$i]}"
  # Kendi metrik uç noktandan hata oranı farkını al (yüzde puan olarak)
  DIFF=$(curl -fsS http://127.0.0.1:9090/canary/error-delta || echo 99)
  awk -v d="$DIFF" 'BEGIN { exit (d > 0.5) ? 0 : 1 }' && rollback
done
echo "Kanarya %100 — yayın tamamlandı."

Bu betiğin kritik noktası || echo 99 kısmıdır: metrik uç noktasına ulaşılamıyorsa varsayılan davranış "iyi kabul et" değil, "geri dön" olmalıdır. Ölçemediğin bir şeyi güvenli varsaymak, canary'nin varlık sebebini ortadan kaldırır.

Sık Yapılan Hatalar#

En yaygın hata, kanaryayı çok kısa süre gözlemlemektir. Beş dakikada geçen bir kanarya yalnızca "açılıyor mu" sorusunu yanıtlar; bellek sızıntısı, bağlantı havuzu tükenmesi ve gece çalışan toplu işler saatler sonra ortaya çıkar. İkinci yaygın hata, kanaryayı yalnızca iç ağdan ya da tek bir test hesabıyla denemektir; o zaman zaten gerçek trafikle sınamış olmazsın ve elinde sadece karmaşık bir staging kurulumu kalır.

Diğer tuzaklar da şunlar:

• Kanaryaya farklı kaynak vermek. Kanarya iki kat CPU'lu bir makinede çalışıyorsa gecikme karşılaştırması anlamsızdır. İki taraf da aynı donanım profilinde olmalı.
• Loglarda sürüm etiketi olmaması. Hangi kaydın hangi sürümden geldiğini ayırt edemiyorsan karşılaştırma yapamazsın. Uygulama loglarına sürüm alanı ekle; konteyner loglarını okuma yöntemleri için Docker log ve exec rehberine bakabilirsin.
• Geri dönüşü hiç denememek. Rollback yolunu ilk kez gerçek bir olayda denemek en kötü senaryodur. Kanaryayı en az bir kez bilerek geri al ve süreyi ölç.
• Veritabanı yazma şemasını kanaryada değiştirmek. Kanarya, geri alınabilir olmalıdır; geri alınamayan bir yazma işlemi bu güvenceyi bozar.

Sıkça Sorulan Sorular#

Canary deployment küçük trafikli siteler için uygun mu#

Trafiğin çok düşükse %1'lik bir dilim istatistiksel olarak anlamsız kalır; on beş dakikada yalnızca birkaç istek toplarsın ve hiçbir şey ölçemezsin. Bu durumda ya yüzdeleri yükselt (%10 ile başla) ya da kademeli yüzde yerine feature flag kullanarak belirli kullanıcıları hedefle. Küçük kurulumlarda blue-green genellikle daha az karmaşık ve yeterince güvenlidir.

Canary ile blue-green arasındaki fark nedir#

Blue-green tüm trafiği tek hamlede eski sürümden yeni sürüme çevirir; karar ikilidir. Canary ise trafiği yüzde bazında böler ve yeni sürümü kademeli olarak açar. Blue-green kurması daha basit ve geri dönüşü daha nettir; canary ise hataları sınırlı hasar yarıçapıyla gerçek trafikte yakalamanı sağlar. Çoğu ekip ikisini birleştirir: iki ortam kurar, geçişi tek seferde değil kademeli ağırlıklarla yapar.

Canary aşaması ne kadar sürmeli#

Kanaryanın toplam süresi uygulamanın doğasına bağlıdır ama pratik bir alt sınır birkaç saattir. Yalnızca web isteklerine bakan bir API'de bir saat yeterli olabilirken, gece toplu iş çalıştıran bir sistemde en az bir tam gün gerekir; çünkü bazı kod yolları yalnızca o işlerle tetiklenir. Kural olarak, uygulamanın tüm periyodik görevleri en az bir kez çalışmadan kanaryayı %100'e çıkarma.

Kanaryaya düşen kullanıcılar bunu fark eder mi#

Doğru kurulmuşsa hayır. Kullanıcı yalnızca yeni sürümün getirdiği görünür değişiklikleri görür; hangi ortama düştüğüne dair bir işaret olmaz. Ancak oturum yapışkanlığı kurmazsan aynı kullanıcı sayfa yenilemelerinde farklı sürümler arasında gidip gelir ve arayüz tutarsızlığı olarak bunu fark eder. Bu yüzden bölmeyi istek başına değil, çerez ya da kullanıcı kimliği üzerinden yap.

Otomatik geri dönüş için hangi metriği kullanmalıyım#

Tek bir metrik yeterli değildir ama başlangıç için en güvenilir ikili, sunucu hata oranı (5xx) ve p95 yanıt süresidir. Bunları mutlak değer olarak değil, kararlı sürümle farkı olarak ölç. Olgunlaştıkça iş metriklerini de ekle: kayıt tamamlama, sepete ekleme veya ödeme başarı oranı gibi. Teknik olarak sağlıklı görünüp dönüşümü düşüren bir sürüm, hata veren bir sürüm kadar zararlıdır.

Kanarya ve kararlı sürüm aynı veritabanını kullanabilir mi#

Evet ve pratikte çoğu kurulumda öyle olur; iki ayrı veritabanı kullanırsan kanaryada oluşan veriyi kaybedersin. Bunun bedeli, şemanın her iki sürümle de uyumlu olma zorunluluğudur. Sütun silme veya yeniden adlandırma gibi geri alınamaz değişiklikleri kanarya aşamasında yapma; önce ekle, iki sürüm bir süre birlikte yaşasın, eskisini bir sonraki dağıtımda temizle.

Kapanış#

Canary deployment'ı işe yarar kılan şey trafiği bölmek değil, o bölmeyi ölçülebilir hale getirmektir. Aklında kalması gereken dört alışkanlık şunlar: yüzdeleri önceden planlanmış adımlar halinde yükselt, her adım için minimum gözlem süresi ve net bir çıkış eşiği belirle, bölmeyi istek başına değil kullanıcı başına yap ve metrik ölçülemiyorsa varsayılan kararın "geri dön" olsun. Geri dönüş yolunu gerçek bir olaydan önce en az bir kez prova etmeyi de listenin başına yaz.

İki sürümü yan yana çalıştırmak ve trafiği önlerinde bölmek için esnek kaynağa ihtiyacın olacak; bulut sunucu ve VDS paketlerimiz bu tür kademeli yayın kurulumları için uygun bir zemin sunar. Nginx ağırlıklarını, metrik toplamayı ve otomatik geri dönüş betiklerini kendin kurmak istemiyorsan sunucu yönetimi hizmetimiz kurulumu ve izlemeyi üstlenir; yayın anında gelen ani trafik dalgalarına karşı DDoS koruma katmanımıza da göz atabilirsin.