Yüksek Erişilebilirlik mi Güçlü Tek Sunucu mu?

E-ticaret ve SaaS Projelerinde Yüksek Erişilebilirlik İkilemi

E-ticaret veya SaaS projesi planlarken teknik toplantıların en kritik sorularından biri şudur: “Yüksek erişilebilirlik (HA) kümesi mi kurmalıyız, yoksa çok güçlü tek bir sunucu mu yeterli?” Bu soru sadece mimari bir tercih değil; doğrudan gelir kaybını, ekip iş yükünü, hata payını ve uzun vadeli ölçeklenebilirliği belirleyen stratejik bir karar.

Bir yanda, çok çekirdekli CPU, bol RAM ve hızlı NVMe disklerle donatılmış tek bir sunucu: Basit, yönetmesi kolay, maliyeti daha öngörülebilir. Diğer yanda, birden fazla sunucuya yayılmış, yük dengeleyicili, otomatik failover’lı, veritabanı replikasyonlu yüksek erişilebilirlik mimarileri: Daha karmaşık ama doğru kurulduğunda kesintilere karşı çok daha dirençli.

Bu yazıda, DCHost tarafında yıllardır gördüğümüz gerçek senaryolara dayanarak HA kümesi mi, güçlü tek sunucu mu sorusunu e-ticaret ve SaaS bakış açısıyla parçalara ayıracağız. Hangi ciro seviyesinde, hangi SLA hedefinde ve hangi teknik ekiple hangi stratejinin mantıklı olduğuna odaklanacağız. Eğer “yanlış mimariyle başlayıp sonra taşınmak” kabusundan kaçmak istiyorsanız, buradaki çerçeve size oldukça net bir yol haritası verecek.

Yüksek Erişilebilirlik ve Tek Sunucu Yaklaşımını Doğru Anlamak

Önce kavramları netleştirelim. Yüksek kullanılabilirlik (HA) nedir sorusunu detaylı anlattığımız yazıda da vurguladığımız gibi, HA sihirli bir “hiç çökmez” düğmesi değildir. Aslında yaptığınız şey, tekil hata noktalarını azaltarak kesinti süresini istatistiksel olarak küçültmektir.

Tek güçlü sunucu yaklaşımı şunu varsayar: “Donanımım sağlam, yazılımım iyi bakımlı, düzenli yedeklerim var. Arada bir kesinti olabilir ama kabul edebilirim.” Basit mimari, düşük operasyonel karmaşıklık ve genelde daha düşük başlangıç maliyeti sağlar.

HA yaklaşımı ise şunu hedefler: “Donanım arızası, işletim sistemi çökmesi, veri merkezi problemi ve hatta bazen bölgesel sorunlar olduğunda bile sistemim çalışmaya devam etsin.” Bunun için tipik olarak:

• Birden fazla uygulama sunucusu (active-active veya active-passive)
• Replikasyonlu veya cluster veritabanı altyapısı
• Yük dengeleyici (load balancer)
• Paylaşımlı veya replikasyonlu depolama
• DNS / ağ tarafında otomatik failover mekanizmaları

Bu noktada işin matematiği devreye giriyor. 99.9% uptime ne demek yazısında gösterdiğimiz gibi, yıllık bazda:

• 99% uptime ≈ yılda ~3.65 gün kesinti
• 99.9% uptime ≈ yılda ~8.7 saat kesinti
• 99.99% uptime ≈ yılda ~52 dakika kesinti

Strateji seçerken asıl sorunuz şu olmalı: “Ben yılda ne kadar kesintiyi iş ve gelir tarafında gerçekten tolere edebilirim?”

E-Ticaret ve SaaS Projelerinde Kesinti Maliyeti

Teknik tarafta konuşmak kolaydır; asıl kritik olan, kesintinin iş tarafındaki maliyetini sayılara dökebilmek. Bunu yapmadan HA kararını sağlıklı vermek mümkün değil.

E-ticaret sitelerinde kesinti etkisi

Basit bir örnek üzerinden gidelim:

• Aylık cironuz: 1.200.000 TL (günlük ortalama 40.000 TL)
• Yoğun saatler: 12.00–14.00 ve 20.00–23.00 arası
• Sunucunuz günde ortalama 1 saat, tam da kampanya dönemlerinde sorun çıkarıyor

Günlük 40.000 TL ciro yaptığınız bir sitede, yoğun saatlerde yaşanan 1 saatlik kesinti çok kabaca 5.000–10.000 TL arası kayıp anlamına gelebilir. Üstüne müşteri memnuniyetsizliği, reklam kampanyalarının boşa gitmesi, sepetten vazgeçmeler ve marka algısı da eklenince gerçek maliyet daha da artar.

Yoğun trafikli kampanyalar için hosting ölçeklendirme rehberi yazısında anlattığımız gibi, özellikle kampanya ve indirim dönemlerinde anlık trafik patlamalarına hazırlıklı olmak kritik. Bu dönemlerde tek sunucunun sınırlarına çarpmak çok kolay.

SaaS uygulamalarında kesinti etkisi

SaaS tarafında ise tablo biraz farklı. Kurumsal müşterilere hizmet veriyorsanız:

• Müşteri sözleşmelerinde uptime taahhütleri (SLA) olabilir
• Kesintiler, destek yükünü ve iade taleplerini artırır
• Kritik iş süreçleri size emanet olduğu için güven kaybı daha derin olur

Örneğin, bordro, CRM veya proje yönetimi gibi iş üretiminde kullanılan bir SaaS ürünü sunuyorsanız, ayda 2–3 saatlik kesinti bile bazı müşteriler için “satıcı değiştirme” kararı demek olabilir. Böyle bir senaryoda HA yatırımı, pazarlama bütçesinden bile daha önemli hale geliyor.

Tek Güçlü Sunucu Ne Zaman Yeterlidir?

Her proje için HA kümesi şart değil. Özellikle başlangıç aşamasında, doğru tasarlanmış ve sağlam bir şekilde yönetilen tek güçlü sunucu, hem e-ticaret hem SaaS için gayet mantıklı bir başlangıç noktası olabilir.

Tek sunucu yaklaşımının mantıklı olduğu durumlar

• Yeni başlayan projeler: Ürün–pazar uyumu henüz net değil, trafik ve ciro öngörülemiyor.
• Düşük ciro / kritik olmayan iş yükü: Saatlik kesinti, gelirinize dramatik darbe vurmuyorsa.
• Küçük ekipler: DevOps veya sistem yöneticisi tam zamanlı yoksa, karmaşık bir HA mimarisi yönetmek risklidir.
• Basit monolitik mimariler: Tek bir kod tabanı, tek veritabanı, ek servislerin az olduğu yapılar.

Bu senaryolarda yapılacak en iyi şey, güçlü bir sunucu üzerinde olabildiğince HA’ya geçişe hazır olacak şekilde tasarım yapmaktır.

Tek sunucuda uygulanması gereken asgari iyi uygulamalar

• Düzenli ve dış lokasyona yedek: En az günlük tam yedek, saatlik/veri tabanı odaklı artımlı yedekler. Yedeklerin geri yükleme testleri mutlaka yapılmalı.
• İzleme ve uyarı sistemleri: CPU, RAM, disk, I/O, HTTP cevap süresi, veritabanı gecikmesi, SSL süresi gibi metrikler için alarmlar.
• Güncellemeler için bakım penceresi: WooCommerce veya benzeri sistemler için güncellemeleri güvenle yapmak şart. Planlı bakım pencereleri belirlenmeli.
• Önbellek ve optimizasyon: Tek sunucudan maksimum verim almak için uygulama ve veritabanı optimizasyonu, nesne ve tam sayfa önbellek, CDN kullanımı.
• Felaket planı: Sunucu tamamen kaybedilirse (disk arızası, ciddi hack vb.) kaç saat içinde yeni sunucuda ayağa kalkabileceğinizin net bir runbook’u olmalı.

Başlangıçta DCHost üzerinde güçlü bir VPS veya dedicated sunucuyla yola çıkıp, zamanla kritik bileşenleri ayırarak HA’ya evrilmek, pratik ve maliyet anlamında dengeli bir yaklaşım oluyor.

