Barındırma (Hosting) Seçimi: Paylaşımlı, VPS, Bulut, Edge

"Hangi hosting daha iyi?" sorusunun tek bir cevabı yok. Aynı kurumsal site, bir yapıda sorunsuz çalışırken başka bir yapıda her ay güncelleme ve güvenlik işi çıkarabilir. Bu yazıda barındırma türlerini yönetim yükü ve risk açısından karşılaştırıyor, sonra seçim adımlarını sıralıyoruz. Firma önerisi yapmıyoruz; örnek verdiğimiz dokümanlar yalnız kavramları göstermek için.

Barındırma türleri: kime uygun, yükü kimde?

Barındırma türleri arasındaki asıl fark, sunucunun hangi katmanını sizin yönettiğiniz. Bulut sağlayıcılarının "paylaşılan sorumluluk" modeli bunu iyi özetliyor: sağlayıcı altyapının güvenliğinden, müşteri ise kendi kurduğu şeyin güvenliğinden sorumlu. Sanal sunucu gibi altyapı hizmetlerinde işletim sistemi güncellemeleri, güvenlik yamaları ve güvenlik duvarı ayarları müşteriye düşüyor; daha soyut hizmetlerde bu yük sağlayıcıya kayıyor 4.

Bu tablo bir sıralama değil. Paylaşımlı barındırma, kimsenin sunucuya bakmayacağı bir VPS'ten çoğu zaman daha güvenlidir. Bulut da doğru yapılandırılmazsa esneklikten çok karmaşıklık getirir.

Statik ve edge barındırma, CDN nedir?

CDN (içerik dağıtım ağı), birçok konuma yayılmış ve verinin kopyalarını tutan sunucular grubudur; istek, kullanıcıya en yakın sunucudan karşılanır. MDN'e göre CDN'ler stil ve betik dosyaları gibi statik varlıkların yanında, HTML, CSS ve JavaScript'ten oluşan statik bir siteyi tamamen de sunabilir 1. Cloudflare da önbelleğini, sık erişilen içeriğin kopyalarının kullanıcıya kaynak sunucudan daha yakın veri merkezlerinde tutulması olarak tanımlıyor 3.

"Edge barındırma" denince kastedilen genellikle şudur: sayfalar derleme sırasında üretilir ve doğrudan CDN'den sunulur, kaynak sunucu her istekte çalışmaz. Vercel'in dokümanı, statik siteler ve pazarlama sayfaları için sayfaların derleme anında üretilip kaynağa gitmeden CDN'den sunulabileceğini; içerik değiştiğinde sayfaların arka planda yeniden üretilebileceğini anlatıyor 2. Aynı dokümanda HTTPS sertifikalarının otomatik sağlandığı da belirtiliyor 2.

Bu yaklaşımın bedeli de var: iletişim formu, arama, üye girişi gibi dinamik işler için sunucusuz fonksiyonlar ya da ayrı bir servis gerekir. İçeriği kimin, hangi panelden güncelleyeceği de baştan planlanmalı. Bu kurgu çoğunlukla headless bir içerik yönetim sistemiyle birlikte kullanılır; ayrıntıları headless CMS nedir yazısında anlattık.

Sunucu konumu ve KVKK: yurt dışına aktarım

Sunucunun nerede olduğu iki açıdan önemlidir: hız ve kişisel veri. Hız tarafında CDN, içeriği kullanıcıya yakın noktalardan sunduğu için kaynak sunucunun konumunun etkisini azaltır 1. Kişisel veri tarafı ise daha dikkat isteyen konu.

2024'te 6698 sayılı Kanun'un 9. maddesi değişti ve ayrıntılar 10 Temmuz 2024'te Resmî Gazete'de yayımlanan yönetmelikle düzenlendi. Yönetmelik, yurt dışına aktarımı kişisel verilerin yurt dışındaki bir veri sorumlusuna ya da veri işleyene iletilmesi veya başka bir yolla erişilebilir hâle getirilmesi olarak tanımlıyor 7. Aktarım için yeterlilik kararı, uygun güvenceler (standart sözleşme, bağlayıcı şirket kuralları, yazılı taahhütname) ya da arızi aktarım istisnaları gibi yollar öngörülüyor 7. Standart sözleşme, imzaların tamamlanmasından itibaren beş iş günü içinde Kurum'a bildirilmek zorunda; Kurum bunun için çevrim içi bir bildirim modülü de açtı 8.

Web sitesi açısından pratik soru şu: iletişim formları, teklif talepleri, üyelik ya da sipariş verileri nerede tutuluyor? Barındırma, form servisi, e-posta ve analitik sağlayıcıları yurt dışındaysa bu akışların her biri ayrı değerlendirilmeli. Çerez ve aydınlatma metinleri tarafını KVKK ve çerez bandı yazısında ele aldık.

Yedekleme ve SLA: sözleşmede neye bakmalı?

Yedekleme konusunda sağlayıcıya sorulacak sorular net: yedek ne sıklıkla alınıyor, kaç gün saklanıyor, aynı altyapıda mı duruyor, geri yükleme kim tarafından ve ne kadar sürede yapılıyor? Sağlayıcının yedeği olsa bile, sizin erişebildiğiniz ayrı bir konumda düzenli bir kopya tutmak bağımlılığı azaltır.

SLA (hizmet düzeyi sözleşmesi), sağlayıcının erişilebilirlik taahhüdüdür. Örnek olarak Google Cloud'un sanal sunucu SLA'sı, erişilebilirliği aylık çalışma süresi yüzdesiyle ölçüyor; taahhüt karşılanmazsa hizmet kredisi veriyor, planlı bakım ve müşteri kaynaklı sorunları kapsam dışında tutuyor ve kredinin müşteri tarafından talep edilmesini istiyor 5. Bu yapı sektörde yaygındır ve bir şeyi açıkça gösterir: SLA kesintiyi önlemez, yalnız kesinti sonrası ne olacağını tanımlar. Kaybedilen satış ya da itibar tazmin edilmez.

Bu yüzden SLA'ya güvenmek yerine kendi izlemenizi kurun. Sitenin ana sayfasını ve iletişim formunu birkaç dakikada bir dışarıdan kontrol eden bir erişilebilirlik izleme servisi, kesintiyi müşteriden önce fark etmenizi sağlar. Kesinti kayıtları, sağlayıcıdan kredi talep ederken de elinizdeki tek somut kanıttır. Uyarıların tek bir kişiye değil, ortak bir kanala ya da birden fazla kişiye gitmesi gerekir; tatildeki bir çalışanın telefonuna düşen uyarı, hiç gelmemiş uyarıyla aynı sonucu doğurur.

Yazılım sürümleri de sözleşme kadar önemli. WordPress kullanıyorsanız, WordPress.org'un güncel önerisi PHP 8.3 veya üstü ile MySQL 8.0 ya da MariaDB 10.11 veya üstü; daha eski sürümler çalışabilse de resmi destek süresi biten sürümlerin sitenizi güvenlik açıklarına maruz bırakabileceği belirtiliyor 6. Sağlayıcının hangi sürümleri sunduğunu ve ne zaman güncellediğini sorun.

Sık yapılan hatalar ve maliyeti belirleyen etkenler

Barındırma kararlarında sorun çoğu zaman paketin kendisinden değil, varsayımlardan çıkar. Sık karşılaşılan hatalar şunlar:

• E-postayı ve siteyi aynı pakete bağlamak. Paket değiştiğinde ya da sunucu sorun yaşadığında e-posta da durur. Kurumsal e-postayı ayrı bir hizmette tutmak, site taşımalarını çok daha sakin hâle getirir; bunun için yalnız MX ve ilgili TXT kayıtlarını doğru yönetmeniz yeterlidir.
• Hesabı kişisel e-postayla açmak. Barındırma hesabı, alan adı gibi şirket adına ve ortak bir kurumsal adresle açılmalı. Aksi hâlde fatura, yenileme ve güvenlik uyarıları ayrılan kişinin kutusunda kalır.
• Yalnız ilk yıl fiyatına bakmak. Yenileme ücreti, ek alan, yedek saklama ve trafik aşımı ücretleri toplam maliyeti belirler. Sözleşmede bu kalemlerin yazılı olup olmadığına bakın.
• Kaynakları tahminle büyütmek. Yavaşlığın nedeni çoğu zaman sunucu gücü değil; optimize edilmemiş görseller, gereksiz eklentiler ya da önbelleğin kapalı olmasıdır. Daha büyük paket almadan önce bu kalemleri kontrol edin.
• Çıkış planı yapmamak. Bazı paketlerde yedekler yalnız sağlayıcının paneline özgü bir biçimde alınır. Dosyalarınızı ve veritabanınızı standart bir biçimde dışa aktarabildiğinizden emin olun.

Maliyeti rakamla değil etkenlerle düşünmek daha doğru: sitenin dinamik mi statik mi olduğu, trafik miktarı ve dalgalanması, veritabanı ihtiyacı, yedek saklama süresi, destek seviyesi ve yönetim işinin kimde olduğu. Statik ve edge barındırmada maliyet çoğunlukla istek ve veri aktarımı üzerinden oluşur 2; sunucu kiralamada ise sabit kaynak bedeli öne çıkar. Hangisinin uygun olduğu, sitenin trafik profiline bağlıdır. Proje bütçesinin nasıl oluştuğunu web sitesi fiyatları yazısında anlattık.

Barındırma seçimi adım adım

1. Sitenin teknik yapısını yazın: hangi CMS ya da çerçeve, hangi dil sürümü, veritabanı gerekiyor mu, dinamik özellikler neler?
2. Bakımı kimin yapacağını belirleyin. Sunucu yönetecek biri yoksa VPS ve ham bulut sunucusunu listeden çıkarın 4.
3. Trafik profilini tahmin edin: düzenli mi, kampanya dönemlerinde ani artışlar var mı? Ani artışlar için CDN'li ya da ölçeklenebilen yapılar daha uygun 1.
4. Kişisel veri akışlarını çıkarın: form, e-posta, analitik ve yedeklerin nerede tutulduğunu listeleyin; yurt dışı aktarım varsa danışmanınızla aktarım aracını belirleyin 7.
5. Yedekleme politikasını sorun: sıklık, saklama süresi, konum, geri yükleme süreci.
6. SLA'yı okuyun: erişilebilirlik oranı, kapsam dışı durumlar, kredi koşulları 5.
7. Yazılım sürümlerini ve güncelleme takvimini kontrol edin 6.
8. Çıkış planı yapın: verilerinizi ve dosyalarınızı hangi biçimde, ne kadar sürede alabileceğinizi öğrenin.

Barındırma seçildikten sonra işin sürekli kısmı başlar: güncellemeler, yedek testleri, izleme ve yenileme takibi. Bunun neleri kapsadığını web sitesi bakımı yazısında, bu işleri nasıl üstlendiğimizi bakım ve destek hizmet sayfamızda bulabilirsiniz.