Yüksek Erişilebilirlik Mimarisi Tasarımı

Yüksek erişilebilirlik mimarisi, "sunucu çökerse ne olacak" sorusuna önceden verilmiş bir cevaptır. Kulağa pahalı ve karmaşık gelir ama aslında tek bir disipline dayanır: sistemdeki her bileşen için "bu çökerse ne olur" diye sormak ve cevabı "hiçbir şey" olana kadar tasarımı değiştirmek. Bunu yapmadığın sürece altyapın, en zayıf halkasının dayanıklılığı kadar dayanıklıdır — ve o halka genellikle kimsenin aklına gelmeyen bir yerdedir.

Bu yazıda bir HA mimarisini nasıl tasarlayacağını sırayla anlatacağım. Önce gerçekçi bir erişilebilirlik hedefi belirlemeyi ve o hedefin sana neye mal olacağını, sonra sistemdeki tek hata noktalarını sistematik biçimde çıkarmayı göreceğiz. Ardından aktif-aktif ile aktif-pasif kurgu arasındaki seçimi, durumu uygulamadan ayırmayı, işin en zor kısmı olan veri katmanını ve devretme zincirinin nasıl kurulduğunu ele alacağız. Sonunda da veri merkezi seviyesinde dayanıklılık ve bu alanda en sık yapılan hatalar var.

Önce Hedefi Belirle: Dokuzların Maliyeti#

Mimariye başlamadan önce cevaplaman gereken tek soru şudur: yılda kaç dakika kesinti kabul edilebilir? Bu soruya "hiç" demek kolaydır ama teknik olarak anlamsızdır; her sistemin bir kesinti bütçesi vardır ve o bütçeyi bilmeden ne kadar yatırım yapman gerektiğine karar veremezsin.

Her satır, bir öncekine göre kabaca maliyeti ikiye katlar. %99,9'dan %99,99'a çıkmak sunucu sayısını ikiye katlamakla kalmaz; izleme, otomatik devretme ve düzenli tatbikat da gerektirir. Bu yüzden hedefi teknik heves yerine iş etkisiyle belirle: bir saatlik kesinti sana ne kaybettiriyor? Cevap birkaç yüz lira ise %99,9 fazlasıyla yeterlidir; on binlerce lira ise %99,99 yatırımı birkaç olayda kendini amorti eder.

Planlı bakımların bu bütçeye dahil olup olmadığına da karar vermelisin: çoğu SLA bakım penceresini hesabın dışında tutar, ama kullanıcı açısından site kapalıysa kapalıdır. Kendi hesabını yapmak için uptime SLA hesaplayıcı aracını kullanabilirsin; kesinti süresinin yanında veri kaybı toleransını da belirlemen gerekir ki bu ikili RTO ve RPO yazısının konusudur.

Tek Hata Noktalarını Çıkarmak#

Tek hata noktası (SPOF), çöktüğünde tüm sistemi durduran bileşendir. HA tasarımının ilk somut adımı bunların envanterini çıkarmaktır; bu iş beyaz tahta başında, mimarinin her kutusunu tek tek işaret ederek yapılır ve her bileşen için tek soru sorulur: "Bu şimdi ölse, kullanıcı ne görür?"

Son satır şaka değil: gerçek kesintilerin önemli bir kısmında teknik yedeklilik vardır ama devretmeyi nasıl yapacağını bilen tek kişi ulaşılamaz durumdadır. Bir HA mimarisi süreç ve bilgi düzeyinde de yedekli olmak zorundadır.

Gözden kaçan klasik noktalar: paylaşımlı dosya sistemi, tek makinede çalışan sertifika yenileme cron'u, log toplama noktası ve dış servis bağımlılıkları (ödeme sağlayıcısı, SMS API'si). Dış bağımlılıkları yedekleyemezsin ama çöktüklerinde sistemin tamamen durmak yerine sınırlı çalışmaya devam etmesini (graceful degradation) tasarlayabilirsin.

