Küçük İşletmeler İçin Multi-Region DNS ve CDN Failover

Küçük İşletme Siteleri İçin Multi-Region ve Failover Neden Önemli?

Küçük bir işletme sitesi yönetirken çoğu zaman öncelik tasarım, içerik ve reklam bütçesinde olur. Ancak “Siteye giremiyorum” veya “Sayfa çok yavaş açılıyor” gibi sorunlar, bu yatırımların etkisini azaltabilir. Bir sunucu arızası, veri merkezi tarafındaki bir ağ problemi veya beklenmeyen bir bakım çalışması; satışta olan bir e-ticaret sitesini, rezervasyon alan bir otel sitesini ya da B2B teklif formu olan bir kurumsal sayfayı dakikalar içinde iş yapamaz hale getirebilir.

Multi-region DNS ve CDN failover mimarisi tam da bu noktada devreye giriyor. Amaç; bütçeyi zorlamadan, mümkün olduğunca az ek bileşenle, sitenizi birden fazla bölgeye yaymak ve bir bölge ya da sunucu sorun yaşadığında trafiği otomatik olarak ayakta kalan hedefe yönlendirmek. Yani tek bir sunucuya ve tek bir veri merkezine bağımlı kalmamak.

Multi-region tasarımında maliyeti belirleyen yalnızca sunucu sayısı değil, veri senkronizasyonu ve işletim gereksinimleridir. Aslında doğru planlandığında, iki uygun boyutlu VPS ve akıllı bir DNS/CDN kurgusu ile gayet erişilebilir ve sürdürülebilir bir yapı kurmak mümkün. Bu yazıda tam olarak bunu, adım adım ve bütçeyi de düşünerek anlatacağız.

Temel Kavramlar: DNS, CDN, Failover ve Multi-Region

DNS seviyesinde resim: Trafiği hangi origin’e göndereceğiz?

DNS, multi-region mimaride hedef seçiminin yapılabileceği katmanlardan biridir. Kullanıcının tarayıcısı alanadiniz.com için çözümleme yaptığında, A/AAAA kayıtlarından veya CNAME zincirinden elde edilen IP adreslerine bağlanır. Bu hedef doğrudan bir origin ya da CDN olabilir. CDN kullanıldığında, origin seçimi ayrıca CDN katmanında yapılabilir; her mimaride bölgeler arası seçimi DNS’in yapması gerekmez.

DNS kayıtlarının ne anlama geldiğini ve sık yapılan hataları daha önce A, AAAA, CNAME, MX, TXT ve diğer DNS kayıt türlerini anlattığımız rehberde detaylı açıklamıştık. Multi-region senaryosunda özellikle A/AAAA, CNAME ve gerektiğinde CAA gibi kayıtlar önem kazanır.

Ayrıca DNS tarafında Premium DNS, Registrar DNS ve CDN tabanlı DNS farklarını bilmek kritik. Basit bir domain kayıt firmasının sunduğu temel DNS ile gelişmiş sağlık kontrolü, coğrafi yönlendirme veya ağırlıklı routing sunan bir DNS altyapısı aynı değildir. Bu farkları Premium DNS vs Registrar DNS vs Cloudflare karşılaştırma rehberimizde ayrıntılı olarak ele aldık; multi-region kurgusuna girmeden önce o yazıya da göz atmanız faydalı olacaktır.

CDN tarafında resim: İçeriği edge noktalarından sunmak

CDN (Content Delivery Network), statik içerikleri (görseller, CSS, JS ve uygun önbellek politikalarıyla herkese açık HTML) dünyanın farklı yerlerindeki önbellek (edge) noktalarından sunabilir. Böylece kullanıcı, CDN üzerinden sunulan kaynaklar için doğrudan asıl sunucunuza (origin) değil, ağ yönlendirmesinin seçtiği bir CDN noktasına bağlanır. Önbellekten karşılanan istekler gecikmeyi ve origin sunucunuzun yükünü azaltabilir.

CDN’in ne zaman gerçekten işe yaradığını ve hangi trafik profillerinde mantıklı olduğunu merak ediyorsanız, CDN nedir, ne zaman gerekir ve trafik/lokasyona göre nasıl karar verilir? başlıklı yazımızı da mutlaka okumanızı öneririz. Multi-region failover tasarlarken, CDN’i sadece hız aracı değil, aynı zamanda ek bir dayanıklılık katmanı olarak düşünmek gerekir.

Failover nedir, neyi çözer?

