Yüksek Erişilebilir WordPress ve WooCommerce Küme Mimarisi

Yüksek Erişilebilir WordPress ve WooCommerce Neden Gündeme Geliyor?

WordPress ve WooCommerce ile çalışan projelerin önemli bir kısmı başlangıçta tek sunucu üzerinde, oldukça basit bir mimariyle yayına alınır. Zamanla trafik arttıkça, kampanyalar sıklaştıkça, sipariş hacmi büyüdükçe bu basit yapı bazı kritik soruları gündeme getirir: “Sunucu giderse ne olacak?”, “Bakım yaparken siteyi kapatmak zorunda mıyız?”, “Kampanya sırasında CPU %100 olursa ödeme sayfası çöker mi?”

Yüksek erişilebilirlik (High Availability, HA) tam bu noktada devreye girer. Amaç, WordPress veya WooCommerce sitenizi sadece hızlı değil, aynı zamanda kesintilere dayanıklı hale getirmektir. Yani tek bir sunucuya, tek bir diske, tek bir veritabanına bağımlı olmadan; bileşenleri çoğaltarak ve akıllı bir şekilde dağıtarak çalışmak.

Biz DCHost ekibi olarak, özellikle e-ticaret ve yüksek trafikli içerik sitelerinde, klasik tek sunucu modelinden küme (cluster) mimarisine geçişleri sıkça yönetiyoruz. WordPress ölçeklendirme yol haritası üzerine yazdığımız rehberde de anlattığımız gibi, ölçek büyüdükçe konu sadece daha fazla CPU/RAM eklemekten çıkar; mimariyi çoğaltma ve yedeklilik tasarımı öne çıkar.

Bu yazıda, yüksek erişilebilir WordPress ve WooCommerce için çok sunuculu hosting, ortak depolama ve veritabanı replikasyonu temelli pratik bir küme mimarisini konuşacağız. Gerçek projelerden öğrendiğimiz iyi/kötü örnekleri, sık yapılan hataları ve DCHost üzerinde uyguladığımız tipik mimari desenleri sade dille toparlayacağız.

Yüksek Erişilebilir Kümenin Temel Bileşenleri

Önce parçaları netleştirelim. Yüksek erişilebilir bir WordPress / WooCommerce kümesi genellikle şu katmanlardan oluşur:

• Ön uç (Load Balancer): Trafiği birden fazla web sunucusuna dağıtan katman.
• Uygulama/Web sunucuları: PHP-FPM ve web sunucusunun (Nginx, Apache, LiteSpeed vb.) çalıştığı WordPress düğümleri.
• Ortak dosya sistemi / medya depolama: Tüm düğümlerden erişilebilen wp-content (veya en azından uploads) yapısı.
• Veritabanı kümesi: MySQL/MariaDB (veya PostgreSQL) için replikasyon ya da cluster mimarisi.
• Önbellek ve oturum katmanı: Redis veya Memcached ile nesne önbelleği ve PHP/WordPress oturum yönetimi.
• Yedekleme, izleme ve otomasyon: Yedekler, loglar, alarmlar, CI/CD ve yapılandırma yönetimi.

Bu katmanların hepsinin aynı anda “hyper-enterprise” seviyede olması gerekmez. Birçok projede önce veritabanını ayırmak, sonra uygulama sunucusunu çoğaltmak, en son ortak dosya sistemi ve otomasyonlara geçmek gibi, adım adım ilerleyen bir yol haritası tasarlıyoruz.

Bu yazıda, tüm katmanların en az iki düğüme sahip olduğu, pratikte sık kullandığımız bir referans mimariyi baz alacağız.

Ortak Depolama: wp-content, Medya Dosyaları ve NFS Stratejisi

WordPress’i çok sunuculu çalıştırmanın kritik noktalarından biri dosya sistemidir. Kod tabanını (tema, eklentiler) CI/CD ile dağıtmak kolaydır; asıl mesele, dinamik üretilen içeriktir:

• uploads klasöründeki görseller ve dosyalar
• bazı eklentilerin ürettiği cache / rapor dosyaları
• bazı log veya geçici dosyalar

Bu dosyaların tüm uygulama sunucularından tutarlı ve eşzamanlı görülmesi gerekir. Temel yaklaşımlar:

1) Klasik NFS Paylaşımlı wp-content

En bilinen model, bir dosya sunucusunda wp-content (veya sadece uploads) klasörünü tutup, diğer WordPress düğümlerine NFS ile bağlamaktır. NFS, Linux dünyasında yıllardır kullanılan olgun bir dosya paylaşım protokolüdür. Detaylarına NFS, SSHFS ve rsync ile çok sunuculu dosya paylaşımı rehberimizde oldukça detaylı girmiştik.

Avantajları:

• WordPress tarafında ekstra eklenti veya büyük değişiklik gerektirmez.
• Tüm düğümler aynı dizini gördüğü için medya dosyalarıyla ilgili 404 veya tutarsızlık sorunları minimuma iner.

Dikkat edilmesi gerekenler:

• NFS sunucusu tek başına bir “tekil hata noktası” olabilir. Bunu yedekli disk, RAID, replikasyon veya dağıtık dosya sistemleriyle hafifletmek gerekir.
• IOPS ve gecikme süreleri iyi planlanmalıdır; aksi halde yüksek trafikli WooCommerce sitelerinde dosya sistemi darboga zı olabilir.

DCHost tarafında genellikle NVMe tabanlı depolama ve yedekli NFS sunucuları ile bu katmanı güçlendiriyoruz. Küçük/orta ölçekli kümelerde bile bu fark net hissediliyor.

2) Medya Dosyalarını Object Storage’a Offload Etmek

Daha modern yaklaşım, uploads klasörünü tamamen bir object storage (S3 uyumlu depolama) arkasına taşımaktır. Böylece:

• WordPress sadece URL üretir; dosyalar doğrudan object storage veya CDN üzerinden servis edilir.
• Uygulama sunucularında ortak dosya sistemi baskısı ciddi şekilde azalır.
• Çok bölgeli mimarilerde medya replikasyonu daha kolay hale gelir.

DCHost altyapısında S3 uyumlu depolama ile çalışan WordPress/WooCommerce kümelerinde, medya trafiğini büyük ölçüde bu katmana alıp web sunucularının CPU ve disk yükünü hafifletiyoruz. Object storage ve CDN ile medya offload detaylarını, medya offload stratejisi yazımızda ayrıca anlattık; burada sadece HA perspektifinden önemli noktayı vurgulayalım: web düğümünü kaybettiğinizde bile dosyalarınızın hayatta kalması.

3) rsync / Unison ile Yaklaşan Senkronizasyon

Daha basit projelerde bazen uploads klasörü her düğümde lokal tutulup, rsync veya benzeri araçlarla sık aralıklarla senkronize edilir. Bu yöntem bazı küçük/orta siteler için iş görse de, yüksek hacimli WooCommerce mağazalarında:

• Eşzamanlı yüklemelerde çakışma riskleri
• Senaryoların karmaşıklaşması (hangi düğüm ana?)
• Gerçek zamanlı olmama (son birkaç dakikanın tutarsız olabilmesi)

gibi sebeplerle nadiren öneriyoruz. Gerçek küme mimarilerinde NFS / dağıtık dosya sistemi veya object storage tabanlı çözümler çok daha sağlıklı çalışır.

Veritabanı Katmanı: Replikasyon, Cluster ve Tutarlılık

WooCommerce söz konusu olduğunda, veritabanı sadece bir içerik deposu değil, para hareketlerinin kaynağıdır. Bu yüzden yüksek erişilebilirlik tasarlarken veritabanı tarafında acele karar vermemek gerekiyor.

1) Primary–Replica (Master–Slave) Replikasyon Mimarisi

En yaygın ve yönetilebilir model, tek bir primary (yazma) sunucu ve bir veya birden çok replica (okuma) sunucu kullanmaktır:

• Tüm yazma işlemleri (sipariş, kullanıcı, stok güncelleme) primary üzerinde gerçekleşir.
• Raporlama, istatistik veya bazı önbellek ısınma işlerini replica’lara kaydırmak mümkündür.
• Primary sunucu arızalanırsa, kontrollü bir şekilde replica’dan yeni primary yükseltilebilir.

Burada kritik konu, replikasyonun senkron mu asenkron mu olduğu ve failover senaryosunda ne kadar veri kaybını (RPO) göze alabildiğinizdir. Bazı MariaDB/MySQL yapılandırmalarında yarı senkron (semi-sync) replikasyon ile veri kaybı riski azaltılabilir.

