AWS’te DNS’ten Konteynerlere Trafik Yönetimi: Route 53 ve ALB Rehberi

Günümüzün hızla değişen dijital dünyasında, uygulamalarınızın trafiğini verimli ve güvenli bir şekilde yönetmek, başarının anahtarıdır. Peki, milyonlarca kullanıcının talebini karşılayan bulut tabanlı bir uygulamaya sahipseniz, trafiği bir DNS kaydından başlayıp nihayetinde konteyner tabanlı servislerinize nasıl yönlendirirsiniz? AWS’in güçlü servisleri Route 53 ve Application Load Balancer (ALB) tam da bu noktada devreye giriyor. Bu makalede, bu iki temel AWS hizmetinin birlikte nasıl çalıştığını, mimarinizi nasıl optimize edebileceğinizi ve uygulamalarınızın kesintisiz hizmet sunmasını nasıl sağlayabileceğinizi detaylıca inceleyeceğiz.

Modern bulut mimarilerinde kullanıcı trafiğini doğru hedefe ulaştırmak, sadece hız değil, aynı zamanda güvenilirlik ve maliyet etkinliği açısından da kritik bir rol oynar. Bu karmaşık sürecin kalbinde, Alan Adı Sistemi (DNS) ve yük dengeleme mekanizmaları yer alır. AWS ekosisteminde, bu iki ana işlevi üstlenen temel servisler Amazon Route 53 ve Application Load Balancer (ALB)‘dır. Her ikisi de, uygulamanızın internet üzerindeki varlığını ve performansını doğrudan etkileyen kritik bileşenlerdir.

Peki, bu iki servis neden bu kadar önemlidir ve birbirlerini nasıl tamamlarlar? Basitçe ifade etmek gerekirse, Route 53, kullanıcıların tarayıcılarına yazdığı kolayca akılda kalıcı alan adlarını (örneğin, www.ornekuygulama.com) uygulamanızın gerçek IP adresine veya bir yük dengeleyiciye çeviren küresel bir DNS hizmetidir. Bu, internetin telefon rehberi gibi çalışır; bir numara aradığınızda, ilgili kişiye ulaşmanızı sağlar. Route 53 olmadan, kullanıcılar uygulamanıza sadece sayısal IP adresleri üzerinden erişebilirlerdi ki bu da pratik ve kullanıcı dostu bir yöntem değildir. Aynı zamanda, Route 53 sadece temel DNS çözümlemesi yapmakla kalmaz, aynı zamanda gelişmiş trafik yönlendirme politikaları sunarak uygulamanızın global erişilebilirliğini ve performansını artırır. Örneğin, coğrafi yakınlığa dayalı yönlendirme veya belirli bir bölgede sorun yaşandığında trafiği başka bir bölgeye aktarma gibi senaryoları destekler.

Öte yandan, Application Load Balancer (ALB), gelen uygulama trafiğini, arkasındaki birden çok sunucu (veya konteyner) arasında dağıtan, katman 7 (HTTP/HTTPS) tabanlı bir yük dengeleyicidir. Kullanıcı bir kez Route 53 aracılığıyla uygulamanızın ALB’sine ulaştığında, ALB devreye girer. Tek bir sunucuya aşırı yük binmesini engeller, sunucu arızalarını otomatik olarak algılar ve trafiği sağlıklı sunuculara yönlendirir. Bu, uygulamanızın yüksek erişilebilirlik ve hata toleransı sağlaması için hayati öneme sahiptir. Özellikle modern mikroservis tabanlı ve konteynerize uygulamalar için ALB, farklı servislerin aynı port üzerinde bile olsa aynı yük dengeleyici arkasında çalışmasına olanak tanıyan gelişmiş yönlendirme kuralları sunar. Bu, URL yoluna, ana bilgisayar adına veya HTTP başlıklarına göre trafiği farklı hedef gruplarına (Target Groups) yönlendirme yeteneği sayesinde gerçekleşir.

Bu iki servis bir araya geldiğinde, sorunsuz ve esnek bir trafik yönlendirme mimarisi oluştururlar. Route 53, ilk kapıyı açar ve kullanıcıyı doğru bölgedeki veya doğru IP adresindeki ALB’ye yönlendirir. ALB ise bu trafiği alarak uygulamanızın içindeki belirli konteynerlere veya EC2 örneklerine akıllıca dağıtır. Bu entegrasyon, yalnızca uygulamanızın performansını ve güvenilirliğini artırmakla kalmaz, aynı zamanda ölçeklenebilirliğini de büyük ölçüde iyileştirir. Yeni bir sunucu veya konteyner eklediğinizde, ALB bunu otomatik olarak tanır ve trafiği ona yönlendirmeye başlar. Benzer şekilde, bir sunucu çöktüğünde, ALB o sunucuya trafik göndermeyi durdurur. Bu otomatik yönetim yetenekleri, operasyonel yükü azaltır ve mühendislik ekiplerinin daha çok inovasyona odaklanmasını sağlar.

