Çoklu CDN Stratejisi ve Yük Dengeleme: Kapsamlı Rehber

Tarafındankomut
0 Yorum

Bir gün üretim ortamınızda tek CDN sağlayıcınızın kesintiye uğradığını düşünün. Tüm statik varlıklarınız erişilemez, kullanıcılar boş sayfalar görüyor ve siz panik halinde destek hattını arıyorsunuz. İşte bu senaryo, çoklu CDN stratejisinin neden kritik önem taşıdığını en net şekilde açıklıyor. Tek bir CDN’e bağımlı kalmak, tek bir sunucuya bağımlı kalmaktan pek farklı değil. Çoklu CDN yaklaşımı hem yüksek erişilebilirlik hem de coğrafi performans optimizasyonu açısından modern altyapıların vazgeçilmez bir parçası haline geldi.

Çoklu CDN Stratejisi Neden Gerekli?

Geleneksel CDN yaklaşımında bir sağlayıcı seçilir, DNS kayıtları ona yönlendirilir ve iş biter. Ama bu yaklaşım birkaç kritik riski görmezden geliyor.

Tek nokta arızası (SPOF): Cloudflare, Fastly veya Akamai gibi devler bile zaman zaman büyük çaplı kesintiler yaşıyor. 2021’deki Fastly kesintisi saatlerce büyük siteleri etkiledi. 2022’deki Cloudflare kesintisi küresel çapta hissedildi.

Coğrafi performans farklılıkları: Bir CDN sağlayıcısı Kuzey Amerika’da mükemmel performans gösterirken Güneydoğu Asya’da veya Orta Doğu’da yetersiz kalabilir. Kullanıcı kitleniz küresel ise bu fark direkt olarak dönüşüm oranlarını etkiliyor.

Maliyet optimizasyonu: Farklı CDN sağlayıcıları farklı coğrafi bölgelerde farklı fiyatlandırma politikalarına sahip. Trafik tipine ve bölgeye göre sağlayıcı seçimi ciddi maliyet tasarrufu sağlıyor.

Pazarlık gücü: Tek sağlayıcıya kilitlenmek fiyat artışlarında elinizi zayıflatıyor. Çoklu CDN kullanımı gerçek bir rekabet ortamı yaratıyor.

Temel Mimari Yaklaşımlar

Çoklu CDN uygulamasında üç temel mimari yaklaşım var:

Aktif-Aktif (Active-Active): Tüm CDN sağlayıcıları aynı anda trafik alıyor. DNS tabanlı yük dengeleme veya anycast yönlendirme ile gerçekleştiriliyor. En yüksek performans ve dayanıklılık bu modelde elde ediliyor.

Aktif-Pasif (Active-Passive): Birincil CDN çalıştığı sürece tüm trafik ona gidiyor. Arıza durumunda ikincil CDN devreye giriyor. Daha basit yapılandırma ama daha yavaş failover.

Coğrafi Segmentasyon: Farklı bölgeler için farklı CDN sağlayıcıları kullanılıyor. Avrupa trafiği Fastly’ye, Asya trafiği Cloudflare’e, Amerika trafiği Akamai’ye gidebiliyor.

DNS Tabanlı Yük Dengeleme

En yaygın ve uygulanması görece kolay olan yaklaşım DNS tabanlı yük dengelemedir. Bu yaklaşımda Cloudflare, AWS Route 53 veya NS1 gibi gelişmiş DNS sağlayıcıları kullanılır.

AWS Route 53 ile Coğrafi Yönlendirme

# Route 53 coğrafi yönlendirme politikası oluşturma
aws route53 create-traffic-policy 
  --name "multi-cdn-geo-policy" 
  --document file://geo-routing-policy.json 
  --comment "Multi-CDN geographic routing"

