Infrastructure as Code ile Disaster Recovery Planı Oluşturmak

Infrastructure as Code ile Disaster Recovery Planı Oluşturmak

Sunucu arızaları, veri merkezi kesintileri veya siber saldırılar her an gerçekleşebilir. Infrastructure as Code (IaC) ile disaster recovery planınızı kod olarak tanımlayarak, felaket anında dakikalar içinde altyapınızı yeniden oluşturabilirsiniz. Bu rehberde RPO/RTO kavramlarından Terraform multi-re

Sunucu arızaları, veri merkezi kesintileri veya siber saldırılar her an gerçekleşebilir. Infrastructure as Code (IaC) ile disaster recovery planınızı kod olarak tanımlayarak, felaket anında dakikalar içinde altyapınızı yeniden oluşturabilirsiniz. Bu rehberde RPO/RTO kavramlarından Terraform multi-region kurulumuna, otomatik yedeklemeden failover otomasyonuna kadar tüm DR sürecini inceliyoruz.

DR Temel Kavramları: RPO ve RTO

Disaster recovery planının temelini iki kritik metrik oluşturur: RPO (Recovery Point Objective) kabul edilebilir veri kaybı süresini, RTO (Recovery Time Objective) ise kabul edilebilir kesinti süresini tanımlar.

Metrik Tanım Örnek IaC ile Hedef
RPO Maksimum veri kaybı süresi Son 1 saatlik veri Dakikalar (otomatik replikasyon)
RTO Maksimum kesinti süresi 4 saat Dakikalar (otomatik failover)
MTTR Ortalama onarım süresi 2 saat Dakikalar (kod ile yeniden oluşturma)

💡 İpucu: RPO ve RTO değerlerini iş gereksinimlerinize göre belirleyin. E-ticaret siteleri için RPO 5 dakika ve RTO 15 dakika hedeflenirken, dahili araçlar için RPO 1 saat ve RTO 4 saat kabul edilebilir olabilir.

Terraform ile Multi-Region Altyapı

Terraform modülleri kullanarak birincil ve DR bölgelerinde aynı altyapıyı kod olarak tanımlayabilirsiniz. Bu sayede felaket anında DR bölgesini dakikalar içinde aktif hale getirebilirsiniz.

main.tf
# Birincil bölge (Primary)
module "primary" {
  source    = "./modules/infrastructure"
  region    = "eu-west-1"
  env       = "production"
  is_primary = true

  instance_count = 3
  instance_type  = "c5.xlarge"
  db_multi_az    = true
}

# DR bölgesi (Standby)
module "dr" {
  source    = "./modules/infrastructure"
  region    = "us-east-1"
  env       = "dr"
  is_primary = false

  # DR'da daha az kaynak (maliyet optimizasyonu)
  instance_count = 1
  instance_type  = "c5.large"
  db_multi_az    = false
}

IaC ile Otomatik Yedekleme Yapılandırması

Yedekleme stratejinizi de kod olarak tanımlayarak, tutarlı ve tekrarlanabilir backup süreçleri oluşturabilirsiniz. Aşağıdaki Terraform konfigürasyonu veritabanı ve dosya sistemi yedeklemelerini otomatikleştirir.

backup.tf
# Otomatik veritabanı yedekleme
resource "aws_db_instance" "primary" {
  identifier              = "app-db-primary"
  engine                  = "postgres"
  engine_version          = "15.4"
  instance_class          = "db.r6g.large"

  # Yedekleme ayarları
  backup_retention_period = 30
  backup_window           = "03:00-04:00"
  copy_tags_to_snapshot   = true

  # Cross-region replikasyon
  replicate_source_db     = null
}

# DR bölgesine cross-region replica
resource "aws_db_instance" "dr_replica" {
  provider            = aws.dr
  replicate_source_db = aws_db_instance.primary.arn
  instance_class      = "db.r6g.large"
}

Failover Otomasyonu

Manuel failover süreçleri hata yapma riskini artırır ve zaman kaybettirir. DNS tabanlı failover ile otomatik geçiş yapılandırabilirsiniz.

