AWS Route 53 Yük Dengeleme Politikaları: Kapsamlı Rehber

Tarafındankomut
0 Comments

AWS üzerinde çalışan bir uygulamanın trafiğini yönetmek, özellikle küresel kullanıcı kitlesine hitap eden sistemlerde gerçek bir sanat haline geliyor. Route 53’ün sunduğu yük dengeleme politikaları, sadece DNS yönlendirmesinin ötesine geçerek uygulamanızın performansını, dayanıklılığını ve kullanıcı deneyimini doğrudan etkiliyor. Bu yazıda Route 53’ün routing policy’lerini derinlemesine inceleyeceğiz ve her birini ne zaman, nasıl kullanacağınızı gerçek dünya senaryolarıyla açıklayacağız.

Route 53 Routing Policy Nedir?

Route 53’te bir DNS kaydı oluştururken sadece “bu domaine şu IP’yi döndür” demekle kalmıyorsunuz. Hangi koşullarda hangi kaynağa yönlendirme yapılacağını belirleyen politikalar tanımlıyorsunuz. Bu politikalar sayesinde coğrafi konum, kaynak sağlığı, gecikme süresi veya ağırlıklı dağılım gibi kriterlere göre DNS yanıtlarını şekillendirebiliyorsunuz.

Route 53’ün desteklediği yönlendirme politikaları şunlar:

  • Simple Routing: Tek kaynak, temel yönlendirme
  • Weighted Routing: Ağırlık tabanlı trafik dağılımı
  • Latency-Based Routing: En düşük gecikmeye göre yönlendirme
  • Failover Routing: Aktif-pasif yedekleme
  • Geolocation Routing: Coğrafi konum tabanlı yönlendirme
  • Geoproximity Routing: Coğrafi yakınlık ve bias ile yönlendirme
  • Multivalue Answer Routing: Çoklu değer döndürme
  • IP-Based Routing: CIDR bloğuna göre yönlendirme

Şimdi her birini detaylıca inceleyelim.

Simple Routing Policy

En basit yönlendirme türü. Bir domain adına tek bir kaynak tanımlarsınız ve Route 53 her zaman o kaynağa yönlendirir. Health check desteklemez (alias kayıtlar hariç).

# AWS CLI ile Simple Routing kaydı oluşturma
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.orneksite.com",
        "Type": "A",
        "TTL": 300,
        "ResourceRecords": [
          {"Value": "203.0.113.10"}
        ]
      }
    }]
  }'

Simple routing’in bir ilginç özelliği, tek kayıt içinde birden fazla IP tanımlayabilmeniz. Bu durumda Route 53 tüm değerleri döndürür ve DNS istemcisi rastgele birini seçer. Ancak bu bir health check mekanizması değil, basit bir round-robin’dir.

# Birden fazla IP ile Simple Routing
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.orneksite.com",
        "Type": "A",
        "TTL": 60,
        "ResourceRecords": [
          {"Value": "203.0.113.10"},
          {"Value": "203.0.113.11"},
          {"Value": "203.0.113.12"}
        ]
      }
    }]
  }'

Ne zaman kullanılır? Tek sunuculu uygulamalar, development ortamları veya henüz ölçeklendirme ihtiyacı duymayan küçük projeler için idealdir.

Weighted Routing Policy

Trafik dağılımını yüzdesel olarak kontrol etmek istediğinizde weighted routing devreye giriyor. Her kayda bir ağırlık (0-255 arası) atıyorsunuz ve Route 53 bu ağırlıklara göre trafik dağılımını hesaplıyor.

Gerçek dünya senaryosu: Yeni bir uygulama sürümü yayınlıyorsunuz ve önce trafiğin %10’unu yeni versiyona yönlendirip, sorun yoksa kademeli artırmak istiyorsunuz. Bu klasik blue-green deployment veya canary release senaryosu.

# Blue ortam - mevcut versiyon (ağırlık: 90)
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.orneksite.com",
        "Type": "A",
        "SetIdentifier": "blue-env",
        "Weight": 90,
        "TTL": 60,
        "ResourceRecords": [{"Value": "10.0.1.100"}],
        "HealthCheckId": "abc123-health-blue"
      }
    }]
  }'