# Traffic policy örneği (geo-routing-policy.json)
cat > geo-routing-policy.json << 'EOF'
{
  "AWSPolicyFormatVersion": "2015-10-01",
  "RecordType": "A",
  "Endpoints": {
    "cloudflare-endpoint": {
      "Type": "value",
      "Value": "104.16.x.x"
    },
    "fastly-endpoint": {
      "Type": "value", 
      "Value": "151.101.x.x"
    },
    "akamai-endpoint": {
      "Type": "value",
      "Value": "96.7.x.x"
    }
  },
  "Rules": {
    "geo-rule": {
      "RuleType": "geo",
      "GeoproximityLocations": [
        {
          "Region": "eu-west-1",
          "EndpointReference": "cloudflare-endpoint"
        },
        {
          "Region": "ap-southeast-1", 
          "EndpointReference": "fastly-endpoint"
        },
        {
          "IsDefault": true,
          "EndpointReference": "akamai-endpoint"
        }
      ]
    }
  }
}
EOF

NS1 ile Akıllı DNS Yönlendirme

NS1, RUM (Real User Monitoring) verilerini DNS kararlarına entegre edebilen güçlü bir platformdur. Gerçek zamanlı performans verilerine göre en iyi CDN’e yönlendirme yapabilirsiniz.

# NS1 API ile monitoring zone oluşturma
curl -X PUT 
  -H "X-NSONE-Key: YOUR_API_KEY" 
  -H "Content-Type: application/json" 
  -d '{
    "zone": "cdn.yourdomain.com",
    "nx_ttl": 3600,
    "retry": 7200,
    "expiry": 604800,
    "refresh": 3600,
    "primary": {
      "enabled": false
    }
  }' 
  "https://api.nsone.net/v1/zones/cdn.yourdomain.com"

# RUM tabanlı yönlendirme kaydı
curl -X PUT 
  -H "X-NSONE-Key: YOUR_API_KEY" 
  -H "Content-Type: application/json" 
  -d '{
    "zone": "cdn.yourdomain.com",
    "domain": "assets.cdn.yourdomain.com",
    "type": "A",
    "use_client_subnet": true,
    "filters": [
      {
        "filter": "geotarget_country",
        "config": {}
      },
      {
        "filter": "select_first_n",
        "config": {"N": 1}
      }
    ],
    "answers": [
      {
        "answer": ["104.16.x.x"],
        "meta": {
          "country": ["TR", "DE", "FR", "GB"],
          "note": "Cloudflare - Europe"
        }
      },
      {
        "answer": ["151.101.x.x"],
        "meta": {
          "country": ["US", "CA", "MX"],
          "note": "Fastly - North America"  
        }
      }
    ]
  }' 
  "https://api.nsone.net/v1/zones/cdn.yourdomain.com/assets.cdn.yourdomain.com/A"

Anycast ve BGP Tabanlı Yaklaşım

Daha gelişmiş bir seçenek olarak kendi IP bloğunuzu birden fazla CDN sağlayıcısına aynı anda duyurabilirsiniz. Bu yaklaşım özellikle büyük ölçekli operasyonlar için uygundur.

# BGP community ile CDN tercih ayarı örneği
# Cloudflare Magic Transit veya benzeri hizmetlerle çalışırken

# Birincil CDN için daha düşük AS_PATH (tercih edilir)
ip route 203.0.113.0/24 via 10.0.0.1 
  route-map SET_CLOUDFLARE_PRIMARY

# İkincil CDN için daha yüksek metrik
ip route 203.0.113.0/24 via 10.0.0.2 
  route-map SET_FASTLY_SECONDARY

# Route map tanımı
route-map SET_CLOUDFLARE_PRIMARY permit 10
  set local-preference 200
  set community 13335:20000

route-map SET_FASTLY_SECONDARY permit 10
  set local-preference 100
  set community 54113:10000

CDN Sağlık Kontrolü ve Otomatik Failover

Sağlık kontrolü olmayan çoklu CDN stratejisi eksik kalır. Sağlayıcılardan biri sorun yaşadığında otomatik olarak diğerine geçiş yapabilmek kritik önemde.

Bash ile Basit Sağlık Kontrol Scripti

#!/bin/bash
# cdn-healthcheck.sh - CDN sağlık kontrolü ve otomatik failover

