MongoDB Atlas Kullanımı ve Yönetimi: Kapsamlı Rehber

yazar

Bulut tabanlı veritabanı çözümleri artık modern uygulama geliştirmenin vazgeçilmez bir parçası haline geldi. MongoDB Atlas, kendi sunucularında MongoDB kurmanın karmaşıklığından kurtulup tamamen yönetilen bir hizmet üzerinden çalışmak isteyen ekipler için mükemmel bir seçenek. Ancak “yönetilen servis” demek “yönetim yok” demek değil. Atlas’ı doğru kullanmak, maliyetleri kontrol altında tutmak ve performansı optimize etmek için ciddi bir öğrenme eğrisi var. Bu yazıda gerçek dünya senaryoları üzerinden Atlas’ı nasıl kuracağınızı, yöneteceğinizi ve izleyeceğinizi ele alacağız.

MongoDB Atlas Nedir ve Ne Zaman Kullanılır

MongoDB Atlas, MongoDB şirketinin sunduğu tam yönetilen cloud veritabanı servisidir. AWS, Google Cloud ve Azure üzerinde çalışabiliyor ve multi-cloud senaryolarını bile destekliyor. Kendi sunucunuzda MongoDB kurmanın getirdiği yük; yama yönetimi, yedekleme, replikasyon konfigürasyonu gibi işleri Atlas sizin adınıza hallediyor.

Ancak Atlas her proje için doğru seçim olmayabilir. Şu durumlarda Atlas’ı tercih etmek mantıklı:

  • Ekibinizde dedicated DBA yoksa ve operasyonel yükü azaltmak istiyorsanız
  • Hızlı ölçeklendirme ihtiyacınız varsa
  • Coğrafi dağıtım (Global Clusters) gerektiren bir uygulamanız varsa
  • Compliance gereksinimleriniz varsa (SOC 2, HIPAA, GDPR)
  • Startup veya küçük-orta ölçekli ekiplerseniz

Kendi veri merkezinizde tam kontrol istiyorsanız veya çok büyük veri hacimleriyle çalışıyorsanız, self-hosted MongoDB veya MongoDB Ops Manager daha uygun olabilir.

Atlas CLI Kurulumu ve İlk Adımlar

Atlas’ı web arayüzünden yönetebilirsiniz ama sysadmin olarak CLI tercih etmek hem otomasyon hem de tekrarlanabilirlik açısından çok daha sağlıklı.

# macOS
brew install mongodb-atlas-cli

# Linux (Debian/Ubuntu)
wget -qO - https://www.mongodb.org/static/pgp/server-6.0.asc | sudo apt-key add -
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu focal/mongodb-org/6.0 multiverse" | 
  sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list
sudo apt-get update
sudo apt-get install -y mongodb-atlas-cli

# Versiyon kontrolü
atlas --version

Kurulum sonrası kimlik doğrulama:

# Interaktif login
atlas auth login

# API key ile login (CI/CD ortamları için önerilir)
export MONGODB_ATLAS_PUBLIC_KEY="your_public_key"
export MONGODB_ATLAS_PRIVATE_KEY="your_private_key"
export MONGODB_ATLAS_ORG_ID="your_org_id"

# Bağlantıyı test et
atlas auth whoami

API key oluştururken dikkat edilmesi gereken nokta: Organization API key ile Project API key farklı şeyler. Eğer birden fazla projeyi yönetiyorsanız Organization level key almanız daha pratik oluyor, ancak güvenlik açısından project-level key’ler daha az yetki verdiği için tercih edilebilir.

Cluster Oluşturma ve Konfigürasyon

# Yeni bir proje oluştur
atlas projects create "production-app" --orgId <ORG_ID>

# Projeleri listele ve ID'yi al
atlas projects list

# M10 tier ile bir cluster oluştur (production için minimum önerilen)
atlas clusters create prod-cluster 
  --projectId <PROJECT_ID> 
  --provider AWS 
  --region EU_WEST_1 
  --tier M10 
  --members 3 
  --type REPLICASET 
  --mdbVersion 7.0