# Green ortam - yeni versiyon (ağırlık: 10)
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.orneksite.com",
        "Type": "A",
        "SetIdentifier": "green-env",
        "Weight": 10,
        "TTL": 60,
        "ResourceRecords": [{"Value": "10.0.2.100"}],
        "HealthCheckId": "abc456-health-green"
      }
    }]
  }'

Ağırlık hesaplaması şöyle çalışır: Tüm kayıtların ağırlıkları toplanır (bu örnekte 100) ve her kaydın trafikten aldığı pay kendi ağırlığının toplama oranıdır. Bir kaydın ağırlığını 0 yaparsanız, o kayda trafik gitmez ama kayıt silinmez. Bu özellik bakım moduna almak için kullanışlıdır.

# Kaydı sıfır ağırlıkla bakım moduna alma
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "api.orneksite.com",
        "Type": "A",
        "SetIdentifier": "green-env",
        "Weight": 0,
        "TTL": 60,
        "ResourceRecords": [{"Value": "10.0.2.100"}]
      }
    }]
  }'

Latency-Based Routing Policy

Kullanıcıları en düşük ağ gecikmesine sahip AWS region’a yönlendirir. Route 53, kullanıcının IP adresine bakarak hangi AWS region’a bağlanmanın daha hızlı olacağını hesaplar.

Önemli not: Latency-based routing, kullanıcının fiziksel konumuna değil, AWS bölgeleriyle olan ağ gecikmesine bakar. Türkiye’deki bir kullanıcı teorik olarak Frankfurt yerine Londra’ya daha hızlı bağlanabilir.

# us-east-1 bölgesi için latency kaydı
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.orneksite.com",
        "Type": "A",
        "SetIdentifier": "us-east-1",
        "Region": "us-east-1",
        "TTL": 60,
        "ResourceRecords": [{"Value": "54.204.10.1"}],
        "HealthCheckId": "health-us-east"
      }
    }]
  }'

# eu-west-1 bölgesi için latency kaydı
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.orneksite.com",
        "Type": "A",
        "SetIdentifier": "eu-west-1",
        "Region": "eu-west-1",
        "TTL": 60,
        "ResourceRecords": [{"Value": "52.208.10.1"}],
        "HealthCheckId": "health-eu-west"
      }
    }]
  }'

Failover Routing Policy

Aktif-pasif yüksek erişilebilirlik senaryoları için tasarlanmış. Primary kaynak sağlıklıyken tüm trafik ona gider; sağlık kontrolü başarısız olursa trafik otomatik olarak secondary kaynağa yönlendirilir.

Health check olmadan failover routing çalışmaz. Bu kritik bir detay. Primary kaydına mutlaka bir health check bağlamalısınız.

# Önce health check oluştur
aws route53 create-health-check 
  --caller-reference "primary-hc-$(date +%s)" 
  --health-check-config '{
    "IPAddress": "203.0.113.50",
    "Port": 443,
    "Type": "HTTPS",
    "ResourcePath": "/health",
    "FullyQualifiedDomainName": "primary.orneksite.com",
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'
# Primary kayıt
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "service.orneksite.com",
          "Type": "A",
          "SetIdentifier": "primary",
          "Failover": "PRIMARY",
          "TTL": 60,
          "ResourceRecords": [{"Value": "203.0.113.50"}],
          "HealthCheckId": "HEALTH_CHECK_ID_BURAYA"
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "service.orneksite.com",
          "Type": "A",
          "SetIdentifier": "secondary",
          "Failover": "SECONDARY",
          "TTL": 60,
          "ResourceRecords": [{"Value": "203.0.113.51"}]
        }
      }
    ]
  }'

Gerçek dünya senaryosu: Ana veri merkeziniz eu-central-1’de, disaster recovery ortamınız ise us-east-1’de. Normal koşullarda tüm trafik Frankfurt’a gidiyor. Bir problem çıktığında Route 53 health check’i yakalar ve trafiği otomatik olarak Virginia’ya yönlendirir. RTO (Recovery Time Objective) değerinizi DNS TTL süresiyle doğrudan ilişkili hale getirir.