CDN_ENDPOINTS=(
  "cloudflare:https://cdn1.yourdomain.com/health"
  "fastly:https://cdn2.yourdomain.com/health"  
  "akamai:https://cdn3.yourdomain.com/health"
)

LOG_FILE="/var/log/cdn-healthcheck.log"
ALERT_EMAIL="[email protected]"
THRESHOLD=3
FAILED_CHECKS=0

check_endpoint() {
  local name=$1
  local url=$2
  local response_code
  local response_time

  response_code=$(curl -s -o /dev/null -w "%{http_code}" 
    --max-time 5 
    --connect-timeout 3 
    "$url")
  
  response_time=$(curl -s -o /dev/null -w "%{time_total}" 
    --max-time 5 
    "$url")

  if [ "$response_code" -eq 200 ]; then
    echo "$(date '+%Y-%m-%d %H:%M:%S') OK $name - HTTP $response_code - ${response_time}s" >> "$LOG_FILE"
    return 0
  else
    echo "$(date '+%Y-%m-%d %H:%M:%S') FAIL $name - HTTP $response_code" >> "$LOG_FILE"
    return 1
  fi
}

failover_dns() {
  local failed_cdn=$1
  echo "$(date '+%Y-%m-%d %H:%M:%S') FAILOVER: $failed_cdn devre disi, failover basliyor..." >> "$LOG_FILE"
  
  # AWS Route 53 health check ile otomatik failover
  aws route53 change-resource-record-sets 
    --hosted-zone-id "YOUR_ZONE_ID" 
    --change-batch "{
      "Changes": [{
        "Action": "UPSERT",
        "ResourceRecordSet": {
          "Name": "assets.yourdomain.com",
          "Type": "CNAME",
          "TTL": 60,
          "ResourceRecords": [{
            "Value": "backup-cdn.yourdomain.com"
          }]
        }
      }]
    }"

  # Uyarı gönder
  echo "CDN Failover: $failed_cdn devre disi alindi. Yedek CDN aktif." | 
    mail -s "CDN ALERT: Failover Tetiklendi" "$ALERT_EMAIL"
}

# Ana kontrol döngüsü
for endpoint_info in "${CDN_ENDPOINTS[@]}"; do
  cdn_name=$(echo "$endpoint_info" | cut -d: -f1)
  cdn_url=$(echo "$endpoint_info" | cut -d: -f2-)
  
  if ! check_endpoint "$cdn_name" "$cdn_url"; then
    ((FAILED_CHECKS++))
    
    if [ "$FAILED_CHECKS" -ge "$THRESHOLD" ]; then
      failover_dns "$cdn_name"
      FAILED_CHECKS=0
    fi
  fi
done

Terraform ile Çoklu CDN Altyapısı

Altyapıyı kod olarak yönetmek çoklu CDN ortamlarında özellikle önem kazanıyor. Birden fazla sağlayıcının konfigürasyonunu elle takip etmek hata prone ve yorucu.

# Terraform ile Cloudflare ve Fastly aynı anda yapılandırma
# providers.tf

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 4.0"
    }
    fastly = {
      source  = "fastly/fastly"
      version = "~> 5.0"
    }
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
  }
}

provider "cloudflare" {
  api_token = var.cloudflare_api_token
}

provider "fastly" {
  api_key = var.fastly_api_key
}

# Cloudflare Zone ve Page Rules
resource "cloudflare_zone" "main" {
  account_id = var.cloudflare_account_id
  zone       = "yourdomain.com"
  plan       = "pro"
}

resource "cloudflare_zone_settings_override" "performance" {
  zone_id = cloudflare_zone.main.id
  
  settings {
    ssl                      = "full"
    always_use_https         = "on"
    http3                    = "on"
    brotli                   = "on"
    cache_level              = "aggressive"
    browser_cache_ttl        = 14400
    edge_cache_ttl           = 86400
    min_ttl                  = 0
    minify {
      js   = "on"
      css  = "on"
      html = "off"
    }
  }
}

