Kullanılabilirlik Alanları Arası (Cross-AZ) Veri Transferi Ekonomisi: Kubernetes Topology Spread ve Bölge Vergisi

Staff/Principal (L6+)

⚡ÖZET VE TEKNİK CEVAP

Bulut sağlayıcıları (AWS, Azure, GCP) aynı bölge içindeki farklı Kullanılabilirlik Alanları (AZ) arasında akan ağ trafiği için her yönde 0,01/GB (çift yönde 0,02/GB) ücret keser. Kubernetes'te yüksek erişilebilirlik (HA) sağlamak için topologySpreadConstraints ile pod'lar 3 farklı AZ'ye eşit dağıtılır. Ancak A Servisi B Servisini standart Kubernetes ClusterIP üzerinden çağırdığında, kube-proxy trafiği tüm AZ'lerdeki pod'lara rastgele dağıtır. İstatistiki olarak tüm servis içi RPC çağrılarının %66,7'si gereksiz yere AZ sınırlarını iki kez geçer. Ayda 200 TB dahili trafik çeviren bir mikroservis yapısında bu 'görünmez' bölge vergisi şirkete her ay 4.000 ila 12.000 arasında tamamen boşuna harcanan ağ faturası çıkarır. Canlı bulut sistemleri bunu Kubernetes Topology-Aware Routing (Bölge Duyarlı Yönlendirme) ile çözer: İstekleri kesinlikle çağıran pod ile aynı AZ'deki pod'lara yönlendirir; yalnızca o bölgedeki pod'lar çökerse diğer AZ'lere taşır.

Mühendislik El Kitabı & Mekanizma

6 Boyutlu Mimari Analiz

⚙️1. Temel Çalışma Mekanizması

Mekanizma

Bölge Duyarlı Yönlendirme (Topology-Aware Routing) Kubernetes EndpointSlice ipuçlarıyla çalışır:

Düğüm Bölge Etiketi: Düğümler topology.kubernetes.io/zone=us-east-1a ile etiketlenir.

EndpointSlice Kontrolcüsü: Kontrol düzlemi her bölgedeki pod kapasitesini hesaplar; dengeli ise EndpointSlice kayıtlarına forZones: ['us-east-1a'] ipucunu yazar.

Kube-Proxy Bölge Kilitleme: Kube-proxy bu ipuçlarını okuyarak iptables kurallarını günceller ve istekleri sadece çağıran pod'un bulunduğu yerel AZ'deki pod'lara yönlendirir.

Kesintisiz Hata Kurtarma: Yerel bölgedeki pod'lar çökerse veya aşırı yüklenirse, kontrolcü ipucunu kaldırarak trafiği otomatik olarak diğer AZ'lere yönlendirir.

🎯2. Doğru Kullanım Senaryosu

Kapsam

Yüksek verimli mikroservis iletişimleri (gRPC çağrıları), dağıtık veritabanı replikasyonları, Kafka akış tüketicileri ve çok kiracılı Kubernetes platformları.

⚠️3. Prodüksiyon Arıza Modları

Kritik Risk

✓
Pod'ların eşit dağılmadığı bir serviste (AZ-A'da 5 pod varken AZ-B'de 1 pod olması) Topology-Aware Routing açıp AZ-B'deki tek pod'un aşırı yükten çökmesine sebep olmak
✓
Kafka üreticilerini rastgele bölümlendirmeyle bölgeler arası trafiğe boğmak

📡4. Teşhis ve Telemetri Sinyalleri

Metrikler

✓
AWS Fatura Detaylarında 'InterZone-In' ve 'InterZone-Out' kalemlerinin toplam EC2 faturasının %15'ini aşması
✓
VPC Flow Logs analizinde AZ'ler arası devasa veri akışının tespit edilmesi

🛡️5. Önleme ve Mimari Bariyerler

Bariyerler

✓
Tüm dahili Kubernetes servislerine service.kubernetes.io/topology-mode: Auto etiketini ekleyin
✓
topologySpreadConstraints ile pod'ların AZ'lere eşit dağılmasını sağlayın
✓
Istio/Envoy üzerinde bölge duyarlı yönlendirmeyi aktif edin

