CDN ile API Hızlandırma ve Önbellekleme Stratejileri

API’lerinizin yavaş çalıştığından şikayet eden kullanıcılarınız var mı? Origin sunucunuz her istek için ter döküyor, veritabanı sorguları tekrar tekrar çalışıyor ve dünya genelindeki kullanıcılarınız yüksek gecikme süreleriyle boğuşuyor. İşte tam bu noktada CDN ile API hızlandırma devreye giriyor. Bu yazıda, CDN’i sadece statik içerik dağıtımı için değil, API katmanınızı ciddi ölçüde hızlandırmak için nasıl kullanabileceğinizi, gerçek dünya senaryolarıyla ele alacağız.

CDN ve API: Neden Birlikte Çalışır?

Çoğu sysadmin CDN’i yalnızca resim, CSS ve JavaScript dosyaları için düşünür. Oysa modern CDN platformları çok daha fazlasını yapabilir. Cloudflare, AWS CloudFront, Fastly gibi platformlar artık edge computing, akıllı önbellekleme ve request manipulation özellikleriyle tam anlamıyla bir uygulama katmanına dönüşmüş durumda.

API hızlandırmanın temel mantığı şu: Kullanıcınız İstanbul’dan bir istek gönderiyor, origin sunucunuz Frankfurt’ta. Her API çağrısında İstanbul-Frankfurt arası gidiş-dönüş yapılıyor. CDN ile aradaki edge node’da yanıt önbelleklenirse, bu gecikme dramatik biçimde düşüyor. Özellikle GET endpoint’leri ve sık değişmeyen veriler için bu yaklaşım altın değerinde.

Tabii her API endpoint’i önbelleklenemez. Kullanıcıya özel veriler, anlık stok bilgileri, ödeme işlemleri gibi dinamik yanıtlar için farklı stratejiler gerekiyor. Önce neyin önbellekleneceğini anlamak, sonra yapılandırmaya geçmek en sağlıklı yaklaşım.

Önbelleklenebilir ve Önbelleklenemeyen API Endpoint’leri

Önbelleklenebilir endpoint’ler:

  • Ürün kataloğu, kategori listeleri
  • Döviz kurları (makul bir TTL ile)
  • Hava durumu verileri
  • Blog yazıları, içerik API’leri
  • Coğrafi veri, ülke/şehir listeleri
  • Yapılandırma ve feature flag API’leri

Önbelleklenmemesi gereken endpoint’ler:

  • Kullanıcıya özel sepet, profil bilgileri
  • Ödeme ve işlem API’leri
  • Authentication endpoint’leri
  • Gerçek zamanlı mesajlaşma ve bildirim servisleri
  • Yazma işlemleri (POST, PUT, DELETE)

Bu ayrımı iyi yapmazsanız kullanıcılar birbirinin verisini görmeye başlar, ki bu hem güvenlik açığı hem de ciddi bir operasyonel kabus olur.

Cache-Control Header’larını Doğru Yapılandırmak

Her şey doğru HTTP header’larını göndermekten geçiyor. CDN’ler bu header’lara bakarak neyi ne kadar süre önbellekleyeceğine karar verir.

# Nginx ile API yanıtlarına Cache-Control header eklemek
# /etc/nginx/conf.d/api.conf

server {
    listen 443 ssl;
    server_name api.sirketiniz.com;

    location /v1/products {
        proxy_pass http://backend_upstream;
        proxy_set_header Host $host;
        
        # 5 dakika CDN önbelleği, tarayıcı önbelleği yok
        add_header Cache-Control "public, max-age=300, s-maxage=300";
        add_header Vary "Accept-Encoding, Accept-Language";
    }

    location /v1/user {
        proxy_pass http://backend_upstream;
        
        # Kullanıcı verisi asla önbelleklenmesin
        add_header Cache-Control "private, no-store, no-cache";
    }

    location /v1/config {
        proxy_pass http://backend_upstream;
        
        # Yapılandırma 1 saat önbellekte kalsın
        add_header Cache-Control "public, max-age=3600, stale-while-revalidate=60";
    }
}