Yüksek Erişilebilirlik Mimarileri: Uygulama, Veritabanı ve Ağ Katmanı

HA dendiğinde çoğu kişinin aklına sadece “iki sunucu olsun, biri düşerse diğeri devreye girsin” geliyor. Gerçekte, uygulama katmanı, veritabanı katmanı ve ağ/DNS katmanı birlikte tasarlanmadıkça gerçek anlamda yüksek erişilebilirlik elde etmek zor.

1. Uygulama Katmanında Yüksek Erişilebilirlik

İlk adım, uygulamanızı mümkün olduğunca stateless hale getirmek; yani oturum, dosya gibi durum bilgisini sunucunun diskine değil, merkezi bir yere taşımak:

• Oturum verisini Redis/Memcached gibi dış bir serviste tutmak
• Upload edilen dosyaları S3 uyumlu depolama veya paylaşımlı disk üzerinde saklamak
• Hazır olduğunda, birden çok uygulama sunucusunu yük dengeleyici arkasına almak

Bu noktada önünüzde iki tipik mimari olur:

• Active-active: Tüm uygulama sunucuları aynı anda trafiği karşılar. Bir tanesi düşerse load balancer otomatik olarak trafiği diğerlerine yönlendirir.
• Active-passive: Bir sunucu aktiftir, diğeri hazır bekler. Aktif sunucu düşerse pasif devreye girer. Yönetimi nispeten daha basittir.

2. Veritabanı Katmanında Yüksek Erişilebilirlik

Gerçek dönüşüm genelde burada başlar. Uygulamayı çoğaltmak görece daha kolaydır; kritik verinin taşındığı veritabanını çoğaltmak ve tutarlı tutmak ise daha zordur.

MySQL/MariaDB dünyasında HA için yaygın yaklaşımlar:

• Primary–Replica replikasyon: Tüm yazmalar bir primary sunucuya gider, okuma yükünün bir kısmı replikalara dağıtılır.
• Galera Cluster / Group Replication: MariaDB Galera Cluster ve MySQL Group Replication gibi çözümlerle çoklu node üzerinde senkron veya yarı senkron replikasyon.

E-ticaret ve SaaS projelerinde sık gördüğümüz yaklaşım, önce primary–replica ile başlamak, trafik ve ciro arttıkça cluster mimarilerine geçmektir. Burada kritik olan:

• Otomatik failover sürecinin iyi test edilmiş olması
• Split-brain (iki primary birden aktif olması) senaryolarına karşı korunmak
• Backupların cluster yapısına uygun tasarlanması

3. Depolama ve Dosya Katmanı

E-ticaret projelerinde ürün görselleri, SaaS’te kullanıcı dokümanları vb. dosyalar genelde tek sunucunun diskine yazılır. Uygulama sunucularını çoğaltmak istiyorsanız, bu dosyaların da yüksek erişilebilir olması gerekir:

• S3 uyumlu bir depolama (örneğin DCHost üzerinde S3 tarzı bir nesne depolama) kullanmak
• Paylaşımlı NFS / CEPH tarzı dağıtık depolama sistemleri
• Statik içerik için mutlaka CDN kullanmak

Bu mimariler, HA’nın “arka planda” kalan ama işin kırılma noktasını oluşturan kısmıdır. Depolama tarafı düşünülmemiş bir HA mimarisi, ilk ciddi arızada tatsız sürprizler yapar.

4. Ağ ve DNS Katmanı: Gerçek Failover Burada Başlıyor

Sunucu, veritabanı ve uygulama katmanını çoğaltmak önemli ama kullanıcı, DNS kayıtları üzerinden size ulaşıyor. Bu yüzden HA senaryolarında DNS ve ağ mimarisi kritik hale geliyor.

Anycast DNS ve otomatik failover konusunu detaylı anlattığımız yazıda olduğu gibi, özellikle çok bölgeli mimarilerde:

• DNS tabanlı sağlık kontrolleri
• Coğrafi yönlendirme (geo-routing)
• Ağırlıklı trafik dağıtımı