Disk katmanı özellikle sinsidir çünkü arıza kademelidir: RAID kullansan bile bozulan diski fark etmezsen ikinci disk de bozulduğunda her şey biter. Disk arızası tespiti ve SMART/RAID yazısı bu izlemeyi anlatıyor.

Aktif-Aktif mi Aktif-Pasif mi#

Yedeklilik iki temel biçimde kurulur ve bu seçim mimarinin geri kalanını büyük ölçüde belirler.

Aktif-pasif kurguda ikinci makine trafik almaz, hazır bekler ve birincil düştüğünde devreye girer. Avantajı basitliğidir: iki makinenin aynı anda aynı veriye yazma ihtimali yoktur. Dezavantajı, yedeğin çoğu zaman boşta durması ve gerçek arızaya kadar çalışıp çalışmadığının belirsiz kalmasıdır.

Aktif-aktif kurguda her iki makine de aynı anda trafik alır. Avantajı, kapasitenin ikiye katlanması ve yedek yolun sürekli test ediliyor olmasıdır — çünkü zaten sürekli kullanılmaktadır. Dezavantajı, uygulamanın gerçekten durumsuz olmasını ve veri katmanının eşzamanlı yazmaya hazır olmasını gerektirmesidir.

Pratik tavsiyem şudur: uygulama katmanını aktif-aktif, veri katmanını aktif-pasif kur. Web sunucularının hepsi aynı anda trafik alsın, veritabanında ise tek yazma düğümü olsun ve yedeği hazır beklesin. Bu kombinasyon çoğu ihtiyacı karşılarken çok yazıcılı veritabanlarının çakışma karmaşasından uzak durur.

"N+1" kuralını da unutma: üç sunucu gerekiyorsa dört çalıştır. Üçünden birini kaybettiğinde kalan ikisi %150 yük altında ezilir ve arıza zincirleme büyür. Kapasite ile ölçekleme ilişkisi için yatay mı dikey mi ölçekleme yazısına bakabilirsin.

Durumu Uygulamadan Ayırmak#

Yatay yedekliliğin önündeki en yaygın engel, uygulamanın durumu kendi üzerinde tutmasıdır. Oturum bellekte, yüklenen dosyalar yerel diskte duruyorsa iki sunucu birbirinin yerine geçemez — kullanıcı ikinci sunucuya düştüğünde oturumu kaybolur, yüklediği dosyayı bulamaz.

Bu üç şeyi dışarı çıkarmak HA mimarisinin ön koşuludur:

; PHP oturumlarını Redis'e taşımak (php.ini)
session.save_handler = redis
session.save_path = "tcp://10.0.0.30:6379?auth=GUCLU_PAROLA&database=0"

# Yüklenen dosyaları paylaşımlı depolamada tutmak
# Seçenek 1: nesne depolama (en dayanıklısı, uygulama değişikliği ister)
# Seçenek 2: NFS — ama NFS sunucusu yeni bir tek hata noktasıdır
mount -t nfs4 10.0.0.40:/veri /var/www/uploads

# Seçenek 3: iki yönlü senkron (küçük hacimlerde pratik)
rsync -az --delete /var/www/uploads/ 10.0.0.12:/var/www/uploads/

Oturumu ortak depoya taşımak yük dengeleyicide sticky session ihtiyacını da ortadan kaldırır: istekleri gerçekten en uygun sunucuya dağıtabilir, bakım için bir düğümü havuzdan çıkardığında kimseyi sistemden atmamış olursun.

Dosya paylaşımında NFS'i seçerken dikkatli ol: tek bir NFS sunucusu sorunu daha merkezî bir noktaya taşımaktan başka bir şey yapmaz, o makine çökerse tüm uygulama düğümleri birden takılır. Ya NFS'i de yedekli kur ya da nesne depolamaya geç.

Veri Katmanı: Mimarinin En Zor Halkası#

Uygulama sunucusu eklemek kolaydır; veritabanını yedeklemek zordur. Sebep basit: uygulama sunucuları durumsuz olabilir, veritabanı olamaz. İki düğümün aynı veriye sahip olmasını sağlamak, ağ gecikmesi ve arıza senaryolarıyla birlikte kendi başına bir mühendislik konusudur.

