Coğrafi Yedeklilik ve Çoklu Bölge Mimarisi

Tek bir veri merkezinde ne kadar yedeklilik kurarsanız kurun — çift güç kaynağı, RAID, kümelenmiş sunucular — o binanın tamamını etkileyen bir olay hepsini birden götürür. Elektrik altyapısı arızası, yangın, ağ omurgasında bir kesinti ya da doğal afet, mükemmel tasarlanmış bir kümeyi bir anda erişilemez hâle getirir. Coğrafi yedeklilik, bu tek bina bağımlılığını ortadan kaldırma çabasıdır ve çoklu bölge mimarisi bunun uygulanmış hâlidir.

Bu rehberde coğrafi yedekliliği pratik bir gözle ele alacağım: hangi üç mimari modelin var olduğu ve maliyet-karmaşıklık dengelerinin nasıl değiştiği, işin gerçek zorluğunun neden veri katmanında yattığı, trafiği bölgeler arasında yönlendirmenin yolları, statik içerik ve nesne depolamanın çoğaltılması, gecikme ile maliyetin nasıl bir sınır çizdiği ve bu mimarilerde en sık yapılan hatalar. Sonunda kendi sisteminiz için hangi seviyenin gerçekten gerekli olduğuna karar verebileceksiniz.

Coğrafi Yedeklilik Neyi Çözer, Neyi Çözmez#

Coğrafi yedeklilik, sisteminizin kopyalarını fiziksel olarak birbirinden uzak veri merkezlerinde tutmak demektir. Amaç, bir bölgenin tamamen kaybedilmesi durumunda hizmetin başka bir bölgeden devam etmesidir. Bu, aynı binadaki iki sunucuyla ya da aynı rafın iki tarafındaki disklerle elde edilemeyecek bir koruma seviyesidir.

Neyi çözmediğini de baştan netleştirelim, çünkü çoklu bölge mimarisi sıklıkla her derde deva sanılır. Uygulamanızdaki bir hata, hatalı bir dağıtım ya da yanlışlıkla silinen bir tablo, replikasyon sayesinde tüm bölgelere anında yayılır. Fidye yazılımı aynı şekilde davranır. Yani coğrafi yedeklilik bir yedekleme stratejisinin yerine geçmez; onunla birlikte kurulur. Yedekleme "zamanda geri gitme" yeteneğidir, coğrafi yedeklilik ise "mekânda alternatif" yeteneğidir. İkisinin ayrımını ve nasıl birlikte planlanacağını felaket kurtarma planı hazırlama yazısında ayrıntılı ele aldım.

Bir de dürüst bir maliyet uyarısı: çoklu bölge, altyapı maliyetini iki katına çıkarmakla kalmaz, işletme karmaşıklığını çok daha fazla artırır. İki bölge iki kat sunucu, iki kat yama yönetimi, iki kat izleme, bölgeler arası trafik ücreti ve çok daha zor bir hata ayıklama demektir. Çoğu işletme için doğru cevap, tam etkin-etkin bir mimari değil, ikinci bölgede iyi hazırlanmış bir kurtarma ortamıdır.

Üç Mimari Model#

Karar vermeden önce seçeneklerin ne olduğunu net görmek gerekir. Pratikte üç model vardır ve aralarındaki fark, ikinci bölgenin ne kadar "hazır" olduğudur.

Soğuk yedek en yaygın ve çoğu işletme için en makul seçenektir. İkinci bölgede yalnızca yedekleriniz durur; felaket anında sunucuları kurar, veriyi geri yükler ve DNS'i çevirirsiniz. Otomasyon iyiyse (imaj ya da yapılandırma yönetimi hazırsa) bu süre birkaç saate iner. Sunucu kurulumunu betiklemek için Ansible ile sunucu otomasyonu yazısı doğrudan bu amaca hizmet eder.

Ilık yedek (etkin-pasif), ikinci bölgede sunucuların ayakta ve güncel olduğu, veritabanının sürekli çoğaltıldığı ama trafiğin yalnızca birincil bölgeye gittiği modeldir. Geçiş, veritabanı kopyasını birincil hâle getirmek ve trafiği yönlendirmekten ibarettir. Maliyet iki katına yakındır ama geçiş süresi dakikalarla ölçülür.