stale-while-revalidate direktifi özellikle güçlü bir araç. Cache süresi dolduğunda, arka planda yeni içerik çekilirken kullanıcıya eski (stale) yanıt servis etmeye devam eder. Kullanıcı gecikme yaşamaz, arka planda güncelleme gerçekleşir.

Cloudflare ile API Önbellekleme Yapılandırması

Cloudflare, ücretsiz planında bile API önbellekleme için kullanışlı özellikler sunuyor. Ücretli planlarda ise çok daha gelişmiş kontrol imkanı var.

# Cloudflare API'si üzerinden Cache Rules oluşturma
# Bu örnek curl ile Cloudflare API'yi çağırıyor

ZONE_ID="sizin_zone_id"
API_TOKEN="sizin_api_token"

curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rulesets" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "name": "API Cache Rules",
    "kind": "zone",
    "phase": "http_request_cache_settings",
    "rules": [
      {
        "action": "set_cache_settings",
        "action_parameters": {
          "cache": true,
          "edge_ttl": {
            "mode": "override_origin",
            "default": 300
          },
          "browser_ttl": {
            "mode": "bypass"
          }
        },
        "expression": "(http.request.uri.path matches "^/v1/products.*") and (http.request.method eq "GET")",
        "description": "Cache product API responses"
      }
    ]
  }'

Cloudflare Workers ile daha granüler kontrol de mümkün. Örneğin Authorization header’ı olan istekleri CDN önbelleğinin dışına almak, ama anonim istekleri önbelleklemek için Workers kullanabilirsiniz.

# Cloudflare Worker örneği - wrangler ile deploy edilebilir
# wrangler.toml dosyası

name = "api-cache-worker"
main = "src/worker.js"
compatibility_date = "2024-01-01"

[env.production]
vars = { ENVIRONMENT = "production" }

AWS CloudFront ile API Gateway Hızlandırma

AWS ekosistemindeyseniz, CloudFront ile API Gateway kombinasyonu oldukça güçlü bir duo oluşturuyor. Özellikle Lambda tabanlı API’lerde cold start sürelerini gizlemek için önbellekleme hayat kurtarıcı.

# CloudFront distribution oluşturma - AWS CLI ile
aws cloudfront create-distribution 
  --distribution-config '{
    "Origins": {
      "Quantity": 1,
      "Items": [{
        "Id": "api-gateway-origin",
        "DomainName": "abc123.execute-api.eu-west-1.amazonaws.com",
        "CustomOriginConfig": {
          "HTTPSPort": 443,
          "OriginProtocolPolicy": "https-only"
        },
        "OriginPath": "/prod"
      }]
    },
    "DefaultCacheBehavior": {
      "TargetOriginId": "api-gateway-origin",
      "ViewerProtocolPolicy": "redirect-to-https",
      "CachePolicyId": "4135ea2d-6df8-44a3-9df3-4b5a84be39ad",
      "AllowedMethods": {
        "Quantity": 2,
        "Items": ["GET", "HEAD"]
      }
    },
    "CacheBehaviors": {
      "Quantity": 1,
      "Items": [{
        "PathPattern": "/v1/products*",
        "TargetOriginId": "api-gateway-origin",
        "ViewerProtocolPolicy": "redirect-to-https",
        "DefaultTTL": 300,
        "MaxTTL": 3600,
        "MinTTL": 0,
        "AllowedMethods": {
          "Quantity": 2,
          "Items": ["GET", "HEAD"]
        }
      }]
    },
    "Enabled": true,
    "Comment": "API CDN Distribution"
  }'

CloudFront’ta cache policy ve origin request policy ayrımına dikkat edin. Cache policy, hangi header/cookie/query string kombinasyonunun önbellek anahtarını oluşturduğunu belirler. Origin request policy ise origin’e hangi bilgilerin iletileceğini tanımlar. Bu ikisini doğru ayarlamazsanız ya cache miss oranınız çok yükselir ya da yanlış yanıtlar servis edilir.

Cache Invalidation: En Zor Kısım