gibi özellikler devreye girer. Kritik SaaS uygulamalarında, bir bölgede yaşanan kısmi veri merkezi problemine rağmen diğer bölgede hizmet vermeye devam edebilmek için çok bölgeli mimariler fazlasıyla değerli hale gelir.

Maliyet Karşılaştırması: HA Kümesi mi Daha Güçlü Tek Sunucu mu?

Kararı verirken en sık yaptığımız hata, sadece “sunucu fiyatına” bakmak. Oysa HA, donanım maliyetinden çok daha fazlasını içeriyor.

Tek güçlü sunucunun maliyet profili

• Donanım: Yüksek CPU, RAM ve NVMe disk; genellikle tek bir güçlü dedicated sunucu veya yüksek kaynaklı VPS.
• Lisanslar: Panel (cPanel/Plesk), veritabanı vb. tek sunucu lisansı.
• Operasyon: Yönetilmesi görece basit; izleme, yedek, güvenlik katmanları yine gerekli.

Toplam maliyet kalem sayısı azdır, öngörmesi kolaydır. Buna karşılık donanım, ağ, disk gibi tüm bileşenler genellikle tekil hata noktasıdır.

HA kümesinin maliyet profili

• Çoklu sunucu: En az 2 uygulama + 2 veritabanı + 1 load balancer gibi kombinasyonlar (küçük HA kümelerinde bile 3–4 sunucu yaygındır).
• Ek ağ bileşenleri: Yük dengeleyiciler, VPN veya özel ağ altyapısı.
• Depolama: Dağıtık veya paylaşımlı depolama, nesne depolama, ek yedek katmanları.
• Operasyonel maliyet: Tasarım, kurulum, dokümantasyon, izleme, DR (felaket kurtarma) senaryolarının yazılması ve test edilmesi.

Buna karşılık eğer işiniz için dakikalar bile kritikse, HA’nın sağladığı daha az kesinti süresi genellikle kendini fazlasıyla amorti eder. Özellikle:

• Aylık altı haneli ciroya ulaşmış e-ticaret projeleri
• Ciddi kontrat ve SLA’lere sahip B2B SaaS ürünleri
• Kamu veya regüle sektörle çalışan uygulamalar

için HA, pazarlık götürmeyen bir gereklilik haline gelir.

Adım Adım Yol Haritası: Tek Sunucudan HA’ya Evrilmek

En sağlıklı yaklaşım, projeye HA kümesiyle başlamak zorunda hissetmemek ama başlangıçtan itibaren HA’ya geçişi düşünerek tasarlamak. DCHost tarafında birlikte çalıştığımız e-ticaret ve SaaS projelerinde çoğu zaman şu yolu izliyoruz:

1. Faz: Güçlü tek sunucuda sağlam temel

• Yeterli CPU, RAM ve NVMe diskli bir VPS veya dedicated sunucu
• Uygulama, veritabanı, cache ve dosya yükü bu sunucuda konumlandırılır
• İyi kurgulanmış yedekleme (3-2-1 prensibini ve 3-2-1 yedekleme stratejisini uygulamak önemli)
• İzleme ve alarmlar devreye alınır

2. Faz: Bileşenleri ayırmaya başlama

• Veritabanını ayrı bir sunucuya taşıma (veritabanı sunucusunu uygulama sunucusundan ayırmak burada kritik bir eşik)
• Statik dosyaları nesne depolama veya ayrı bir dosya sunucusuna taşıma
• CDN entegrasyonu ve cache stratejilerini olgunlaştırma

3. Faz: Uygulama katmanını çoğaltma

• En az iki uygulama sunucusu kurma (aynı veri tabanına bağlanan)
• Önlerine bir load balancer (HAProxy, Nginx vb.) yerleştirme
• Health check ve ağırlıklı yük dağıtımı kuralları tanımlama

4. Faz: Veritabanı HA ve DR senaryoları

• Primary–replica veya cluster yapısına geçiş
• Otomatik failover, split-brain koruması ve yeniden senkronizasyon senaryolarını test etme
• Uygulama tarafında bağlantı havuzu ve time-out ayarlarını optimize etme