Bu mimarinin WooCommerce tarafındaki avantaj ve dezavantajlarını, ayrıca Galera gibi cluster seçenekleri ile farklarını MariaDB yüksek erişilebilirlik rehberimizde ayrıntılı olarak anlattık. Burada WordPress/WooCommerce özelinde özetleyelim:

• Sipariş tutarlılığı kritikse, çoğu durumda primary-replica + sağlam yedekleme doğru başlangıç noktasıdır.
• Çok düğümlü yazma gerektiren, çok bölgeli dev cluster’lar çoğu işletme için gereksiz karmaşıklık düzeyindedir.

2) Galera Cluster ve Multi-Primary Senaryolar

Galera Cluster (veya MySQL Group Replication) gibi çözümlerle aynı anda birden fazla düğüme yazma yapılabilen cluster yapıları kurmak mümkündür. Ancak WooCommerce gibi uygulamalarda:

• Lock, deadlock ve write conflict senaryoları doğru yönetilmezse performans dalgalanmaları görülebilir.
• Uygulama düzeyinde bağlantı havuzu ve write-split mimarisi iyi tasarlanmalıdır.

Bu tarz mimarileri genellikle çok yüksek hacimli ve birden fazla veri merkezine yayılmış projelerde öneriyoruz. Küçük ve orta ölçekli WooCommerce projeleri için, iyi ayarlanmış primary–replica + sağlam yedekleme stratejisi hem daha basit hem de operasyonel olarak daha güvenlidir.

3) Veritabanı İçin Operasyonel Kurallar

İster primary–replica, ister cluster kullanın; aşağıdaki kurallar neredeyse değişmez:

• Yedekler mutlaka ayrı bir depolama katmanına ve tercihen farklı bir veri merkezine aktarılmalı.
• Yedekler düzenli olarak geri yükleme testi ile doğrulanmalı.
• Replikasyon gecikmesi (replication lag) izlenmeli ve alarm eşikleri tanımlanmalı.
• Uzun süren sorgular tespit edilip indeksleme/optimizasyon yapılmalı.

Biz DCHost’ta WooCommerce kümelerinde, veritabanı için ayrı yüksek performanslı VPS veya dedicated sunucular kullanmayı, replikasyon ve yedeklemeyi bu katmanda konumlandırmayı tercih ediyoruz. Uygulama düğümlerinin çökmesi, yeniden kurulması veya yeniden ölçeklenmesi bu sayede çok daha az riskli hale geliyor.

Uygulama Katmanı: PHP, Önbellek ve Oturum Yönetimi

Yüksek erişilebilir bir WordPress kümesinde, her bir uygulama düğümü mümkün olduğunca stateless (durumsuz) olmalıdır. Yani belirli bir kullanıcının oturumu, sepeti veya cache’i sadece tek bir sunucuya bağlı olmamalı.

1) PHP Session ve WooCommerce Sepetleri

Varsayılan PHP ayarlarında oturumlar (session) genellikle dosya sistemi üzerinde tutulur. Tek sunuculu yapıda sorun değil; ancak iki veya daha fazla uygulama düğümü olduğunda şöyle problemler ortaya çıkar:

• Kullanıcı load balancer yüzünden farklı isteklerde farklı düğüme düşer.
• Oturum dosyası sadece bir düğümde olduğundan diğer düğümde kullanıcı çıkış yapmış gibi görünür.

Bunu çözmek için:

• PHP session handler’ı dosya sisteminden Redis veya Memcached gibi paylaşımlı bir depoya taşımak,
• veya load balancer tarafında sticky session (oturum yapışkanlığı) kullanmak

gerekir. Yüksek erişilebilirlik açısından en temiz çözüm genelde Redis tabanlı oturum yönetimidir; böylece bir düğüm kaybedildiğinde kullanıcı oturumları başka düğümlerde devam edebilir.

2) Nesne Önbelleği (Object Cache)

WordPress ve WooCommerce performansında object cache katmanı çok kritik. Özellikle ürün sorguları, menüler, ayarlar ve eklenti verileri için veritabanı yükünü ciddi şekilde hafifletir. Burada yaygın iki seçenek var: Redis ve Memcached.