Phil Karlton’ın meşhur sözü var: “Bilgisayar biliminde yalnızca iki zor şey vardır: cache invalidation ve şeylere isim vermek.” API önbellekleme dünyasında bu söz her zamankinden daha anlamlı.

Veri güncellendiğinde önbelleği temizlemek için birkaç strateji var:

# Cloudflare önbellek temizleme - belirli URL'ler için
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "files": [
      "https://api.sirketiniz.com/v1/products",
      "https://api.sirketiniz.com/v1/products/categories"
    ]
  }'

# AWS CloudFront invalidation oluşturma
aws cloudfront create-invalidation 
  --distribution-id EDFDVBD6EXAMPLE 
  --paths "/v1/products*" "/v1/categories*"

Büyük ölçekte çalışıyorsanız, önbellek temizleme işlemini CI/CD pipeline’ınıza entegre edin. Yeni bir ürün eklendiğinde veya içerik güncellendiğinde, deployment sürecinin bir parçası olarak ilgili CDN önbelleğini otomatik temizleyin.

# Deployment sonrası önbellek temizleme scripti
# deploy_hook.sh

#!/bin/bash
set -e

ZONE_ID="${CLOUDFLARE_ZONE_ID}"
API_TOKEN="${CLOUDFLARE_API_TOKEN}"
DEPLOY_ENV="${1:-production}"

echo "Deployment tamamlandı, CDN önbelleği temizleniyor..."