Etkin-etkin, her iki bölgenin de aynı anda trafik aldığı modeldir. En yüksek erişilebilirliği verir ama en zor olanıdır: yazma işlemlerinin hangi bölgede yapılacağı, çakışmaların nasıl çözüleceği ve oturum verisinin nasıl paylaşılacağı gibi sorular uygulama tasarımını doğrudan etkiler. Uygulamanız bu model düşünülerek yazılmamışsa, sonradan geçmek çoğu zaman baştan yazmak kadar iş çıkarır.

Veri Katmanı: İşin Gerçek Zorluğu#

Uygulama sunucularını çoğaltmak kolaydır; durumsuz (stateless) oldukları sürece istediğiniz kadar kopya çalıştırabilirsiniz. Zorluk her zaman veritabanındadır ve burada fizik kanunlarıyla karşı karşıyasınızdır: iki veri merkezi arasındaki gidiş-dönüş gecikmesi, ışık hızı yüzünden sıfırlanamaz. İki şehir arasında tipik olarak birkaç milisaniye, kıtalar arasında onlarca milisaniye ödersiniz.

Bu, iki çoğaltma modeli arasında seçim yapmanızı zorunlu kılar:

Senkron çoğaltma, yazma işlemini ikinci bölge de onaylayana kadar tamamlanmış saymaz. Veri kaybı yoktur (RPO sıfır) ama her yazma, bölgeler arası gecikmeyi öder. 20 ms'lik bir mesafede saniyede yapılabilecek sıralı yazma sayısı ciddi biçimde düşer ve bu, kullanıcı deneyimine doğrudan yansır.

Asenkron çoğaltma, yazmayı birincil bölgede tamamlar ve ikinciye arka planda gönderir. Performans yerel yazma kadar iyidir ama birincil bölge aniden kaybolursa henüz gönderilmemiş işlemler kaybolur — yani RPO sıfır değildir.

Pratikte çoğu kurulum asenkron çoğaltmayı seçer ve gecikmeyi (replication lag) izler. PostgreSQL için tipik bir kurulum şöyle görünür:

# İkincil bölgedeki sunucuda: birincilden temel yedek al
sudo -u postgres pg_basebackup \
  -h db-birincil.firmaniz.com -U replikator \
  -D /var/lib/postgresql/16/main -R -P --wal-method=stream

sudo systemctl start postgresql

-- Birincil sunucuda: çoğaltma gecikmesini izle
SELECT client_addr,
       state,
       pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS gecikme_bayt,
       write_lag, flush_lag, replay_lag
FROM pg_stat_replication;

gecikme_bayt sütununu izleme sisteminize bir metrik olarak ekleyin. Bu sayı sürekli büyüyorsa ikinci bölgeniz göründüğü kadar güncel değildir ve gerçek RPO'nuz, planladığınızdan çok daha kötüdür. MySQL tarafında karşılığı SHOW REPLICA STATUS çıktısındaki Seconds_Behind_Source değeridir.

Dosya katmanında da benzer bir seçim yaparsınız. Bölge içinde senkron dağıtık dosya sistemleri iyi çalışır, ancak GlusterFS gibi çözümleri bölgeler arası senkron replica olarak kurmak hemen her zaman hataya çıkar; her yazma tüm kopyalara gitmek zorunda olduğu için gecikme uygulamaya doğrudan yansır. Bölgeler arası dosya senkronu asenkron olmalıdır.

Trafik Yönlendirme ve Devralma#

Bölgeler hazır olsa bile trafiği yönlendiremezseniz hiçbir işe yaramaz. Üç yaygın yöntem vardır.

DNS failover en yaygın ve en erişilebilir yöntemdir. Sağlık kontrolü yapan bir DNS servisi, birincil bölge yanıt vermediğinde kaydı ikincil IP'ye çevirir. Kurulumu basittir ama devralma süresi TTL'e bağlıdır ve gerçek dünyada bazı çözümleyiciler TTL'e tam uymaz.

; Failover için düşük TTL kullanın
firmaniz.com.       60   IN  A   185.12.34.56    ; birincil bölge
; sağlık kontrolü başarısız olduğunda kayıt şuna döner:
; firmaniz.com.     60   IN  A   185.12.40.90    ; ikincil bölge

