Hiç Kesilmeden Yayında Kalmak Mümkün mü? Anycast DNS ve Otomatik Failover ile Nasıl Sağlanır?

Ofiste Gece Yarısı: Bir Kopuş, Bir Aydınlanma

Hiç sizi uykunuzdan kaldıran bir bildirimle yataktan fırladığınız oldu mu? Benim oldu. Bir gece, saat 02:17. Telefon çaldı, ekibin acil kanalında mesajlar yağmur gibi. Site açılmıyor, müşteri servisleri susmuyor. Sunucular sapasağlam görünüyor ama kullanıcılar 404 yerine sonsuz bir bekleyişle karşılaşıyor. Dakikalar içine sinmese de, sorunun sunucu tarafında olmadığını fark ettik. Dışarıdan DNS sorguları bazı bölgelerde yanıtlamıyordu. O an kafamda şimşek çaktı: “Tek bir yoldan dünyaya ulaşmaya çalışıyoruz; o yol kapanınca her şey durmuş gibi oluyor.”

Ertesi gün, kahvemi alıp masaya oturduğumda kendime söz verdim. Böyle bir kopuş bir daha yaşanmayacaktı. Çözümün adı, kulağa süslü gelse de özünde çok basit bir fikirden doğuyordu: Anycast DNS ve otomatik failover. Yani, dünyaya tek kapıdan değil, her köşeden açılan kapılarla çıkmak. Bir kapı sıkışırsa, diğeri sessizce devreye girecek. Bu yazıda, bunu nasıl kurduğumu, nerelerde tökezlediğimi ve pratikte nelerin işlediğini kendi dilimden anlatmak istiyorum.

Eğer siz de “Benim sistemlerim kritik, kesinti lüksüm yok” diyorsanız, gelin beraber adım adım ilerleyelim. Mesela neden bazı kullanıcılar erişebiliyor, bazıları erişemiyor? Otomatik failover neyi otomatikler? TTL’leri düşürmek yetiyor mu? Hepsini konuşacağız.

Önce Can Yakan Gerçek: Kesinti Neden Bir Anda Dünya Çapında Hissedilir?

Bir sistem çöktüğünde işler sadece sunucu odasında kalmıyor. Müşteri destek hattı kilitleniyor, satışlar duruyor, ekip stresleniyor. Üstelik en sinir bozucu an, bazı kullanıcıların sorunsuzca erişirken diğerlerinin “bağlantı zaman aşımı” ile karşılaşması. Mesela İstanbul’daki biri giriyor, Berlin’deki biri giremiyor. O an ‘sunucular ya var ya yok’ mantığı kafana uymuyor. Ama DNS tarafı bambaşka bir dünya: çözümleyiciler farklı ağ yolları deneyebilir, bazıları yanıtı önbellekten verir, bazıları yeni sorgu atar ve yakındaki ad sunucusuna ulaşamazsa bekler, sonra vazgeçer.

İşte bu yüzden DNS’i tek noktadan dünyaya dağıtmak riskli. Bir bölgede bir şeyler aksarsa, o bölgedeki kullanıcılar bir süreliğine sizi kaybetmiş gibi olur. Üstelik “kısa süreliğine” dediğimiz şey bazen küçük bir TTL ayarıyla bile uzayabiliyor. Çünkü bazı çözümleyiciler, pratikte TTL’e sıkı sıkıya bağlı kalmıyor ya da ara katmanlar ilgisiz negatif önbellekler oluşturabiliyor.

Anycast DNS Nedir? En Yakın Kapıdan İçeri Alınmanın Basit Hali

Anycast DNS’i, şehirdeki aynı mağazanın birden çok şubesi gibi düşünün. Hepsi aynı tabelayı taşıyor, hepsi aynı ürünleri satıyor. Sen hangi şubeye daha yakındaysan, kapı oradan açılıyor. Teknik tarafta, aynı IP adresinin farklı noktalardan internete duyurulması var. Trafik, ağın kendisi tarafından en yakın ya da en iyi görünen yola yönlendiriliyor. Kullanıcı için büyü yok; sadece daha hızlı yanıt ve daha sağlam bir erişim hissi.