Geolocation Routing Policy

Kullanıcının coğrafi konumuna göre yönlendirme yapmanızı sağlar. Avrupa’daki kullanıcıları AB veri merkezinize, Asya’dakileri APAC bölgesine yönlendirebilirsiniz. Veri egemenliği (data sovereignty) gereksinimleri için de sıklıkla kullanılır.

Geolocation routing üç seviyede tanımlanabilir:

  • Kıta seviyesi: Europe, Asia, North America vb.
  • Ülke seviyesi: TR, DE, US vb.
  • ABD eyalet seviyesi: Sadece Amerika için eyalet bazında
# Türkiye kullanıcıları için Frankfurt'a yönlendirme
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.orneksite.com",
        "Type": "A",
        "SetIdentifier": "turkey-users",
        "GeoLocation": {
          "CountryCode": "TR"
        },
        "TTL": 300,
        "ResourceRecords": [{"Value": "52.29.100.1"}]
      }
    }]
  }'
# Avrupa geneli için kayıt
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.orneksite.com",
        "Type": "A",
        "SetIdentifier": "europe-users",
        "GeoLocation": {
          "ContinentCode": "EU"
        },
        "TTL": 300,
        "ResourceRecords": [{"Value": "52.29.200.1"}]
      }
    }]
  }'

# Varsayılan kayıt - coğrafi eşleşme olmayan kullanıcılar için
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "app.orneksite.com",
        "Type": "A",
        "SetIdentifier": "default",
        "GeoLocation": {
          "CountryCode": "*"
        },
        "TTL": 300,
        "ResourceRecords": [{"Value": "54.200.50.1"}]
      }
    }]
  }'

Kritik nokta: Varsayılan (default) kaydı mutlaka ekleyin. Eğer bir kullanıcının konumu hiçbir kaydınızla eşleşmezse ve varsayılan kaydınız yoksa, Route 53 NODATA yanıtı döner. Ülke seviyesindeki kayıt her zaman kıta seviyesindeki kaydın önüne geçer.

Geoproximity Routing Policy

Bu politika, Route 53 Traffic Flow özelliği gerektirir ve en güçlü yönlendirme seçeneklerinden biridir. Geolocation routing’e benzer ama ek olarak “bias” değeri ile yönlendirme alanlarını genişletip daraltabilirsiniz.

Bias değerleri:

  • Pozitif bias (+1 ile +99): Kaynağın çekim alanını genişletir, daha fazla trafik çeker
  • Negatif bias (-1 ile -99): Kaynağın çekim alanını daraltır, daha az trafik çeker

Bu özelliği Traffic Flow policy ile JSON formatında tanımlamanız gerekir. AWS Console üzerinden görsel editor kullanmak çok daha pratiktir, ancak CLI için şöyle bir yapı oluşturabilirsiniz:

# Traffic policy oluşturma (geoproximity için)
aws route53 create-traffic-policy 
  --name "geoproximity-policy" 
  --document '{
    "AWSPolicyFormatVersion": "2015-10-01",
    "RecordType": "A",
    "StartRule": "geoproximity-rule",
    "Rules": {
      "geoproximity-rule": {
        "RuleType": "geo-proximity",
        "GeoproximityLocations": [
          {
            "Region": "eu-central-1",
            "Bias": 10,
            "EndpointReference": "frankfurt-endpoint"
          },
          {
            "Region": "ap-southeast-1",
            "Bias": 0,
            "EndpointReference": "singapore-endpoint"
          }
        ]
      }
    },
    "Endpoints": {
      "frankfurt-endpoint": {
        "Type": "value",
        "Value": "52.29.100.1"
      },
      "singapore-endpoint": {
        "Type": "value",
        "Value": "13.251.100.1"
      }
    }
  }'

Multivalue Answer Routing