5. Faz: Çok bölgeli mimari (gerekliyse)

• Kritik projeler için ikinci bir veri merkezinde sıcak/ılık yedek ortam
• DNS tabanlı coğrafi veya otomatik failover kuralları
• Veritabanı replikasyonu ve tutarlılık stratejilerinin belirlenmesi

Bu adımların her birini bir anda yapmak zorunda değilsiniz. Önemli olan, ilk günden itibaren kodunuzu, veritabanı şemanızı ve deploy süreçlerinizi HA’yı zorlaştırmayacak şekilde tasarlamak.

E-Ticaret ve SaaS İçin Karar Matrisi: Hangi Sorulara Ne Cevap Veriyorsunuz?

Karar vermenizi kolaylaştırmak için, DCHost’ta birlikte çalıştığımız projelerde kullandığımız basitleştirilmiş soruları paylaşalım. Her soruya dürüstçe verdiğiniz cevap, sizi tek sunucuya mı yoksa HA’ya mı daha yakın olduğunuzu gösterir:

• Aylık cironuz nedir ve 1 saatlik kesinti ortalama ne kadar gelir kaybı demek?
• Müşterilerinizle SLA taahhüdünüz var mı? Varsa yüzde kaç?
• Yılda kaç planlı bakım saati ayırabilirsiniz?
• Kesinti anında maksimum kabul edilebilir RTO (yeniden ayağa kalkma süresi) ve RPO’nuz (veri kaybı toleransı) nedir?
• Ekibinizde HA mimarisi yönetebilecek deneyime sahip bir kişi/ekip var mı?

Eğer “1 saatlik kesinti bizi çok zorlar”, “RPO 0’a yakın olmalı” ve “SLA’mız 99.9% üzeri” gibi cevaplar veriyorsanız, HA artık bir lüks değil zorunluluk demektir. Buna karşılık “Ayda bir iki saatlik kesinti kabul edilebilir, ürün henüz erken aşamada” diyorsanız, güçlü bir tek sunucu ile başlayıp adım adım HA’ya evrilmek çok daha sağlıklı bir seçim olacaktır.

DCHost ile Doğru HA Stratejisini Seçmek

Yüksek erişilebilirlik mi, yoksa güçlü tek sunucu mu sorusunun tek ve herkese uyan bir cevabı yok. Karar; ciro, risk iştahı, ekip yetkinliği ve büyüme hedeflerinizin kesişim noktasında şekilleniyor. Önemli olan, bugünkü ihtiyaçlarınızı karşılayan ama yarın HA’ya geçişinizi kilitlemeyen bir yol seçmek.

DCHost tarafında gördüğümüz en sağlıklı yol, projeleri genellikle şöyle konumlandırmak:

• Başlangıç ve düşük–orta ölçek için: Güçlü, iyi izlenen ve düzenli yedeklenen tek VPS veya dedicated sunucu
• Büyüyen, kampanya trafiği artan, SLA baskısı yükselen projeler için: Bileşenleri ayrılmış, adım adım HA’ya evrilen mimari
• Kritik e-ticaret ve B2B SaaS için: HA kümeleri, veritabanı replikasyonu, çok bölgeli yapı ve DNS failover stratejileri

Eğer “Bizim projeye özel nasıl bir yol izlemeliyiz?” diye düşünüyorsanız, en sağlıklısı iş tarafı verilerinizi (tahmini ciro, kullanıcı sayısı, büyüme hedefleri) ve teknik kısıtlarınızı masaya yatırarak birlikte bir mimari tasarlamak. DCHost ekibi olarak; ister tek güçlü sunucuyla başlayıp yavaş yavaş büyümeyi, ister direkt yüksek erişilebilirlik kümesine geçmeyi hedefleyin, size özel bir HA stratejisi kurgulamanıza yardımcı olabiliriz. Böylece hem bugünkü bütçenizi zorlamadan, hem de yarının kesinti risklerine hazırlıklı şekilde ilerleyebilirsiniz.