MongoDB Hosting: Managed mı Self-Hosted mı? Net Karşılaştırma

MongoDB’de managed (yönetilen) hosting ile self-hosted (kendi yönettiğin) kurulum arasında seçim yaparken tek soru “hangisi daha iyi?” değildir. Asıl soru; operasyon yükü, arıza/geri dönüş (RTO/RPO), veri güvenliği, ölçekleme ve performans takibinin kimde olacağıdır. Bu rehberde MongoDB için iki modeli net kriterlerle karşılaştırıp, hangi senaryoda hangisinin daha doğru olduğuna karar vermenizi sağlayacak ölçülebilir kontroller sunacağız.

Managed MongoDB nedir, self-hosted MongoDB nedir?

Managed MongoDB; altyapı sağlayıcısının MongoDB kurulumu, servis yönetimi, temel güvenlik ayarları, yedekleme/restore süreçleri ve çoğu durumda bazı performans iyileştirmelerini üstlendiği hizmet modelidir. Genellikle siz sadece uygulama tarafı (veritabanı kullanıcıları, şema tasarımı, indeks stratejisi) üzerinde çalışırsınız.

Self-hosted MongoDB ise MongoDB’yi kendi sunucunuzda (ör. VDS/dedicated üzerinde) kurduğunuz ve güncelleme, replikasyon (replication), yedekleme (backup), disk/IO takibi, log analizi gibi işleri siz yönettiğiniz modeldir.

Operasyon kimin sorumluluğunda?

Net ayrım şudur: - Managed: Sağlayıcı “platform” seviyesini yönetir; siz “veri ve uygulama” tarafına odaklanırsınız. - Self-hosted: Her katmanda siz varsayılan karar vericisiniz. Bu; güncelleme takvimi, sürüm uyumluluğu, replikasyon mimarisi, yedekleme topolojisi ve felaket kurtarma planı (disaster recovery) anlamına gelir.

Net maliyet hesabı: Sadece aylık fiyat değil, toplam operasyon maliyeti

MongoDB hosting maliyetini değerlendirirken üç kalem genellikle gizli kalır: 1) İş gücü (operasyon + takip + arıza müdahalesi) 2) Risk bedeli (yedek başarısızlığı, veri kaybı, restore süresi) 3) Sistem performansı (IOPS/CPU sınırları ve verimsiz sorgu sonucu büyüyen maliyet)

Managed maliyeti nasıl okunmalı?

Managed hizmetlerde aylık tutar; çoğu zaman disk + RAM/CPU + işlemci (ops) + yedekleme/restore politika bileşenlerinden oluşur. Burada kontrol etmeniz gereken iki net nokta vardır: - Yedekleme sıklığı ve saklama (retention): Örneğin “her 1 saatte snapshot” gibi ifadeler RPO hedefinize uyuyor mu? - Restore yöntemi ve test edilebilirlik: “Backup var” demek tek başına yeterli değildir. Restore süresini (RTO) ve başarının nasıl doğrulandığını sormalısınız.

Self-hosted maliyeti nasıl okunmalı?

Self-hosted’te aylık VDS/dedicated maliyeti + ek yazılım/iş gücü maliyeti oluşur. Net maliyet şunları ekleyerek hesaplanmalıdır: - Replikasyon için ek düğüm maliyeti (tek node yerine en az 3 node yaklaşımı yaygındır) - Disk ve IO paylaşımlarının performans bedeli (özellikle write-heavy senaryolarda) - Yedekleme için ek storage/kanal (ör. ayrı disk veya obje storage) - Güncelleme/patch yönetimi için işçilik

Yedekleme ve restore (RPO/RTO): MongoDB’de seçim kriteri

MongoDB’de “veri kaybı riski” teknik bir detay değil, doğrudan iş etkisidir. Bu yüzden seçim yaparken şu hedefleri yazın ve hizmet modelini buna göre test edin: - RPO (Recovery Point Objective): Veri kaybı en fazla kaç dakika/saniye olmalı? - RTO (Recovery Time Objective): Sistem kaç sürede tekrar çalışır hale gelmeli?

Managed tarafında kontrol listesi