# Ürün API'si önbelleğini temizle
RESPONSE=$(curl -s -X POST 
  "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/purge_cache" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{"purge_everything": false, "files": ["https://api.sirketiniz.com/v1/products"]}')

SUCCESS=$(echo $RESPONSE | python3 -c "import sys,json; print(json.load(sys.stdin)['success'])")

if [ "$SUCCESS" = "True" ]; then
    echo "Önbellek temizleme başarılı"
else
    echo "Önbellek temizleme başarısız: $RESPONSE"
    exit 1
fi

ETag ve Conditional Request Stratejisi

Önbelleklemenin sadece TTL tabanlı olması gerekmez. ETag mekanizması ile veri gerçekten değiştiğinde tam yanıt gönderin, değişmediğinde sadece 304 Not Modified döndürün. Bu hem bant genişliğini hem de origin yükünü ciddi ölçüde azaltır.

# Node.js / Express API'de ETag implementasyonu örneği
# Bu konfigürasyonu backend uygulamanızda yapabilirsiniz

# Nginx ile ETag destekli proxy yapılandırması
location /v1/products {
    proxy_pass http://backend_upstream;
    
    # ETag header'larını ilet
    proxy_pass_header ETag;
    proxy_pass_header Last-Modified;
    
    # Conditional request header'larını origin'e ilet
    proxy_set_header If-None-Match $http_if_none_match;
    proxy_set_header If-Modified-Since $http_if_modified_since;
    
    # CDN'e 5 dakika önbelleklemesini söyle
    add_header Cache-Control "public, max-age=300";
    
    # Farklı dil/encoding için ayrı önbellek girdisi
    add_header Vary "Accept-Encoding, Accept-Language";
}

Gerçek Dünya Senaryosu: E-Ticaret API’si

Bir e-ticaret platformu hayal edin: 50.000 ürün, günlük 2 milyon API isteği, dünya genelinde kullanıcılar. Origin sunucu sürekli database sorgusu yapıyor, yavaş yanıt veriyor.

Problem analizi:

  • /v1/products endpoint’i dakikada 10.000 istek alıyor
  • Her istek DB’ye gidip 200ms harcıyor
  • Ürün verisi ortalama 15 dakikada bir değişiyor

Çözüm stratejisi:

  • Ürün listesi: 10 dakika CDN önbelleği
  • Ürün detayı: 15 dakika CDN önbelleği
  • Stok bilgisi: Önbellekleme yok (anlık)
  • Kategori ağacı: 1 saat CDN önbelleği

Bu stratejiyle origin’e giden istek sayısı %95 düşüyor. 10.000 istek/dakika olan yük, 500 istek/dakikaya iniyor. Sunucu maliyetleri azalıyor, yanıt süreleri düşüyor, kullanıcı deneyimi iyileşiyor.

Peki önbellekleme etkinliğini nasıl ölçersiniz? Cache Hit Ratio metriğine bakın. CDN dashboard’unuzda bu değer %80’in altındaysa bir şeyler yanlış demektir.

# Nginx log'larından cache hit ratio hesaplama
# Upstream_cache_status değerlerini analiz ediyoruz

grep -E "upstream_cache_status" /var/log/nginx/access.log | 
  awk '{print $NF}' | 
  sort | uniq -c | sort -rn

# Beklenen çıktı:
# 15234 HIT
# 892   MISS  
# 156   EXPIRED
# 45    BYPASS

# Hit ratio = HIT / (HIT + MISS + EXPIRED) * 100
echo "Hit Ratio hesapla:"
awk '
/upstream_cache_status/ {
    status = $NF
    count[status]++
    total++
}
END {
    print "Hit Ratio: " (count["HIT"]/total)*100 "%"
    for (s in count) print s ": " count[s]
}
' /var/log/nginx/access.log

Vary Header ile Akıllı Önbellekleme

Vary header’ı, CDN’e “aynı URL için farklı versiyonlar olabilir” demenin yolu. Ama dikkatli kullanmazsanız cache hit oranınızı mahveder.

Vary: Accept-Language eklerseniz, Türkçe ve İngilizce yanıtlar ayrı ayrı önbelleklenir. Mantıklı.

Vary: Cookie eklerseniz, her kullanıcı için ayrı önbellek girdisi oluşur. Bu neredeyse hiç önbellek hit’i sağlamaz. Kaçının.

Vary: Authorization da benzer şekilde önbelleklemeyi devre dışı bırakır. Authenticated endpoint’leri zaten önbelleklememelisiniz.

# Doğru Vary kullanımı - Nginx konfigürasyonu
location /v1/products {
    proxy_pass http://backend_upstream;
    
    # Sadece encoding ve dil bazında farklılaştır
    add_header Vary "Accept-Encoding, Accept-Language";
    add_header Cache-Control "public, max-age=300";
}

location /v1/search {
    proxy_pass http://backend_upstream;
    
    # Arama sonuçları önbelleklenebilir ama kullanıcıya özel değil
    # Accept-Encoding yeterli
    add_header Vary "Accept-Encoding";
    add_header Cache-Control "public, max-age=60";
}

Rate Limiting ve DDoS Koruması

CDN’in bir diğer kritik faydası, origin’e ulaşmadan önce kötü trafiği filtrelemesi. Cloudflare, AWS WAF ve benzeri sistemler bu konuda çok güçlü.

# Cloudflare Rate Limiting kuralı oluşturma
curl -X POST "https://api.cloudflare.com/client/v4/zones/${ZONE_ID}/rate_limits" 
  -H "Authorization: Bearer ${API_TOKEN}" 
  -H "Content-Type: application/json" 
  -d '{
    "disabled": false,
    "description": "API endpoint rate limit",
    "match": {
      "request": {
        "url_pattern": "api.sirketiniz.com/v1/*",
        "methods": ["GET", "POST"],
        "schemes": ["HTTPS"]
      },
      "response": {
        "status": [200, 201, 400, 401, 403, 404]
      }
    },
    "threshold": 100,
    "period": 60,
    "action": {
      "mode": "simulate",
      "timeout": 60,
      "response": {
        "content_type": "application/json",
        "body": "{"error": "Too many requests", "retry_after": 60}"
      }
    }
  }'

Rate limiting’i önce simulate modunda test edin, gerçek trafiğinizi ve meşru kullanım örüntülerini anlayın, sonra aktif hale getirin. Yoksa gerçek kullanıcılarınızı engellersiniz.

Monitoring ve Gözlemlenebilirlik

CDN önbelleklemenizi kurduktan sonra işin bittiğini sanmayın. Sürekli izlemek şart.

İzlemeniz gereken temel metrikler:

  • Cache Hit Ratio: %80 üzerinde tutmaya çalışın
  • Origin Response Time: CDN devredeyken bu değer ne kadar düştü?
  • Edge Response Time: Son kullanıcının gördüğü gecikme
  • Bandwidth Saved: CDN’in ne kadar trafik absorbe ettiği
  • Error Rate: 5xx hataları artıyorsa origin’de sorun var demek