Bunun güzelliği şu: Bir şube kapansa bile şehirde başka şubeler var. DNS tarafında, bir noktadaki ad sunucusu sorun yaşasa bile diğer noktalar aynı IP ile bayrağı devralır. Tabii bu “hiç problem olmaz” demek değil. Ağ yolları dalgalanabilir, bazı bölgeler beklenmedik şekilde farklı noktalara düşebilir. Ama genel resimde, tek bir bölgede yaşanan aksaklık tüm dünyayı kaplamaz, etki alanı daralır.

Bu yaklaşımın internetteki mantığını biraz daha kurcalamak istersen anycast uygulamalarını anlatan bu dokümana göz atmak keyifli olabilir. Ama şunu unutmayalım: Anycast bir temeldir, tek başına tam çözüm değil. Onun yanında akıllı sağlık kontrolleri ve otomatik geçiş mekanizmaları da gerekir.

Otomatik Failover: Yanıt Vermeyen Hizmete Sessiz Bir Şerit Değiştirme

Otomatik failover, şerit değiştirmeyi sezdirmeden yapma sanatı. Bir uygulama noktası sorun yaşadığında, sağlık kontrolü yapan bir göz “burada bir gariplik var” der ve DNS kayıtlarını mantıklı bir alternatife çevirir. Bu, çoğu zaman birincil IP’den ikincil IP’ye geçmek ya da birincil CNAME’den yedek CNAME’e dönmek demek. “O an kullanıcı ne hisseder?” derseniz, çoğu zaman hiçbir şey. Sadece sayfa bir anda açılır. Yeter ki TTL ayarınız, geçişin hızlı olmasını sağlayacak kadar makul olsun.

Burada iki kritik detay var. İlki, sağlık kontrolünün gerçekçi olması. Sadece ping atıp “yaşıyor” demek yetmez. Mesela /health gibi uygulamanın kendi kontrol ettiği bir noktadan basit ama anlamlı bir yanıt beklemek daha iyi. İkincisi, çırpınmayı (flapping) kontrol altına almak. Yani, tek bir başarısız kontrol ile rota değişmemeli; bir eşik değer olsun, üst üste birkaç başarısız kontrolden sonra geçiş yapılsın. Aynı şekilde dönüş de hemen değil, istikrar görülünce olsun.

Failover mantığını anlamak için pratik bir kaynak istersen DNS failover akışlarını anlatan bu kılavuz kafandaki resmi tamamlamaya yardımcı olabilir. Ama marka bağımsız düşün; önemli olan yaklaşımın kendisi ve uyguladığın disiplin.

Kendi Kurulum Hikayem: İki Bölge, Bir Sağlık Nabzı, Sakin Geçiş

İlk kez bu işi kurduğumda, iki ayrı bölgede benzer kapasitede ortam hazırladım. Uygulamanın en temel fonksiyonlarını kontrol eden küçük bir /health ucu vardı: veritabanına erişebiliyor mu, kuyruklar tıkalı mı, diskte tehlikeli doluluk var mı? Tam bir check-up değil, ama temel yaşamsal belirtiler. DNS tarafında birincil ve ikincil kayıtları tanımladım; işin güzelliği, sağlık kontrolü başarısız olduğunda yedek kayda çevrilecek şekilde kural yazdım. TTL’i akşam ilk denemede 20 saniyeye çektim, sonra gündüz trafiğinde daha sakin ilerlemek için 30-60 saniye aralığına oturttum.

İlk tatbikatı hafta sonu yaptık. Birincil bölgede uygulama servislerini kontrollü kapattım. Sağlık kontrolü birkaç kez başarısız dönünce failover tetiklendi ve sorgular yedeğe yöneldi. Birkaç kullanıcı bir iki saniyelik gecikme dışında hiçbir şey fark etmedi. Dönüşü de hemen yapmadık. Birincil bölgeyi toparlayıp 10 dakika sorunsuz çalıştığını görünce eski düzenine çevirdik. Bütün süreç sakin, kimsenin ter basmayacağı kadar sıkıcıydı. Tam da istediğimiz gibi.

TTL, Önbellek ve Diğer Küçük Ama Etkili Ayrıntılar