Detaylı kıyaslamayı WordPress ve WooCommerce için Redis mi Memcached mi? rehberimizde anlattık; özetle:

• Redis: Veriyi disk üzerinde de tutabilmesi, script desteği ve gelişmiş veri yapılarıyla daha esnek.
• Memcached: Sadece RAM’de tutulan, çok hafif ve basit bir key-value store.

Yüksek erişilebilir küme senaryolarında çoğunlukla Redis tercih ediyoruz; çünkü hem oturum hem de object cache için ortak bir katman kurulabiliyor. Redis tarafında da sentinel, replikasyon ve gerekirse cluster ile tekil hata noktası riskini düşürüyoruz.

3) Tam Sayfa Önbellek ve WooCommerce Özel Alanları

Statik sayfalar ve blog içerikleri için tam sayfa önbellek (full-page cache) kullanmak çok büyük performans kazanımları sağlar. Ancak WooCommerce’de:

• Sepet, ödeme, hesap sayfaları
• Dinamik fiyat/indirim gösteren bölümler

özel muamele ister. Bu sayfaların cache edilmemesi veya kullanıcıya göre özelleştirilmesi gerekir.

Nginx FastCGI Cache, Varnish veya LiteSpeed Cache gibi çözümlerle, cache kurallarını WooCommerce’in dinamik sayfalarına saygı duyacak biçimde tasarlamak gerekiyor. DCHost üzerinde yönettiğimiz kümelerde genellikle:

• Blog, kurumsal sayfalar, kategori sayfaları için agresif cache
• Sepet ve ödeme için cache bypass
• Mobil/masaüstü gibi varyasyonlar için uygun cache-key tasarımı

uyguluyoruz.

Load Balancer, SSL ve Trafik Dağıtımı

Çok sunuculu WordPress ve WooCommerce mimarisinde ziyaretçinin ilk temas ettiği nokta genellikle bir load balancer olur. Bu, ayrı bir VPS/dedicated, donanım load balancer veya bazı durumlarda reverse proxy görevinde bir Nginx sunucu olabilir.

1) L4 vs L7 Load Balancing

Genel olarak iki seviye vardır:

• L4 (TCP) yük dengeleme: IP ve port düzeyinde trafik dağıtır; protokolün içini bilmez. Genellikle daha basittir ve çok yüksek performanslıdır.
• L7 (HTTP) yük dengeleme: URL, host header, cookie gibi bilgileri okuyabilir; path bazlı yönlendirme, A/B test, canary deployment gibi gelişmiş senaryolara izin verir.

WooCommerce kümelerinde çoğu zaman L7 (HTTP/S) load balancer kullanmak daha esnektir; çünkü:

• wp-admin veya /api isteklerini farklı havuzlara gönderebilirsiniz.
• Sağlık kontrolü (health check) için özel URL’ler tanımlayabilirsiniz.
• Gerekirse bazı IP aralıklarına farklı kurallar uygulayabilirsiniz.

2) SSL Nerede Sonlandırılmalı?

İki temel yaklaşım var:

• SSL’i load balancer üzerinde sonlandırmak: Ziyaretçi ile LB arasındaki trafik şifrelenir, LB ile uygulama düğümleri arasındaki trafik HTTP olabilir.
• Uçtan uca şifreleme (end-to-end TLS): LB sadece passthrough yapar veya hem LB’de hem backend’de SSL vardır.

Güvenlik ve regülasyon (PCI DSS vb.) seviyenize bağlı olarak, özellikle ödeme sayfalarında uçtan uca şifrelemeyi tercih etmek daha doğru olabilir. Performans açısından modern CPU’lar ve TLS 1.3 ile bu ek yük çoğu zaman kabul edilebilir seviyededir.

DCHost altyapısında, HTTP/2 ve HTTP/3 (QUIC) desteğiyle birlikte çalışan SSL yapılarını sıkça kuruyoruz; böylece hem güvenlik hem de Core Web Vitals tarafında avantaj sağlanıyor.

3) Health Check ve Failover Mantığı

Yüksek erişilebilirlik için sadece birden fazla sunucuya sahip olmak yetmez; bu sunucuların sağlık durumunu izleyip sorunlu düğümleri trafiğin dışına alabilmek gerekir. Load balancer seviyesinde tipik olarak:

• Belirli bir path (örneğin /healthz.php) üzerinden HTTP 200 beklenir.
• Belirli sayıda başarısız denemeden sonra düğüm “down” kabul edilir.
• Düğüm tekrar sağlığına kavuştuğunda kontrollü olarak havuza alınır.

Bu mekanizma sayesinde, bir uygulama düğümünde PHP çökse, disk dolsa veya deploy sırasında geçici hatalar oluşsa bile, ziyaretçilerin önemli bir kısmı sorunsuz düğümlere yönlendirilmeye devam eder.

DevOps Boyutu: Deploy, Sürüm Yönetimi ve Sıfır Kesinti

Yüksek erişilebilir WordPress/WooCommerce kümesinde işin bir de operasyonel tarafı var: Yeni sürümleri, tema güncellemelerini, WooCommerce ve eklenti yükseltmelerini kesinti yaratmadan yayınlamak.

1) Blue-Green ve Canary Dağıtım

Klasik yaklaşımda tek sunucuda güncelleme yaparsınız; hata olursa tüm site etkilenir. Küme mimarisinde ise şöyle bir lüksünüz var:

• Yeni sürümü önce yeşil ortamda (green) hazırlayıp test etmek,
• Ardından trafiği mavi (blue) ortamdan yeşile kademeli olarak almak,
• Hata durumunda saniyeler içinde eski sürüme geri dönmek.

Bunu detaylı olarak blue-green deployment ile WooCommerce güncellemeleri yazımızda anlattık. Yüksek erişilebilir mimarilerde, özellikle:

• WooCommerce çekirdeği
• Ödeme eklentileri
• Cache ve güvenlik eklentileri

gibi kritik bileşenleri güncellerken bu stratejileri kullanmak, üretim ortamında büyük rahatlık sağlıyor.

2) CI/CD ve Konfigürasyon Yönetimi

Birden fazla WordPress düğümü olduğunda “SSH ile girip elle dosya kopyalamak” sürdürülebilir değildir. Tipik olarak:

• GIT tabanlı bir repo (tema, custom eklentiler, muhtemelen wp-core harici kod)
• CI/CD pipeline (GitHub Actions, GitLab CI, vb.)
• Her deploy’da versiyon klasörleri ve sembolik link kullanımı

tasarlamak gerekir. Bu sayede:

• Tüm düğümler aynı kod sürümünü çalıştırır.
• Geri alma (rollback) saniyeler içinde yapılabilir.
• Konfigürasyon farkları minimize edilir.

DCHost üzerinde yönettiğimiz kümelerde, deploy işlemlerini genellikle bir “orchestration” sunucusu veya CI sistemi üzerinden otomatikleştiriyoruz. Böylece insan hatası riski ciddi oranda düşüyor.

3) İzleme, Loglama ve Alarm

Yüksek erişilebilir bir mimarinin gerçekten “yüksek erişilebilir” olup olmadığını anlamanın yolu, izleme ve alarmlardır. Önerdiğimiz temel metrikler:

• Her WordPress düğümü için CPU, RAM, disk IO, network
• Veritabanı için sorgu süresi, bağlantı sayısı, replikasyon gecikmesi
• Redis veya diğer önbellekler için hit/miss oranları
• HTTP hata oranları (4xx/5xx) ve TTFB

Bunlara ek olarak, Uptime Kuma veya benzeri araçlarla dışarıdan uptime izlemesi yapmayı da mutlaka öneriyoruz. Kendi durum sayfanızı nasıl kurabileceğinizi uptime izleme rehberimizde adım adım anlattık.

DCHost Üzerinde Örnek WordPress / WooCommerce Küme Senaryosu

Şimdi tüm bu parçaları somutlaştırmak için, DCHost altyapısında sıkça kurduğumuz tipik bir mimariyi özetleyelim. Amaç: Aylık birkaç yüz bin ziyaretçi ve günde yüzlerce sipariş alan bir WooCommerce sitesi.