# Prometheus ile CDN metriklerini toplama
# nginx-prometheus-exporter veya custom scraper kullanabilirsiniz

# Nginx stub_status modülü ile temel metrikler
server {
    listen 8080;
    server_name localhost;
    
    location /nginx_status {
        stub_status on;
        access_log off;
        allow 127.0.0.1;
        allow 10.0.0.0/8;
        deny all;
    }
    
    location /metrics {
        proxy_pass http://localhost:9113/metrics;
        allow 10.0.0.0/8;
        deny all;
    }
}

# Basit cache hit ratio izleme scripti
#!/bin/bash
# cache_monitor.sh - cron ile her 5 dakikada çalıştırın

LOG_FILE="/var/log/nginx/access.log"
ALERT_THRESHOLD=70  # %70 altında alert gönder

HITS=$(grep -c "upstream_cache_status: HIT" $LOG_FILE 2>/dev/null || echo 0)
MISSES=$(grep -c "upstream_cache_status: MISS" $LOG_FILE 2>/dev/null || echo 0)
TOTAL=$((HITS + MISSES))

if [ $TOTAL -gt 0 ]; then
    RATIO=$((HITS * 100 / TOTAL))
    echo "Cache Hit Ratio: %${RATIO}"
    
    if [ $RATIO -lt $ALERT_THRESHOLD ]; then
        echo "UYARI: Cache hit ratio %${RATIO} - eşik altında!" | 
          mail -s "CDN Cache Alert" [email protected]
    fi
fi

Sık Yapılan Hatalar

Hata 1: Her şeyi önbelleklemek POST isteklerini veya authenticated endpoint’leri önbelleklemek veri sızıntısına yol açar. Mutlaka HTTP metoduna göre filtreleme yapın.

Hata 2: TTL’i çok uzun tutmak “Daha uzun TTL = daha iyi cache hit” mantığı doğru ama veri tutarsızlığını da beraberinde getirir. Verinin güncellenme sıklığına göre TTL belirleyin.

Hata 3: Cache invalidation’ı unutmak Veri güncellendiğinde CDN önbelleğini temizlemezseniz, kullanıcılar saatlerce eski veri görür. Deployment pipeline’ınıza invalidation adımını ekleyin.

Hata 4: Vary header’ını kötüye kullanmak Vary: Cookie veya Vary: User-Agent eklemek önbelleklemenizi fiilen devre dışı bırakır. Vary header’larını minimumda tutun.

Hata 5: Sadece CDN’e güvenmek CDN bir katman, asıl çözüm değil. Uygulamanızda da Redis gibi bir önbellek katmanı olmalı. CDN miss olduğunda bile hızlı yanıt vermek için backend’inizi optimize edin.

Sonuç

CDN ile API hızlandırma, doğru yapılandırıldığında hem maliyet hem de performans açısından ciddi kazanımlar sağlar. Origin yükünüzü %80-95 oranında düşürebilir, dünya genelindeki kullanıcılarınıza tutarlı düşük gecikme süreleri sunabilirsiniz.

Başlangıç noktası olarak şu adımları izlemenizi öneririm: Önce API endpoint’lerinizi analiz edin ve neyin önbelleklenebileceğini belirleyin. Sonra Cache-Control header’larınızı doğru yapılandırın. CDN kurallarınızı oluşturun ve ilk hafta cache hit ratio’nuzu yakından takip edin. Deployment sürecinize cache invalidation adımını ekleyin. Son olarak monitoring altyapınızı kurarak sürekli gözlemleyin.

CDN önbellekleme bir kez yapıp unutulan bir iş değil, trafik örüntüleriniz değiştikçe, API’leriniz evrildikçe düzenli olarak gözden geçirilmesi gereken bir strateji. Ama bir kez doğru kurulduğunda, hem kullanıcılarınız hem de sunucularınız size teşekkür eder.

Bir yanıt yazın

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