Temel seçim eşzamanlı ile eşzamansız çoğaltma arasındadır. Eşzamanlıda yazma, yedek düğüm de onaylamadan tamamlanmış sayılmaz: veri kaybı riski sıfıra yakındır ama her yazma ağ gecikmesi kadar yavaşlar. Eşzamansızda yazma hemen biter, yedek biraz geriden gelir; hızlıdır ama birincil o pencerede çökerse aradaki işlemler kaybolur.

-- MySQL: çoğaltmanın sağlığını ve gecikmesini kontrol et
SHOW REPLICA STATUS\G
-- Bakılacak alanlar:
--   Replica_IO_Running: Yes
--   Replica_SQL_Running: Yes
--   Seconds_Behind_Source: 0
--   Last_Error: (boş olmalı)

-- PostgreSQL: aktif çoğaltma bağlantıları ve gecikme
SELECT client_addr, state, sent_lsn, write_lsn, replay_lsn,
       write_lag, replay_lag
FROM pg_stat_replication;

Bu sorguları elle çalıştırıp "iyi görünüyor" demek yeterli değil; çoğaltma gecikmesini izleme sistemine bağla ve eşik aşıldığında uyarı al. Sessizce durmuş bir çoğaltma, arıza anında elinde günler öncesine ait bir yedek olduğunu keşfetmek demektir.

Üç noktayı özellikle vurgulamak isterim. Birincisi, çoğaltma yedekleme değildir: birincilde yanlışlıkla çalıştırılan bir DELETE saniyeler içinde yedek düğüme de kopyalanır, dolayısıyla gerçek bir yedekleme stratejisine ihtiyacın var — Borg ile sunucu yedekleme yazısı bu tarafı ele alıyor. İkincisi, otomatik veritabanı devretmesi split-brain riski taşır; bu yüzden ya tek karar merciyle çalışan bir yönetici süreç ya da tek sayıda düğümle çoğunluk (quorum) mantığı kullanılır. Üçüncüsü, devretme sonrası eski birincili otomatik geri almak neredeyse her zaman yanlıştır — nedenini failover ve fallback farkı yazısında anlatıyoruz.

Sağlık Kontrolü ve Otomatik Devretme Zinciri#

Yedek bileşenlerin varlığı yetmez; sistemin arızayı fark etmesi ve doğru tepkiyi vermesi gerekir. Bu zincirin üç halkası vardır: tespit, karar, eylem. Üçünden biri eksikse yedeklilik kağıt üzerinde kalır.

Tespit tarafında kritik konu sağlık kontrolünün derinliğidir. Açık bir TCP portu sunucunun çalıştığını gösterir ama uygulamanın veritabanına erişebildiğini göstermez. Doğru yaklaşım, gerçek bağımlılıkları sınayan hafif bir uç nokta eklemektir:

# /saglik uç noktası şu üçünü kontrol etmeli ve JSON dönmeli:
#   1) veritabanına basit bir sorgu
#   2) önbellek/oturum deposuna ping
#   3) kritik disk alanının doluluğu
curl -s http://10.0.0.11:8080/saglik
# {"db":"ok","cache":"ok","disk":"ok","surum":"2026.08.1"}

Bu uç noktanın hafif olması şarttır — saniyede birkaç kez çağrılacaktır. Ağır sorgu çalıştıran bir sağlık kontrolü yük altında ilk çöken şey olur ve sağlıklı sunucuları havuzdan attırarak arızayı kendisi yaratır.

Karar tarafında dikkat edilecek şey histerezistir: tek bir başarısız kontrolde devretmek, geçici bir dalgalanmada gereksiz devretme üretir. Ardışık üç başarısızlıkta arıza, ardışık iki başarıda sağlıklı saymak makul bir ayardır.

Eylem tarafında zincirin tamamını kurmalısın: uygulama düğümü çökerse yük dengeleyici onu havuzdan çıkarır (yük dengeleyici nedir), dengeleyici çökerse sanal IP diğer düğüme geçer (Keepalived ve VRRP), veritabanı çökerse yedek düğüm birincil olur. Her halka ayrı ayrı test edilmelidir.

