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

MongoDB, günümüzde hem geliştiricilerin hem de operasyon ekiplerinin birlikte yönetmek zorunda kaldığı bir veritabanı. Ancak MongoDB’nin “doğru çalışması” sadece cluster kurmakla bitmiyor; yedekleme (backup), güncelleme, erişim denetimi, disk/IO izleme ve felaket senaryoları gibi işler de performansı doğrudan etkiliyor. Bu yazıda MongoDB hosting tarafında managed (hazır yönetilen) ile self-hosted (kendi yönetimin) seçeneklerini; somut kontrol listeleri, ölçülebilir gereksinimler ve karar eşiğiyle karşılaştırıyorsunuz.

Managed MongoDB nedir, Self-hosted MongoDB nedir?

Managed MongoDB; sağlayıcının sizin adınıza kurulum, operasyon (patch/güncelleme), yedekleme, izleme ve çoğu durumda ölçekleme/performans ayarlarını yürüttüğü hizmettir. Genellikle erişim güvenliği, cluster konfigürasyonu ve servis sürekliliği için hazır süreçler vardır. Kısaca: DB’nin işletimi bir “kısmi ürün” gibi sunulur.

Self-hosted MongoDB; MongoDB’yi kendi VDS/VPS veya dedicated sunucularınıza kurduğunuz, cluster’ı (replica set, sharding vb.) siz yönettiğiniz modeldir. Sunucu işletim sistemi, kernel/IO ayarları, replika akışı, güncellemeler, yedekleme stratejisi ve erişim politikaları tamamen sizin sorumluluğunuzda olur.

Kararı etkileyen temel fark: operasyon yükü

• Managed: Operasyon yükünün büyük kısmı sağlayıcıdadır.
• Self-hosted: Operasyon yükü sizin ekip/iş süreçlerinize dağılır.

Bu fark, “aynı özellikleri alacağım” gibi görünen taleplerde bile maliyeti ve riski belirler.

Hangi senaryolarda Managed MongoDB seçilmeli?

Managed tarafının avantajı, özellikle şu koşullarda somutlaşır:

1) SLA ve kesinti toleransı düşük

Sıkı SLA hedefi olan ekiplerde managed, daha öngörülebilir operasyon sunar. Örnek kriterler: - Planlı bakım pencereleri ile ilgili net iletişim - Otomatik failover (felaket durumunda anlık geçiş) - Donanım arızası veya disk sorunu gibi durumlarda hızlı aksiyon

2) Ekip operasyon konusunda sınırlı

Aşağıdakilerden en az ikisi sizde “düşük kapasite” ise managed daha rasyoneldir: - Veritabanı güncellemesi (major/minor) planlama tecrübesi sınırlı - Yedekleme testini düzenli doğrulama (restore test) rutin değil - Performance tuning için zaman yok (özellikle sorgu + indeks + disk IO)

3) Yedekleme ve restore doğrulama kritik

Managed sağlayıcılar çoğu zaman yedeklemeyi otomatikleştirir; ancak asıl fark, yedek almanın yanında restore doğrulamasının süreçte olup olmamasıdır.

Managed için kontrol listesi (teknik talepler): - Noktasal zamanlı geri yükleme (point-in-time restore) var mı? - Yedek saklama süresi (örn. 7/14/30+ gün) ve maliyeti net mi? - Restore testi raporlanıyor mu? En azından “restore süresi” SLA’sı var mı?

Hangi senaryolarda Self-hosted MongoDB seçilmeli?

Self-hosted; maliyet kontrolü, özel mimari ve tam erişim gereksinimlerinde öne çıkar.

1) Şeffaf maliyet ve maksimum kontrol hedefi

Örneğin log yönetimi, özel ağ topolojisi, özel disk/IO planlaması veya belirli bir storage sınıfı (disk tipi) zorunlulukları varsa self-hosted daha esnektir.

2) Özel güvenlik ve uyumluluk gereksinimleri

Bazı kurumlar için şu talepler kritiktir: - Ağ katmanında (network) katı firewall kurallarıyla izolasyon - Özel anahtar yönetimi (KMS) entegrasyonu - Kurumsal SIEM’e (Security Information and Event Management) tam log aktarımı

Self-hosted tarafında bunu sağlayabilmek için teknik sorumluluk sizde olur.

3) Mimari “cluster tuning” ihtiyacı yüksek

Sharding, özel replica set topolojisi veya sıra dışı I/O desenleri olan sistemlerde MongoDB’nin yanında işletim sistemi/IO ayarları da kritik hale gelir. Burada “managed otomatik yapar” her zaman sizin hedeflediğiniz şekilde olmayabilir.

Self-hosted için kontrol listesi (minimum): - Disk türü ve IOPS beklentisi: storage performansı net ölçülüyor mu? - Replica set sağlığı izleniyor mu: oplog gecikmesi, replication lag, failover tetikleri - Otomatik güncelleme süreci var mı, yoksa manuel change planı var mı? - Restore testi için prosedür ve süre hedefi belirlendi mi?

Performans ve operasyon: Managed vs Self-hosted karşılaştırma tablosu

Aşağıdaki tablo, karar vermeyi kolaylaştırmak için “hangi iş kimin sorumluluğunda” fikrini netleştirir.

Karar eşiği: Maliyet, iş gücü ve risk nasıl hesaplanır?

Bu bölümde “en ucuz” değil, “en mantıklı” seçimi hedefleyen sayısal yaklaşım var.

1) Ayda kaç saat DB operasyonu ayırabileceksiniz?

Self-hosted modelde operasyon süreleri genellikle şu başlıklarda çıkar: - Güncelleme planlama ve uygulama - Yedekleme/restore testi (en az aylık veya kritik değişikliklerde) - Performans olaylarına müdahale (CPU spike, IO wait, memory pressure) - Log/uyarı yönetimi ve kapasite planlama

Managed’de bu süreler belirgin azalır; ancak sıfırlanmaz. Yine de en azından “temel DB operasyonu” sağlayıcıya taşınır.

2) Restore süresi hedefi belirleyin (RTO)

Managed veya self-hosted fark etmeksizin şu soruyu net cevaplayın: - “Veri kaybı/servis kesintisi durumunda kaç dakikada ayağa kalkmak istiyorum?”

Self-hosted’de restore süresi; yedek boyutu, storage hızı, network ve prosedür kalitesine bağlıdır. Managed’de restore süresi daha öngörülebilir olma eğilimindedir ama yine de dokümana bakılmalıdır.

3) Yedek saklama süresi ve geri yükleme maliyeti

Aşağıdaki iki kalem toplam maliyeti etkiler: - Yedek saklama süresi (ör. 7/14/30+ gün) - Restore sırasında kullanılan kaynaklar ve olası ücretlendirme

Managed’de yedek saklama genellikle tarifeye bağlıdır. Self-hosted’de ise storage maliyeti ve yedek pipeline (yedekleme altyapısı) maliyeti çıkar.

Güvenlik ve uyumluluk: Her iki modelde mutlaka istenenler

MongoDB hosting için güvenlik “tek ayar” değildir; bir sistemdir. Managed ile self-hosted fark etmeksizin şu maddeleri yazılı talep haline getirin.

1) Ağ erişimi (network access)

• MongoDB portu internete açık olmamalıdır.
• Sadece uygulama sunucularının IP aralıkları erişebilmelidir.
• Sağlayıcı kullanıyorsa private network / peering / özel ağ gibi seçenekleri kontrol edin.

2) Kimlik doğrulama ve yetkilendirme

• Kullanıcı bazlı rol (role) ayrımı net olmalı.
• Admin yetkileri minimal tutulmalı.
• Uygulama kullandığı kullanıcıyla çalışmalı (tek root kullanıcıyla değil).

3) Şifreleme (encryption)

• Aktarım sırasında şifreleme: TLS zorunlu olmalı.
• Saklama sırasında şifreleme: disk-level encryption veya eşdeğer mekanizma olmalı.

4) Log ve denetim izi (audit trail)

• Kim erişmiş? Hangi komutlar çalışmış? Bu izler toplanabiliyor olmalı.
• Olay analizini hızlandırmak için log retention politikası belirlenmeli.

MongoDB için pratik seçim senaryoları (net öneriler)

Aşağıdaki senaryolar “hangi model daha iyi?” sorusuna hızlı yanıt verir.

Senaryo A: Yeni proje, ekip küçük, zaman kısıtı var

Öneri: Managed - İlk 3 ay içinde DB operasyonu ile uğraşmak yerine geliştirmeye odaklanmak daha mantıklıdır. - Yedekleme, failover ve izleme hazır geliyorsa kurulum riski düşer.

Senaryo B: Kurumsal uyumluluk ve özel mimari var

Öneri: Self-hosted veya managed + güçlü kontrol - Özel ağ/şifreleme/log gereksinimleri çok sıkı ise self-hosted daha esnek olur. - Managed seçilecekse “hangi düzeyde kontrol” verildiğini sözleşmede netleştirin (izleme metrikleri, ağ izolasyonu, yedek erişimi, anahtar yönetimi).

Senaryo C: Kritik sorgu performansı ve yoğun veri kullanımı

Öneri: Kendinize ait performans metrikleriyle karar verin - Her iki model de performans verebilir; asıl fark I/O ve tuning imkânıdır. - Managed seçerseniz sağlayıcının performans olaylarına müdahale süresi ve darboğaz tespit süreci dokümante olmalı. - Self-hosted seçerseniz CPU/RAM/IO izleme ve kapasite planlama rutininizi yazılı hale getirin.

Sonuç: Hızlı aksiyon planı

MongoDB hostingte managed mi self-hosted mı sorusunun cevabı, “kurulumdan sonra yönetim yükü”nün kime ait olduğuna göre netleşir. Eğer DB operasyonuna aylık somut bir zaman ayıramıyorsanız, yedek/restore doğrulama ve failover için öngörü hedefiniz varsa managed seçin. Self-hosted ise özel güvenlik, ağ topolojisi, şeffaf maliyet kontrolü ve gelişmiş cluster tuning ihtiyacı baskınsa doğru yoldur; ancak restore testi ve izleme rutinini önceden prosedürleştirin.

Aksiyon olarak bugün yapmanız gereken tek şey: Seçmeden önce iki kontrol listesine yazılı cevap alın. (1) Yedekleme/restore (RPO/RTO), (2) ağ erişimi ve loglama (TLS, IP kısıtı, audit/log retention). Bu iki sorunun cevabı netleştiğinde karar tek bir modele daralır.