E-Ticaret Sunucu Kiralama: Performans ve Güvenlik

E-ticaret sunucu kiralama, yalnızca web sitesinin açıldığı bir sanal makineyi seçmek değildir. Ürün arama, sepet güncelleme, ödeme, stok entegrasyonu, kampanya ve raporlama aynı anda çalışırken hangi katmanın darboğaz oluşturacağını belirlemek gerekir. Yavaşlayan bir ürün sayfası müşteri deneyimini etkileyebilir; fakat ödeme akışında oluşan hata doğrudan işlemin tamamlanmasını engeller. Bu nedenle işletmeler için en doğru sunucu, ölçülen iş yükünü güvenli biçimde karşılayan ve büyümeye göre genişleyebilen altyapıdır.

Kısa cevap: WooCommerce, Magento Open Source veya Adobe Commerce kullanan işletmeler; PHP ve veritabanı sürüm uyumluluğunu, gerçek eş zamanlı oturumları, CPU/RAM kullanımını, disk gecikmesini, önbellek mimarisini, ödeme güvenliğini ve kurtarma hedeflerini birlikte değerlendirmelidir. VPS bazı mağazalar için yeterliyken yüksek ve sürekli yüklerde dedicated sunucu veya birden fazla katmandan oluşan mimari anlamlı olabilir. Karar, yalnız ziyaretçi sayısıyla verilmemelidir.

1. Platformunuzun gerçek teknik gereksinimlerini belirleyin

Önce mağazanın tam ürününü, sürümünü, eklentilerini ve dış entegrasyonlarını kaydedin. WooCommerce için WordPress, PHP, MySQL veya MariaDB sürümleri; ödeme ve kargo eklentilerinin destek durumu önemlidir. Üreticinin resmî WooCommerce sunucu önerileri sürüme göre değişebilen koşulları açıklar. Eski bir PHP sürümü yalnız hız sorunu değil, güvenlik ve destek riski de yaratabilir. Üretici önerilerini kontrol ederken canlı mağazanın kritik eklentilerinin bu sürümleri desteklediğini ayrıca doğrulayın.

Magento Open Source ve Adobe Commerce tarafında uygulama sunucusuna ek olarak arama servisi, veritabanı, kuyruk, önbellek ve planlı görevlerin uyumu değerlendirilir. Adobe'nin güncel sistem gereksinimleri tablosu her sürüm için test edilmiş bileşenleri listeler; farklı sürümlerden rastgele bileşen seçerek birleşik kurulumun desteklendiği varsayılmamalıdır.

Başlangıç envanterinde uygulama sürümü, günlük sipariş, ürün ve varyant sayısı, aktif eklentiler, entegrasyon servisleri, kullanılan veritabanı motoru, medya büyüklüğü ve trafik kaynakları bulunmalıdır. Böylece sunucu teklifini mağazanın gerçek iş yüküne bağlayabiliriz.

2. Ziyaretçi sayısı yerine eş zamanlı işlemleri ölçün

Bir ayda yüz bin ziyaret alan iki mağazanın kaynak ihtiyacı farklı olabilir. İlk mağaza çoğunlukla önbellekten ürün sayfası sunarken, diğeri kişiselleştirilmiş filtreler, stok sorguları ve yoğun ödeme işlemleri yapabilir. Toplam aylık trafik değil, yoğun dakikalardaki eş zamanlı dinamik istek ve veritabanı davranışı kapasite kararını daha iyi yönlendirir.

Sunucu seçimi öncesi normal gün, kampanya başlangıcı, maaş dönemi veya özel indirim anları ayrı ölçülmelidir. HTTP yanıt sürelerini ortalama yerine p95/p99 gibi yüzdeliklerle incelemek kuyruk ve ani yavaşlama sorunlarını görünür kılar. Uygulama işlem süresi, PHP-FPM worker doluluğu, veritabanı sorgu süresi, disk beklemesi, CPU ve RAM kullanımını aynı zaman aralığında kaydedin.

Google Analytics ziyaretçiyi ve dönüşümü yorumlamak için değerlidir; ancak sunucu darboğazı için APM, web sunucusu logları ve veritabanı ölçümleri gerekir. Beklenmedik bir sipariş trafiği artışında sistemin nasıl davrandığını görmek üzere üretim verilerini riske atmayan yük testleri yapılabilir.

3. VPS mi dedicated sunucu mu: doğru seçim nerede değişir?