Failover, aktif bir sistem (sunucu, bölge, origin) arıza yaşadığında, trafiğin otomatik olarak yedek sisteme yönlendirilmesi sürecidir. Burada iki kritik kavram vardır:

• Failover süresi: Arıza anından itibaren trafiğin yeni hedefe yönlenmesine kadar geçen süre.
• Gözlemlenebilirlik: Problem olduğunu nasıl anlıyorsunuz? DNS sağlayıcısının health check’i mi, CDN’in origin denetimi mi, yoksa sizin uptime izleme aracınız mı alarm üretiyor?

DNS tabanlı failover’da sağlık kontrolü ve yönlendirme kararı sonrasında DNS önbelleklerinin etkisi de sürer; bu nedenle geçiş dakikalar alabilir ve tüm istemciler aynı anda toparlanmaz. CDN tabanlı origin failover, kullanıcı DNS kaydını değiştirmeden geçiş yapabilir; ancak süresi kontrol aralığına, zaman aşımlarına, yedeğin hazır olmasına ve geçiş politikasına bağlıdır. Her iki modelde de gerçek toparlanma süresini kontrollü provalarla ölçün; sabit bir süre garantisi varsaymayın.

Multi-region kavramı: Aynı sitenin birden fazla bölgede yaşaması

Multi-region, sitenizin (veya uygulamanızın) birden fazla coğrafi bölgede çalışması anlamına gelir; aynı bölgedeki iki veri merkezi tek başına multi-region sayılmaz. En basit haliyle:

• İstanbul veri merkezinde bir VPS (Region-1)
• İstanbul’daki ana origin’den farklı bir coğrafi bölgede ikinci bir VPS (Region-2); örneğin Avrupa’da veya Türkiye’nin başka bir coğrafi bölgesinde
• Veritabanı ve dosya senkronizasyonu; yalnızca yedek kullanılıyorsa geçişten önce geri yükleme ve kabul edilebilir veri kaybı planı
• Üstte DNS + CDN ile trafik yönlendirme

Daha büyük yapılarda ihtiyaçlara göre coğrafi yönlendirme, yazma/okuma ayrımı veya aktif-aktif veritabanı kümeleri gibi daha karmaşık çözümler kullanılabilir. Bunları DNS geo-routing ve veritabanı replikasyonuyla çok bölgeli mimariler kurmayı anlattığımız yazıda derinlemesine ele aldık. Bu yazıda ise küçük işletmeler için daha sade ve uygun maliyetli senaryolara odaklanacağız.

Kısıtlı Bütçeyle Uygulanabilir Multi-Region ve Failover Senaryoları

Senaryo 1 – Tek origin ve CDN önbelleğiyle sınırlı dayanıklılık

Düşük maliyetli bir başlangıç seçeneği, sadece bir origin (örneğin tek VPS veya paylaşımlı hosting) kullanıp, üzerine akıllı bir CDN katmanı oturtmaktır. Mantık şu şekilde işler:

• Tüm statik içerik (görseller, CSS, JS) CDN üzerinden sunulur.
• CDN, origin ile bağlantı kuramazsa, desteklediği ve etkinleştirilmiş stale-if-error benzeri politikalar kapsamında önbellekte hâlâ bulunan uygun yanıtları sunabilir; bu özellik önbellekte olmayan içeriği kurtarmaz.
• DNS tarafında CDN sağlayıcısının belirttiği IP veya CNAME hedefini kullanırsınız. Kısa TTL (örneğin 300 sn) tek başına failover sağlamaz; bu senaryoda ikinci bir DNS hedefi yoktur.

Bu modelde origin tarafında multi-region olmasanız da CDN edge noktaları ve uygun önbellekleme sayesinde gecikmeyi azaltabilir, sınırlı dayanıklılık sağlayabilirsiniz. Origin tamamen devre dışı kalırsa, dinamik işlemler (giriş, sepet, ödeme vb.) çalışmaz; ancak önceden önbelleğe alınmış ve kesintide sunulmasına izin verilen statik HTML sayfaları (bilgilendirme, sıkça sorulan sorular vb.) erişilebilir kalabilir. Yalnızca görsel, CSS ve JS dosyalarını önbelleklemek sayfaların açılmasını sağlamaz; bakım sayfası için de önceden hazırlanmış bir sunum kuralı gerekir.

Küçük kataloglu, nadiren güncellenen kurumsal siteler için bu bile çoğu zaman ciddi fark yaratır.

Senaryo 2 – İki farklı bölgede VPS + DNS tabanlı failover