# Cluster durumunu izle
atlas clusters watch prod-cluster --projectId <PROJECT_ID>

Tier seçimi kritik bir karar. Gerçek dünyada sık yapılan hata, geliştirme ortamı için M0 (free tier) kullanıp production’da da aynı davranışı beklemek. M0 ile M10+ arasında performans ve özellik açısından ciddi farklar var:

  • M0/M2/M5: Shared cluster, production için uygun değil, geliştirme ve test için ideal
  • M10: Dedicated cluster başlangıcı, küçük production workload’ları için uygun
  • M30 ve üzeri: Yüksek throughput gerektiren uygulamalar için
  • M80+: Enterprise workload’lar, büyük veri hacimleri

Network Erişimi ve Güvenlik Konfigürasyonu

Atlas’ta güvenlik katmanlı bir yapıda çalışıyor. Network erişimini doğru ayarlamak, saldırı yüzeyini minimize etmenin en temel adımı.

# IP whitelist ekle (tek IP)
atlas accessLists create 
  --projectId <PROJECT_ID> 
  --ip "203.0.113.42" 
  --comment "Office NAT IP"

# CIDR block ekle (bir subnet için)
atlas accessLists create 
  --projectId <PROJECT_ID> 
  --cidr "10.0.0.0/8" 
  --comment "Internal VPC range"

# Mevcut access list'i görüntüle
atlas accessLists list --projectId <PROJECT_ID>

# VPC Peering için (AWS örneği)
atlas networking peering create aws 
  --projectId <PROJECT_ID> 
  --awsAccountId "123456789012" 
  --vpcId "vpc-0a1b2c3d4e5f" 
  --routeTableCidrBlock "172.31.0.0/16" 
  --region eu-west-1

Güvenlik açısından 0.0.0.0/0 kullanmaktan kaçının. Bu, tüm internete veritabanı portunu açmak demek. Eğer dinamik IP’ler ile çalışıyorsanız ya VPN kullanın ya da programatik olarak IP güncelleme mekanizması kurun.

Database user yönetimi için:

# Yeni database kullanıcısı oluştur
atlas dbusers create 
  --projectId <PROJECT_ID> 
  --username "app-user" 
  --password "$(openssl rand -base64 32)" 
  --role "readWrite@production_db"

# Read-only kullanıcı (analytics için)
atlas dbusers create 
  --projectId <PROJECT_ID> 
  --username "analytics-user" 
  --password "$(openssl rand -base64 32)" 
  --role "read@production_db"

# Kullanıcıları listele
atlas dbusers list --projectId <PROJECT_ID>

Şifreleri asla hardcode etmeyin. Yukarıdaki örnekte openssl rand ile random şifre üretip bunu bir secret manager’a (AWS Secrets Manager, HashiCorp Vault) kaydetmek çok daha güvenli bir yaklaşım.

Bağlantı String’i ve Uygulama Entegrasyonu

# Connection string'i al
atlas clusters connectionStrings describe prod-cluster 
  --projectId <PROJECT_ID>

# Çıktıyı parse etmek için jq kullan
atlas clusters connectionStrings describe prod-cluster 
  --projectId <PROJECT_ID> 
  --output json | jq -r '.standardSrv'

Uygulama tarafında connection string kullanırken dikkat edilmesi gereken parametreler:

  • retryWrites=true: Geçici ağ hatalarında yazma işlemlerini otomatik retry yapar
  • w=majority: Yazma işleminin majority’e ulaşmasını bekler, veri kaybını önler
  • maxPoolSize: Bağlantı havuzu boyutu, uygulamanızın eş zamanlı isteğine göre ayarlayın
  • connectTimeoutMS: Bağlantı timeout süresi
  • serverSelectionTimeoutMS: Driver’ın uygun server bulması için bekleme süresi