# Fastly Service - Asya-Pasifik bölgesi için
resource "fastly_service_vcl" "apac" {
  name = "yourdomain-apac-cdn"
  
  domain {
    name    = "apac-cdn.yourdomain.com"
    comment = "APAC CDN endpoint"
  }
  
  backend {
    address = "origin.yourdomain.com"
    name    = "origin_server"
    port    = 443
    use_ssl = true
    ssl_hostname = "origin.yourdomain.com"
    connect_timeout    = 5000
    first_byte_timeout = 60000
    between_bytes_timeout = 30000
  }
  
  force_destroy = true
}

Performans İzleme ve Metrik Toplama

Çoklu CDN ortamında hangi sağlayıcının ne kadar iyi performans gösterdiğini sürekli izlemek gerekiyor. Gerçek kullanıcı verilerini toplamadan optimizasyon yapmanız mümkün değil.

#!/bin/bash
# cdn-performance-monitor.sh
# Farklı CDN'lerin performansını karşılaştırmalı olarak ölçer

CDN_ENDPOINTS=(
  "cloudflare=https://cf-cdn.yourdomain.com/test-asset.js"
  "fastly=https://fastly-cdn.yourdomain.com/test-asset.js"
  "akamai=https://akamai-cdn.yourdomain.com/test-asset.js"
)

TEST_REGIONS=("Istanbul" "London" "Singapore" "New_York")
METRICS_FILE="/var/log/cdn-metrics-$(date +%Y%m%d).csv"
PROMETHEUS_PUSHGATEWAY="http://pushgateway:9091"

# CSV başlık
if [ ! -f "$METRICS_FILE" ]; then
  echo "timestamp,cdn_provider,region,dns_time,connect_time,ttfb,total_time,status_code" > "$METRICS_FILE"
fi

measure_performance() {
  local provider=$1
  local url=$2
  local region=$3
  
  # Curl ile detaylı timing bilgisi
  local result
  result=$(curl -s -o /dev/null 
    -w "%{time_namelookup},%{time_connect},%{time_starttransfer},%{time_total},%{http_code}" 
    --max-time 10 
    -H "X-Test-Region: $region" 
    "$url")
  
  local timestamp
  timestamp=$(date +%s)
  
  echo "$timestamp,$provider,$region,$result" >> "$METRICS_FILE"
  
  # Prometheus'a push
  local ttfb
  ttfb=$(echo "$result" | cut -d, -f3)
  
  cat << PROM | curl -s --data-binary @- "${PROMETHEUS_PUSHGATEWAY}/metrics/job/cdn_performance/cdn/${provider}/region/${region}"
# TYPE cdn_ttfb_seconds gauge
cdn_ttfb_seconds{provider="$provider",region="$region"} $ttfb
PROM
}

for endpoint_info in "${CDN_ENDPOINTS[@]}"; do
  provider=$(echo "$endpoint_info" | cut -d= -f1)
  url=$(echo "$endpoint_info" | cut -d= -f2)
  
  for region in "${TEST_REGIONS[@]}"; do
    measure_performance "$provider" "$url" "$region"
    sleep 1
  done
done

echo "Performans olcumu tamamlandi. Sonuclar: $METRICS_FILE"

Gerçek Dünya Senaryosu: E-Ticaret Platformu

Büyük bir e-ticaret platformu düşünün. Black Friday döneminde günlük 5 milyon ziyaretçi, peak saatlerde dakikada 50.000 istek. Bu trafik yapısını tek CDN ile yönetmek hem riskli hem de pahalı.

Bu tip bir platform için olası mimari şöyle kurgulanabilir:

  • Statik varlıklar (JS, CSS, resimler): Cloudflare, düşük TTL ile agresif cache
  • Ürün görselleri: Fastly, image optimization özellikleri nedeniyle tercih ediliyor
  • API edge caching: AWS CloudFront, Lambda@Edge ile özelleştirilmiş mantık
  • Video içerik: Akamai, medya streaming optimizasyonu
# Nginx ile çoklu CDN upstream yönetimi
# nginx.conf - upstream konfigürasyonu

upstream cloudflare_cdn {
  server cf-origin-1.yourdomain.com:443 weight=5 max_fails=3 fail_timeout=30s;
  server cf-origin-2.yourdomain.com:443 weight=3 max_fails=3 fail_timeout=30s;
  keepalive 32;
}