Bir adım ileri gitmek istiyorsanız, değerlendirebileceğiniz bir çözüm şudur:

• İki farklı coğrafi bölgede iki VPS seçersiniz (Region-1 ve Region-2); bölge seçeneği ve kapasite, seçilen sağlayıcı ve plan için doğrulanmalıdır.
• Asıl trafik Region-1’e gider; Region-2 pasif yedek gibi davranır (aktif-pasif).
• DNS failover hizmetinde Region-1 birincil, Region-2 yedek hedef olarak tanımlanır; sağlık kontrolleri iki hedefin de hizmet vermeye hazır olup olmadığını izler. Normalde A/AAAA yanıtlarında yalnızca birincil hedef sunulur; iki sıradan kayıt eklemek aktif-pasif failover sağlamaz.
• Region-1 sağlıksız bulunduğunda, hazır ve sağlıklı Region-2 DNS yanıtlarında sunulur. İstemcilerin geçişi DNS önbellekleri ve mevcut bağlantılar nedeniyle aynı anda gerçekleşmez.

Bu modelin avantajları:

• Uygulama ve veri bağımlılıkları da yedek bölgede çalışabiliyorsa bölgesel yedeklilik elde edersiniz.
• Bakım veya güncelleme yapmak istediğinizde trafiği geçici olarak Region-2’ye alabilirsiniz.
• CDN’iniz çoklu origin ve failover destekliyorsa iki origin arasında geçiş yapılandırabilirsiniz. Çift katmanlı failover için DNS’in hangi hedefi değiştireceği ayrıca tasarlanmalıdır: Kullanıcı DNS’i CDN’i gösteriyorsa bu kaydın TTL’si tek başına origin geçişini yönetmez.

Dezavantajı ise veritabanı ve dosya senkronizasyonu gerektirmesidir. WordPress veya benzeri PHP tabanlı uygulamalarda dosyalar rsync/cron ile senkronize edilebilir; veritabanı için replikasyon ya da düzenli yedek/restore seçilebilir. Ancak yedek/restore, hazır bir failover veritabanıyla eşdeğer değildir: geri yükleme süresi ve son yedekten sonraki veri kaybı hesaba katılmalıdır. Replikasyonda da gecikme izlenmeli; trafiği yedeğe almadan önce veritabanının yazmaya hazır olduğu doğrulanmalı ve eski birincilin aynı anda yazı kabul etmesi engellenmelidir. DCHost tarafında veritabanı replikasyonu ve senkronizasyonu konusunda daha önce MySQL ve PostgreSQL replikasyon rehberimizde detaylı örnekler paylaşmıştık; oradaki prensipler burada da aynen geçerli.

Senaryo 3 – Statik acil durum sitesi + CDN üzerinden failover

Bazı küçük işletmeler için iki tam kopya sunucu yönetmek fazla olabilir. Bu durumda şu hibrit model oldukça pratiktir:

• Ana site: Asıl hosting/VPS ortamınız (dinamik, veritabanı ve ödeme sistemi olan site).
• Acil durum sitesi: Farklı bir bölgede, sadece statik HTML barındırdığınız küçük bir VPS veya statik hosting.
• CDN: Çoklu origin ve uygun failover kuralları destekleyen bir hizmet seçilir. Normalde ana origin kullanılır; arızada uygun sayfa istekleri ikinci origin olarak statik acil durum sitesine yönlendirilir. İstenen yolların statik sitedeki karşılığı veya bakım sayfasına eşlenmesi önceden hazırlanır; ödeme ve form gönderimleri burada işlenmez.

Bu senaryoda asıl siteniz tamamen erişilemez olsa bile, kullanıcılar en azından şu bilgileri görebilir:

• Marka/logo ve temel iletişim bilgileri
• “Şu anda bakım çalışması yapıyoruz” veya “Geçici bir teknik sorun yaşıyoruz” mesajı
• Telefon, e-posta veya alternatif sipariş kanallarına yönlendirme

Özellikle B2B iş yapan, siparişlerini çoğunlukla telefon/e-posta üzerinden alan küçük işletmeler için bu model, tam kesinti yerine degrade olmuş ama ayakta kalan bir deneyim sunar; ikinci bir tam uygulama ortamına göre kaynak ihtiyacını azaltabilir.

DNS Katmanında Failover

TTL ayarları: Ne kadar küçük, ne kadar mantıklı?