Bu işin görünmez kahramanı TTL. Çok düşük tutarsan, her sorgu daha sık yenilenir; geçişler hızlı olur ama çözücüler ve ad sunucular daha fazla çalışır, bazı ağlarda gecikme hissedilir. Çok yüksek tutarsan, geçişler yavaşlar; sorunlu bir kaydı bazı kullanıcılar uzun süre önbellekten görür. Benim gördüğüm en sağlıklı yaklaşım, çekirdek hizmetlerde 30-60 saniye gibi bir ortalama, ikincil önemdekilerde biraz daha yukarı. Ama tek kural yok; senin trafiğin, kullanıcı dağılımın, hata toleransın belirleyici olmalı.

Bir diğer detay, negatif önbellek. Bazı çözümleyiciler başarısız sonuçları da kısa bir süre hatırlar. Bu yüzden, geçiş gerçekleşse bile belli bir kullanıcı grubu anında düzelme görmeyebilir. Bu anları kısaltmak için sağlık kontrollerinin anlamlı, TTL’in dengeli ve ad sunucularının yaygın erişilebilir olması önemli.

DNS kayıtlarının düzenine hâkimsen işin çok hızlanır. A/AAAA, CNAME ve MX gibi klasik yıldızların yanında TXT ve SRV gibi başka karakterler de sahnede rol alır. Eğer bu konularda kısa bir tazeleme istersen, DNS kayıtlarını doğru yapılandırma rehberimiz pratikte sık yapılan hataları da hatırlatıyor.

Anycast DNS’in Sahne Arkası: Trafiğin Dağılımı ve Küçük Sürprizler

Anycast, “aynı adres, çok yer” mantığıyla işler. Ağ, en iyi rotayı seçer; bu seçim bazen mesafe, bazen yoğunluk, bazen de ağ politikaları nedeniyle beklediğinden farklı olabilir. Bazen de anlık yönlendirme değişiklikleri yaşanır. Panik yok, bu dalgalanmalar genelde saniyelerle, bilemedin dakikalarla ölçülür. Önemli olan, bu iniş çıkışlar sırasında kullanıcı deneyiminin ciddi şekilde etkilenmemesi. Bunu da geniş kapsama alanına sahip bir DNS ağı ve dengeli TTL ayarlarıyla sağlarsın.

Anycast’in temelini daha yalın şekilde okumak istersen, anycast ağlarını özetleyen bu sayfa kavramı sade bir dille anlatıyor. Benim tecrübem şu: Anycast, tek başına bir garanti değil; ama sahaya doğru ekipmanla çıkarsan harikalar yaratır. Sağlık kontrolleri dürüst olacak, failover kuralları aceleci olmayacak, gözlemleme sürekli olacak. O zaman taşlar yerine oturuyor.

Failover Mantığını Uygularken Karşılaştığım Tuzaklar

İlk tuzak, tek metriğe aldanmak. Sadece “ping atınca dönüyor mu” diye bakmak, uygulamanın aslında çökmüş halini gözden kaçırabiliyor. Gerçekten iş yapan bir uçtan, küçük bir test çalıştırmak daha güvenli. Mesela “özet sayfa açılıyor mu, ana sorgu 200 dönüyor mu” gibi. İkincisi, çok hızlı geri dönüş. Birincil bölge 10 saniye toparlandı diye hemen geri dönmek, kullanıcılar için gereksiz bir sallantı yaratıyor. Ben dönüş koşuluna bir istikrar süresi koydum, ruhum rahat etti.

Üçüncüsü, duruma özel yol kapanları. Diyelim ki uygulama sağlıklı ama veritabanı yazmalarında tutarsızlık var. DNS ile trafiği yedeğe kaydırman, veri bütünlüğü açısından yeni dertler doğurabilir. Bu yüzden kritik yazma işlemlerinde bölgesel dağıtım stratejini önceden düşün. Failover sadece yönlendirme değil, iş akışını koruma meselesi. Dördüncüsü, istemci tarafı yapışkanlık. Bazı kullanıcılar tarayıcı önbelleği, bazıları yerel çözümleyici davranışı yüzünden değişik gecikmeler yaşayabilir. Bu normal. İyi haber şu: Kısa TTL ve sağlam anycast altyapısı, bu gecikmeleri mümkün olduğunca küçültüyor.

DDoS ve Anycast: Trafiği Yayarak Dayanıklılık Kazanmak