Basit routing’in gelişmiş versiyonu gibi düşünebilirsiniz. Birden fazla kayıt tanımlar ve her birine health check ekleyebilirsiniz. Route 53 sağlıklı olan kayıtlardan rastgele sekiz tanesini döndürür.

Multivalue routing bir load balancer’ın yerini tutmaz. Ama client-side load balancing için DNS tabanlı basit bir çözüm sunar.

# Multivalue routing - birden fazla sağlıklı endpoint
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "srv.orneksite.com",
          "Type": "A",
          "SetIdentifier": "server-1",
          "MultiValueAnswer": true,
          "TTL": 60,
          "ResourceRecords": [{"Value": "10.0.1.10"}],
          "HealthCheckId": "hc-server-1"
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "srv.orneksite.com",
          "Type": "A",
          "SetIdentifier": "server-2",
          "MultiValueAnswer": true,
          "TTL": 60,
          "ResourceRecords": [{"Value": "10.0.1.11"}],
          "HealthCheckId": "hc-server-2"
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "srv.orneksite.com",
          "Type": "A",
          "SetIdentifier": "server-3",
          "MultiValueAnswer": true,
          "TTL": 60,
          "ResourceRecords": [{"Value": "10.0.1.12"}],
          "HealthCheckId": "hc-server-3"
        }
      }
    ]
  }'

Health Check Yapılandırması

Routing politikalarının gerçek gücü, health check ile birleşince ortaya çıkıyor. Sağlıksız endpoint’lere trafik yönlendirilmesini engellemek için doğru health check konfigürasyonu şart.

# Gelişmiş health check yapılandırması
aws route53 create-health-check 
  --caller-reference "advanced-hc-$(date +%s)" 
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "api.orneksite.com",
    "Port": 443,
    "ResourcePath": "/api/health",
    "RequestInterval": 10,
    "FailureThreshold": 2,
    "EnableSNI": true,
    "Regions": ["us-east-1", "eu-west-1", "ap-southeast-1"],
    "AlarmIdentifier": {
      "Region": "us-east-1",
      "Name": "api-error-rate-alarm"
    },
    "InsufficientDataHealthStatus": "Unhealthy"
  }'

Health check parametrelerinin özeti:

  • RequestInterval: 10 veya 30 saniye. 10 saniye daha hızlı failover sağlar ama maliyet artar
  • FailureThreshold: Kaç ardışık başarısız kontrol sonrası unhealthy sayılsın (1-10 arası)
  • Regions: Health check’in hangi AWS bölgelerinden yapılacağını belirler, en az 3 bölge seçin
  • EnableSNI: HTTPS kontrolleri için SNI desteği
  • InsufficientDataHealthStatus: CloudWatch alarmı veri yoksa nasıl davransın (Healthy, Unhealthy, LastKnownStatus)

Politikaları Birleştirme: Gerçek Dünya Mimarisi

Sadece tek bir routing policy kullanmak zorunda değilsiniz. DNS kayıtlarını iç içe geçirerek (DNS chaining) karmaşık yönlendirme senaryoları oluşturabilirsiniz.

Senaryo: Global bir e-ticaret platformu. Önce kullanıcıyı coğrafi bölgesine göre yönlendirin, sonra o bölge içinde weighted routing ile A/B test yapın.

Bu yapıyı oluşturmak için şu adımları izlersiniz:

  1. Her bölge için us.orneksite.com, eu.orneksite.com gibi alt domainler oluşturun ve bunlara weighted routing uygulayın
  2. Ana app.orneksite.com kaydında geolocation routing yaparak Amerikalı kullanıcıları us.orneksite.com‘a, Avrupalıları eu.orneksite.com‘a yönlendirin
# Bölgesel alt domain için weighted kayıtlar (Avrupa)
aws route53 change-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --change-batch '{
    "Changes": [
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "eu.orneksite.com",
          "Type": "A",
          "SetIdentifier": "eu-stable",
          "Weight": 95,
          "TTL": 30,
          "ResourceRecords": [{"Value": "52.29.100.1"}]
        }
      },
      {
        "Action": "CREATE",
        "ResourceRecordSet": {
          "Name": "eu.orneksite.com",
          "Type": "A",
          "SetIdentifier": "eu-canary",
          "Weight": 5,
          "TTL": 30,
          "ResourceRecords": [{"Value": "52.29.100.2"}]
        }
      }
    ]
  }'