DNS failover’ın toparlanma süresi büyük ölçüde TTL (Time To Live) değerlerine bağlıdır. TTL, DNS yanıtının normalde kaç saniye önbellekte tutulabileceğini belirtir; tüm istemcilerin tam bu sürede yeni adrese geçeceğini garanti etmez. Çok yüksek TTL, değişikliklerin geç yayılması demektir; çok düşük TTL ise DNS sorgu maliyetlerini artırabilir.

Genel pratik yaklaşım:

• Normal zamanlarda: 1200–3600 sn gibi yüksek TTL değerleri sorgu yükünü azaltabilir, ancak beklenmedik kesintide eski origin’e yönlendirmeyi uzatabilir. Otomatik failover için TTL’i toparlanma hedefinize göre seçin.
• Planlı geçişler ve bakım öncesinde: 300 sn veya sağlayıcının desteklediği 120 sn gibi düşük TTL değerleri düşünülebilir. Düşürme işlemini en az önceki TTL süresi kadar önceden yapın; mevcut önbellekler geriye dönük kısalmaz.

DNS TTL stratejilerini ve zero-downtime geçiş senaryolarını detaylı anlattığımız TTL stratejileri ve DNS yayılımını hızlandırma rehberimiz, multi-region kurgusuna girerken elinizin altında olması gereken bir başucu yazısıdır.

Health check mekanizması: DNS sağlayıcınız siteyi nasıl “ölçüyor”?

Otomatik DNS failover için bir sağlık izleme mekanizmasının sonucuna göre DNS yanıtlarının güncellenmesi gerekir. Bu mekanizma DNS sağlayıcısına entegre olabilir veya harici izleme ve otomasyonla kurulabilir. Bu kontroller genellikle şu şekilde yapılır:

• HTTP(S) isteği: Belirli bir URL’ye (örneğin /healthz veya ana sayfa) istek atılır; beklenen yanıt kodu ve gerekiyorsa içerik kontrol edilir. Örneğin yalnızca 200 bekleyen bir kontrolde diğer kodlar başarısız sayılabilir.
• TCP port kontrolü: Örneğin 443 portuna bağlantı kurulabiliyor mu diye bakılır. Başarılı bağlantı, uygulamanın veya veritabanının sağlıklı olduğunu tek başına göstermez.
• Response time ölçümü: Yanıt süresi belli bir eşiğin üzerindeyse sorunlu olarak işaretlenebilir.

Sağlık kontrolünü sık yapmak (örneğin 5 saniyede bir) algılamayı hızlandırabilir, ancak kontrol yükünü ve maliyeti artırabilir. Yanlış alarmları azaltmak için zaman aşımını, ardışık başarısızlık eşiğini ve kontrol noktalarını birlikte ayarlayın. 30–60 saniye bir başlangıç aralığı olabilir; seçim toparlanma hedefinize bağlıdır. Gerçek süreye arıza algılama, DNS yanıtlarının güncellenmesi, kalan önbellek süreleri ve istemcinin yeniden bağlanması etki eder; yalnızca kontrol aralığı ile TTL’in toplamı değildir.

Multi-provider DNS: Tek bir DNS sağlayıcısına bağlı kalmamak

“Sunucu tarafını yedekledik ama DNS sağlayıcımız sorun yaşarsa ne olacak?” sorusuna yönelik seçeneklerden biri çoklu sağlayıcı DNS mimarileridir. Yani:

• Aynı alan adı için birden fazla DNS sağlayıcısında yetkili ad sunucularınız var.
• Konfigürasyon, kod üzerinden (örneğin YAML) tutulup her iki tarafa da otomatik dağıtılabilir. Bunun yanında alan adının delegasyonu her iki sağlayıcının yetkili sunucularını kapsamalı; kayıtlar ve failover kararları tutarlı olmalıdır. DNSSEC kullanılıyorsa imzalama ve DS kayıtları da çoklu sağlayıcı düzeniyle uyumlu tasarlanmalıdır.

Bunu pratikte nasıl kurabileceğinizi, octoDNS ile çoklu sağlayıcı DNS ve zero-downtime geçiş rehberimizde adım adım anlattık. Küçük işletmeler için ilk aşamada şart olmasa da, ajans olarak onlarca marka yönetenler veya uptime’ı kritik olan SaaS ürünleri için orta vadede mutlaka düşünülmesi gereken bir katman.

CDN Katmanında Failover: Origin Sağlığı, Stale İçerik ve Multi-Origin

Origin health check ve otomatik origin geçişi