TTL'i 60 saniyeye indirmek geçişi hızlandırır ama DNS sorgu yükünü artırır. Planlı bir geçiş yapacaksanız TTL'i en az bir gün önceden düşürün; bunun mantığını ve DNS'in neden anlık davranmadığını DNS değişti, site eski sunucuda açılıyor yazısında ayrıntılı anlatıyorum.

Anycast, aynı IP adresinin birden çok lokasyondan duyurulmasıdır; kullanıcı en yakın olana yönlenir ve bir lokasyon düştüğünde yönlendirme ağ katmanında saniyeler içinde değişir. En hızlı yöntemdir ama kendi IP bloğunuzu ve BGP duyurusunu gerektirir; pratikte çoğu işletme buna bir CDN ya da koruma servisi üzerinden erişir.

Ters vekil / yük dengeleyici katmanı, iki bölgeyi önünde duran bir katmanın arkasına koyar. Sağlık kontrolü başarısız olan bölgeye trafik göndermez ve geçiş DNS'e göre çok daha hızlıdır. Bu katmanın kendisinin yedekli olması gerektiğini unutmayın; aksi hâlde tek nokta arızayı bir kat yukarı taşımış olursunuz. Saldırı anlarında trafiği emmek için DDoS koruma ve uygulama katmanı için WAF hizmetleri bu katmanla birlikte düşünülür.

Hangi yöntemi seçerseniz seçin, devralmayı otomatik yapıp yapmayacağınıza bilinçli karar verin. Otomatik devralma hızlıdır ama yanlış pozitif bir sağlık kontrolü, sağlıklı bir bölgeden gereksiz yere çıkmanıza ve asenkron çoğaltmada veri kaybına yol açabilir. Birçok ekip için doğru denge, tespiti otomatikleştirip devralma kararını bir insana bırakmaktır.

Statik İçerik, Nesne Depolama ve Oturum Verisi#

Veritabanı dışındaki üç katman genellikle daha kolay çözülür ama unutulduklarında geçişi baltalar.

Statik varlıklar (CSS, JS, görseller) için doğru cevap neredeyse her zaman CDN'dir. İçerik zaten kenar sunucularda önbelleklendiği için bir bölgenin kaybı statik içeriği etkilemez; üstelik normal zamanda da hız kazanırsınız.

Kullanıcı yüklemeleri nesne depolamada tutulmalı ve bölgeler arası çoğaltılmalıdır. Çoğu S3 uyumlu sistem kova düzeyinde çoğaltma kuralı sunar; sunmuyorsa rclone ile zamanlanmış bir senkron da işi görür:

# İki bölge arasında tek yönlü senkron (birincil -> ikincil)
rclone sync birincil:firmaniz-yuklemeler ikincil:firmaniz-yuklemeler \
  --transfers 16 --checkers 32 --fast-list --stats 30s

Nesne depolamanın kavramları ve erişim modeli için S3 uyumlu nesne depolama yazısına bakabilirsiniz.

Oturum verisi en çok gözden kaçan kalemdir. Oturumlar uygulama sunucusunun yerel diskinde tutuluyorsa, bölge değiştiğinde tüm kullanıcılar oturumdan düşer — teknik olarak başarılı bir devralma, kullanıcı için tam bir kesinti gibi görünür. Oturumları paylaşılan bir depoya (Redis gibi) taşıyın ya da en azından imzalı çerez tabanlı bir modele geçin.

Bir de sıkça atlanan bir ayrıntı: SSL sertifikaları ve gizli anahtarlar ikinci bölgede hazır olmalıdır. Devralma anında sertifika almaya çalışmak, doğrulama DNS'e bağlı olduğu için tam da en kötü zamanda tıkanır.

Maliyet, Gecikme ve Yasal Kısıtlar#

Karar verirken üç kısıtı birlikte değerlendirin.

Maliyet yalnızca ikinci bölgedeki sunuculardan ibaret değildir. Bölgeler arası veri transferi çoğu sağlayıcıda ücretlidir ve sürekli çoğaltma yapan bir veritabanı bu kalemi şaşırtıcı biçimde büyütebilir. İşletme maliyeti de gerçektir: iki ortamın yamalarını, yapılandırmalarını ve izlemesini senkron tutmak sürekli emek ister.