VPS ve bulut sunucu kiralama, kaynakları kademeli genişletmek isteyen ve uygulamanın sanallaştırmaya uygun olduğu işletmeler için iyi bir başlangıç olabilir. Dedicated sunucu ise ayrılmış fiziksel kaynak, özel donanım veya yoğun ve sürekli işlem yükü gerektiren projelerde değerlendirilir. Fakat sunucu tipinin adı tek başına hızlı SSD, otomatik yedek veya kesintisiz hizmet sözü değildir.

Örneğin günde az sayıda sipariş alan bir WooCommerce mağazası için gereğinden büyük fiziksel sunucu kiralamak maliyeti artırabilir. Buna karşılık çok sayıda eş zamanlı ürün filtresi, entegrasyon ve raporlama yapan mağaza için en düşük fiyatlı VPS verimli olmayabilir. Dedicated sunucu kiralama seçeneğini kıyaslarken aynı yedek, firewall, ağ, yönetim ve destek kapsamını esas alın.

4. Web uygulaması ile veritabanı iş yükünü ayırın

Mağazanın ön yüzüyle sipariş, stok ve müşteri verilerinin işlenmesi aynı yük türü değildir. Yavaş bir ürün sayfası her zaman daha fazla CPU gerektiğini göstermez; ağır SQL sorguları, eksik indeksler veya harici servis gecikmeleri de etken olabilir. Önce darboğazı katmanına göre ölçün.

Başlangıçta tek sunucu kullanılan bir kurulum, büyüme arttığında uygulama ve veritabanını ayrı kaynaklara taşıyabilir. Bunun artısı kaynak sınırlarını daha kolay yönetmektir; eksisi ağ gecikmesi, yedek koordinasyonu, güvenlik politikaları ve işletim karmaşıklığıdır. Ayrıştırma otomatik performans kazancı sağlamaz.

Veritabanında yavaş sorgular, kilitlenme, bağlantı havuzu tüketimi, disk okuma/yazma beklemeleri ve replikasyon gereksinimleri analiz edilmelidir. Sipariş ve ödeme verilerinde tutarlılık önemli olduğundan yalnızca okuma kopyalarına geçmenin uygulamanın her sorgusu için güvenli olduğu varsayılmamalıdır.

5. Önbellek ve CDN planında sepeti koruyun

Statik görsel, CSS ve JavaScript dosyalarının CDN üzerinden sunulması istemciye yakın teslimat sağlayabilir. Uygun sayfalarda tam sayfa önbelleği de uygulama yükünü azaltır. Ancak sepet, ödeme, oturum ve kişiye özel stok/fiyat alanları herkese aynı içeriğin sunulduğu bir önbelleğe yanlışlıkla girerse ciddi kullanıcı deneyimi ve gizlilik sorunları doğabilir.

WooCommerce için sepet ve ödeme uçlarının önbellek dışı tutulması, oturum çerezlerinin doğru ele alınması gerekir. Magento/Adobe Commerce tarafında da platformun desteklediği önbellek invalidation ve dinamik içerik mekanizmaları izlenmelidir. Redis veya Valkey gibi bellek içi servisler kullanılacaksa üretici destek matrisi, bellek sınırı ve erişim kontrolü doğrulanmalıdır.

CDN, WAF ve nesne önbelleği ayrı katmanlardır. CDN tek başına yavaş veritabanı sorgularını çözmez; WAF ise hatalı eklentinin ürettiği açıkları tamamen ortadan kaldırmaz. Uygulama izlemesiyle birlikte çalışmaları gerekir.

6. Ödeme ve müşteri verilerinde güvenlik öncelikleri

E-ticaret altyapısında HTTPS zorunlu başlangıçtır; doğru TLS yapılandırması, güvenlik başlıkları ve oturum çerezleri de değerlendirilmelidir. Yönetim panelini ve veritabanı portlarını internete gereksiz yere açmayın. Yönetici erişimini MFA ve mümkünse VPN veya IP kısıtlamasıyla koruyun. Oturum açma, ödeme ve hesap kurtarma gibi hassas işlemlerde hız sınırı ve bot kontrolü tasarlayın.

Ödeme hizmeti sağlayıcısı kullanmak, mağazanın bütün güvenlik sorumluluklarının ortadan kalktığı anlamına gelmez. Kart verisinin mağaza sistemine girip girmediği, yönlendirme veya gömülü ödeme formunun mimarisi, PCI DSS değerlendirme kapsamını değiştirebilir. Uygun kapsam ödeme sağlayıcısı ve yetkin uyum danışmanıyla doğrulanmalıdır; bu makale uyumluluk sertifikası yerine geçmez.

