Sıfır Kesinti Süreli Dağıtım Stratejileri: Güncellemeler Sırasında Uygulamanızın Çalışmasını Sağlayın

Planlı kesinti süresi işletmelere dakika başına ortalama 5.600 ABD dolarına mal oluyor. Ancak şirketlerin %43'ü dağıtım sırasında uygulamalarını hâlâ çevrimdışına alıyor. Sıfır kesinti süreli dağıtım bir lüks değil, bir beklentidir. Müşteriler, arama motorları ve entegrasyon ortakları, kısa süreliğine de olsa çevrimdışı olan uygulamaları cezalandırır.

Bu kılavuz, üç temel sıfır kesinti süreli dağıtım stratejisini, çalışma süresini koruyan veritabanı geçiş tekniklerini ve otomatik geri alma mekanizmalarını kapsar.

Önemli Çıkarımlar

• Mavi-yeşil dağıtım en güvenli stratejidir: trafiği önceki sürüme döndürerek anında geri alma
• Veritabanı geçişleri geriye dönük olarak uyumlu olmalıdır --- eski uygulama sürümü yeni şemayla çalışmalıdır
• Durum denetimleri ve hazırlık araştırmaları, trafiğin hizmet vermeye hazır olmayan bölmelere yönlendirilmesini önler
• Hata oranı izlemeyi temel alan otomatik geri alma, ortalama kurtarma süresini 2 dakikanın altına düşürür

---

Strateji Karşılaştırması

---

Mavi-Yeşil Dağıtım

Mimarlık

Load Balancer
    |
    |--- [ACTIVE] Blue environment (v2.0.0) <-- receives 100% traffic
    |
    |--- [IDLE] Green environment (v2.1.0) <-- deployed, tested, waiting

Dağıtımda:

1. V2.1.0'ı boş (yeşil) ortama dağıtın
2. Yeşile karşı duman testleri yapın
3. Yük dengeleyiciyi yeşile çevirin
4. Mavi boşta kalır (anında geri alma için kullanılabilir)

Nginx ile Uygulama

# /etc/nginx/conf.d/app.conf
upstream blue {
    server 10.0.1.10:3000;
    server 10.0.1.11:3000;
}

upstream green {
    server 10.0.2.10:3000;
    server 10.0.2.11:3000;
}

# Active environment - change this during deployment
map $host $active_upstream {
    default blue;  # Change to 'green' to switch
}