Sonuç olarak, Route 53 ve ALB, AWS üzerinde modern, yüksek performanslı ve dayanıklı uygulamalar geliştirmek isteyen herkes için vazgeçilmez araçlardır. Birbirlerini tamamlayarak, DNS çözümlemesinden başlayıp uygulama katmanındaki yük dengelemeye kadar uzanan kesintisiz bir trafik akışı sağlarlar.

Amazon Route 53 Nasıl Çalışır ve Trafiği Nasıl Yönlendirir?

Amazon Route 53, AWS’in ölçeklenebilir ve yüksek oranda erişilebilir bir alan adı sistemi (DNS) web hizmetidir. İnternetin temel altyapısı olan DNS’in kalbinde yer alır ve kullanıcıların tarayıcılarına yazdığı alan adlarını, web sunucularının veya diğer internet kaynaklarının IP adreslerine dönüştürmekten sorumludur. Bu “çeviri” süreci olmadan, internetin bugünkü haliyle çalışması mümkün olmazdı. Route 53’ün sadece bir DNS çözücüden çok daha fazlası olduğunu anlamak, AWS’teki trafik yönetimi stratejilerinizi geliştirmeniz için kritik öneme sahiptir.

Peki, Route 53 tam olarak nasıl çalışır ve trafiği nasıl yönlendirir? Süreç genellikle şu adımları izler:

1. Kullanıcı İsteği: Bir kullanıcı tarayıcısına www.ornekuygulama.com gibi bir alan adı yazdığında, bilgisayarının işletim sistemi bu alan adının IP adresini bulmak için bir DNS sorgusu başlatır.
2. Yerel DNS Çözümleyicisi: Sorgu, kullanıcının internet servis sağlayıcısının (İSS) DNS çözümleyicisine ulaşır.
3. Kök ve TLD Sunucuları: İSS’nin çözümleyicisi, alan adını çözümlemek için önce kök DNS sunucularına, ardından .com gibi Üst Düzey Alan Adı (TLD) sunucularına sorgu gönderir.
4. Yetkili DNS Sunucusu (Route 53): TLD sunucusu, ornekuygulama.com için yetkili DNS sunucusunun Amazon Route 53 olduğunu belirtir. Sorgu daha sonra Route 53’e yönlendirilir.
5. Route 53 Kayıtları: Route 53, kendi içinde tuttuğu DNS kayıtlarına bakar (örneğin, bir A kaydı veya CNAME kaydı). Bu kayıtlar, alan adını belirli bir IP adresine, başka bir alan adına veya bir AWS kaynağına (bir ALB gibi) eşler.
6. IP Adresi Yanıtı: Route 53, uygun IP adresini İSS’nin çözümleyicisine geri gönderir.
7. Bağlantı Kurulumu: İSS çözümleyicisi bu IP adresini kullanıcının bilgisayarına iletir ve kullanıcı tarayıcısı bu IP adresiyle doğrudan bağlantı kurarak uygulamaya erişir.

Bu temel işleyişin yanı sıra, Route 53, trafiği daha akıllıca yönlendirmek için çeşitli yönlendirme politikaları sunar. Bu politikalar, uygulamanızın performansını, güvenilirliğini ve maliyet etkinliğini artırmanıza yardımcı olur:

• Basit Yönlendirme Politikası (Simple Routing Policy): Tek bir kaynak için DNS kayıtları oluşturur. En basit senaryolar için idealdir.
• Failover Yönlendirme Politikası (Failover Routing Policy): Aktif-pasif bir mimari kurmanıza olanak tanır. Birincil kaynak kullanılamaz hale geldiğinde trafiği otomatik olarak ikincil kaynağa yönlendirir. Bu, yüksek erişilebilirlik için kritik öneme sahiptir ve uygulamaların kesintisiz hizmet sunmasına yardımcı olur.
• Ağırlıklı Yönlendirme Politikası (Weighted Routing Policy): Trafiği birden fazla kaynağa belirli ağırlık oranlarına göre dağıtır. Örneğin, trafiğin %80’ini yeni bir versiyona, %20’sini eski bir versiyona yönlendirerek A/B testleri veya kademeli dağıtım (canary deployment) yapabilirsiniz. Bu, yeni özelliklerin veya güncellemelerin etkilerini ölçmek ve riskleri azaltmak için mükemmel bir araçtır.
• Gecikme Tabanlı Yönlendirme Politikası (Latency Routing Policy): Kullanıcının bulunduğu yere en yakın ve en düşük gecikmeye sahip AWS bölgesindeki kaynağa trafiği yönlendirir. Bu, global uygulamalar için kullanıcı deneyimini önemli ölçüde iyileştirir.
• Coğrafi Konum Yönlendirme Politikası (Geolocation Routing Policy): Kullanıcının coğrafi konumuna (ülke, kıta vb.) göre trafiği belirli kaynaklara yönlendirir. Bu, bölgesel içerik sunumu veya lisans kısıtlamaları olan uygulamalar için kullanışlıdır.
• Coğrafi Yakınlık Yönlendirme Politikası (Geoproximity Routing Policy): Kaynakların ve kullanıcıların coğrafi konumlarına göre trafiği yönlendirir. Gecikme tabanlıdan daha granüler kontrol sunar ve Route 53 trafik akışları (Traffic Flow) ile entegre çalışır.
• Çok Değerli Yanıt Politikası (Multivalue Answer Routing Policy): Bir DNS sorgusuna birden fazla IP adresi döndürür ve istemcinin bunlardan birini rastgele seçmesini sağlar. Basit bir yük dengeleme formu olarak düşünülebilir, ancak ALB kadar gelişmiş değildir.