upstream fastly_cdn {
  server fastly-origin.yourdomain.com:443 weight=5 max_fails=2 fail_timeout=20s;
  keepalive 16;
}

# Backup upstream
upstream backup_cdn {
  server backup-cdn.yourdomain.com:443;
}

server {
  listen 443 ssl http2;
  server_name assets.yourdomain.com;
  
  # Statik varlıklar Cloudflare'e
  location ~* .(css|js|woff2?)$ {
    proxy_pass https://cloudflare_cdn;
    proxy_set_header Host "cf-cdn.yourdomain.com";
    proxy_connect_timeout 3s;
    proxy_read_timeout 10s;
    proxy_next_upstream error timeout http_502 http_503;
    proxy_next_upstream_tries 2;
    
    # Failover: Cloudflare çalışmazsa Fastly'ye geç
    error_page 502 503 = @fastly_fallback;
  }
  
  # Görseller Fastly'ye
  location ~* .(jpg|jpeg|png|webp|avif)$ {
    proxy_pass https://fastly_cdn;
    proxy_set_header Host "fastly-cdn.yourdomain.com";
    proxy_next_upstream error timeout http_502;
    error_page 502 503 = @backup_fallback;
  }
  
  location @fastly_fallback {
    proxy_pass https://fastly_cdn;
    proxy_set_header Host "fastly-cdn.yourdomain.com";
  }
  
  location @backup_fallback {
    proxy_pass https://backup_cdn;
    proxy_set_header Host "backup.yourdomain.com";
  }
}

Cache Tutarlılığı ve Invalidasyon Stratejisi

Çoklu CDN ortamında en can sıkıcı sorunlardan biri cache tutarlılığıdır. Bir sağlayıcıda cache’i temizlediğinizde diğerini unutursanız farklı kullanıcılar farklı versiyonları görür.

#!/bin/bash
# cdn-cache-purge.sh
# Tüm CDN sağlayıcılarında eş zamanlı cache temizleme

CLOUDFLARE_ZONE_ID="your_zone_id"
CLOUDFLARE_API_TOKEN="your_api_token"
FASTLY_SERVICE_ID="your_service_id"
FASTLY_API_KEY="your_fastly_key"
AKAMAI_ACCESS_TOKEN="your_akamai_token"

PURGE_URLS=("$@")