İşletim sistemi, WordPress/eklenti veya Commerce paketleri güncellenirken sürüm uyumluluğu ve geri dönüş planı önemlidir. Güvenlik yamalarını plansız uygulamak yerine test, bakım penceresi ve geri alma adımlarını birlikte düzenleyin. Müşteri ve sipariş verileri için yetkili erişim, log saklama ve KVKK sorumlulukları ayrıca ele alınmalıdır.

7. Ödeme dışındaki entegrasyonları da haritalayın

E-fatura, ERP, pazar yeri, kargo, stok, e-posta, SMS ve ödeme sağlayıcıları uygulamanın dış bağımlılıklarıdır. Mağaza hızlı yanıt verse bile başarısız kuyruk işleri, stok senkronizasyonu veya kargo bildirimi sipariş sürecini aksatabilir. Teklifi yalnız web sunucusuna göre hazırlamak bu yükleri görünmez kılar.

Zamanlanmış görevler ve kuyruk işleyicileri için ayrı CPU/RAM bütçesi ayırmak gerekebilir. Geciken görev, başarısız ödeme bildirimi ve tekrar eden sipariş işlemi için idempotency kontrolleri tasarlanmalıdır. Harici API erişim kısıtları, sabit çıkış IP'si, firewall izinleri ve bağlantı zaman aşımı stratejileri de kayıt altına alınmalıdır.

Uygulama sürümü veya veri merkezi değişikliğinde tüm entegrasyonları uçtan uca denemek gerekir. Sadece anasayfanın açılması mağazanın sipariş kabulüne hazır olduğu anlamına gelmez.

8. Yedekleme stratejisini sipariş tutarlılığına bağlayın

Her gece dosya kopyalamak tek başına yeterli değildir. Sipariş veritabanı, ürün medyası, yapılandırmalar, cron ve kuyruk durumları tutarlı bir kurtarma planıyla ele alınmalıdır. İşletmenin kabul edebildiği veri kaybı (RPO) ile yeniden hizmete dönüş hedefi (RTO) önceden tanımlanmalıdır.

Örneğin yoğun sipariş saatinde veritabanının birkaç saat eski yedeğine dönmek, ödeme sağlayıcısında tamamlanmış işlemler ile mağazada görünen siparişler arasında fark oluşturabilir. Bu nedenle yalnızca yedek dosyasının varlığı değil; işlem tutarlılığı, geri yükleme süresi ve üçüncü taraf sistemlerle mutabakat adımları test edilmelidir.

Yedeklerin üretimden ayrı tutulması, yetkilerinin sınırlandırılması ve uygun durumlarda değiştirilemez veya erişimi kısıtlı kopyalar oluşturulması fidye yazılımı riskine karşı yararlıdır. Ancak bu özellikler sağlayıcıdan teyit edilmeden teklifte varmış gibi yazılmamalıdır.

9. Sunucu taşıma ve sürüm yükseltme için kontrollü geçiş

Yeni bir e-ticaret ve web uygulamaları sunucu çözümü planlarken önce DNS, SSL, veri boyutu, dosya ve veritabanı erişimi, eklentiler, webhook'lar, e-posta gönderimi ve ödeme entegrasyonlarını envantere alın. Test ortamında yeni sunucuyla uygulamanın desteklenen sürüm kombinasyonunu doğrulayın.

Ardından kısa süreli kesinti ihtimali, veri eşitleme modeli ve geri dönüş koşulları belirlenir. Taşıma günü ürün görüntüleme, sepete ekleme, kupon, ödeme onayı, sipariş kaydı, stok düşümü, kargo tetikleme ve yönetici raporu gerçekçi test senaryoları üzerinden incelenir. Mümkünse test işlemleri üretim müşterilerini etkilemeyecek şekilde yürütülür.

DNS değişiminin tamamlanması ile tüm kullanıcıların aynı sürüme ulaşması aynı anda gerçekleşmeyebilir. Bu nedenle trafik yönlendirme, CDN önbelleği ve eski sunucuya geri dönme kararını önceden tasarlamak gerekir. Kesintisiz geçiş garanti edilmez; riski azaltmaya yönelik doğrulanabilir plan uygulanır.

10. Teklif karşılaştırmasında hangi kalemler bulunmalı?

Aynı vCPU ve RAM değerini sunan iki sağlayıcının yönetim kapsamı farklı olabilir. Karşılaştırma yaparken aylık sunucu ücretinin yanında diskin türü ve beklenen I/O performansı, yedek sıklığı, trafik/bant genişliği, firewall ve WAF, SSL yönetimi, işletim sistemi bakımı, destek saatleri ve olay müdahalesini ayrı yazdırın.

