İçindekiler
- 1 Neden Küçük SaaS Uygulamaları İçin Hosting Mimarisi Bu Kadar Önemli?
- 2 Önce Çerçeveyi Netleştirelim: “Küçük SaaS”tan Ne Kastediyoruz?
- 3 Doğru Mimariyi Seçerken Hangi Kriterlere Bakmalısınız?
- 4 Tek VPS Mimarisi: Küçük SaaS İçin Ne Zaman Mantıklı?
- 5 Çoklu VPS Mimarisi: Esneklik ve Yüksek Erişilebilirliğe Adım
- 6 Yönetilen Bulut Mimarisi: Operasyon Yükünü Devretmek
- 7 Karşılaştırma: Tek VPS mi, Çoklu VPS mi, Yönetilen Bulut mu?
- 8 Adım Adım Yol Haritası: MVP’den Büyüyen SaaS’e
- 9 Hangi Soruyu Sorarak Başlamalısınız?
- 10 Sonuç ve DCHost ile Bir Sonraki Adım
Neden Küçük SaaS Uygulamaları İçin Hosting Mimarisi Bu Kadar Önemli?
Küçük bir SaaS ürünü geliştirirken herkesin aklında benzer sorular dolaşır: “Şimdilik tek bir VPS yeter mi, yoksa baştan mikro servis ve çoklu sunucuya mı geçmeliyim?”, “Yönetilen bulut hizmeti için bütçe ayırmaya gerçekten değer mi?”, “İlk etapta yanlış mimari seçersem, taşırken ne kadar acı çekerim?”. Bu soruların tek doğru cevabı yok; ama yanlış kararın maliyeti çok net: gereksiz yüksek faturalar, beklenmedik kesintiler ve geceleri log karıştırılan stresli bakım operasyonları.
DCHost ekibi olarak hem MVP aşamasındaki küçük SaaS projelerini hem de ciddi trafiğe ulaşmış, ölçeklenme sancısı çeken ürünleri sık sık görüyoruz. Ortak desen şu: Başta basit bir mimariyle başlamak mantıklı; ancak ne zaman ve nasıl evrileceğinizi planlamazsanız, bir noktada büyüme hızınız altyapınızın limitine takılıyor. Bu yazıda tek VPS, çoklu VPS ve yönetilen bulut mimarilerini; maliyet, ölçeklenebilirlik, güvenilirlik ve operasyonel yük açısından karşılaştıracağız. Amacımız, “hangi model daha havalı”yı değil, sizin SaaS’iniz için hangi yolun hangi aşamada doğru olduğunu mümkün olduğunca netleştirmek.
Önce Çerçeveyi Netleştirelim: “Küçük SaaS”tan Ne Kastediyoruz?
“Küçük SaaS uygulaması” ifadesi herkes için farklı bir şey çağrıştırabiliyor. Bu rehberde aşağıdaki senaryolara odaklanıyoruz:
- Ayda 10.000 – 200.000 arası sayfa görüntüleme alan,
- Aktif müşteri sayısı 20 – 1.000 aralığında olan,
- Genelde tek veya küçük (1–3 kişilik) ürün ve geliştirme ekibinin yönettiği,
- Tipik olarak monolitik veya hafif modüler (örneğin Laravel, Django, Rails, Node.js monolit, küçük arka plan işleyicilerle) mimariye sahip,
- Anlık trafik patlamaları sınırlı, ama iş kritikliği orta-yüksek olan (fatura, rezervasyon, üyelik, B2B dashboard vb.)
Yani henüz devasa bir çok bölgeli, dağıtık Kubernetes kümesine ihtiyacınız yok; ama “paylaşımlı hosting üzerinde WordPress blog”dan çok daha karmaşık bir uygulamadan bahsediyoruz. Eğer SaaS’iniz çok kiracılı çalışıyorsa, SaaS uygulamaları için çok kiracılı mimari türleri yazımızı da mutlaka bu rehberle birlikte düşünmenizi öneririz.
Doğru Mimariyi Seçerken Hangi Kriterlere Bakmalısınız?
Tek VPS, çoklu VPS veya yönetilen bulut arasında karar verirken birkaç temel ekseni netleştirmek gerekiyor:
1. Trafik ve Büyüme Hızı
- Şu anki trafik: Mevcut kullanıcı sayınız, saniyedeki istek (RPS) ve veri tabanı yükünüz.
- 6–12 aylık hedef: “Şu an yetiyor”dan ziyade, bir yıl içinde nerede olmayı planladığınız.
- Patlama riski: Ürününüz viral olabilir mi? Lansman, büyük kampanya, entegrasyon gibi ani sıçramalar bekliyor musunuz?
2. İş Kritikliği ve SLA Beklentisi
- Müşterilere uptime taahhüdü veriyor musunuz?
- Bir saatlik kesinti size kaç müşteri kaybı, kaç TL zarar yazdırır?
- Bakım için geceleri 1–2 saatlik kesintiyi tolere edebiliyor musunuz?
Bu konuyu daha teknik boyutuyla ele aldığımız “Yüksek erişilebilirlik mi güçlü tek sunucu mu?” yazımız da karar sürecinde işinize yarayacaktır.
3. Ekip Yetkinliği ve Operasyonel Kapasite
- Sistem yöneticisi veya DevOps deneyimi olan biri var mı?
- Güvenlik güncellemeleri, yedekler, izleme, alarm kurma gibi işleri kim yönetecek?
- Geliştirici ekibiniz sunucu yönetimiyle ne kadar uğraşmak istiyor?
4. Bütçe ve Toplam Sahip Olma Maliyeti (TCO)
Maliyet sadece aylık sunucu ücreti değil. Şunları da hesaba katmalısınız:
- Operasyonel zaman maliyeti (geliştiricinin sistem işi yapması),
- Hatalı yapılandırmadan kaynaklanabilecek performans sorunları,
- Yetersiz yedek / felaket senaryosu maliyeti.
Bu noktada hosting maliyetlerini düşürme ve doğru VPS boyutlandırma rehberi yazımıza da göz atmanızı tavsiye ederiz.
5. Veri Güvenliği, KVKK / GDPR ve Yedekleme
- Müşteri verilerinizin hassasiyeti (kişisel veriler, ödeme verileri, sağlık vb.).
- Veri yerelleştirme ihtiyaçları (Türkiye/AB veri merkezleri vb.).
- Yedekleme stratejiniz, RPO/RTO hedefleriniz.
SaaS ürünlerinde bu özellikle kritik olduğu için, SaaS uygulamaları için müşteri verisi yedekleme ve veri saklama politikaları ve RPO/RTO odaklı yedekleme stratejisi rehberini mutlaka okumanızı öneriyoruz.
Tek VPS Mimarisi: Küçük SaaS İçin Ne Zaman Mantıklı?
Tek VPS Mimarisi Nasıl Görünür?
En basit (ve en çok kullanılan) başlangıç senaryosu:
- Tek bir VPS üzerinde hem web sunucusu (Nginx/Apache),
- Hem uygulama (PHP-FPM, Node.js, Python, Ruby vs.),
- Hem veritabanı (MySQL/MariaDB/PostgreSQL),
- Hem de arka plan işler (queue worker, cron job’lar)
aynı makinede çalışır.
Basit bir network yapınız vardır: Uygulama doğrudan veritabanına localhost üzerinden bağlanır, cache için Redis/Memcached yine aynı sunucudadır. Genellikle tek bir production ortamınız olur, staging ortamını da aynı VPS’te farklı bir port veya alt klasörde tutarsınız.
Avantajları
- Düşük maliyet: Tek VPS ödersiniz, ağ trafiği için ekstra bir iç trafik maliyeti yoktur.
- Basitlik: Ağ topolojisi, güvenlik grupları, iç DNS gibi konularla daha az uğraşırsınız.
- Kolay yönetim: Tek sunucuda log, izleme, yedek işlemleri daha kolay takip edilir.
- MVP ve POC’lar için ideal: Henüz iş modeli ispatlanmamış, müşteri sayısı az olan SaaS uygulamaları için mantıklı giriş noktasıdır.
Dezavantajlar ve Riskler
- Tek hata noktası (SPOF): VPS’iniz çökerse her şey (API, panel, cron, veritabanı) aynı anda gider.
- Kaynak paylaşımı: Yoğun bir rapor sorgusu CPU/IO’yu sömürdüğünde tüm kullanıcılar yavaşlar.
- Bakım kesintileri: Kernel güncellemesi, büyük versiyon geçişleri genellikle kesinti anlamına gelir.
- Ölçeklenme sınırı: Dikeyde belli bir noktaya kadar büyüyebilirsiniz; sonrası zor ve maliyetli olur.
Gerçekçi Kullanım Senaryosu
Örneğin, müşterilerinize küçük bir B2B dashboard sunan SaaS düşünelim: günlük 300–500 aktif kullanıcı, saniyede 2–5 istek, küçük raporlar, basit formlar. Bu tip bir SaaS ürünü için:
- 4 vCPU, 8 GB RAM, NVMe diskli bir tek VPS,
- İyi yapılandırılmış bir web sunucusu ve veritabanı (örneğin InnoDB için makul buffer pool ayarları),
- Düzenli otomatik yedekleme ve izleme
başlangıçta fazlasıyla yeterli olur. Özellikle bütçeniz çok kısıtlıysa ve henüz 7/24 SLA veremeyecekseniz, tek VPS’le başlamak mantıklıdır.
Tek VPS’i Ne Zaman Zorlamaya Başladığınızı Gösteren Sinyaller
- Yoğun saatlerde CPU’nuz sürekli %70–90 bandında geziniyorsa,
- Veritabanı sorguları altında disk IO tavan yapıyorsa,
- Queue işçileriniz geri kalıyor, anlık bildirimler dakikalar sonra düşüyorsa,
- Bakım için her dokunduğunuzda müşterilere toplu mail atmak zorunda kalıyorsanız,
artık çoklu VPS veya yönetilen bulut mimarisine geçişi ciddi ciddi düşünme zamanınız gelmiş demektir. Bu aşamada paylaşımlı hosting’den VPS’e geçiş rehberinde anlattığımız taşıma prensipleri, tek VPS’ten çoklu VPS’e geçişte de benzer şekilde işinize yarar.
Çoklu VPS Mimarisi: Esneklik ve Yüksek Erişilebilirliğe Adım
Çoklu VPS Mimarisi Nasıl Kurulur?
Çoklu VPS mimarisi, bileşenleri mantıksal rollere göre ayırmanız anlamına gelir. Tipik bir küçük SaaS mimarisi şu şekilde olabilir:
- VPS-1: Uygulama Sunucusu
- Nginx/Apache + uygulama (Laravel, Node.js, Django vb.)
- Statik dosyaların sunumu, API uç noktaları
- VPS-2: Veritabanı Sunucusu
- MySQL/MariaDB/PostgreSQL
- Uygulama sunucusundan yalnızca iç ağ üzerinden erişim
- VPS-3: Queue / Arka Plan İşleri
- Queue worker’lar (ör. Laravel Horizon, Celery, BullMQ)
- Rapor üretme, e-posta gönderme, entegrasyonlar
- İsteğe bağlı VPS-4: Önbellek / Yardımcı Servisler
- Redis/Memcached, bazen ElasticSearch/OpenSearch gibi arama motorları
Daha da ileri bir adım olarak, uygulama sunucusunu çoğaltıp önlerine bir yük dengeleyici koyabilirsiniz: Örneğin 2 adet uygulama VPS’i ve 1 adet load balancer VPS’i ile temel bir yüksek erişilebilirlik kurmak mümkün.
Avantajları
- Kaynak izolasyonu: Ağır raporlar veritabanı VPS’inde CPU/IO tüketirken, uygulama sunucusunun cevaplama süresi daha az etkilenir.
- Daha kolay yatay ölçek: Uygulama sunucusunu çoğaltmak nispeten kolaydır; veritabanını ayrı tuttuğunuz için app katmanını büyütmek zahmetsizleşir.
- Daha kontrollü bakım: Sadece veritabanı veya sadece uygulama VPS’i üzerinde bakım yapabilirsiniz.
- Güvenlik: Veritabanı sunucusunu dış dünyaya tamamen kapatıp sadece iç ağdan erişime açabilirsiniz.
Dezavantajları
- Artan karmaşıklık: Ağ, güvenlik duvarı, DNS, iç IP’ler, bağlantı havuzu ayarları gibi konular devreye girer.
- Daha fazla yönetim yükü: Güncellemeler, izleme, yedekler artık birden çok VPS için ayrı ayrı takip edilmelidir.
- Senaryo planlama ihtiyacı: Failover, disk dolması, replikasyon gibi konularda net bir runbook yazmanız gerekir.
Hangi Durumlarda Çoklu VPS Mantıklı?
Genelde şu eşiklere geldiğinizde çoklu VPS’e geçiş güçlü bir aday olur:
- Tek VPS’in CPU/IO kullanımını agresif şekilde optimize etmenize rağmen performans sınırına dayanmışsanız,
- Veri tabanı boyutu büyümüş, yedek süreleri uzamaya başlamışsa,
- Bakım ve kernel güncellemeleri için müşterilere sürekli duyuru yapmak istemiyor, kesintileri minimize etmek istiyorsanız,
- Ekipte temel seviyede de olsa sistem yönetimi/DevOps deneyimi olan en az bir kişi varsa.
Özellikle veritabanını uygulamadan ayırma kararı kritik bir dönüm noktasıdır. Bu noktayı detaylı ele aldığımız veritabanı sunucusunu uygulama sunucusundan ayırmak ne zaman mantıklı? rehberini bu yazıyla birlikte okumanız faydalı olacaktır.
Örnek Çoklu VPS Yol Haritası
- Aşama 1: Mevcut tek VPS’i analiz
- CPU, RAM, disk IO, veritabanı sorgu süreleri, network kullanımı ölçülür.
- Aşama 2: Veritabanını ayrı VPS’e taşıma
- Uygulama ve DB ayrılır; iç ağ veya VPN üzerinden güvenli bağlantı sağlanır.
- Aşama 3: Queue ve ağır işler için üçüncü VPS
- PDF rapor, toplu mail, entegrasyon işleri ayrı makina üzerinde çalıştırılır.
- Aşama 4 (isteğe bağlı): Uygulama sunucusunu çoğaltma
- Ön tarafa basit bir yük dengeleyici konur, iki uygulama VPS’i aynı kod tabanıyla hizmet verir.
Bu yapı, henüz tam anlamıyla “büyük kurumsal cluster” seviyesinde olmasa da; küçük SaaS projeleri için ciddi bir esneklik ve dayanıklılık artışı sağlar.
Yönetilen Bulut Mimarisi: Operasyon Yükünü Devretmek
Yönetilen Bulut Dediğimizde Neyi Kastediyoruz?
Burada kastettiğimiz, altyapının büyük kısmının DCHost gibi bir ekip tarafından yönetildiği ve sizin daha çok uygulama koduna odaklandığınız modeldir. Örneğin:
- Birden fazla VPS’ten oluşan,
- Yük dengeleyici, veritabanı kümesi, cache altyapısı,
- Merkezi loglama, izleme, alarm kuralları,
- Otomatik veya yarı otomatik yedekleme ve kurtarma senaryoları
DCHost mühendisleri tarafından tasarlanır, izlenir ve gerektiğinde müdahale edilir.
Siz ise çoğunlukla şu sorulara odaklanırsınız: “Yeni özellik ne zaman çıkacak?”, “Sorguyu nasıl hızlandırırım?”, “UX’i nasıl iyileştiririm?”.
Avantajları
- Düşük operasyonel yük: Sunucu güncellemeleri, güvenlik yamaları, temel izleme ve yedekleme süreçleri profesyonel ekip tarafından yürütülür.
- Daha öngörülebilir performans: Başta doğru boyutlandırma ve izleme kurulduğu için, ivmeli büyümede nerede neyi büyütmeniz gerektiğini daha net görürsünüz.
- Danışmanlık değeri: Mimari tasarımda yapılan küçük ama kritik hatalar, erken aşamada engellenmiş olur.
- Ekibin odağı ürün tarafında kalır: Geliştiriciler sunucu ayarı yerine doğrudan ürüne yatırım yapar.
Dezavantajları
- Daha yüksek başlangıç maliyeti: Salt altyapı (yalın VPS) maliyetinden genellikle daha yüksek olur; çünkü içine mühendislik emeği dahildir.
- Daha yapılandırılmış süreç: Rastgele SSH ile sunucuya girip istediğinizi yapma dönemi biter; değişiklikler daha kontrollü yapılır (bu aslında uzun vadede avantajdır, ama kısa vadede alışma süreci gerektirir).
Hangi SaaS Takımları İçin İdeal?
- Geliştirici ağırlıklı ekipler: Ekipte sistem yönetimi/DevOps tecrübesi yoksa, yönetilen bulut ciddi bir rahatlama sağlar.
- Hızla ölçeklenmesi beklenen SaaS’ler: Lansman, yatırım sonrası büyüme, agresif satış planı olan ürünler.
- Regülasyon ve güvenlik baskısı yüksek olanlar: KVKK/GDPR, log saklama, yedekleme ve felaket kurtarma planlarının titizlikle uygulanması gereken sektörler.
Örneğin; fatura/ön muhasebe SaaS’i, sağlık randevu SaaS’i, hukuk odaklı SaaS ürünleri gibi alanlarda KVKK ve GDPR uyumlu hosting gereklilikleri devreye girdiği için, yönetilen bulut mimarisi çoğu zaman en güvenli yoldur.
Karşılaştırma: Tek VPS mi, Çoklu VPS mi, Yönetilen Bulut mu?
Aşağıdaki tabloyu “mutlak doğrular” değil, pratikte gördüğümüz ortalama desenler olarak düşünün:
| Kriter | Tek VPS | Çoklu VPS | Yönetilen Bulut |
|---|---|---|---|
| Maliyet (kısa vadeli) | En düşük | Orta | En yüksek |
| Maliyet (uzun vadeli, büyümede) | Hızla artabilir, yeniden mimari ihtiyacı doğar | Dengeli, kademeli büyütülebilir | Planlı büyüme ile öngörülebilir |
| Ölçeklenebilirlik | Sınırlı, dikey ağırlıklı | İyi, yatay + dikey | Çok iyi, genelde hazır desenler |
| Yüksek erişilebilirlik | Zayıf (SPOF) | İyi kurgulanırsa orta-iyi | İyi/çok iyi (tasarıma bağlı) |
| Operasyonel karmaşıklık | Düşük | Orta-yüksek | Düşük (operasyonun çoğu yönetilen) |
| Ekipte DevOps ihtiyacı | Asgari | Var, özellikle büyüdükçe artar | Asgari (sağlayıcının ekibi devrede) |
| Taşıma ve geçiş esnekliği | Başlangıç için çok kolay, büyüyünce zorlaşır | Esnek, modüler | Tasarım ve sözleşmeye bağlı |
Adım Adım Yol Haritası: MVP’den Büyüyen SaaS’e
DCHost tarafında gördüğümüz en sağlıklı desenlerden biri, “tek seferde mükemmel mimari” aramak yerine, kademeli bir evrim yol haritası çizmek. Örnek bir yol şöyle olabilir:
1. Aşama: MVP ve İlk Müşteriler (Tek VPS)
- 4 vCPU, 8 GB RAM civarı bir tek VPS ile başlarsınız.
- Web + uygulama + veritabanı + queue hepsi aynı sunucudadır.
- Temel güvenlik ayarları, firewall, otomatik yedekleme, basit izleme kurulur.
Bu aşamada hız ve maliyet ön plandadır. Ürün-pazar uyumu ararken gereksiz mimari karmaşa yüklenmezsiniz.
2. Aşama: Ürün Tutundu, Yük Artıyor (Çoklu VPS’e İlk Adım)
- Veritabanını ayrı bir VPS’e taşırsınız.
- Queue/worker işlerini üçüncü bir VPS’e kaydırırsınız.
- Uygulama sunucusunda daha agresif önbellek (OPcache, Redis, HTTP cache) kullanırsınız.
Bu sayede, tek VPS’in en büyük riski olan kaynak rekabeti ciddi şekilde azalır ve görece düşük ek maliyetle daha stabil bir yapı elde edersiniz.
3. Aşama: SLA ve Yüksek Erişilebilirlik İhtiyacı (Çoklu VPS + Yük Dengeleme)
- Uygulama sunucusunu en az ikiye çıkarırsınız.
- Önlerine bir yük dengeleyici (reverse proxy) koyarsınız.
- Veritabanında replikasyon veya yüksek erişilebilirlik senaryolarını düşünmeye başlarsınız.
Bu aşamada, 7/24 çalışan bir SaaS için artık “bakım için komple kapatmak” pek kabul edilebilir olmaktan çıkar. Yavaş yavaş yüksek erişilebilirlik desenleri devreye girer.
4. Aşama: Yönetilen Buluta veya Tam Yönetilen Küçük Cluster’a Geçiş
- Operasyonel yük ekibinizi yoruyorsa, DCHost tarafında yönetilen bir çoklu VPS veya bulut mimarisine geçersiniz.
- İzleme, alarm, yedekleme, felaket kurtarma planları daha kurumsal şekilde tanımlanır.
- Geliştirme–staging–canlı ortam ayrımı netleştirilir; sıfır kesinti deploy süreçleri kurulabilir.
Bu noktada, DCHost’un VPS ve bulut barındırma trendleri ve VPS’e sıfır kesinti CI/CD kurulum rehberi gibi yazılarındaki desenleri kendi SaaS’inize uyarlayarak oldukça olgun bir mimariye ulaşabilirsiniz.
Hangi Soruyu Sorarak Başlamalısınız?
Tüm bu seçeneklerin arasında kaybolmamak için, kendinize şu soruları sorarak başlayın:
- Önümüzdeki 12 ayda kullanıcı sayımı 10 katına çıkarma ihtimalim ne?
- Şu anki ekibimde, 7/24 izleme, yama, yedek ve felaket kurtarma yönetebilecek biri var mı?
- Bir saatlik kesinti beni ne kadar üzer, kaç müşteriyi kaybettirir?
- Bütçemi kod geliştirmeye mi, altyapı operasyonuna mı harcamak istiyorum?
Eğer yanıtlarınız “şimdilik yavaş büyüyoruz, kritik değil, ekip küçük ve bütçe sınırlı” ise; tek VPS ile başlayıp çoklu VPS’e doğru kademeli geçiş mantıklıdır. Eğer “büyüme hızla gelecek, müşteri başına gelir yüksek, SLA baskısı ciddi, ekipte DevOps yok” diyorsanız, DCHost tarafında yönetilen bulut / yönetilen çoklu VPS senaryolarını masaya yatırmak daha sağlıklı olacaktır.
Sonuç ve DCHost ile Bir Sonraki Adım
Küçük SaaS uygulamaları için “tek doğru hosting mimarisi” yok; ama her aşama için daha mantıklı bir seçim var. MVP döneminde tek bir güçlü VPS, hem bütçenizi korur hem de sizi gereksiz karmaşadan uzak tutar. Ürün çekiş kazandığında, çoklu VPS mimarisiyle veritabanı, uygulama ve arka plan işlerini ayırarak hem performans hem de güvenilirlik kazanırsınız. İş kritikliği yükselip SLA beklentileri devreye girdiğinde ise, yönetilen bulut veya yönetilen çoklu VPS mimarileri, ekibinizin omzundaki operasyon yükünü ciddi anlamda hafifletir.
DCHost olarak; tek VPS’ten başlayıp çoklu VPS ve yönetilen bulut mimarilerine geçen pek çok SaaS projesine eşlik ettik. İsterseniz yalnızca kapasite ve mimari danışmanlık alın, isterseniz uçtan uca tasarım, kurulum ve işletme tarafında desteğimizi devreye sokun. Mevcut veya planladığınız SaaS projenizin mimarisini birlikte masaya yatırmak, tek VPS, çoklu VPS ve yönetilen bulut seçeneklerini netleştirmek isterseniz, bize birkaç satır detay yazarak ulaşmanız yeterli. Gerisini DCHost ekibi olarak sakin sakin, veriye dayalı şekilde birlikte planlarız.