Route 53, bu politikaları kullanarak uygulamaların global ölçekte verimli, hızlı ve dayanıklı olmasını sağlar. Özellikle bir Application Load Balancer (ALB) ile entegre edildiğinde, DNS katmanından başlayan akıllı bir trafik yönetimi zincirinin ilk halkasını oluşturur.

# Route 53 A kaydı oluşturma örneği (CloudFormation YAML)
# Bu örnek, bir Application Load Balancer'a işaret eden bir A kaydının nasıl oluşturulacağını gösterir.
Resources:
  MyDomainRecordSet:
    Type: AWS::Route53::RecordSet
    Properties:
      HostedZoneName: "ornekuygulama.com." # Alan adınız
      Name: "www.ornekuygulama.com."       # Tam etki alanı adı
      Type: A
      AliasTarget:
        HostedZoneId: !GetAtt MyALB.CanonicalHostedZoneID # ALB'nizin Hosted Zone ID'si
        DNSName: !GetAtt MyALB.DNSName                 # ALB'nizin DNS Adı
        EvaluateTargetHealth: true

Uzman İpucu: Route 53 kayıtlarınızın TTL (Time To Live) değerini dikkatlice ayarlayın. Düşük bir TTL, değişikliklerin (örneğin, bir yük dengeleyici değişikliği) daha hızlı yayılmasını sağlarken, DNS sunucuları üzerinde daha fazla yük oluşturur. Yüksek bir TTL ise tersine, daha yavaş yayılır ancak daha az sorguya neden olur.

Application Load Balancer (ALB) ile Konteyner Trafiği Nasıl Yönlendirilir?

Application Load Balancer (ALB), AWS ekosisteminde Layer 7 (uygulama katmanı) düzeyinde çalışan güçlü bir yük dengeleyicidir. Gelen HTTP ve HTTPS trafiğini hedeflenen kaynaklar arasında dağıtmakla kalmaz, aynı zamanda gelişmiş içerik tabanlı yönlendirme özellikleriyle modern, mikroservis tabanlı ve konteynerize uygulamalar için vazgeçilmez bir araçtır. Route 53'ün DNS çözümlemesi ile trafiği ALB'ye yönlendirmesinden sonra, ALB'nin görevi bu trafiği alıp uygulamanızın içinde çalışan belirli servis konteynerlerine veya EC2 örneklerine akıllıca dağıtmaktır.

ALB'nin konteyner trafiğini yönetme yeteneği, özellikle Amazon ECS (Elastic Container Service) ve Amazon EKS (Elastic Kubernetes Service) gibi konteyner orkestrasyon servisleriyle birleştiğinde gerçek gücünü gösterir. İşte ALB'nin bu süreci nasıl yönettiğinin adımları:

1. Listener (Dinleyici) Oluşturma: İlk adım, ALB'nin hangi portlar ve protokoller üzerinden (örneğin, HTTP:80 veya HTTPS:443) gelen bağlantıları dinleyeceğini belirten bir dinleyici oluşturmaktır. HTTPS dinleyicileri için, ALB SSL/TLS sonlandırmasını da yapabilir, bu da konteynerlerinizin CPU yükünü azaltır ve güvenlik sertifikalarını merkezi olarak yönetmenizi sağlar.
2. Target Groups (Hedef Grupları): ALB, trafiği doğrudan bireysel konteynerlere değil, "Hedef Grupları" adı verilen mantıksal gruplara yönlendirir. Bir hedef grubu, belirli bir protokole ve porta sahip bir veya daha fazla tescilli hedef (örneğin, EC2 örnekleri, IP adresleri veya Lambda fonksiyonları) içerir. Konteynerize uygulamalar için, bir hedef grubu genellikle aynı servisi çalıştıran bir grup konteyneri temsil eder. Örneğin, bir web uygulaması için bir "Frontend" hedef grubu ve bir API servisi için bir "Backend API" hedef grubu olabilir.
3. Health Checks (Sağlık Kontrolleri): Her hedef grubu için sağlık kontrolleri tanımlanır. ALB, bu sağlık kontrollerini kullanarak hedef grubundaki her bir hedefin (konteynerin) çalışır durumda olup olmadığını periyodik olarak kontrol eder. Bir konteyner sağlık kontrolünü geçemezse, ALB ona trafik göndermeyi durdurur ve bu, uygulamanızın kesintisiz hizmet vermesini sağlar.
4. Routing Rules (Yönlendirme Kuralları): ALB'nin en güçlü özelliklerinden biri, gelişmiş yönlendirme kurallarıdır. Bir dinleyiciye gelen istekleri farklı hedef gruplarına yönlendirmek için koşullar tanımlayabilirsiniz. Örneğin:
   • Yol Tabanlı Yönlendirme (Path-based routing): /api/* yoluna gelen istekleri "Backend API" hedef grubuna, /* yoluna gelen istekleri "Frontend" hedef grubuna yönlendirme.
   • Ana Bilgisayar Adı Tabanlı Yönlendirme (Host-based routing): app.ornek.com adresine gelen istekleri "Uygulama" hedef grubuna, admin.ornek.com adresine gelen istekleri "Yönetim Paneli" hedef grubuna yönlendirme.
   • HTTP Başlığı Tabanlı Yönlendirme (HTTP header-based routing): Belirli bir HTTP başlığına sahip isteklere göre yönlendirme.
   • Sorgu Dizesi Parametresi Tabanlı Yönlendirme (Query string parameter-based routing): URL'deki sorgu parametrelerine göre yönlendirme.

   Bu kurallar, mikroservis mimarilerinde çok sayıda servisi tek bir ALB üzerinden yönetmeyi son derece kolaylaştırır.

Konteyner ve Dinamik Port Entegrasyonu: ECS ve EKS gibi konteyner servisleriyle çalışırken, ALB'nin dinamik port eşleme yeteneği kritik öneme sahiptir. Konteynerler genellikle kısa ömürlüdür ve her yeniden başlatıldığında farklı bir ana bilgisayar portu üzerinde çalışabilirler. ALB, bu dinamik portları otomatik olarak algılar ve hedeflere kaydeder. Örneğin, bir ECS servisini bir ALB hedef grubuna kaydettiğinizde, ECS servis tanımınızda belirtilen hedef portu (konteyner içindeki port) ALB dinleyici portuna yönlendirilir. ALB ise bu trafiği konteynerin EC2 ana bilgisayarındaki dinamik olarak atanmış porta yönlendirir. Bu sayede, uygulamanızın ölçeklenmesi veya güncellenmesi sırasında herhangi bir manuel konfigürasyona gerek kalmaz.

Örnek Senaryo: Mikroservis Uygulaması

Diyelim ki bir e-ticaret uygulamanız var ve bu uygulama mikroservisler halinde çalışıyor: bir "ürün katalog" servisi, bir "ödeme" servisi ve bir "kullanıcı profili" servisi. Tüm bu servisler ECS Fargate üzerinde konteynerlerde çalışıyor.

• Bir ALB oluşturursunuz.
• HTTPS:443 için bir dinleyici tanımlarsınız.
• Üç ayrı hedef grubu oluşturursunuz: product-catalog-tg, payment-tg, user-profile-tg.
• Her bir hedef grubuna ilgili ECS servislerinizdeki görevleri (task) kaydeder ve sağlık kontrollerini yapılandırırsınız.
• ALB dinleyiciniz için aşağıdaki yönlendirme kurallarını belirlersiniz:
  • Eğer istek yolu /products/* ise, trafiği product-catalog-tg'ye yönlendir.
  • Eğer istek yolu /checkout/* ise, trafiği payment-tg'ye yönlendir.
  • Eğer istek yolu /users/* ise, trafiği user-profile-tg'ye yönlendir.
  • Varsayılan (Default) kural olarak, ana sayfaya veya diğer statik içeriğe yönlendirmek için bir frontend-tg oluşturup, tüm diğer istekleri oraya yönlendirebilirsiniz.

Bu yapı sayesinde, tek bir alan adı (Route 53 üzerinden ALB'ye işaret eden) altında birden çok mikroservisi yönetebilir ve her bir servisi bağımsız olarak ölçekleyebilirsiniz. ALB, gelen isteklere bakarak doğru servise (doğru konteynere) trafiği iletir. Bu, modern bulut tabanlı uygulamaların esnekliğini ve verimliliğini artıran temel bir yaklaşımdır.

# ALB Listener Rule örneği (CloudFormation YAML)
# Bu örnek, /api yoluna gelen istekleri belirli bir hedef grubuna nasıl yönlendireceğini gösterir.
Resources:
  MyALBListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref MyALB # Mevcut ALB'nizin ARN'si
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref DefaultTargetGroup # Varsayılan hedef grup ARN'si

  ApiListenerRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      ListenerArn: !Ref MyALBListener
      Priority: 10 # Kuralların değerlendirilme önceliği
      Conditions:
        - Field: path-pattern
          Values: ["/api/*"]
      Actions:
        - Type: forward
          TargetGroupArn: !Ref ApiTargetGroup # API servisi hedef grubu ARN'si

Uzman İpucu: ALB'nin Request Tracing (İstek İzleme) özelliğini kullanarak, isteklerin ALB'den hedeflere nasıl ulaştığını izleyebilirsiniz. X-Forwarded-For, X-Forwarded-Proto ve X-Forwarded-Port başlıkları, orijinal istemci bilgilerini hedeflerinize iletmek için kullanılır.

Vaka Analizi: Global Bir E-ticaret Platformunun Trafik Akışı

Modern bir e-ticaret platformu, dünyanın dört bir yanındaki milyonlarca kullanıcıya hizmet vermesi gereken karmaşık ve yüksek performanslı bir yapıdır. Bu tür bir platformda trafik yönetimi, sadece uygulamanın erişilebilirliğini değil, aynı zamanda kullanıcı deneyimini, iş sürekliliğini ve hatta güvenlik postürünü de doğrudan etkiler. Şimdi, hayali ama gerçekçi bir global e-ticaret platformu olan "GlobalShop" üzerinden, Route 53 ve Application Load Balancer (ALB)'ın konteynerize servislerle birlikte nasıl çalıştığını inceleyelim.

Problem Senaryosu: GlobalShop'un Zorlukları Nelerdi?

GlobalShop, ilk başlarda tek bir AWS bölgesinde (örneğin, us-east-1) barındırılan monolitik bir uygulamaydı. Ancak dünya çapında genişledikçe şu sorunlarla karşılaştılar:

1. Yüksek Gecikme: Avrupa ve Asya'daki kullanıcılar, uygulamanın Amerika'da olmasından dolayı belirgin bir gecikme yaşıyorlardı.
2. Tek Nokta Hatası (SPOF): Tek bir bölgedeki bir arıza, tüm platformu çevrimdışı bırakma potansiyeli taşıyordu.
3. Ölçeklenebilirlik Kısıtlamaları: Yoğun satış dönemlerinde (Kara Cuma gibi), monolitik uygulama yeterince hızlı ölçeklenemiyordu ve performans düşüşleri yaşanıyordu.
4. Mikroservis Entegrasyonu Zorluğu: Yeni özellikler eklemek veya mevcut servisleri güncellemek, tüm uygulamayı etkiliyordu. Bu nedenle, uygulamayı mikroservislere bölme kararı aldılar ve bu servisleri Amazon ECS (Elastic Container Service) üzerinde çalıştırmak istediler.

Çözüm: Çok Bölgeli, Konteynerize Mimari

GlobalShop, bu sorunları çözmek için çok bölgeli (multi-region) ve mikroservis tabanlı bir mimariye geçmeye karar verdi. Temel mimari şu şekilde şekillendirildi:

1. Çok Bölgeli Dağıtım: Uygulama, us-east-1, eu-west-1 ve ap-southeast-1 olmak üzere üç farklı AWS bölgesine dağıtıldı. Her bölge, uygulamanın tam bir kopyasını (ön uç, ürün kataloğu, ödeme, kullanıcı servisi vb.) barındırıyor.
2. Route 53 ile Akıllı DNS Yönlendirme:
   • GlobalShop, alan adı (globalshop.com) için Route 53'ü yetkili DNS servisi olarak kullandı.
   • Her bölgedeki Application Load Balancer (ALB) için birer A kaydı oluşturuldu.
   • Bu A kayıtları için Gecikme Tabanlı Yönlendirme Politikası (Latency Routing Policy) uygulandı. Bu sayede, Avrupa'dan gelen bir kullanıcı otomatik olarak eu-west-1 bölgesindeki ALB'ye, Asya'dan gelen bir kullanıcı ise ap-southeast-1 bölgesindeki ALB'ye yönlendirildi. Bu, kullanıcılar için en düşük gecikmeyi ve en iyi deneyimi sağladı.
   • Ayrıca, bir bölgedeki ALB'nin sağlık kontrolünü geçememesi durumunda trafiği otomatik olarak sağlıklı olan diğer bir bölgedeki ALB'ye yönlendirmek için Failover Yönlendirme Politikası da konfigüre edildi. Bu, platformun yüksek erişilebilirliğini garanti altına aldı.
3. ALB ve Konteynerlerin Gücü:
   • Her AWS bölgesinde, ayrı bir Application Load Balancer konuşlandırıldı. Bu ALB'ler, tüm gelen HTTP/HTTPS trafiğini sonlandırıyor ve SSL sertifikalarını yönetiyordu.
   • GlobalShop'un her mikroservisi (örneğin, product-catalog-service, payment-service, user-service), Amazon ECS Fargate üzerinde kendi konteynerlerinde çalışıyordu. Her bir servis için ayrı bir Hedef Grubu (Target Group) oluşturuldu.
   • ALB dinleyicileri, gelen istekleri URL yoluna göre ilgili hedef gruplarına yönlendirmek için yol tabanlı yönlendirme kuralları kullanıyordu:
     • /products/* istekleri product-catalog-tg hedef grubuna.
     • /checkout/* istekleri payment-tg hedef grubuna.
     • /users/* istekleri user-profile-tg hedef grubuna.
   • Her hedef grubu, ECS Fargate servisindeki konteynerlerin dinamik portlarını otomatik olarak algılayacak şekilde yapılandırıldı. Bu sayede, servislerin ölçeklenmesi veya güncellenmesi sırasında ALB otomatik olarak yeni veya güncellenmiş konteynerleri tanıyordu.
   • Sağlık kontrolleri her hedef grubunda etkinleştirildi. Bir konteyner sorun yaşadığında, ALB o konteynere trafik göndermeyi durduruyor ve sağlıklı konteynerlere yönlendiriyordu.

Sonuç ve Kazanımlar

Bu mimari değişikliği sayesinde GlobalShop, önemli faydalar elde etti:

• Küresel Performans Artışı: Kullanıcılar, kendilerine en yakın veri merkezinden hizmet alarak gecikmeyi minimuma indirdi ve çok daha hızlı bir alışveriş deneyimi yaşadı.
• Yüksek Erişilebilirlik ve Felaket Kurtarma: Bir AWS bölgesinde yaşanan bir kesinti durumunda bile Route 53, trafiği otomatik olarak başka bir sağlıklı bölgeye yönlendirerek iş sürekliliğini sağladı.
• Esnek Ölçeklenebilirlik: ALB ve ECS Fargate'in entegrasyonu sayesinde, her mikroservis kendi ihtiyacına göre bağımsız olarak ölçeklenebildi. Yoğun dönemlerde sadece ihtiyacı olan servisler ölçeklendi, bu da maliyet etkinliğini artırdı.
• Kolay Geliştirme ve Dağıtım: Mikroservis mimarisi, ekiplerin daha küçük kod parçaları üzerinde paralel çalışmasına olanak tanıdı ve yeni özelliklerin daha hızlı ve risksiz bir şekilde dağıtılmasını sağladı.
• Gelişmiş Güvenlik: ALB, SSL/TLS sonlandırması yaparak hassas verilerin şifreli iletilmesini sağladı ve konteynerlere giden trafiği daha güvenli hale getirdi.

Bu vaka analizi, AWS Route 53 ve Application Load Balancer'ın, konteynerize uygulamalarla birleştiğinde nasıl güçlü, esnek ve küresel ölçekte başarılı bir trafik yönetim çözümü sunduğunu açıkça göstermektedir. Bu servislerin doğru konfigürasyonu, modern bulut uygulamalarının omurgasını oluşturur.

İleri Düzey Uygulamalar: Daha Akıllı Trafik Yönlendirme Stratejileri

Route 53 ve Application Load Balancer (ALB)'ın temel entegrasyonu bile uygulamalarınıza önemli avantajlar sağlarken, bu servislerin sunduğu ileri düzey özellikler, çok daha sofistike ve dayanıklı trafik yönlendirme stratejileri geliştirmenize olanak tanır. Özellikle büyük ölçekli, global veya yüksek performans gerektiren konteynerize uygulamalar için bu stratejiler hayati öneme sahiptir.

Route 53 Trafik Akışları (Traffic Flow) ve Sağlık Kontrolleri

Route 53'ün en güçlü özelliklerinden biri olan Trafik Akışları (Traffic Flow), farklı yönlendirme politikalarını birleştirerek daha karmaşık trafik yönetimi senaryoları oluşturmanıza imkan tanır. Örneğin, hem coğrafi konum hem de ağırlık tabanlı yönlendirmeyi aynı anda kullanabilirsiniz. Trafik Akışları, görsel bir arayüzle yönlendirme kararlarını daha anlaşılır hale getirir.

Sağlık Kontrolleri (Health Checks), Route 53'ün proaktif bir şekilde hedeflerinizin durumunu izlemesini sağlar. Bir web sunucusu, bir ALB veya bir ELB (Classic/Network Load Balancer) gibi bir kaynağa doğrudan sağlık kontrolü yapabilir. Eğer bir hedef sağlık kontrolünü geçemezse, Route 53 o hedefe trafik yönlendirmeyi durdurur. Bu, özellikle Failover veya Weighted Routing politikalarıyla birlikte kullanıldığında, uygulamanızın kesintisiz hizmet vermesi için kritik öneme sahiptir.

• Örnek Senaryo: Çok Bölgeli Felaket Kurtarma (Multi-Region Disaster Recovery)

  Uygulamanızın birincil bölgesi (örneğin, us-east-1) ve bir felaket kurtarma bölgesi (örneğin, eu-west-1) var. Her iki bölgede de bir ALB çalışıyor. Route 53'te, us-east-1'deki ALB'ye işaret eden bir birincil (primary) kayıt seti ve eu-west-1'deki ALB'ye işaret eden bir ikincil (secondary) kayıt seti oluşturursunuz. Her iki ALB için de sağlık kontrolleri tanımlarsınız. Eğer us-east-1'deki ALB sağlık kontrolünü geçemezse, Route 53 otomatik olarak tüm trafiği eu-west-1'deki ALB'ye yönlendirir. Bu sayede, büyük bir bölgesel kesinti durumunda bile uygulamanızın hizmet vermeye devam etmesi sağlanır.

ALB'nin Gelişmiş Yönlendirme Yetenekleri ve Entegrasyonlar

ALB, sadece yol veya ana bilgisayar adı tabanlı yönlendirmeden daha fazlasını sunar:

• HTTP Header ve Sorgu Dizesi Yönlendirme: Belirli HTTP başlıklarına veya URL'deki sorgu dizesi parametrelerine göre yönlendirme yapabilirsiniz. Bu, özellikle A/B testleri, canary dağıtımlar veya belirli kullanıcı gruplarına özel özellikler sunmak için faydalıdır. Örneğin, "X-User-Type: Premium" başlığına sahip istekleri özel bir "Premium Servis" hedef grubuna yönlendirebilirsiniz.
• Lambda Hedef Grupları: ALB, gelen istekleri doğrudan AWS Lambda fonksiyonlarına yönlendirebilir. Bu, sunucusuz (serverless) mimarileri, uygulamanızın diğer konteynerize mikroservisleriyle aynı yük dengeleyici arkasında çalıştırmanıza olanak tanır.
• IP Hedef Grupları: EC2 örnekleri yerine doğrudan IP adreslerini hedef olarak belirleyebilirsiniz. Bu, özellikle farklı VPC'lerdeki kaynaklara veya şirket içi (on-premise) sunuculara yönlendirme yapmanız gerektiğinde esneklik sağlar.
• Yapışkan Oturumlar (Sticky Sessions): Kullanıcıların belirli bir sunucuya (veya konteyner örneğine) bağlı kalmasını sağlamak için yapışkan oturumları etkinleştirebilirsiniz. Bu, oturum durumu tutan uygulamalar için faydalıdır, ancak genellikle stateless (durumsuz) mikroservis mimarilerinde kaçınılması önerilir.
• Otokeynaklama (Autoscaling) ile Entegrasyon: ALB, otomatik ölçeklendirme grupları (Auto Scaling Groups) ve ECS/EKS servisleri ile sorunsuz bir şekilde entegre olur. Yeni konteynerler veya EC2 örnekleri başlatıldığında, ALB bunları otomatik olarak hedef grubuna kaydeder ve sağlık kontrolünden geçirir. Bu, uygulamanızın talebe göre dinamik olarak ölçeklenmesini sağlar.

# İleri düzey ALB Listener Rule örneği (HTTP Header ve Query String)
Resources:
  MyALBListener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref MyALB
      Port: 443
      Protocol: HTTPS
      SslPolicy: ELBSecurityPolicy-2016-08
      Certificates:
        - CertificateArn: arn:aws:acm:REGION:ACCOUNTID:certificate/CERT_ID
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref DefaultTargetGroup

  ABTestRule:
    Type: AWS::ElasticLoadBalancingV2::ListenerRule
    Properties:
      ListenerArn: !Ref MyALBListener
      Priority: 5 # Daha yüksek öncelik
      Conditions:
        - Field: http-header
          HttpHeaderConfig:
            HttpHeaderName: X-AB-Test
            Values: ["VariantB"] # X-AB-Test başlığı VariantB ise
        - Field: query-string
          QueryStringConfig:
            Values:
              - Key: feature
                Value: newUI # veya URL'de ?feature=newUI varsa
      Actions:
        - Type: forward
          TargetGroupArn: !Ref ABTestTargetGroup # Variant B veya yeni UI için hedef grup

Uzman İpucu: Çok sayıda yönlendirme kuralı kullanıyorsanız, kuralların öncelik sıralamasına dikkat edin. Daha spesifik kurallar (örneğin, belirli bir yol veya başlık için) daha yüksek önceliğe sahip olmalı, genel kurallar (örneğin, varsayılan yönlendirme) ise daha düşük öncelikte olmalıdır.

WAF (Web Application Firewall) Entegrasyonu

ALB'nizi AWS WAF ile entegre ederek uygulamanızın güvenliğini önemli ölçüde artırabilirsiniz. WAF, SQL enjeksiyonu, XSS (Cross-Site Scripting) gibi yaygın web açıklıklarına karşı koruma sağlar. Bu entegrasyon, trafik daha ALB'nize ulaşmadan kötü niyetli istekleri engeller ve konteyner tabanlı servislerinizin üzerinde ek bir güvenlik katmanı oluşturur.

Bu ileri düzey stratejiler, uygulamalarınızın sadece çalışmasını değil, aynı zamanda en üst düzeyde performans, esneklik, güvenilirlik ve güvenlik sunmasını sağlar. Route 53'ün küresel DNS gücü ile ALB'nin akıllı uygulama katmanı yönlendirme yeteneklerini birleştirmek, modern bulut tabanlı uygulamalar için sağlam bir omurga oluşturur.

Sıkça Sorulan Sorular

Soru 1: Route 53 ile ALB entegrasyonu neden gereklidir?

Cevap: Route 53, alan adınızı (örneğin, www.ornek.com) uygulamanızın bulunduğu bir IP adresine veya bir yük dengeleyiciye çeviren DNS hizmetidir. Kullanıcılar bir alan adı yazdığında, Route 53 DNS sorgusunu çözümler ve ALB'nizin DNS adını veya IP adresini döndürür. ALB ise bu gelen trafiği alarak uygulamanızın arkasındaki sağlıklı sunuculara veya konteynerlere dağıtır. Kısacası, Route 53 "nereden gidileceğini" söyler, ALB ise "oraya nasıl varılacağını ve trafiğin nasıl dağıtılacağını" yönetir. Bu entegrasyon, hem kolay erişim hem de yüksek erişilebilirlik, ölçeklenebilirlik ve performans sağlar.

Soru 2: ALB, konteynerlerimin dinamik portlarını nasıl yönetir?

Cevap: ALB'nin Hedef Grupları (Target Groups), özellikle Amazon ECS ve EKS gibi konteyner orkestrasyon servisleriyle entegrasyonda dinamik portları destekler. Bir konteyner başlatıldığında, ana bilgisayar üzerinde dinamik olarak bir port atanır (örneğin, 49153). ALB'nin hedef grubu, bu dinamik portu ve konteynerin çalıştığı EC2 örneğini (veya Fargate durumunda ENI IP'sini) otomatik olarak kaydeder. ALB, gelen trafiği dinleyici portundan (örneğin, 80 veya 443) alıp, hedef gruptaki doğru konteynerin dinamik olarak atanan portuna yönlendirir. Bu, konteynerlerin esnek bir şekilde ölçeklenmesini ve güncellenmesini kolaylaştırır.

Soru 3: Route 53'teki farklı yönlendirme politikaları ne zaman kullanılır?

Cevap:

• Basit Yönlendirme: Tek bir kaynak için standart DNS çözümlemesi.
• Failover Yönlendirme: Aktif/pasif felaket kurtarma senaryolarında, birincil kaynak arızalandığında trafiği otomatik olarak ikincil kaynağa yönlendirmek için.
• Ağırlıklı Yönlendirme: A/B testleri, canary dağıtımları veya trafikte kademeli geçişler yapmak için, trafiği farklı kaynaklara belirli oranlarda dağıtmak.
• Gecikme Tabanlı Yönlendirme: Kullanıcıları coğrafi olarak en yakın ve en düşük gecikmeye sahip AWS bölgesindeki uygulamanıza yönlendirerek performansı artırmak için.
• Coğrafi Konum Yönlendirme: Kullanıcıların coğrafi konumuna (ülke, kıta) göre içerik sunmak veya lisans kısıtlamalarını yönetmek için.

Doğru politika seçimi, uygulamanızın gereksinimlerine (performans, erişilebilirlik, dağıtım stratejisi) bağlıdır.

Soru 4: ALB ve WAF entegrasyonu nasıl çalışır?

Cevap: AWS WAF (Web Application Firewall), web uygulamalarınızı yaygın web saldırılarına karşı korumak için tasarlanmış bir güvenlik hizmetidir. ALB'nizi bir WAF Web ACL (Access Control List) ile ilişkilendirdiğinizde, ALB'ye gelen tüm istekler WAF tarafından tanımlanan kurallara göre incelenir. WAF, kötü niyetli veya şüpheli istekleri (örneğin, SQL enjeksiyonu, XSS, IP adresi engelleme) uygulamanıza ulaşmadan önce engeller, izin verir veya loglar. Bu, konteynerize uygulamalarınız için ek bir güvenlik katmanı sağlar ve arka uç servislerinizin sadece temiz trafiği işlemesini sağlar.

Soru 5: ALB SSL/TLS sonlandırması ne anlama geliyor ve neden önemlidir?

Cevap: SSL/TLS sonlandırması, ALB'nin gelen şifreli (HTTPS) trafiği deşifre etmesi ve şifresini çözülmüş (HTTP) trafiği arka uç hedeflerinize (konteynerleriniz) iletmesi anlamına gelir. Bu, birkaç önemli avantaj sunar:

• Performans: SSL/TLS şifreleme ve deşifreleme işlemleri CPU yoğun görevlerdir. ALB'nin bu yükü üstlenmesi, konteynerlerinizin kendi iş mantığına odaklanmasına ve daha az CPU tüketmesine olanak tanır.
• Yönetim Kolaylığı: SSL sertifikalarını tek bir yerden (ALB) yönetirsiniz, her bir konteyner için ayrı ayrı sertifika yönetimi yapmanıza gerek kalmaz. AWS Certificate Manager (ACM) ile kolayca entegre edilebilir.
• Güvenlik: ALB ile arka uç hedefleriniz arasındaki bağlantı için ek bir şifreleme (ALB-to-target encryption) de yapılandırabilirsiniz, böylece tüm iletişim yolu şifreli kalır.

Bu, özellikle yüksek trafikli uygulamalar için önemlidir ve güvenlik ile performans arasında optimal bir denge sağlar.