Teklifte gerçek olmayan uptime oranı veya tüm projelere uygun tek bir fiyat söylemek yerine teknik keşifle kapsamı belirlemek daha sağlıklı sonuç verir. İşletmenin mevcut e-ticaret platformunu ve satış yoğunluğunu paylaşması ilk kapasite çalışmasını hızlandırır.

Sık sorulan sorular

1. WooCommerce için VPS yeterli olur mu?

Birçok küçük ve orta ölçekli mağazada doğru yapılandırılmış VPS yeterli olabilir. Ancak eş zamanlı dinamik oturum, ürün filtresi, eklenti yükü, önbellek ve veritabanı gecikmesi ölçülmeden kesin kapasite söylenemez. Büyümeye göre kaynak artırma seçeneği planlanmalıdır.

2. Magento veya Adobe Commerce için mutlaka dedicated sunucu gerekir mi?

Hayır. Desteklenen sanallaştırma veya bulut mimarisi de değerlendirilebilir. Platform sürümünün veritabanı, arama, kuyruk ve önbellek gereksinimlerini karşılamak önemlidir. Dedicated seçiminde izolasyon ve sürekli yük de maliyetle birlikte değerlendirilmelidir.

3. CDN kullanmak sunucu ihtiyacını tamamen ortadan kaldırır mı?

Hayır. CDN statik içerik ve uygun önbellekli sayfalarda trafik yükünü azaltabilir; sepet, ödeme, hesap, stok veya kişiselleştirilmiş dinamik işlemler sunucu ve veritabanı kaynaklarına ihtiyaç duymaya devam eder. Önbellek kurallarının yanlış uygulanması ayrı risk oluşturur.

4. Sipariş yoğunluğunda hangi performans değerlerini izlemeliyiz?

İstek gecikmesinin p95/p99 değerleri, hata oranı, dinamik istek sayısı, PHP worker tüketimi, CPU, RAM, disk gecikmesi, yavaş SQL sorguları, kuyruk uzunluğu ve harici servis yanıt süreleri birlikte izlenmelidir. Tek bir CPU yüzdesi bütün darboğazı anlatmaz.

5. Ödeme altyapısı için PCI DSS uyumluluğu otomatik sağlanır mı?

Hayır. Ödeme sağlayıcısı entegrasyonu, kart verisinin hangi sistemlerden geçtiği, mağaza uygulamasının güvenliği ve iş süreçleri uyum kapsamını etkiler. Sunucu kiralamak veya SSL kurmak tek başına PCI DSS uyumlu olunduğunu göstermez; gerekli denetimler ayrıca yapılır.

6. Sunucu taşırken müşterilerin sepeti veya siparişi kaybolabilir mi?

Kontrolsüz taşıma, oturum veya veritabanı tutarsızlığı riski taşır. Veri eşitleme, değişim penceresi, ödeme mutabakatı ve geri dönüş planı önceden belirlenmelidir. Önemli iş akışları test edilmeden sıfır kesinti veya sıfır veri kaybı sözü verilmemelidir.

7. E-ticaret sunucu kiralama teklifinde hangi bilgileri paylaşmalıyız?

Platform ve sürümü, ürün/varyant sayısı, günlük ve yoğun saat siparişleri, trafik/kampanya profili, aktif eklentiler, ödeme ve ERP entegrasyonları, veritabanı boyutu, mevcut performans sorunu, güvenlik beklentisi, yedekleme hedefi ve geçiş takvimi doğru başlangıç girdileridir.

Mağazanız için doğru sunucu mimarisini birlikte belirleyelim

E-ticaret altyapısında tek bir hazır paket yerine müşteri deneyimi, sipariş sürekliliği, veri güvenliği ve ölçülmüş iş yükü birlikte ele alınmalıdır. Netsun Bilişim ile mevcut WooCommerce, Magento veya Adobe Commerce kurulumunuzu değerlendirirken gereken sunucu kapasitesini, yedekleme yöntemini, güvenli erişimi ve yönetim sorumluluklarını açık bir plan halinde netleştirebilirsiniz.

Mevcut mağazanızı, yaklaşık yoğun saat trafiğinizi ve varsa performans sorununuzu belirtin; e-ticaret sunucu kiralama için teklif talebi oluşturun. Satın alma kararı öncesinde canlı sürümün teknik gereksinimleri ve hizmet koşulları ayrıca doğrulanmalıdır.