server {
    listen 443 ssl;
    server_name app.example.com;

    location / {
        proxy_pass http://$active_upstream;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

Dağıtım Komut Dosyası

#!/bin/bash
set -e

CURRENT=$(cat /etc/nginx/active-env)  # "blue" or "green"
TARGET=$( [ "$CURRENT" = "blue" ] && echo "green" || echo "blue" )

echo "Current: $CURRENT, deploying to: $TARGET"

# Deploy to inactive environment
ssh "deploy@$TARGET-1" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"
ssh "deploy@$TARGET-2" "cd /opt/app && git pull && pnpm install --frozen-lockfile && pnpm build && pm2 restart all"

# Wait for health checks
for i in 1 2; do
  echo "Checking $TARGET-$i health..."
  for attempt in $(seq 1 30); do
    if curl -sf "http://$TARGET-$i:3000/health" > /dev/null; then
      echo "$TARGET-$i is healthy"
      break
    fi
    sleep 2
  done
done

# Run smoke tests
pnpm test:smoke --base-url "http://$TARGET-1:3000"

# Switch traffic
sed -i "s/default $CURRENT/default $TARGET/" /etc/nginx/conf.d/app.conf
nginx -s reload
echo "$TARGET" > /etc/nginx/active-env

echo "Traffic switched to $TARGET. Rollback: change active-env back to $CURRENT"

---

Devamlı Güncelleme

Devam eden güncellemeler örnekleri aşamalı olarak değiştirerek bir miktar kapasitenin her zaman kullanılabilir olmasını sağlar.

Kubernetes Devamlı Güncellemesi

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # Create 1 extra pod during update
      maxUnavailable: 0   # Never reduce below desired replicas
  template:
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.1.0
          readinessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 5
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 3001
            initialDelaySeconds: 15
            periodSeconds: 10

maxSurge: 1 ve maxUnavailable: 0 ile sürekli güncelleme işlemi:

1. v2.1.0 ile 1 yeni bölme oluşturun (toplam 6 bölme: 5 eski + 1 yeni)
2. Yeni bölme hazırlığı sondasının geçmesini bekleyin
3. 1 eski bölmeyi sonlandırın (5 bölme: 4 eski + 1 yeni)
4. Başka bir yeni bölme oluşturun (6 bölme: 4 eski + 2 yeni)
5. Tüm bölmeler v2.1.0 olana kadar tekrarlayın

---

Kanarya Dağıtımı

Trafik Bölme

# Istio VirtualService for canary routing
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: api-canary
spec:
  hosts:
    - api.example.com
  http:
    - route:
        - destination:
            host: api-stable
            port:
              number: 3001
          weight: 95
        - destination:
            host: api-canary
            port:
              number: 3001
          weight: 5

Aşamalı Kanarya Sunumu

---

Kesinti Olmadan Veritabanı Taşıma İşlemleri

Sıfır kesinti süreli dağıtımdaki en büyük zorluk, veritabanı şeması değişiklikleridir. Eski uygulama sürümü yeni şemayla çalışmalıdır ve bunun tersi de geçerlidir.

Genişletme-Sözleşme Modeli

Aşama 1: Genişletme (şema değişikliğini dağıtma)

-- Add new column (nullable, no default)
ALTER TABLE orders ADD COLUMN shipping_method VARCHAR(50);

Eski uygulama kodu yeni sütunu yok sayar. Yeni uygulama kodu hem eski hem de yeni sütunlara yazar.

2. Aşama: Verileri taşıyın

-- Backfill existing data
UPDATE orders SET shipping_method = 'standard' WHERE shipping_method IS NULL;

Aşama 3: Sözleşme (özel olarak yeni sütunu kullanan kodu dağıtın)

Tüm uygulama örnekleri yeni sütunu kullandıktan sonra:

-- Make column required
ALTER TABLE orders ALTER COLUMN shipping_method SET NOT NULL;
ALTER TABLE orders ALTER COLUMN shipping_method SET DEFAULT 'standard';

Tehlikeli Göç Modelleri

---

Otomatik Geri Alma

Hata Oranına Dayalı Geri Alma

#!/bin/bash
# post-deploy-monitor.sh

DEPLOY_TIME=$(date +%s)
MONITOR_DURATION=300  # 5 minutes
ERROR_THRESHOLD=0.02  # 2%

while [ $(($(date +%s) - DEPLOY_TIME)) -lt $MONITOR_DURATION ]; do
  ERROR_RATE=$(curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{status=~'5..'}[2m])/rate(http_requests_total[2m])" | jq -r '.data.result[0].value[1]')

  if (( $(echo "$ERROR_RATE > $ERROR_THRESHOLD" | bc -l) )); then
    echo "ERROR: Rate $ERROR_RATE exceeds threshold $ERROR_THRESHOLD"
    echo "Initiating rollback..."
    kubectl rollout undo deployment/api
    exit 1
  fi

  sleep 15
done

echo "Deployment healthy for $MONITOR_DURATION seconds"

---

Sıkça Sorulan Sorular

Hangi stratejiyle başlamalıyız?

Mavi-yeşil dağıtımla başlayın. Uygulanması en basit olanıdır, anında geri alma sağlar ve her türlü uygulama mimarisiyle çalışır. Sürekli güncellemeler, çok sayıda replika içeren Kubernetes ortamları için daha iyidir. Canary dağıtımları, tam kullanıma sunmadan önce değişiklikleri gerçek trafikle doğrulamak istediğiniz yüksek trafikli uygulamalara yöneliktir.

Dağıtım sırasında uzun süredir devam eden arka plan işlerini nasıl hallederiz?

Zarif kapatmayı kullanın. Bir bölme bir sonlandırma sinyali aldığında, yeni işleri kabul etmeyi bırakın, devam eden işleri (zaman aşımı ile) bitirin ve ardından kapatın. Kubernetes'te işlerin tamamlanması için yeterli süreyi sağlayacak şekilde terminationGracePeriodSeconds öğesini yapılandırın. Yetkisiz kullanım süresinden daha uzun süren işler için, başarısız işleri hayatta kalan işçiler üzerinde yeniden deneyen bir iş kuyruğu (Redis, RabbitMQ) kullanın.

Dağıtım sırasında WebSocket bağlantıları ne olacak?

WebSocket bağlantıları uzun ömürlüdür ve dikkatli kullanılmalıdır. Devamlı güncelleme sırasında, eski bölmedeki mevcut bağlantılar bölme sonlandırılana kadar etkin kalır. İstemciler otomatik yeniden bağlanma mantığını uygulamalıdır. Mavi-yeşil dağıtımlar için, mevcut bağlantıların bir zaman aşımı ile eski ortamdan tüketilmesine izin verirken yeni bağlantıları yeni ortama geçirin.

Sıfır kesinti süreli dağıtımları nasıl test ederiz?

Dağıtım sırasında bir yük testi çalıştırın. Sürekli trafik oluşturmak için k6 veya benzer bir araç kullanın, ardından dağıtımı tetikleyin. Devralma sırasında herhangi bir hata, artan gecikme veya kopmuş bağlantı olup olmadığını kontrol edin. Uygulama ayrıntıları için yük testi kılavuzumuza bakın.

---

Sırada Ne Var?

Sıfır kesinti süreli dağıtım, sık ve güvenli sürümler için bir ön koşuldur. Tam dağıtım hattı için bunu CI/CD otomasyonu ve dağıtım sonrası doğrulama için izleme ile birleştirin.

Dağıtım stratejisi danışmanlığı için ECOSIRE ile iletişime geçin veya altyapı yol haritasının tamamı için DevOps kılavuzumuzu inceleyin.

---

ECOSIRE tarafından yayınlandı - işletmelerin kesinti olmadan dağıtım yapmasına yardımcı oluyor.