Bazı günler saldırı gelir, gelen trafiğin bir kısmı masum gibi görünür ama sistemin nefesini keser. Anycast burada gizli bir kahraman gibi çalışır: Saldırının yükü coğrafyaya yayılır, tek bir noktaya yığılmaz. Böylece savunma araçlarının işini kolaylaştırır, süre kazanırsın. Elbette bu tek başına tam kalkan değil; ama güçlü bir temel. Bu mantığın neden işe yaradığını anlamak istersen, anycast’in trafiği nasıl böldüğünü anlatan kaynaklar oldukça açıklayıcı. Örneğin yukarıda paylaştığım anycast ağlarını anlatan sayfa, fikri netleştiriyor.

Benim deneyimimde, saldırı anlarında en çok işe yarayan disiplin, gözlemleme ve soğukkanlı failover oldu. Her şey yolunda giderken yapılan tatbikatlar, saldırı anında terlememeyi sağlıyor. “Nasıl olsa hiç olmaz” dediğin gün olur, hem de en yoğun kampanyanın ortasında olur.

Gözlemleme: Görmediğin Sorunu Yönetemezsin

Anycast DNS ve otomatik failover kurduysan işin yarısı biter. Diğer yarısı, olan biteni anlık izlemek. DNS sorgu sürelerini bölge bazında takip etmek, başarısız sağlık kontrollerini günlükten okumak, kullanıcı tarafında ping ve sayfa açılış sürelerini ölçmek, hepsi bir bütün. Ben basit sentetik kontrolleri dünyanın farklı noktalarından çalıştırıp “hangi bölgede ne hissediliyor” sorusuna bakmayı seviyorum. Sorun olduğunda posta kutuma değil de hem bana hem ekibe giden, sessiz ama etkili bir uyarı düşüyor. Bildirimi gördüğümde, runbook’taki iki üç adımı açıp ilerliyorum. Panik yok, prosedür var.

Adım Adım Başlangıç Planı: Basit Tut, Sık Test Et

Bu işe başlarken basit bir plan işini görür. Önce, anycast destekli bir DNS sağlayıcısı seç. Ardından, birincil ve ikincil konumlarını belirleyip sağlık kontrollerini tanımla. Sağlık kontrolü gerçek işi doğrulasın; örneğin ana sayfanın kritik parçaları yükleniyor mu diye bak. TTL’i ilk etapta 30-60 saniye bandına koy, sonra gözlemle ve trafiğine göre ayarla. Sonra da tatbikat yap: kontrollü bir kesinti simüle et, kullanıcıların ne yaşadığını izle, geri dönüş koşullarını gözden geçir.

Bir süre sonra, yedek konumu sadece felaket anlarında değil, yoğun trafik anlarında da devreye sokmak isteyebilirsin. O zamana kadar temel yapı taşları sağlam olsun. Gözlemleme panellerin hazır olsun, uyarılar kalabalık yapmasın ama kritik olanı kaçırmasın. Geri dönüşü tek tıkla değil, belli bir istikrar eşiğiyle yap ki kullanıcılar sarsıntı hissetmesin.

Kapanış: Her Kapıdan Aynı Mağazaya Girmenin Huzuru

Anycast DNS ve otomatik failover, kulağa büyük işletmelerin işi gibi gelebilir. Ama aslında işin özü, çok basit bir kullanıcı beklentisinde gizli: “Tıkladığımda açılsın.” Bu kadar. Biz de perde arkasında bu basit beklentiyi tutarlı kılmaya çalışıyoruz. Trafiği en yakın noktaya götürmek, sorun anında sessizce alternatif yola çevirmek, dengeli TTL’lerle gereksiz beklemeleri azaltmak… Hepsi küçük küçük dokunuşlar. Bir araya geldiğinde, gecenin bir vakti telefonun çalmasını engelleyen büyük bir fark yaratıyor.

Pratik tavsiyem şu: Küçükten başla, sık test et, gözlemle ve not al. Sağlık kontrollerini gerçekçi ama hafif tut, dönüşlerde acele etme, kullanıcı deneyimini öncelik listende hep üstte tut. Bazen bir sorun, tek bir ayarla çözülür; bazen birkaç küçük ayarın birleşimi gerekir. Önemli olan, yapboz parçalarını tanımak ve nerede durduklarını bilmek. Umarım bu yazı, aklındaki boşlukları doldurur ve bir sonraki kesintiyi “hadi canım” diyerek savuşturmanı sağlar. Bir dahaki yazıda görüşmek üzere.