Gecikme kullanıcıya da yansır. İkinci bölge coğrafi olarak uzaksa ve oraya devrettiğinizde kullanıcılarınızın çoğu hâlâ ilk bölgenin yakınındaysa, hizmet ayakta olur ama belirgin şekilde yavaşlar. Bu kabul edilebilir bir durumdur, yeter ki önceden bilinsin ve müşteriye doğru iletilsin.

Yasal ve sözleşmesel kısıtlar özellikle Türkiye'de belirleyici olabilir. Kişisel verilerin yurt dışına aktarımı mevzuata tabidir; ikinci bölgeyi yurt dışında konumlandırmadan önce hukuki tarafı netleştirin. Bazı kurumsal sözleşmeler verinin yurt içinde kalmasını şart koşar ve bu şart, teknik olarak en uygun çözümü elemenizi gerektirebilir.

Son olarak hedefinizi somutlaştırın. "Yüksek erişilebilirlik istiyoruz" cümlesi bir hedef değildir; %99,9 ile %99,99 arasındaki fark yılda yaklaşık 8,8 saatten 53 dakikaya inmek demektir ve bu farkın maliyeti doğrusal değildir. Uptime ve SLA hesaplayıcı aracımızla hedefinizin kaç dakikaya karşılık geldiğini görmek, tartışmayı hızla somutlaştırır. Tek bölgede kalıp altyapıyı güçlendirmenin mi yoksa ikinci bölgeye yatırım yapmanın mı doğru olduğuna karar verirken bulut sunucu mu VDS mi karşılaştırması da yardımcı olur.

Sık Yapılan Hatalar ve Tuzaklar#

Devralmayı hiç denememek. İkinci bölge aylarca bekler, kimse oraya gerçekten geçmeyi denemez ve felaket anında ortaya çıkar ki bir yapılandırma eksiktir ya da veritabanı sürümü uyumsuzdur. Planlı devralma tatbikatı yapın; tercihen düşük trafikli bir saatte, gerçekten trafiği ikinci bölgeye alarak.

Çoğaltma gecikmesini izlememek. Replikasyon sessizce durur: bir disk dolar, bir bağlantı kopar, bir çakışma senkronu bloke eder. Gecikme metriğini alarma bağlamazsanız ikinci bölgeniz haftalarca eski veriyle bekleyebilir.

Bağımlılıkları tek bölgede bırakmak. Uygulama iki bölgede ama Redis, mesaj kuyruğu, arama motoru ya da kimlik doğrulama servisi yalnızca birincidedir. Devralma yapıldığında uygulama açılır ama çalışmaz. Bağımlılık haritası çıkarmadan çoklu bölgeye geçmeyin.

DNS TTL'ini yüksek bırakmak. 86400 saniyelik bir TTL ile failover kurmak, geçişin bir güne yayılması demektir. Failover kayıtlarında TTL 60–300 aralığında olmalıdır.

Oturum ve önbellek katmanını unutmak. Devralma teknik olarak başarılı olur ama tüm kullanıcılar oturumdan düşer ve önbellek boş olduğu için ikinci bölge ilk dakikalarda ağır yük altında ezilir. Önbelleği önceden ısıtmayı da planın parçası yapın.

Çoğaltmayı yedek sanmak. Silinen kayıt, bozulan tablo ve şifrelenen dosya tüm bölgelere anında yayılır. Coğrafi yedeklilik yedeklemenin yerine geçmez.

Gereğinden karmaşık mimari kurmak. Etkin-etkin bir mimari, işletemediğiniz takdirde tek bölgeli sade bir kurulumdan daha az güvenilir olur. Ekibinizin sürdürebileceği en basit modeli seçin.

Sıkça Sorulan Sorular#

Coğrafi yedeklilik her işletme için gerekli mi#

Hayır. Kurumsal bir tanıtım sitesi ya da düşük trafikli bir uygulama için birkaç saatlik kesinti genellikle katlanılabilir ve ikinci bölgenin maliyeti bu riski karşılamaz. Bu tür sistemlerde doğru yaklaşım, düzenli ve uzak lokasyonda tutulan yedekler ile hızlı bir kurtarma otomasyonudur. Kesintinin doğrudan gelir kaybına ya da sözleşmesel yaptırıma yol açtığı sistemlerde ise ikinci bölge yatırımı anlamlı hâle gelir.

İki bölge arasında senkron çoğaltma yapabilir miyim#