CDN tabanlı failover için seçtiğiniz hizmet ve planda birden fazla origin tanımlama, sağlık kontrolü ve otomatik failover desteğini doğrulayın. Desteklenen istek yöntemlerini, geçişi tetikleyen hata koşullarını ve ek ücretleri de değerlendirin. Örnek origin düzeni:

• Origin-1: Seçilen bir Türkiye veri merkezindeki ana VPS.
• Origin-2: Farklı bir bölgedeki yedek VPS.

Bu özellikleri destekleyen CDN’de, origin havuzu ve sağlık kontrolleri yapılandırılır. Origin-1 belirlenen başarısızlık eşiğine ulaştığında, failover politikasının kapsadığı yeni istekler sağlıklı ve hizmet vermeye hazır Origin-2’ye yönlendirilebilir. Kullanıcı tarafındaki DNS kaydını değiştirmek gerekmez; toparlanma süresi kontrol aralığına, zaman aşımlarına ve geçiş politikasına bağlıdır. Devam eden bağlantıların kesintisiz taşınacağı varsayılmamalıdır. Ödeme veya form gönderimi gibi yazma isteklerinde, ilk origin’in işlemi tamamlayıp tamamlamadığı bilinmeden otomatik tekrar yapılması mükerrer işlem yaratabilir; bu istekler için tekrar ve mükerrer işlem önleme davranışını ayrıca tasarlayın.

Stale-if-error ve stale-while-revalidate: Eski yanıtları hangi koşullarda sunabilirsiniz?

CDN ve tarayıcı önbelleklerinde kullanılan stale-if-error ve stale-while-revalidate direktifleri, çok kritik bir detaydır:

• stale-if-error: Destekleyen önbellek, origin’e erişim veya desteklenen sunucu hatalarında, sakladığı eski (stale) yanıtı belirtilen ek süre içinde sunabilir.
• stale-while-revalidate: Destekleyen önbellek, tazeliğini yitirmiş yanıtı belirtilen ek süre içinde sunarken arka planda yeniden doğrulama yapabilir. Bu, tek başına kesinti boyunca içerik sunma garantisi değildir.

Bu mekanizmalar, önbellekte uygun bir kopya varsa ve ilgili direktifler destekleniyorsa kısa süreli kesintilerin veya deploy dalgalanmalarının etkisini azaltabilir. Paylaşımlı CDN önbelleğinde kişiselleştirilmiş hesap, sepet ve ödeme yanıtlarını bu amaçla saklamayın. Bu konuyu stale-while-revalidate ve stale-if-error’un nasıl hayat kurtardığını anlattığımız yazıda örneklerle işlemiştik; multi-region CDN kurgularında da aynı prensipler bire bir geçerlidir.

CDN + DNS birlikte nasıl çalışır?

CDN’in origin failover’ını yönettiği, DNS’in ise kullanıcıyı CDN’e yönlendirdiği bir mimari şöyle kurulabilir:

• DNS katmanı: Kullanıcıları global CDN ağına yönlendirir (CNAME veya A/AAAA).
• CDN katmanı: Trafiği en uygun edge’e, oradan da sağlıklı origin’e yönlendirir.
• Origin tarafı: İki veya daha fazla bölgede barındırılır (multi-region VPS/dedicated).

Bu yapı, uygun önbellekleme ve origin seçimiyle coğrafi gecikmeyi (latency) azaltabilir; sağlıklı bir yedek origin de ana origin arızasının etkisini sınırlayabilir. Ancak origin yedekliliği DNS veya CDN sağlayıcısının kesintisini tek başına telafi etmez; her katmanın hata senaryosu ayrı değerlendirilmelidir.

Örnek Multi-Region DNS + CDN Failover Mimarisi

Adım 1 – Bölgeleri ve sunucu tiplerini seçmek

Küçük bir işletme sitesi için tipik bir senaryo şöyle olabilir:

• Region-1: Türkiye lokasyonlu NVMe VPS (ana origin)
• Region-2: Ana origin’den farklı bir coğrafi bölgedeki veri merkezinde ikinci NVMe VPS (yedek origin); Avrupa’da veya Türkiye’nin başka bir coğrafi bölgesinde seçilebilir. Yalnızca veri merkezinin farklı olması yeterli değildir.
• CDN: Global POP ağı ve origin failover desteği olan bir CDN sağlayıcısı (statik içerik ve yalnızca herkese açık, önbelleğe alınabilir HTML için cache kuralları)
• DNS: CDN’in istediği kayıtları destekleyen DNS altyapısı; doğrudan DNS failover seçilecekse sağlık kontrolüne dayalı aktif-yedek yönlendirme desteği