failover.tf
# Health check - birincil bölge
resource "aws_route53_health_check" "primary" {
  fqdn              = "primary.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3
  request_interval  = 10
}

# DNS failover kaydı
resource "aws_route53_record" "primary" {
  zone_id         = var.zone_id
  name            = "app.example.com"
  type            = "A"
  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id

  failover_routing_policy {
    type = "PRIMARY"
  }

  alias {
    name    = module.primary.lb_dns_name
    zone_id = module.primary.lb_zone_id
  }
}

⚠️ Dikkat: DNS failover'da TTL değerini düşük tutun (60 saniye gibi). Yüksek TTL değerleri, failover sonrası kullanıcıların hala eski IP'ye yönlendirilmesine neden olabilir.

DR Test Checklist

DR planınızı düzenli olarak test etmeden, gerçek bir felaket anında çalışacağından emin olamazsınız. Aşağıdaki checklist'i üç ayda bir uygulayın.

  • Terraform state dosyasının remote backend'de güncel olduğunu doğrulayın
  • DR bölgesinde terraform plan çalıştırarak drift kontrolü yapın
  • Veritabanı replica'sının senkronizasyon gecikmesini kontrol edin (lag < 1 dakika)
  • DNS failover'ı simüle ederek geçiş süresini ölçün
  • DR ortamında uygulama smoke testlerini çalıştırın
  • Yedeklerden geri yükleme (restore) testi yapın
  • Failback (birincil bölgeye geri dönüş) prosedürünü test edin
  • Tüm sonuçları dokümante edin ve RPO/RTO hedeflerini karşılayıp karşılamadığını raporlayın

Terraform temelleri için Terraform IaC rehberimizi, yedekleme stratejileri için Snapshot ve Yedekleme rehberimizi, sunucu izleme için Prometheus + Grafana rehberimizi inceleyin. HashiCorp Terraform Tutorials ve AWS Disaster Recovery Whitepaper ek kaynak olarak faydalıdır.

Sıkça Sorulan Sorular

IaC olmadan disaster recovery yapılamaz mı?

Yapılabilir ancak manuel süreçler hata yapma riskini artırır ve kurtarma süresini uzatır. IaC ile altyapınızı dakikalar içinde yeniden oluşturabilirsiniz. Manuel kurulumda saatler hatta günler sürebilecek işlemler otomatikleşir.

DR bölgesi sürekli çalışmak zorunda mı?

Hayır. Warm standby (minimum kaynaklarla çalışan) veya pilot light (sadece veritabanı replikasyonu) stratejileri ile maliyeti düşürebilirsiniz. Felaket anında IaC ile kaynakları hızla ölçeklendirebilirsiniz.

Terraform state dosyası kaybolursa ne olur?

State dosyası kaybolursa Terraform mevcut altyapıyı tanıyamaz. Bu nedenle state'i S3 + DynamoDB gibi remote backend'de saklayın, versiyonlama ve kilitleme aktif olsun. State dosyasının da yedeklenmesi kritiktir.

DR testleri ne sıklıkla yapılmalı?

En az üç ayda bir tam DR testi yapılmalıdır. Kritik sistemler için aylık testler önerilir. Her büyük altyapı değişikliğinden sonra da DR planını doğrulamak gerekir.

Sonuç

Infrastructure as Code ile disaster recovery planınızı versiyonlanabilir, test edilebilir ve tekrarlanabilir hale getirin. Terraform multi-region modülleri ile altyapınızı tanımlayın, otomatik yedekleme ve failover mekanizmalarını kurun ve düzenli DR testleri ile planınızın çalıştığından emin olun.

Felaket Kurtarma İçin Güvenilir Altyapı

Hosted Cloud sunucuları ile DR planınızı güvenle uygulayın.

Bulut Sunucu Planlarını İncele →
A

Ahmet Yılmaz

Kıdemli Altyapı Mühendisi

10 yılı aşkın bulut altyapısı ve DevOps deneyimiyle Hosted Cloud'un teknik ekibinde yer almaktadır. Kubernetes, Terraform ve yüksek erişilebilirlik mimarileri üzerine uzmanlaşmıştır.

Yorumlar yakında