Teknik olarak yapabilirsiniz ama bedelini her yazma işleminde ödersiniz. Senkron çoğaltmada işlem, ikinci bölge onaylayana kadar tamamlanmaz; bölgeler arası gidiş-dönüş gecikmesi doğrudan uygulama yanıt süresine eklenir. Yakın şehirler arasında birkaç milisaniyelik ek gecikme bazı iş yükleri için kabul edilebilir, uzak bölgelerde ise pratik olmaktan çıkar. Çoğu kurulum asenkron çoğaltma kullanır ve gecikmeyi yakından izler.

DNS failover ne kadar hızlı çalışır#

Teorik olarak TTL süresi kadar, pratikte biraz daha uzun. TTL'i 60 saniyeye ayarlarsanız çoğu çözümleyici bir dakika içinde yeni kaydı alır, ancak bazı ISP çözümleyicileri ve istemci tarafı önbellekler TTL'e tam uymaz; ayrıca sağlık kontrolünün arızayı fark etmesi de zaman alır. Gerçekçi bir beklenti birkaç dakikadır. Saniyeler mertebesinde devralma istiyorsanız DNS yerine anycast ya da önde duran bir yük dengeleyici katmanı gerekir.

İkinci bölge sürekli açık mı durmalı#

Modele bağlıdır. Soğuk yedek modelinde ikinci bölgede yalnızca veri durur, sunucular kapalıdır ve maliyet düşüktür; karşılığında kurtarma saatler alır. Ilık yedek modelinde sunucular açık ve güncel durur, veritabanı sürekli çoğaltılır; maliyet artar ama devralma dakikalara iner. Kararı RTO hedefiniz belirlemeli: kabul ettiğiniz kesinti süresi saatlerse soğuk yedek yeterlidir, dakikalarsa ilık yedeğe geçmeniz gerekir.

Bölgeler arası trafik maliyeti nasıl kontrol edilir#

Öncelikle neyin çoğaltıldığını gözden geçirin; log dosyaları, geçici dosyalar ve önbellek verisi çoğu zaman gereksiz yere kopyalanır ve maliyetin büyük bölümünü oluşturur. Sadece kalıcı ve gerçekten gerekli veriyi çoğaltın. Nesne depolamada yaşam döngüsü kurallarıyla eski sürümleri temizleyin, veritabanında ise sıkıştırmayı açık tutun. Statik içeriği CDN'e taşımak da bölgeler arası trafiği belirgin biçimde azaltır.

Yedeklerimi ikinci bölgede tutmam yeterli mi#

Bu iyi bir başlangıçtır ama tek başına bir çoklu bölge mimarisi değildir; soğuk yedek modeline karşılık gelir. Yeterli olup olmadığı, o yedeklerden ne kadar sürede hizmet ayağa kaldırabildiğinize bağlıdır. Sunucu kurulumu otomatikleştirilmiş, runbook yazılmış ve süreç düzenli test ediliyorsa birçok işletme için gerçekten yeterlidir. Test edilmemişse, ikinci bölgede duran yedekler yalnızca bir umuttur.

Kapanış#

Coğrafi yedeklilik, tek bir binanın kaybına karşı alınan bir sigortadır ve seviyesi ihtiyaca göre seçilir. Aklınızda kalması gereken alışkanlıklar şunlar: önce RTO ve RPO hedefinizi belirleyip modeli ona göre seçin, veri katmanında senkron-asenkron kararını gecikmeyi ölçerek verin, çoğaltma gecikmesini alarma bağlayın, oturum ve sertifika gibi gözden kaçan katmanları bağımlılık haritasına yazın ve en önemlisi devralmayı gerçekten deneyin. Bir de çoğaltmanın yedekleme olmadığını unutmayın; silinen veri her bölgeden aynı anda silinir.

Bu mimarilerin altyapısını kurarken esnek ölçeklenen bulut sunucu ve tam kontrol sunan VDS paketlerimizden yararlanabilir, ikinci kopyanızı üretimden ayrı tutmak için yedekleme çözümlerimize bakabilirsiniz. Trafiği saldırılara ve ani yük artışlarına karşı korumak için DDoS koruma hizmetimiz, mimarinin tasarımı ve işletmesi konusunda destek isterseniz sunucu yönetimi ekibimiz yanınızda olur.