Bu örnekte VPS veya fiziksel sunucuların üzerine seçilen CDN ve DNS çözümleri entegre edilebilir. DCHost fiziksel sunucu sayfası bir değerlendirme bağlantısıdır; örnek, DCHost’un çoklu bölge kapasitesi veya entegrasyon hizmeti sunduğu varsayımına dayanmaz. Önemli olan, başlangıçta aşırı büyük makinelere gitmek yerine, doğru boyutlandırılmış kaynaklarla başlamak; ihtiyaca göre CPU/RAM’i büyütebilmek. Yedek bölgenin uygulama ve veritabanı kapasitesinin, geçişte üstleneceği yükü karşılayabildiğini yük testleriyle doğrulayın; iki küçük VPS’in her iş yükü için yeterli olduğunu varsaymayın.

Adım 2 – Uygulama kopyasını ve veritabanını senkron tutmak

İki bölgede de çalışan bir site istiyorsanız, en kritik konu veri tutarlılığıdır. Basitleştirilmiş bir yaklaşım:

• Dosyalar: Uygulama kodu için git tabanlı deploy; kullanıcıların yüklediği dosyalar için ayrıca rsync gibi bir eşitleme yöntemi. Periyodik eşitlemede son değişikliklerin yedeğe henüz ulaşmamış olabileceğini hesaba katın.
• Veritabanı: MySQL/PostgreSQL replikasyonu veya daha uzun toparlanma ve veri kaybı penceresini kabul eden sistemlerde düzenli yedek alıp geri yükleme. Yedek dosyasını aktarmak tek başına çalışır ve güncel bir yedek veritabanı oluşturmaz; replikasyon da bağımsız yedeklerin yerini tutmaz.

Örneğin WordPress için:

1. Uygulama kodunu bir git deposunda tutun ve her iki VPS’e de otomatik deploy edin.
2. wp-content/uploads klasörünü rsync ile Region-2’ye düzenli eşitleyin.
3. MySQL’i Region-1 → Region-2 replikasyon yapacak şekilde kurun; Region-2’yi read-only durumda tutun.

Bu adımlar tek başına otomatik failover sağlamaz. Region-2 veritabanı read-only kaldığı sürece yazma gerektiren işlemler çalışmaz. Yazma trafiğini açmadan önce eski ana düğümün yazma kabul etmesini engelleyin, replikasyon gecikmesini ve olası veri kaybını değerlendirin, yedeği kontrollü biçimde yeni ana düğüm yapın ve uygulamanın veritabanı bağlantısını buna göre yönlendirin. Geri dönüşte eski ana düğümü yeni ana düğümle yeniden eşitlemeden yazmaya açmayın. Oturumlar, yüklenen dosyalar ve zamanlanmış işler için de geçiş davranışını belirleyin.

Daha sonra gerçekten aktif-aktif yazma ihtiyacı doğarsa, veritabanı kümesi (cluster) gibi daha gelişmiş çözümlere geçilebilir; ancak küçük işletmeler için çoğu zaman aktif-pasif yapı yeterlidir.

Adım 3 – DNS kayıtlarını failover’ı destekleyecek şekilde tasarlamak

DNS tarafında tipik bir kurgu şöyle görünebilir. Bu şema origin failover’ını CDN’in yaptığı modeli gösterir. CDN’in verdiği kayıt hedefini kullanın; bir ad için A/AAAA ile CNAME’i birlikte tanımlamayın. Kullanıcıların eriştiği alan adını CDN’e ekleyip TLS sertifikasını yapılandırın; yalnızca DNS kaydı oluşturmak yeterli değildir. Origin bağlantılarında da doğru hedef adresi, Host/SNI adı ve TLS doğrulamasını yapılandırın:

• www.alanadiniz.com → CNAME → cdn.alanadiniz.com
• cdn.alanadiniz.com → A/AAAA → CDN’in IP’leri veya CNAME
• CDN’in origin tanımı → Origin-1 (Region-1 VPS) ve Origin-2 (Region-2 VPS)

Eğer CDN kullanmıyorsanız, doğrudan:

• www.alanadiniz.com → A/AAAA → Region-1 IP (aktif) + Region-2 IP (yedek)