if [ ${#PURGE_URLS[@]} -eq 0 ]; then
  echo "Kullanim: $0 <url1> [url2] [url3]..."
  exit 1
fi

# Cloudflare cache temizleme
purge_cloudflare() {
  echo "Cloudflare cache temizleniyor..."
  
  local url_list
  url_list=$(printf '"%s",' "${PURGE_URLS[@]}")
  url_list="[${url_list%,}]"
  
  local response
  response=$(curl -s -X POST 
    "https://api.cloudflare.com/client/v4/zones/${CLOUDFLARE_ZONE_ID}/purge_cache" 
    -H "Authorization: Bearer ${CLOUDFLARE_API_TOKEN}" 
    -H "Content-Type: application/json" 
    -d "{"files": ${url_list}}")
  
  if echo "$response" | grep -q '"success":true'; then
    echo "Cloudflare: OK"
  else
    echo "Cloudflare: HATA - $response"
    return 1
  fi
}

# Fastly cache temizleme
purge_fastly() {
  echo "Fastly cache temizleniyor..."
  
  for url in "${PURGE_URLS[@]}"; do
    local response
    response=$(curl -s -X PURGE 
      -H "Fastly-Key: ${FASTLY_API_KEY}" 
      -H "Accept: application/json" 
      "$url")
    
    if echo "$response" | grep -q '"status":"ok"'; then
      echo "Fastly: OK - $url"
    else
      echo "Fastly: HATA - $url - $response"
    fi
  done
}

# Paralel çalıştır
purge_cloudflare &
PID_CF=$!

purge_fastly &
PID_FASTLY=$!

# Tüm işlemlerin bitmesini bekle
wait $PID_CF
CF_STATUS=$?

wait $PID_FASTLY
FASTLY_STATUS=$?

if [ $CF_STATUS -eq 0 ] && [ $FASTLY_STATUS -eq 0 ]; then
  echo "Tum CDN cache temizleme islemi basariyla tamamlandi."
  exit 0
else
  echo "Bazi CDN cache temizleme islemleri basarisiz oldu."
  exit 1
fi

Maliyet Optimizasyonu

Çoklu CDN kullanımı başlangıçta daha pahalı görünebilir ama akıllıca yapılandırıldığında toplam maliyeti düşürebilir.

Uygulanabilecek stratejiler:

  • Bant genişliği arbitrajı: Bazı CDN sağlayıcıları belirli bölgelerde çok daha ucuz. Asya çıkış trafiği için Cloudflare yerine BunnyCDN veya KeyCDN kullanmak %40-60 tasarruf sağlayabilir.
  • Cache hit oranı optimizasyonu: CDN sağlayıcılarının kendi analitik panellerini düzenli kontrol edin. Cache hit oranı %80’nin altındaysa cache politikası ve TTL değerlerini gözden geçirin.
  • Commit bazlı fiyatlandırma: Büyük hacimlerde commit bazlı anlaşmalar kurumsal fiyatlandırmadan çok daha avantajlı olabiliyor. Ama tek sağlayıcıya commit bağlamak esnekliği azaltır.
  • Tier bazlı içerik sınıflandırma: Her içerik eşit değil. Kritik path üzerindeki CSS/JS için premium CDN, kullanıcı tarafından yüklenen resimler için daha ekonomik bir sağlayıcı kullanabilirsiniz.

İzleme ve Alarm Stratejisi

Grafana ve Prometheus kombinasyonu çoklu CDN izleme için ideal temel oluşturuyor. Dikkat etmeniz gereken metrikler:

Erişilebilirlik metrikleri:

  • Her CDN endpoint’i için uptime yüzdesi
  • Health check başarı/başarısızlık oranları
  • Failover tetiklenme sıklığı

Performans metrikleri:

  • TTFB (Time To First Byte) – sağlayıcı bazında
  • Cache hit/miss oranları
  • Bant genişliği kullanımı

Hata metrikleri:

  • 4xx ve 5xx hata oranları
  • Origin’e gelen istek oranı (cache bypass göstergesi)
  • SSL handshake hataları

Maliyet metrikleri:

  • Sağlayıcı bazında bant genişliği tüketimi
  • Request sayısı (özellikle request bazlı fiyatlandırma modellerinde)
  • Tahmini aylık maliyet trend’i

Sonuç

Çoklu CDN stratejisi artık sadece büyük teknoloji şirketlerinin lüksü değil. Makul ölçekte trafik alan her uygulama için ciddi bir değerlendirme konusu olmalı. Tek CDN’e bağımlılık, modern altyapı anlayışında kabul edilemez bir risk.

Başlangıç noktası olarak şunları öneririm: Önce mevcut CDN’inizin performansını bölgesel bazda ölçün. Zayıf kaldığı bölgeleri tespit edin. Sadece o bölgeler için ikinci bir CDN ekleyin. Bu yaklaşım hem riski azaltır hem de operasyonel karmaşıklığı yönetilebilir seviyede tutar.

Failover mekanizması olmayan çoklu CDN yarım iştir. Health check scriptleri yazın, alarm kurallarını belirleyin ve failover senaryolarını test edin. Üretim ortamında ilk kez test etmek istediğiniz bir şey değil bu.

Cache invalidasyon sürecinizi otomatize edin ve deployment pipeline’ınıza entegre edin. Hangi CDN’de hangi içeriğin ne versiyonunun olduğunu takip etmek elle yönetilemeyecek kadar karmaşık bir iş haline geliyor.

Son olarak, bu altyapının bakımını yapacak ekibin bilgi seviyesini göz önünde bulundurun. Mükemmel mimari ama bakımını yapacak kimsenin anlamadığı bir sistem, basit ama iyi anlaşılmış bir sistemden daha tehlikelidir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir