MongoDB Hosting: Managed mı Self-Hosted mı? Net Karar Rehberi

MongoDB barındırma kararı, sadece veritabanı seçmek değildir; altyapı işletimi, yedekleme (backup), izleme (monitoring), güvenlik yamaları ve felaket kurtarma (disaster recovery) gibi başlıklara doğrudan etki eder. Bu rehberde managed MongoDB ile self-hosted MongoDB’yi; maliyet kalemleri, operasyon yükü ve teknik riskler üzerinden net biçimde karşılaştıracaksınız. En sonunda da sizin senaryonuza uygun seçimi kolaylaştıran somut bir kontrol listesi bırakıyorum.

Managed MongoDB mi, Self-Hosted MongoDB mi?

Managed MongoDB; veritabanı motorunun kurulumundan güncellemesine, replikasyon kurulumundan izleme/yedekleme iş akışlarına kadar birçok operasyonun sağlayıcı tarafından yönetildiği hizmet modelidir. Self-hosted ise MongoDB’yi kendi VDS/VPS/dedicated sunucunuzda kurup siz veya ekibinizin işlettiği modeldir.

Bu ayrımın etkisini en çok şu alanlarda görürsünüz: - Güncelleme ve bakım: MongoDB sürüm yükseltme, güvenlik yamaları, konfigürasyon değişiklikleri. - Yedekleme ve restore: Tutarlı snapshot alma, restore denemeleri, RPO/RTO hedefleri. - İzleme ve olay yönetimi: CPU/RAM, disk I/O, replikasyon gecikmesi, disk doluluk trendi, alarm akışı. - Failover ve yüksek erişilebilirlik: Replica set ayarları, otomatik failover davranışı. - Performans ve kapasite planlama: Storage türü, IOPS, bağlantı sayısı, index yönetimi.

Managed’in tipik “ürünleşen” avantajları

Managed modelde aşağıdaki işler çoğu zaman standart iş akışına bağlanır: - Güncelleme planlaması ve sürüm yönetimi (bazı sağlayıcılarda otomatik, bazılarında kontrollü). - Yedekleme stratejileri (snapshot + oplog mantığı, belirli aralıklarla). - İzleme panelleri ve alarm kuralları. - Tipik konfigürasyon şablonları: uygun thread/connection ayarları, disk alanı limitleri.

Self-hosted’in tipik “kontrol” avantajları

Self-hosted tercih edilince, şunları daha doğrudan kontrol edersiniz: - Dosya sistemi, disk türü (ör. NVMe), mount seçenekleri ve tuning. - Network topolojisi (private network, sadece belirli IP’lere açık portlar). - Replikasyon/erişim güvenlik modelleri (ör. uygulama bazlı network segmentleri). - Kod/CI-CD ile konfigürasyon yönetimi (infrastructure as code).

Ancak bu “kontrol”, operasyon yükünü de sizin tarafınıza taşır.

Maliyet kalemleri: Managed tek fiyat mı, self-hosted gizli maliyet mi?

MongoDB hosting maliyetinde tek satırlık fiyat etiketi yanıltıcı olabilir. Çünkü managed’de operasyon ve bazı risk giderimleri paket içindedir; self-hosted’de ise “sunucu + işçilik + risk karşılığı” bileşenleri çıkar.

Aşağıdaki tablo, karar verirken hangi maliyetleri düşünmeniz gerektiğini netleştirir:

Somut bir “toplam sahip olma” (TCO) hesabı için formül

Managed ile self-hosted arasında en net kıyas için şu yaklaşımı kullanın: 1) Self-hosted tarafında aylık sunucu maliyetini alın. 2) İzleme/backup/restore/patch için beklenen saat sayısını belirleyin. 3) Bu saatleri ekip saat maliyetiyle çarpın (iç ekip ya da danışman fark etmez). 4) Olası arıza maliyetini (ör. 1 saat downtime + veri kurtarma) risk olarak ekleyin. 5) Managed’in fiyatını bu toplamla karşılaştırın.

Bu hesapta kritik nokta şudur: Self-hosted’de “sorun çıkana kadar” maliyet düşük gibi görünür; problem çıktığında ise zaman ve itibar kaybı büyür.

Operasyon yükü: Yedekleme, izleme ve güncelleme pratikte kimde?

MongoDB’de en çok kayıp yaratan alanlar genelde yedekleme ve restore pratiklerinin sahada test edilmemesidir. Bu yüzden karar için şu üç başlığı özellikle ele alın.

Yedekleme (backup) stratejisi: Snapshot yeter mi?

Managed’de çoğu sağlayıcı; periyodik yedekleme (snapshot) + değişim akışı mantığıyla (oplog tabanlı tutarlılık) yaklaşır. Self-hosted’de ise şu soruları net sormalısınız: - Yedekler tutarlı mı (consistent) yoksa sadece dosya seviyesinde mi? - Olası restore senaryosunda kaç dakikalık veri kaybı (RPO) olur? - Restore süresi kaç saat sürer ve bu süreyi test ettiniz mi? - Yedek saklama süresi (retention) kaç gün/hafta?

Net kriter: Aynı yedekleme politikasını kullanıyor olsanız bile restore denemesi yapılmadıysa süreç “varsayımsal” kalır.

İzleme (monitoring) ve alarmlar: Replica set gecikmesi görünüyor mu?

MongoDB için izleme, sadece metrik görmek değil; eyleme dönüştürmek demektir. Self-hosted düşünüyorsanız minimum izleme setini somutlaştırın: - CPU kullanımı (sıklıkla yetmez; veri işleme pattern’i önemli) - RAM baskısı (working set) - Disk I/O ve latency - Disk doluluk trendi - Replica set replication lag (sekonder gecikmesi) - Oplog büyüklüğü (oplog space management) - Connection sayısı ve long-running query’ler

Managed’de ise bu metriklerin yanı sıra alarm yönetimi (ör. e-mail/Slack webhook) ve otomatik aksiyonların olup olmadığını kontrol edin.

Güncelleme ve konfigürasyon değişikliği: Test ortamı var mı?

MongoDB sürüm yükseltme, bazı durumlarda index davranışı, query planner veya disk layout etkileyebilir. Managed’de sağlayıcı penceresi ve test prosedürleri devrede olur. Self-hosted’de şu garanti edilmelidir: - Staging ortamında sürüm testi - Canlıda planlı window - Geri dönüş (rollback) stratejisi - Yedek alındıktan sonra değişiklik

Performans: Aynı CPU/RAM her zaman aynı sonuç vermez

MongoDB performansı; storage (özellikle disk IOPS/latency), index tasarımı, çalışma seti boyutu ve bağlantı davranışıyla doğrudan ilişkilidir. Bu nedenle managed mi self-hosted mi sorusunun performansa etkisini “ham donanım” üzerinden değil “çalışma koşulları” üzerinden okuyun.

Self-hosted’de kontrol edebileceğiniz şeyler

• Disk türü (NVMe/SSD), IOPS garantisi
• Dosya sistemi/partition düzeni
• Network ayarları (uygulama ile veritabanı arası latency)
• İş yüküne göre connection limit ve query tuning

Managed’de genelde standartlaşan şeyler

• Kaynak izolasyonu (instance planına göre)
• Bakım pencereleri ve failover mimarisi
• Disk/replication davranışını yöneten şablonlar

Net ölçüm önerisi: Karar vermeden önce kendi sorgularınızla yük testi yapın. Özellikle: - Yazma (insert/update) yoğunluğu - Okuma (read) yüzdesi ve index kapsamı - En pahalı 10 query - Ortalama ve ani yük (spike) davranışı

Güvenlik ve erişim: Port, ağ ve kimlik doğrulama net sınırlar ister

MongoDB erişimi güvenlik açısından “varsayılanı geç” bir konudur. Managed’de sağlayıcı temel güvenlik katmanlarını sunabilir; self-hosted’de ise bunların kurulumundan siz sorumlu olursunuz.

Minimum güvenlik kontrol listesi

• MongoDB portu doğrudan internete açık değil (sadece gerekli network)
• Kimlik doğrulama (authentication) aktif
• Yetkilendirme (authorization) rollerle sınırlandırılmış
• TLS (in-transit) kullanımı
• Audit log (varsa) ve erişim kayıtları
• Şifrelerin saklanması: uygulama tarafında secret yönetimi

Network segmenti neden kritik?

Veritabanı erişimi sınırlı network’e çekilmediğinde, saldırı yüzeyi büyür. Managed’de bu genellikle daha kolay “doğru varsayılanlarla” olur; self-hosted’de ise VDS/VPS tarafında firewall, security group ve routing ayarlarıyla net sınırlar çizmelisiniz.