Buradaki “aktif + yedek”, iki IP’yi aynı anda sıradan DNS yanıtında yayımlamak değildir; A/AAAA kayıtlarında kendiliğinden bir yedek önceliği yoktur. Bu davranışı destekleyen DNS hizmetinde, sağlıklı ana origin’in adresini döndüren ve arızada hazır yedeğe geçen bir failover politikası kurmalısınız. Panel adları sağlayıcıya göre değişir:

• Region-1 ve Region-2 için uygulamanın hizmet vermeye hazır olduğunu ölçen health check tanımlarsınız; yedeğin hazır olduğu doğrulanmadan trafiği ona geçirmezsiniz.
• Region-2 kaydını “standby” veya “backup” olarak işaretlersiniz.
• TTL’i toparlanma hedefinize ve sağlayıcının desteklediği değerlere göre seçersiniz; 300–600 sn örnek bir aralıktır, geçiş süresi garantisi değildir.

DNS kayıtlarını yönetirken, çoklu sağlayıcı stratejilerden geo-routing’e kadar pek çok gelişmiş tekniği gelişmiş DNS yönlendirme rehberimizde detaylıca ele aldık. Multi-region mimari kurgularken bu tekniklerin hangisine gerçekten ihtiyacınız olduğunu oradan ilham alarak belirleyebilirsiniz.

Adım 4 – CDN önbellek politikalarını doğru ayarlamak

CDN tarafında yapmanız gereken temel ayarlar:

• Statik dosyalar için uzun süreli cache (günler/haftalar) + versiyonlama (dosya adı veya CDN cache key’ine dahil edilen query string).
• Yalnızca herkese açık, kişiselleştirilmemiş HTML için kısa TTL (örneğin 30–300 sn); CDN destekliyorsa ve eski içerik sunulması kabul edilebiliyorsa stale-while-revalidate.
• WooCommerce gibi sistemlerde sepet, ödeme, hesap ve oturum açmış kullanıcılara özel yanıtlar için cache bypass kuralları.
• “Maintenance” veya acil durum sayfaları için normale dönüşte eski sayfanın sunulmasını önleyecek kısa TTL veya cache temizleme planı.

WordPress ve WooCommerce gibi popüler sistemler için CDN önbellek kurallarını nasıl yazabileceğinizi, WordPress için CDN önbellek kuralları rehberimizde ayrıntılı örneklerle anlattık. Multi-region mimaride de aynı prensipler geçerli; ayrıca origin’ler arasında içerik sürümlerinin, oturum davranışının ve cache temizleme işlemlerinin tutarlı olması gerekir.

İzleme, Test ve Felaket Provaları

Uptime izleme ve alarm kanalları

Failover mekanizması kurup bir kenara bırakmak yeterli değil. Gerçek dünyada işe yaradığından emin olmanız için düzenli izleme ve test şart:

• HTTP/HTTPS uptime izleme araçlarıyla hem Region-1 hem Region-2 için ayrı kontroller kurun.
• Alarm kanallarını (e-posta, SMS, Slack, Teams vb.) yapılandırın.
• Sitenin kullandığı kök alan adını ve/veya www alt alan adını, ayrıca varsa CDN alt alan adlarını izleyin.

İzleme kurulumuna nereden başlayacağınızı bilmiyorsanız, web sitesi uptime izleme ve alarm kurma rehberimiz küçük işletmeler için oldukça uygulanabilir bir başlangıç listesi sunuyor.

Felaket provası: Kontrollü kesintiyle failover’ı doğrulamak

Teoride çalışan bir mimarinin pratikte de iş gördüğünden emin olmak için düzenli aralıklarla felaket provası yapmanız gerekir. Örneğin:

• Önce test ortamında, üretimde ise planlı bakım penceresinde; Region-2’nin hazır olduğunu ve geri dönüş adımlarını doğruladıktan sonra Region-1 VPS’in web servisini (Nginx/Apache) kısa süreliğine durdurun.
• Uptime izleme aracınızın ve DNS/CDN sağlayıcınızın nasıl tepki verdiğini gözlemleyin.
• Kullanıcı deneyimini farklı lokasyonlardan manuel kontrollerle değerlendirin; algılama ve geçiş sürelerini kaydedin. Test sonunda servisi yeniden başlatın ve normal yönlendirme ile veri tutarlılığını doğrulayın.

Daha önce hosting tarafında felaket kurtarma provası ve yedekleri test etme rehberimizde de vurguladığımız gibi, test edilmeyen hiçbir plan gerçek anlamda hazır değildir. Multi-region DNS ve CDN failover mimariniz için de aynı kural geçerli.

Sık Yapılan Hatalar ve Pratik Kontrol Listesi