Maliyet ve Performans Optimizasyonu

Route 53 pricing konusunda dikkat edilmesi gereken noktalar:

  • Health check maliyeti: Her health check ayda yaklaşık 0.50 dolar. HTTPS ve string matching health check’ler daha pahalı (0.75 dolar/ay)
  • DNS sorgu maliyeti: İlk 1 milyar sorgu için aylık 0.40 dolar/milyon sorgu
  • Alias kayıtlar ücretsiz: AWS kaynaklarına (ELB, CloudFront, S3) yapılan alias kayıtlar için ekstra ücret ödenmez

TTL değerlerini optimize etmek de önemli. Failover senaryolarında düşük TTL (60 saniye) kritik, ancak statik içerikler için yüksek TTL (3600 saniye) DNS sorgu maliyetini azaltır.

# Mevcut routing kayıtlarını listeleme ve kontrol etme
aws route53 list-resource-record-sets 
  --hosted-zone-id Z1234567890ABC 
  --query 'ResourceRecordSets[*].{Name:Name,Type:Type,TTL:TTL,Weight:Weight,Region:Region}' 
  --output table

# Health check durumunu kontrol etme
aws route53 get-health-check-status 
  --health-check-id YOUR_HEALTH_CHECK_ID 
  --query 'HealthCheckObservations[*].{Region:IPAddress,StatusReport:StatusReport.Status}'

Yaygın Hatalar ve Çözümleri

DNS önbellekleme sorunları: TTL değeri ne kadar düşük olursa olsun, bazı ISP’ler ve uygulamalar DNS yanıtlarını daha uzun süre önbellekte tutabilir. Bunu tamamen engelleyemezsiniz, sadece minimize edebilirsiniz.

Health check false positive’ler: Health check endpoint’iniz yük altında zaman zaman timeout alıyorsa, FailureThreshold değerini 2’den 3’e çıkarmak gereksiz failover’ları önler.

Geolocation yanlış eşleşme: Bazı kullanıcıların ISP’leri, kullanıcının gerçek konumundan farklı bir ülkeden IP adresi kullanabilir. VPN kullanan kullanıcılar da bu duruma yol açar. Bu kaçınılmaz bir durum, varsayılan kaydınızın her zaman mevcut olduğundan emin olun.

Weighted routing’de sıfır toplam: Tüm kayıtların ağırlığını 0 yaparsanız Route 53 tüm kayıtları eşit olarak döndürür. Bu bazen kafa karıştırıcı olabilir.

Sonuç

Route 53’ün yük dengeleme politikaları, DNS’i basit bir isim çözümleme mekanizmasının çok ötesine taşıyor. Doğru politikayı seçmek için birkaç temel soruyu kendinize sormalısınız: Kullanıcılarınız coğrafi olarak dağılmış mı? Aktif-pasif yedeklemeye mi ihtiyacınız var? Blue-green deployment mu yapıyorsunuz?

Basit bir kural olarak, yeni başlıyorsanız Failover Routing ile sağlıklı bir temel oluşturun. Büyüdükçe Latency-Based Routing ile performansı artırın. Daha fazla kontrol istediğinizde Geolocation veya Weighted Routing ekleyin. Bu katmanlı yaklaşım hem yönetilebilirliği artırır hem de sorun çıktığında debug etmeyi kolaylaştırır.

Health check konfigürasyonunu asla ihmal etmeyin. Routing politikalarının gerçek değeri, sağlıksız endpoint’leri otomatik olarak devre dışı bırakabilmesinde yatıyor. Son olarak, değişiklik yapmadan önce TTL değerlerinizi düşürün, değişiklik sonrası eski TTL’i geri yükleyin. Bu basit adım, olası sorunlarda geri dönüş sürenizi dramatik biçimde kısaltır.

Bir yanıt yazın

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