Managed hizmeti değerlendirirken aşağıdaki sorulara net cevap isteyin: - Yedekleme hangi aralıkla alınıyor? (örn. 15 dk / 1 saat / günlük) - Saklama süresi kaç gün? - Restore işlemi sırasında beklenen süre nedir? - Failover (birincil node arızasında ikincil node’a geçiş) otomatik mi? - İşlem logları (oplog) üzerinden nokta atışı geri dönüş (point-in-time) sunuluyor mu?

Self-hosted tarafında kontrol listesi

Self-hosted’te aynı çıktıları siz kurmalısınız: - Replica set mimarisi doğru mu? (tercihen odd number ile çoğunluk) - Yedekleme türü: snapshot tek başına yeterli mi, yoksa oplog/continuation stratejisi var mı? - Yedekleri ayrı lokasyon/ayrı depolama alanında tutuyor musunuz? - Restore senaryolarını düzenli test ediyor musunuz? (test restore yapılmıyorsa “backup” kağıt üzerinde kalır)

Not: Snapshot tek başına “gerçek backup” yerine geçmek için yeterli olmayabilir. Asıl ölçüt; restore senaryosunun başarıyla ve kabul edilebilir RTO ile tamamlanmasıdır.

Ölçekleme: Dikey mi yatay mı, veri büyümesi nasıl yönetiliyor?

MongoDB büyüdüğünde sorun sadece “daha çok disk almak” değildir. En kritik konular şunlardır: - Index boyutları ve yazma maliyeti - Shard key seçimi (sharding kullanıyorsanız) - Çalışan sorguların index kullanımı - Cache davranışı (RAM yetersizse ciddi gecikme oluşur)

Managed’da ölçekleme avantajı hangi noktalarda çıkar?

Managed tarafında genellikle: - Replikasyon ve failover yönetimi daha az hataya açık olur. - Daha hızlı kapasite değişimi ve servis planı güncellemeleri daha öngörülebilir olur. - Operasyonel gecikme (kimse “o gece uğraşmadı” problemi) azalır.

Self-hosted’da ölçekleme avantajı hangi noktalarda çıkar?

Self-hosted; özellikle şu durumlarda güçlüdür: - Çok spesifik konfigürasyonlar yapmak zorundaysanız - Lisans/uyumluluk gereği sağlayıcı bağımlılığını azaltmak istiyorsanız - Uygulama ile DB tarafını aynı ekip ve süreçle birlikte optimize ediyorsanız

Net karşılaştırma tablosu (ölçekleme)

Performans: Aynı uygulama, farklı yönetim modeliyle nasıl etkilenir?

MongoDB performansı; CPU, RAM, disk IO ve sorgu planı ile doğrudan ilişkilidir. Managed mi self-hosted mi farkı genellikle şu alanlarda görünür: - Disk IO ve cache verimi - Backup/restore veya patch dönemlerinde performans dalgalanması - Monitoring ve anomali tespiti derinliği

Net performans kontrolü: “Metrik seti”nizi şart koşun

Hangi modeli seçerseniz seçin şu metrikleri düzenli görebildiğinizden emin olun: - CPU kullanımı ve load trendi - RAM kullanımı + cache baskısı - Disk IO (özellikle write yoğunluğunda) - Ortalama ve kuyruk gecikmesi (latency) - Sorgu performansı: yavaş sorgu logları - Replikasyon gecikmesi (replication lag)

H3: Yavaş sorgu bulma kriteri (DB tarafı)

Yavaş sorguların genelde iki ana sebebi vardır: 1) İndeks yokluğu / yanlış indeks 2) Çok büyük “collection scan” (özellikle filtreleme alanlarında)

Net aksiyon için şu adımı standartlaştırın: - “En yavaş 10 sorgu”yu belirleyin - Her sorgu için filtre koşullarını ve kullanılan index’i inceleyin - Uygunsuz indeksleri ayıklayıp doğru index’i ekleyin

Güvenlik ve erişim: Kimlik doğrulama, şifreleme, ağ kısıtları

MongoDB’de güvenlik; sadece “parola var” demek değildir. Net gereksinimler şunlardır: - İstemci kimlik doğrulama mekanizması (kullanıcı/rol bazlı) - Ağ erişimi: yalnızca uygulama sunucularından erişim - Aktarım şifreleme (TLS) - At-rest encryption (disk üzerinde şifreleme) var mı? - Yedeklerin şifrelenmesi (yedek (backup) dosyalarının erişim kontrolü)