Yaygın hatalar

Kaçınılması gereken başlıca hatalar şunlar:

• Çok yüksek TTL değerleri: 14400–86400 sn (4–24 saat) gibi TTL’ler, eski yanıtı önbelleğinde tutan çözümleyiciler için DNS failover geçişini saatlerce geciktirebilir; dakikalar içinde toparlanma hedefiyle uyumlu değildir.
• Sağlık kontrolü olmayan DNS: Sadece elle IP değiştirilerek “failover” yapmaya çalışmak; bu pratikte genelde gecikmiş manuel müdahale anlamına gelir.
• Veritabanı senkronizasyonunu unutarak iki region açmak: Uygulama kodu kopyalanıyor ama veritabanının bölgesel kesintide erişilebilirliği veya güncel yedeğe geçişi planlanmıyor; failover olduğunda site çalışmayabilir ya da eski veriyle açılabilir.
• CDN cache kurallarını yanlış yazmak: Tüm HTML’i agresif cache’leyip kişisel yanıtların başka kullanıcılara sunulmasına veya giriş/sepet bilgilerinin yanlış görünmesine yol açmak.
• Test etmemek: “Kurduk, panelde gözüküyor” noktasında kalıp gerçek kesinti simülasyonu yapmamak.

Basit kontrol listesi

Multi-region DNS + CDN failover mimarinizi hayata geçirirken şu soruları kendinize sorun:

• Seçtiğim senaryo tam uygulama yedeği mi, statik acil durum sitesi mi, yoksa tek origin ve sınırlı CDN önbelleği mi? Kesintide hangi işlevler çalışacak?
• Multi-region seçtiysem iki farklı coğrafi bölgede en az birer origin sunucum var mı?
• Tam uygulama yedeğinde dosya ve veritabanı senkronizasyonu nasıl yapılıyor? Yedeği yazmaya açma, eski ana düğümün yazmasını engelleme ve geri dönüş adımları hazır mı?
• Kabul edilebilir kesinti süresini ve veri kaybı sınırını belirledim mi?
• DNS tabanlı otomatik failover seçtiysem entegre veya harici sağlık kontrolleri DNS yönlendirmesini güncelliyor mu? Hangi aralıkla çalışıyor?
• TTL değerlerim gerçekçi failover süreleriyle uyumlu mu?
• CDN tabanlı origin failover seçtiysem birden fazla origin tanımlı mı? Sağlık kontrolleri, hata koşulları ve kapsanan istek yöntemleri uygun biçimde yapılandırıldı mı?
• CDN destekliyorsa, eski içerik sunulması uygun yanıtlar için stale-if-error / stale-while-revalidate kullanımını ve sürelerini belirledim mi?
• Son 3 ay içinde en az bir kez felaket provası yaptım mı? Önemli altyapı değişikliklerinden sonra ek prova planladım mı?

Sonuç: Küçük İşletmeler İçin Gerçekçi Multi-Region Yol Haritası

Multi-region DNS ve CDN failover mimarisi kulağa ilk bakışta “büyük kurumsal şirket işi” gibi gelebilir. Ancak doğru kurgulandığında, iki uygun boyutlu VPS, makul bir CDN ve akıllı DNS ayarlarıyla küçük bir işletme sitesi için de gayet erişilebilir hale geliyor. Bu yapı kesinti etkisini azaltabilir; CDN ve uygun trafik yönlendirmesi gecikmeyi de düşürebilir. Ancak yedek bölgenin yalnızca arızada kullanıldığı bir düzende multi-region tek başına normal çalışma performansını artırmaz.

Küçük işletmeler, ajanslar ve SaaS projeleri için aşamalı bir geçiş planlanabilir. İlk adım, tek bir bölgede düzgün çalışan bir mimariyi oturtmak; ikinci adım ise ihtiyaçlara göre multi-region ve otomatik failover eklemek olabilir. Yani bir gecede devasa bir yapı kurmak zorunda değilsiniz, adım adım ilerleyebilirsiniz.

Mevcut siteniz için senaryoyu (tek origin + CDN, iki VPS ile DNS failover, statik acil durum sitesi vb.) trafik profilinize, bütçenize ve büyüme hedeflerinize göre seçin. Sunucu maliyetlerinin yanında senkronizasyon, izleme ve düzenli test için gereken işletim emeğini de hesaba katın. Yol haritanızda kabul edilebilir kesinti süresini, veri kaybı sınırını ve ilk failover provasının tarihini belirleyin.