Örnek bir production connection string formatı:

mongodb+srv://app-user:[email protected]/production_db?retryWrites=true&w=majority&maxPoolSize=50&connectTimeoutMS=10000

Yedekleme Stratejisi ve Restore İşlemleri

Atlas iki tür backup sunuyor: Cloud Backup (snapshot tabanlı, M10 ve üzeri) ve Legacy Backup (artık önerilmiyor). Cloud Backup kullanmak istiyorsanız cluster tier en az M10 olmalı.

# Backup politikasını görüntüle
atlas backups schedule describe prod-cluster 
  --projectId <PROJECT_ID>

# Backup politikasını güncelle (daha sık snapshot için)
atlas backups schedule update prod-cluster 
  --projectId <PROJECT_ID> 
  --referenceHourOfDay 2 
  --referenceMinuteOfHour 0 
  --restoreWindowDays 7

# Manuel snapshot al (önemli deployment öncesi)
atlas backups snapshots create prod-cluster 
  --projectId <PROJECT_ID> 
  --desc "Pre-deployment snapshot - v2.3.0"

# Mevcut snapshot'ları listele
atlas backups snapshots list prod-cluster 
  --projectId <PROJECT_ID>

Gerçek dünyada backup’ın değeri sadece restore ettiğinizde anlaşılıyor. Bu nedenle düzenli restore testleri yapmak şart. Bir staging cluster’a restore işlemi yapmayı alışkanlık haline getirin:

# Snapshot ID'yi al
SNAPSHOT_ID=$(atlas backups snapshots list prod-cluster 
  --projectId <PROJECT_ID> 
  --output json | jq -r '.[0].id')

# Automated restore (başka bir cluster'a)
atlas backups restores start automated 
  --projectId <PROJECT_ID> 
  --clusterName prod-cluster 
  --snapshotId $SNAPSHOT_ID 
  --targetClusterName staging-cluster 
  --targetProjectId <STAGING_PROJECT_ID>

# Restore durumunu takip et
atlas backups restores watch 
  --projectId <PROJECT_ID> 
  --clusterName prod-cluster 
  --restoreJobId <JOB_ID>

Performans İzleme ve Optimizasyon

Atlas’ın en güçlü özelliklerinden biri gerçek zamanlı performans izleme araçları. Web UI’daki Performance Advisor ve Real-Time Performance Panel çok kullanışlı, ama bunları CLI ve API üzerinden de otomatize edebilirsiniz.

# Slow query'leri tespit et (Performance Advisor önerileri)
atlas performanceAdvisor suggestedIndexes list 
  --projectId <PROJECT_ID> 
  --clusterName prod-cluster 
  --output json | jq '.suggestedIndexes[] | {namespace: .namespace, impact: .impact, index: .index}'

# Namespace bazında slow query'leri incele
atlas performanceAdvisor slowQueryLogs list 
  --projectId <PROJECT_ID> 
  --clusterName prod-cluster 
  --since 1700000000 
  --duration 3600000

Index optimizasyonu için şu senaryoyu düşünün: E-ticaret uygulamanızda kullanıcıların siparişlerini sorguladığınızı varsayalım. userId ve createdAt alanlarına sık sık filtre uyguluyorsanız compound index oluşturmak sorgu süresini dramatik şekilde düşürebilir.

# mongosh ile bağlanıp index oluştur
mongosh "mongodb+srv://..." --eval "
db.orders.createIndex(
  { userId: 1, createdAt: -1 },
  { background: true, name: 'idx_userId_createdAt' }
)"

# Index kullanımını kontrol et
mongosh "mongodb+srv://..." --eval "
db.orders.find({ userId: 'user123' })
  .sort({ createdAt: -1 })
  .explain('executionStats')
" | jq '.executionStats.totalDocsExamined, .executionStats.totalKeysExamined'