Veri yönetimi: Capacity planlama ve ölçeklenme

MongoDB’de büyüme kontrolü; sadece disk eklemek değildir. Index büyümesi, çalışma seti genişlemesi ve replikasyon trafiği ölçeklenmeyi etkiler.

Self-hosted’de şu sorular net olmalı: - Storage artırımı hangi sürede yapılır? - Disk doluluk alarmı var mı ve eşik değerleri ne? - Yedekleme süresi büyüdükçe restore süresi nasıl etkilenir?

Managed’de sağlayıcı plan yükseltme/ölçekleme mekanizması sunar. Burada hedef, “plan değişimi sırasında downtime olmaması” ve “geçişin test edilmiş olmasıdır.”

Hangi durumda managed seçin? Net senaryolar

Aşağıdaki maddeler, managed’in daha doğru tercih olduğu durumları netleştirir: - Ekibiniz MongoDB operasyonunu “sürekli bakım işi” olarak ayırmayacaksa. - Yedekleme/restore testlerini düzenli yapacak süreç olgunluğunuz yoksa. - SLA hedefleri: kısa RTO ve daha tutarlı RPO istiyorsanız. - Ürün geliştirme odağını kaybetmeden veritabanını güvenle çalıştırmak istiyorsanız.

Managed’de maliyet genelde daha öngörülebilirdir; sürpriz arıza maliyetini azaltma yönü güçlüdür.

Hangi durumda self-hosted seçin? Net senaryolar

Self-hosted, şu durumlarda daha avantajlıdır: - Özel network mimarisi, private route ve belirli güvenlik kısıtları gerektiriyorsanız. - Disk/IO gereksiniminiz çok spesifik ve planların ötesine çıkıyorsa. - Tuning, index/konfigürasyon ve operasyon standardizasyonu ekibinizde hazırsa. - Bütçe kısıtı nedeniyle daha düşük ham maliyet hedefleniyorsa (ama yedek/izleme/restore iş yükü kabul ediliyorsa).

Self-hosted’in başarısı, süreç disiplinine bağlıdır. “Kurduk çalışıyor” aşaması bittiğinde, izleme ve testler başlıca fark yaratır.

Self-hosted için minimum operasyon paketi (gerçekçi olarak)

• Otomatik yedekleme ve yedek saklama (retention)
• Haftalık restore denemesi (en azından staging’de, canlıda planlı)
• İzleme panelleri + e-mail/Slack alarm akışı
• Güncelleme planı: OS ve MongoDB sürümü
• Disk doluluk ve replikasyon gecikmesi eşiği
• Log toplama ve olay sonrası inceleme dokümantasyonu

Net karar kontrol listesi

Aşağıdaki soruların çoğuna “evet” diyorsanız managed daha uygun olur; çoğuna “hayır” ve “süreç yönetebiliriz” diyorsanız self-hosted daha mantıklıdır.

• Yedekleme restore denemelerini düzenli yapacak zamanınız var mı?
• Replica set/HA senaryolarında failover davranışını test ettiniz mi?
• MongoDB ve OS güncellemelerini planlı şekilde yapacak operasyon rutininiz var mı?
• Disk I/O ve latency hedefleri için sağlayıcı bağımlılığı istemiyor musunuz?
• İzleme/alerting altyapısını (monitoring stack) kurup sürdürecek ekibiniz var mı?
• Veri kaybı toleransı (RPO) ve downtime toleransı (RTO) tanımlı mı?

Sonuç: Önce hedefleri yazın, sonra modeli seçin

MongoDB hostingte managed ile self-hosted arasındaki fark; sadece “kolaylık” değil, yedekleme/restore tutarlılığı, izleme kalitesi ve güncelleme riskiyle ilgilidir. Kararınızı hızlandırmak için önce RPO/RTO hedeflerini ve restore denemesi planını netleştirin; ardından kendi sorgu yükünüzle (en pahalı 10 query) performans doğrulaması yapın. Eğer operasyon yükünü üstlenemiyorsanız managed; ağ/disk tuning ve operasyon disiplini sizdeyse self-hosted daha doğru tercihtir. Şimdi NetKıyas’ta mevcut planları karşılaştırırken özellikle yedekleme, izleme ve ölçeklenme maddelerini aynı çerçevede kıyaslayın; fiyatı değil, süreç kalitesini seçin.