Bir servisi “edge’e taşıyorum” dediğinizde çoğu ekip önce CDN veya WAF düşünür. Oysa edge tasarımının en kritik parçası çoğu zaman routing kararının kendisidir: Kullanıcı trafiğini en yakın/sağlıklı POP’a (Point of Presence) nasıl götüreceksiniz, kapasite doygunluğunda nasıl davranacaksınız ve DDoS altında nasıl ayakta kalacaksınız?
Bu yazıda BGP Anycast’i, “sihirli bir yakınlık (proximity) butonu” gibi değil; operasyonel bir sistem gibi ele alıyorum: sağlık sinyali, otomasyon, kapasite ve saldırı senaryolarıyla birlikte.
Anycast neyi çözer, neyi çözmez?
Çözdüğü problem: Tek bir IP (veya /24 gibi bir prefix) ile birden fazla POP’tan servis verip, trafiği routing ile dağıtmak. En yaygın kullanımlar:
- Authoritative DNS (Anycast NS)
- Recursive DNS (kurumsal resolver)
- L4 edge (TCP/UDP proxy, DDoS scrubbing, game/voice servisleri)
- API gateway (özellikle stateless ve kısa ömürlü bağlantılarda)
Çözmediği problem: Anycast, uygulama katmanı durumunu (state) otomatik taşımaz. Uzun TCP oturumları, websocket’ler, sticky session gereksinimi olan sistemler veya veri tutarlılığı hassas back-end çağrıları için “daha yakın POP” tek başına başarı değildir.
Temel bileşenler: Prefix, POP ve upstream
Sağlam bir Anycast tasarımını üç katman olarak düşünün:
- Anycast prefix: Genellikle IPv4’te /24 (announce edilebilir minimum) veya IPv6’ta /48.
- POP: Her POP’ta bu prefix’i servise bağlayan bir edge (L4/L7) ve routing cihazı.
- Upstream/IX: POP’un BGP peering yaptığı transit’ler veya internet exchange’ler.
Bu yapıda kritik sorular:
- Prefix’i kaç POP’ta announce edeceksiniz?
- POP’lar arasında kapasite asimetrisi var mı?
- Upstream çeşitliliği ve “path diversity” yeterli mi?
- POP’un “tamamen sağlıklı” sayılması için hangi sinyaller gerekli?
Sağlık sinyali: “BGP up” sağlıklı demek değildir
En sık görülen hata: “BGP komşuluğu up ise POP sağlıklıdır.” Bu, edge’inizi kısmi arızalara açık bırakır:
- Edge proxy çalışıyor ama back-end erişimi yok
- DNS yanıtlıyor ama authoritative zone senkronu bozulmuş
- CPU/disk dolu, latency uçmuş
- DDoS mitigation devrede ama false positive ile her şeyi blokluyor
Sağlık sinyalini iki seviyede kurun:
- Data-plane health: Gerçek trafikten ölçülen latency, error rate, TCP handshake başarısı.
- Control-plane health: BGP session, route policy, config drift, certificate/zone güncelliği.
Pratik yaklaşım: POP’tan upstream’e announce ettiğiniz prefix’i, “servis sağlıklı değilse geri çek” prensibiyle yönetin.
Anycast failover stratejileri (ve yan etkileri)
Failover’ı “BGP withdraw” ile yapmak basit görünür; ama etkisi globaldir. Üç yaygın model:
1) Hard withdraw (prefix’i tamamen geri çek)
- Artı: En net sinyal; trafik başka POP’lara akar.
- Eksi: Global route churn; convergence süresi ve cache etkileri.
2) De-preference (BGP attribute ile isteksiz ol)
Örn. localpref düşürme, AS-path prepend, MED ayarı, community ile upstream yönlendirme.
- Artı: Daha kontrollü, kademeli boşaltma.
- Eksi: Upstream/policy bağımlılığı; tüm internet aynı şekilde davranmaz.
3) Partial withdraw / scope küçültme
Bazı upstream’lerden çek, bazılarını tut.
- Artı: “Kapasite doygunluğu” gibi kısmi durumlarda iyi.
- Eksi: Operasyonel karmaşıklık artar.
DDoS altında Anycast: Avantaj ve tuzaklar
Anycast’in DDoS’ta en büyük avantajı “saldırıyı dağıtmak”tır. Tek bir POP yerine saldırı, BGP’nin seçtiği birçok POP’a yayılır; bu da her POP’un daha küçük bir yük görmesini sağlar.
Ama iki tuzak var:
- En zayıf POP saldırının hedefi olur: Kapasitesi düşük POP’lar, upstream’leri dar POP’lar önce çöker.
- Routing saldırı vektörü olur: Saldırgan, belirli region’lardan trafik üreterek belirli POP’ları “hotspot” yapabilir.
Bu yüzden Anycast + DDoS için tasarım checklist’i:
- POP başına “scrubbing / rate-limit” kapasitesi ve ölçümü
- Upstream çeşitliliği (tek transit’e bağımlılık yok)
- Blackhole community’leri (RTBH) ve otomasyon
- Trafiği “clean” ve “dirty” olarak ayıran mimari (mümkünse)
Capacity engineering: POP’lar eşit değilse politika şart
POP’larınız farklı kapasitedeyse (çoğu kurumda böyledir), “her POP aynı prefix’i announce ediyor” demek yük dengeleme anlamına gelmez. BGP, kapasiteyi bilmez.
Pratik yöntemler:
- Tiered POP: Büyük POP’lar “prefer”, küçük POP’lar “overflow” gibi konumlanır.
- Region steering: Upstream community ile bazı region’larda daha az görünür ol.
- Kademeli prepend: Küçük POP’ta prepend arttır, büyük POP’ta azalt.
Bu politikaları uygulamadan önce şunu kabul edin: Anycast’te “mükemmel dengeleme” yok; hedefiniz öngörülebilirlik olmalı.
Observability: Anycast’i ölçmek için neye bakarım?
Anycast’te en değerli metrik, “tek bir POP’un metriği” değil; global dağılımdır.
Ben sahada şu sinyalleri birlikte izlerim:
- POP bazında: p50/p95 latency, error rate, conn rate, saturation (CPU/mem), upstream packet loss
- Global: POP trafik payı (%), POP değişim hızı (churn), withdraw/de-prefer olay sayısı
- DNS ise: NXDOMAIN oranı, SERVFAIL, zone serial drift, resolver cache hit/miss sinyali (ölçebiliyorsanız)
Test yaklaşımı: Prod’e dokunmadan “çekme” senaryosu
Anycast tasarımını “masada” bitiremezsiniz; kontrollü test gerekir.
Örnek test planı:
- Tek bir POP’ta prefix’i de-prefer et (prepend/community).
- Trafik dağılımı beklendiği gibi mi değişti ölç.
- Aynı POP’ta hard withdraw et ve convergence süresini ölç.
- Geri getirirken “cold start” etkisini ölç (cache, connection ramp-up).
Kapanış: Anycast’i “ürünle” değil “operasyonla” kazanın
Anycast; doğru tasarlanırsa edge servislerde hem latency hem dayanıklılık hem de DDoS toleransı sağlar. Yanlış tasarlanırsa “bazen yakın, bazen uzak, bazen de kayıp” bir kullanıcı deneyimi üretir.
Bence iyi bir Anycast tasarımının özeti:
- Sağlığı “BGP up” değil “servis iyi” olarak ölç
- Failover’ı kademeli yönet (de-prefer + withdraw)
- POP kapasite asimetrisini routing politikasıyla görünür kıl
- DDoS senaryosunu “normal gün” gibi test et