totalDocsExamined değeri totalKeysExamined değerine eşit veya yakınsa index düzgün çalışıyor demektir. Eğer totalDocsExamined çok yüksekse collection scan yapılıyor olabilir.

Monitoring ve Alert Konfigürasyonu

Proaktif monitoring olmadan sorunları kullanıcılarınız sizi bilgilendirmeden önce fark edemezsiniz. Atlas’ta alert konfigürasyonu şöyle yapılır:

# Alert konfigürasyonunu listele
atlas alerts settings list --projectId <PROJECT_ID>

# Yeni alert oluştur (CPU kullanımı %80 aştığında)
atlas alerts settings create 
  --projectId <PROJECT_ID> 
  --event OUTSIDE_METRIC_THRESHOLD 
  --metricName NORMALIZED_SYSTEM_CPU 
  --operator GREATER_THAN 
  --threshold 80 
  --units RAW 
  --notifications EMAIL 
  --notificationEmailAddress "[email protected]" 
  --notificationIntervalMin 30

# Mevcut aktif alertleri görüntüle
atlas alerts list --projectId <PROJECT_ID> --status OPEN

Izlenmesi gereken kritik metrikler:

  • NORMALIZED_SYSTEM_CPU: CPU kullanımı, %80 üzeri sorun işareti
  • CONNECTIONS: Bağlantı sayısı, maxPoolSize değerinizin %80’ini geçmemeli
  • OPCOUNTER_QUERY: Saniyedeki sorgu sayısı, baseline’dan sapma tespiti için
  • DISK_PARTITION_SPACE_FREE: Disk doluluk oranı, %20 altına düştüğünde alert alın
  • REPLICATION_OPLOG_WINDOW_RUNNING_OUT: Oplog penceresi daralıyorsa replication lag sorunu var demektir
  • NO_PRIMARY: Primary node kaybolmuşsa kritik alert
  • QUERY_TARGETING_SCANNED_OBJECTS_PER_RETURNED: 1000’in üzeriyse index sorunu var

Atlas Data API ve Serverless Entegrasyon

Modern uygulamalarda bazen driver kullanmak yerine HTTP API üzerinden MongoDB’ye bağlanmak isteyebilirsiniz. Atlas Data API bu ihtiyacı karşılıyor.

# Data API'yi aktif et (Atlas App Services üzerinden)
# Önce App ID'nizi alın

# Curl ile veri ekleme
curl --request POST 
  'https://data.mongodb-api.com/app/<APP_ID>/endpoint/data/v1/action/insertOne' 
  --header 'Content-Type: application/json' 
  --header 'api-key: <DATA_API_KEY>' 
  --data '{
    "collection": "orders",
    "database": "production_db",
    "dataSource": "prod-cluster",
    "document": {
      "userId": "user123",
      "product": "Widget A",
      "quantity": 5,
      "createdAt": {"$date": {"$numberLong": "1700000000000"}}
    }
  }'

# Find işlemi
curl --request POST 
  'https://data.mongodb-api.com/app/<APP_ID>/endpoint/data/v1/action/find' 
  --header 'Content-Type: application/json' 
  --header 'api-key: <DATA_API_KEY>' 
  --data '{
    "collection": "orders",
    "database": "production_db",
    "dataSource": "prod-cluster",
    "filter": {"userId": "user123"},
    "sort": {"createdAt": -1},
    "limit": 10
  }'

Data API serverless fonksiyonlar, edge computing ve driver yüklemek istemediğiniz ortamlar için idealdir. Ancak yüksek throughput gerektiren uygulamalar için native driver kullanmak performans açısından çok daha iyi.

Maliyet Yönetimi ve Optimizasyon

Atlas maliyetleri hızla artabilir. Özellikle dikkat edilmesi gereken noktalar:

Cluster tier ve boyutu doğru seçin. Workload analizi yapmadan tier yükseltmek yerine önce mevcut konfigürasyonu optimize edin. Sık yapılan hatalar:

  • Geliştirme ortamı için M10+ tier kullanmak (M0 veya M2 yeterli)
  • Test ortamı cluster’larını hafta sonları kapatmamak
  • Gereksiz data transfer maliyetleri