Managed’da güvenlik avantajı nerede?

Managed hizmetler çoğu zaman: - Varsayılan güvenlik şablonları sunar - TLS ve ağ kısıtlarını kolaylaştırır - Yedekleri şifreleme ve erişim kontrolünü standart hale getirir

Self-hosted’da güvenlik avantajı nerede?

Self-hosted; policy ve compliance gereği: - Kendi sertifika/anahtar yönetiminizi kullanmanıza - Ağ mimarisini (VPC/route/firewall) tamamen sizin kontrol etmenize - Loglama ve SIEM entegrasyonunu istediğiniz gibi tasarlamanıza olanak sağlar.

Hangi senaryoda managed, hangi senaryoda self-hosted daha doğru?

Aşağıdaki karar çerçevesi net ve pratik olsun diye “operasyon yükü” üzerinden ilerliyoruz.

Managed’i tercih etmeniz gereken net durumlar

• 24/7 erişim ve hızlı failover ihtiyacı var
• Operasyon ekibiniz düzenli bakım/patch/restore testini sürdüremiyor
• Net RPO/RTO hedefleriniz var ve sağlayıcıdan restore denemesi bekliyorsunuz
• Ek maliyeti yönetilebilir; kritik iş yükünde operasyon hatasını azaltmak öncelik

Self-hosted’i tercih etmeniz gereken net durumlar

• MongoDB konfigürasyonlarında ileri seviye kontrol ihtiyacı var
• Uyum/bağımsızlık gereği üçüncü taraf bağımlılığını minimize etmek istiyorsunuz
• Ekip DB operasyonunu (yedek + restore testi + monitoring) düzenli yapabilecek kapasitede
• Sharding ve özel replicaset mimarileri gibi özgün tasarımlar yapıyorsunuz

Hızlı seçim özeti (checklist)

Aşağıdaki sorulardan 3+ tanesine “Evet” diyorsanız çoğunlukla managed daha doğru olur: - Yedek restore testini düzenli yapacak operasyon zamanı yok. - RTO hedefi sıkı (ör. saatler değil, dakikalar). - Failover otomasyonu kritik. - Sağlayıcı metrik/raporlama ve log erişimi sunuyor. - At-rest şifreleme ve yedek erişim kontrolü “hazır” olsun istiyorsunuz.

Self-hosted için 3+ “Evet”: - Konfigürasyonu birebir kendiniz yönetmek istiyorsunuz. - Uyum gereği anahtar yönetimi ve ağ politikası tamamen sizde. - İzleme ve yavaş sorgu optimizasyonu süreçleriniz hazır. - Yedekleme/restore testini siz düzenli yapacaksınız.

Net kurulum/işletim gereksinimleri: İki modelde de “olmazsa olmaz”

Managed veya self-hosted fark etmeksizin MongoDB’nin sağlıklı çalışması için şu başlıklar net olmalı: - Monitoring (izleme): CPU/RAM/IO + replication lag + yavaş sorgu - Yedek (backup) stratejisi: snapshot + restore testi + şifreleme - Konfigürasyon yönetimi: sürüm uyumu ve güncelleme planı - Şema ve indeks disiplini: yanlış index yazma maliyetini yükseltir - Loglar: uyarı/error loglarını düzenli kontrol

H3: “Backup var ama işe yaramıyor” durumunu engelleme

En net yöntem, planlanmış bir restore egzersizi (restore drill) yapmaktır: - Son 7/14 günde bir geri dönüş testi uygulayın - Restore edilen DB’nin uygulama ile uyumunu doğrulayın - Restore süresini ölçüp gerçek RTO hedefinizle karşılaştırın

Sonuç: Kararı operasyon hedeflerinize göre verin

Managed MongoDB ile self-hosted arasındaki fark, çoğunlukla “kimin bakım yaptığını” belirler: managed model operasyon riskini sağlayıcıya devreder, self-hosted ise tam kontrol verir ama yedek/restore ve performans takibi yükünü siz alırsınız. Aksiyon önerisi olarak; önce RPO/RTO hedeflerinizi yazın, sonra yedekleme/restore testinin kim tarafından yapıldığını ve hangi metriklerin erişilebilir olduğunu netleştirin. Bu iki net soruya verdiğiniz cevaba göre managed veya self-hosted seçiminiz kararınızda sapma yapmayacaktır.