Tek kural: denenmemiş devretme, çalışmayan devretmedir. Üç ayda bir tatbikat yap, bir düğümü bilerek kapat ve zinciri baştan sona izle. İlk tatbikatta neredeyse kesinlikle bir şey bulacaksın — eksik bir güvenlik duvarı kuralı, kopyalanmamış bir sertifika, yanlış bir öncelik değeri.

Veri Merkezi Seviyesinde Dayanıklılık#

Tek bir veri merkezinde ne kadar yedeklilik kurarsan kur, o merkezin tamamını etkileyen bir olaya karşı korumasızsın: elektrik kesintisi, yangın, ağ omurgasında arıza ya da doğal afet. %99,99 ve üstü hedefler bu yüzden birden fazla lokasyon gerektirir.

Çok lokasyonlu tasarımda ana zorluk yine veri katmanıdır: lokasyonlar arası gecikme eşzamanlı çoğaltmayı pratik olmaktan çıkarır, dolayısıyla eşzamansız çalışır ve belirli bir RPO'yu kabul edersin. Trafik yönlendirmesi ise DNS seviyesinde ya da anycast tabanlı bir katmanla yapılır.

Aşamalı bir olgunluk yolu izlemek en gerçekçi yaklaşımdır:

1. Tek sunucu, sağlam yedekleme. Kesinti olur ama veri kaybolmaz; küçük siteler için yeterlidir.
2. Aynı lokasyonda ikinci sunucu. Donanım arızasına karşı koruma; yük dengeleyici ve otomatik devretme burada girer.
3. Farklı lokasyonda soğuk yedek. Düzenli senkronlanan, gerektiğinde elle ayağa kaldırılan bir kopya.
4. Farklı lokasyonda sıcak yedek. Sürekli çoğaltılan, dakikalar içinde devralabilen bir ortam.
5. Çok lokasyonlu aktif-aktif. En pahalı ve en karmaşık seviye; gerçekten gerektiğinden emin ol.

Çoğu işletme için 2. ve 3. seviyenin birleşimi doğru noktadır: aynı lokasyonda otomatik devretme, farklı lokasyonda düzenli senkronlanan bir kopya.

Sık Yapılan Hatalar#

Yedekliliği yedeklemeyle karıştırmak. Yedeklilik sistemi ayakta tutar, yedekleme veriyi kurtarır; biri diğerinin yerine geçmez. Çoğaltılan bir veritabanı, silinen bir tabloyu geri getirmez.

Devretmeyi hiç test etmemek. Kurulumdan iki yıl sonra, ilk gerçek arızada yedeğin çalışmadığını öğrenmek en pahalı öğrenme biçimidir. Tatbikat bakım planının parçası olmalıdır.

Sağlık kontrolünü yüzeysel bırakmak. Port açık diye sağlıklı saymak, veritabanına erişemeyen bir sunucuya trafik göndermeye devam etmektir. Kontrol gerçek bağımlılıkları sınamalıdır.

N+1 payı bırakmamak. Tam kapasiteyle çalışan bir havuzda bir düğüm kaybetmek kalanları ezer ve zincirleme çöküş üretir. Her zaman bir düğüm fazla çalıştır.

Belgelemeyi atlamak. Devretme yordamı yalnızca bir kişinin kafasındaysa, o kişi izinde olduğunda mimarin yüksek erişilebilir değildir.

Sıkça Sorulan Sorular#

Yüksek erişilebilirlik için en az kaç sunucu gerekir#

Uygulama katmanı için pratik minimum ikidir: bir yük dengeleyici arkasında iki uygulama sunucusu. Ancak dengeleyicinin kendisi yedeklenmezse tek hata noktası olarak kalır, bu yüzden gerçek bir HA kurulumu genellikle dört makineyle başlar. Veritabanını da ayırıp yedeklersen sayı altıya çıkar; küçük kurulumlarda dengeleyici ve uygulama aynı makinede birleştirilip ikiye inilebilir.