Atlas cluster’larını programatik olarak durdurma/başlatma (M10+ için pause özelliği var):

# Cluster'ı duraklat (geliştirme/test ortamı için)
atlas clusters pause dev-cluster --projectId <PROJECT_ID>

# Cluster'ı yeniden başlat
atlas clusters start dev-cluster --projectId <PROJECT_ID>

# Cron job ile mesai saatleri dışı otomatik durdurma (bash script)
#!/bin/bash
# /usr/local/bin/atlas-cluster-pause.sh
PROJECT_ID="your_project_id"
CLUSTER_NAME="dev-cluster"

if [ "$(date +%u)" -ge 6 ]; then
  # Hafta sonu - cluster'ı durdur
  atlas clusters pause $CLUSTER_NAME --projectId $PROJECT_ID
  echo "$(date): $CLUSTER_NAME paused for weekend" >> /var/log/atlas-scheduler.log
fi

Bu scripti crontab’a ekleyerek her Cuma akşamı çalıştırabilirsiniz:

# Crontab ayarı
0 20 * * 5 /usr/local/bin/atlas-cluster-pause.sh
0 8 * * 1 atlas clusters start dev-cluster --projectId YOUR_PROJECT_ID

Disaster Recovery ve Yüksek Erişilebilirlik

Atlas, Multi-Region cluster konfigürasyonu ile gerçek anlamda disaster recovery senaryolarını destekliyor. Ancak bu konfigürasyon maliyet açısından önemli bir artış getiriyor.

Tipik bir production kurulumu için önerilen mimari:

  • Primary region: eu-west-1 (Ireland) – 2 data node
  • Secondary region: eu-central-1 (Frankfurt) – 1 data node
  • Analytics node: Reporting sorguları için ayrı node, production performansını etkilemez

Multi-region cluster oluşturmak için Atlas web UI kullanmak genellikle daha pratik, ancak Terraform ile bu işi IaC kapsamına alabilirsiniz. mongodbatlas Terraform provider’ı oldukça olgunlaşmış durumda ve production ortamları için kesinlikle öneriyorum.

Failover testini düzenli yapmak şart. Atlas, “Test Failover” özelliğiyle primary node’u kasıtlı olarak düşürüp recovery süresini ölçmenize olanak tanıyor. Genellikle 30-60 saniye içinde otomatik failover gerçekleşiyor. Bu süreyi uygulamanızın tolerans ettiğinden emin olun ve connection retry logic’inizi buna göre ayarlayın.

Sonuç

MongoDB Atlas, doğru konfigüre edildiğinde operasyonel yükü ciddi ölçüde azaltan güçlü bir platform. Ancak “yönetilen servis” yanılgısına düşmemek gerekiyor. Network güvenliği, kullanıcı yönetimi, backup testleri, alert konfigürasyonu ve maliyet optimizasyonu gibi konular hala sizin sorumluluğunuzda.

Özellikle şu pratik noktalara dikkat edin: IP whitelist’i 0.0.0.0/0 açmayın, şifreleri secret manager’da saklayın, backup’larınızı düzenli aralıklarla gerçek ortamda test edin ve Performance Advisor önerilerini görmezden gelmeyin. Atlas’ın sunduğu izleme araçları çok güçlü, bunları aktif olarak kullanmak sorunları production’a yansımadan önce yakalamanızı sağlıyor.

Son olarak, tüm Atlas konfigürasyonunuzu Terraform veya Atlas CLI scriptleriyle code olarak yönetin. Bir gün production cluster’ınızı yeniden oluşturmanız gerekirse ya da yeni bir proje başlatırken aynı standartları uygulamak istediğinizde, her şeyin kod olarak versiyonlanmış olması paha biçilmez bir avantaj sağlıyor.

Yorum yapın