• 1 adet Load Balancer VPS: Nginx veya HAProxy ile HTTP/HTTPS trafiğini dağıtır, health check yapar.
• 2–3 adet Uygulama VPS’i: Nginx + PHP-FPM ile WordPress/WooCommerce çalıştırır, kod tabanı CI/CD ile senkronize edilir.
• 1 adet Veritabanı Primary VPS: Yüksek IOPS’lu NVMe diskler üzerinde MariaDB/MySQL.
• 1 adet Veritabanı Replica VPS: Primary’den replikasyon alır, raporlama ve failover için hazır bekler.
• 1 adet Redis VPS: Hem session hem object cache için merkezi katman.
• NFS veya Object Storage: uploads ve gerekli wp-content alt klasörleri için ortak depolama.

Bu mimaride herhangi bir uygulama VPS’ini kaybettiğinizde site tamamen çökmez; load balancer diğer düğümlere devam eder. Veritabanı tarafında primary için problem yaşarsanız, kontrollü bir şekilde replica’yı primary yapıp yola devam edebilirsiniz. Storage katmanında da yedekli disk ve düzenli snapshot ile dosya tarafındaki riskleri azaltırsınız.

Daha büyük projelerde, bu mimariyi dedicated sunucu veya colocation altyapısına taşıyıp, veritabanı ve depolama katmanlarını daha da özelleştiriyoruz. Ancak mantık değişmiyor: tekil hata noktalarını azaltmak, bileşenleri çoğaltmak ve hepsini gözlemlenebilir hale getirmek.

Adım Adım Yol Haritası: Tek Sunucudan Küme Mimarisine Geçiş

Birçok müşterimiz için en sağlıklı yaklaşım, “bir gecede tam HA cluster” yerine aşamalı geçiş oluyor. Önerdiğimiz tipik sıralama:

1. Veritabanını ayır: WordPress kurulumunu ve veritabanını farklı sunuculara böl. Bu adım bile performans ve yönetilebilirlikte büyük fark yaratır.
2. Önbellek ve oturum katmanını merkezi hale getir: Redis kurup session ve object cache’i buraya taşı.
3. İkinci uygulama sunucusunu ekle: Kod dağıtımını CI/CD ile otomatikleştir, her iki düğümü de load balancer arkasına al.
4. Ortak depolamayı devreye al: NFS veya object storage ile uploads klasörünü paylaşımlı hale getir.
5. Veritabanı replica ve yedek stratejisini kur: Primary–replica replikasyon ve düzenli geri yükleme testleri.
6. İzleme ve alarm katmanını tamamla: Hem içeriden (metrikler) hem dışarıdan (uptime) izleme.

Bu süreç boyunca, her adımı ölçerek ilerlemek çok önemli. Örneğin bir aşamada sadece veritabanını ayırırsınız; CPU, RAM, TTFB ve sipariş tamamlama sürelerindeki değişimi izler, sonraki adımı ona göre planlarsınız.

Sonuç ve DCHost ile Sonraki Adım

Yüksek erişilebilir WordPress ve WooCommerce küme mimarisi, kulağa ilk bakışta çok karmaşık gelebilir. Aslında işin özü, parçaları doğru sırayla ele almakta:

• Veritabanını merkezileştirip yedekleri sağlam almak,
• Uygulama katmanını çoğaltıp stateless hale getirmek,
• Dosya sistemini ve medyayı tekil arıza noktası olmaktan çıkarmak,
• Önbellek, load balancer ve izleme ile tüm yapıyı olgunlaştırmak.

DCHost olarak, hem NVMe VPS hem dedicated hem de colocation altyapımız üzerinde, bu bileşenleri projeye ve bütçeye göre birlikte tasarlıyoruz. İster yeni açacağınız WooCommerce mağazası için geleceğe dönük bir mimari kurmak isteyin, ister mevcut yoğun sitenizi tek sunucudan kümeye taşımayı planlayın; adım adım, ölçerek ve geri dönüşü mümkün olacak şekilde ilerlemek mümkün.

Eğer şu anda tek sunuculu bir WordPress/WooCommerce kurulumunuz varsa ve “Bir sonraki adımı atmanın zamanı geldi mi?” diye düşünüyorsanız, sitenizin trafik, kaynak kullanımı ve büyüme hedeflerine birlikte bakıp sizin için en mantıklı küme mimarisini planlayabiliriz. DCHost teknik ekibi olarak; kapasite analizi, mimari tasarım, test ortamı kurulumu ve canlıya geçiş aşamalarını uçtan uca birlikte yönetmek üzere buradayız.