Yüksek erişilebilirlik ile felaket kurtarma aynı şey mi#

Hayır, farklı sorunları çözerler. Yüksek erişilebilirlik sık görülen arızalara (disk bozulması, süreç çökmesi, tek sunucu kaybı) karşı sistemi çalışır tutar; devretme otomatiktir ve saniyeler sürer. Felaket kurtarma ise tüm bir lokasyonun kaybı gibi nadir ama yıkıcı olaylara karşı çalışır, elle tetiklenir ve saatler sürebilir. Olgun bir altyapıda ikisi birlikte bulunur.

%99,99 uptime gerçekten mümkün mü#

Teknik olarak mümkündür ama yalnızca mimariyle sağlanmaz. Yılda 52 dakikalık bütçe; planlı bakımların kesintisiz yapılmasını, güncellemelerin kademeli yayınlanmasını, izlemenin arızayı dakikalar içinde yakalamasını ve devretmenin insan beklemeden çalışmasını gerektirir. Dış bağımlılıkların da (sağlayıcı ağı, DNS, sertifika otoritesi) bu hedefe uyması gerekir. Çoğu işletme için %99,9 çok daha gerçekçidir.

Aktif-aktif mimari her zaman daha mı iyi#

Hayır. Aktif-aktif kaynakları verimli kullanır ve yedek yolu sürekli test eder, ama uygulamanın tamamen durumsuz olmasını ve veri katmanının eşzamanlı erişimi kaldırmasını gerektirir. Bu koşullar yoksa veri tutarsızlığı ve teşhisi zor hatalar üretir. Uygulamada aktif-aktif, veride aktif-pasif kombinasyonu çoğu senaryo için en dengeli tercihtir.

Yüksek erişilebilirlik maliyeti ne kadar artırır#

Kabaca, aynı kapasiteyi yedekli kurmak altyapı maliyetini iki katına çıkarır; buna izleme, otomasyon ve bakım zamanı eklenir. Ancak karşılaştırmayı doğru yap: bir saatlik kesintinin sana maliyeti nedir? Doğrudan gelir üreten sistemlerde yedeklilik maliyeti genellikle tek bir ciddi kesintiyle kendini amorti eder. Düşük etkili sistemlerde ise iyi bir yedekleme ve hızlı geri yükleme çok daha ekonomiktir.

Devretme testini ne sıklıkla yapmalıyım#

En az üç ayda bir, ve mutlaka mimaride bir değişiklik yaptıktan sonra. Sertifika yenileme, çekirdek güncellemesi ya da yeni düğüm ekleme devretme zincirini sessizce bozabilir. Testi gerçek koşullara yakın yap: bir düğümü kapat, kesinti süresini ölç, kayıtları incele ve bulduğun aksaklığı yordama not et. Test edilmemiş bir devretme mekanizması, olmayan bir mekanizmayla aynı değerdedir.

Kapanış#

Yüksek erişilebilirlik mimarisi, pahalı ekipman değil disiplinli bir düşünme biçimidir. Gerçekçi bir hedefle başla, her bileşen için "bu çökerse ne olur" sorusunu sor, durumu uygulamadan ayır, veri katmanını en son ve en dikkatli ele al ve kurduğun her devretme yolunu düzenli test et. Bir de N+1 payını atlama: yedekliliğin işe yaraması için kalan düğümlerin yükü taşıyabilmesi gerekir.

Bu mimariyi kurmak için birden fazla bağımsız sunucuya ihtiyacın var. Bulut sunucu ve VDS paketlerimizle katmanları ayrı makinelere dağıtabilir, donanım seviyesinde tam ayrışma istiyorsan dedicated sunucu tarafına geçebilirsin. Kurulumu, izlemeyi ve devretme tatbikatlarını bize bırakmak istersen sunucu yönetimi hizmetimiz bu işi üstlenir; veri tarafı için yedekleme, saldırı anında ayakta kalmak için DDoS koruma sayfalarımıza göz atabilirsin.