⚖️6. Mimari Ödünleşimler (Trade-offs)

Ödünleşim

Bölge Duyarlı Yönlendirme cross-AZ ağ faturalarını %90 azaltır ve ağ gecikmesini 1-2 ms düşürür; ancak pod sayılarının tüm kullanılabilirlik alanlarında dengeli dağıtılmasını gerektirir.

📋

Vaka İncelemesi (TinyCTO Saha Örneği)

GERÇEK DÜNYA TELEMETRİSİ

Bir medya platformu 3 Kullanılabilirlik Alanına yayılmış API Gateway ve 35 mikroservis arasındaki gRPC çağrıları yüzünden sadece AWS Cross-AZ veri transferine ayda 18.000 ödüyordu. Tüm Kubernetes servislerine service.kubernetes.io/topology-mode: Auto etiketini eklediler ve kube-proxy trafiği yerel AZ'lerde tutmaya başladı. Bölgeler arası ağ trafiği %88 azaldı; aylık transfer faturası 18.000'den 2.160'a gerileyerek şirkete yılda 190.000 net tasarruf sağladı.

İnteraktif Konsept Alıştırmaları

2 Alıştırma

AWS ve Azure'da Kullanılabilirlik Alanları Arası (Cross-AZ) veri transferi maliyet modeli nasıldır?

Giden veri için $0,01/GB + Gelen veri için $0,01/GB; yani bölgeler arası çift yönlü iletişim için toplamda $0,02/GB ücret alınır.

Kubernetes Topology-Aware Routing cross-AZ ağ maliyetlerini nasıl sıfırlar?

Kube-proxy'yi istekleri yalnızca çağıran pod ile aynı Kullanılabilirlik Alanında bulunan pod'lara yönlendirecek şekilde yapılandırarak.

Kullanılabilirlik Alanları Arası (Cross-AZ) Veri Transferi Ekonomisi: Kubernetes Topology Spread ve Bölge Vergisi — Sıkça Sorulan Sorular

Topology-Aware Routing açıkken çağıran pod'un bulunduğu AZ'deki tüm servis pod'ları çökerse ne olur?

EndpointSlice kontrolcüsü yerel bölge ipucunu anında devre dışı bırakır ve kesinti olmaması için trafiği otomatik olarak diğer sağlıklı AZ'lerdeki pod'lara aktarır.

Topology-Aware Routing açmadan önce neden `topologySpreadConstraints` yapılandırılmalıdır?

Çünkü bu yönlendirme her AZ'de eşit pod kapasitesi (1:1:1 oranı) gerektirir; aksi halde az pod bulunan bölgedeki sunucular aşırı yükten çöker.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

▸
Kullanılabilirlik Alanları arası ağ trafiği bulutta çift yönde $0,02/GB maliyet yaratır.
▸
Varsayılan Kubernetes yük dengelemesi tüm dahili trafiğin %66,7'sini gereksiz yere farklı AZ'lere gönderir.
▸
Topology-Aware Routing trafiği yerel AZ pod'larına kilitleyerek ağ faturasını %90'a kadar azaltır.
▸
Bölge bazlı aşırı yüklenmeleri önlemek için pod'ları AZ'lere 1:1:1 oranında eşit dağıtın.

Yaygın Yanılgılar

✗
Yanılgı: Aynı VPC içindeki tüm ağ trafiği tamamen ücretsizdir (Gerçek: Aynı VPC içinde olsa bile farklı AZ'ler arasındaki transfer yön başına $0,01/GB olarak faturalandırılır).
✗
Yanılgı: Bölge duyarlı yönlendirme yüksek erişilebilirliği bozar (Gerçek: Yerel pod'lar çöktüğünde sistem anında diğer AZ'lere otomatik taşma yapar).

Karar Kılavuzu & Önceliklendirme

Yüz binlerce dolarlık gereksiz bulut ağ vergisini ortadan kaldırmak için tüm yüksek trafikli mikroservislerde Kubernetes Topology-Aware Routing'i aktif edin.

Doğrulanmış Kaynaklar & Referanslar

[OFFICIAL_DOCUMENTATION]Kubernetes Documentation: Topology Aware Routing & EndpointSlice Hints— The Kubernetes Authors (CNCF)