Google ACE: Güvenilirlik, Yedekleme ve Felaket Kurtarma — Çalışma kılavuzu

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

Şunun bir parçası: Google Associate Cloud Engineer — Çalışma kılavuzu. Doğrulanmış cevaplarla şurada pratik yapın: Google sınav merkezi, veya şurada süreli deneme sınavları çözün: ExamRoll.io.

Genel Bakış

Google Cloud’da güvenilirlik, yedekleme ve felaket kurtarma; hata etki alanları, veri koruma mekanizmaları, trafik yönetimi ve operasyonel hazırlık konularında bilinçli bir tasarım gerektirir. Bu bölümde, servislerin zone’lar ve region’lar arasında nasıl yapılandırılacağı, durum bilgisi olan (stateful) verilerin nasıl korunacağı ve geri yükleneceği, ayrıca disiplinli runbook’lar ve sürekli dayanıklılık testleri ile kurtarma hedeflerinin nasıl doğrulanacağı açıklanmaktadır. Ayrıca, platformun tanımlanmış kurtarma süresi (RTO) ve kurtarma noktası (RPO) hedefleri dahilinde kurtarılabilmesini sağlamak için DR (Felaket Kurtarma) stratejisi ödünleşimleri ve kapasite planlaması ana hatlarıyla belirtilmektedir.

Hata Etki Alanları ve Bölgesel Tasarım

• Zone’lar, region’lar ve çok bölgeli (multi-region) servisler

  • Zone’lar en küçük bağımsız hata etki alanlarıdır. Tek bir zone arızası, bölgesel (regional) bir servisi kesintiye uğratmamalıdır.
  • Region’lar, bağımsız zone’ları düşük gecikmeli bağlantılarla gruplar. Bölgesel tasarımlar zone arızalarından etkilenmez, ancak tam bölgesel olaylardan her zaman etkilenmeyebilir.
  • Çok bölgeli (multi-region) servisler, region’lar arasında replikasyon yaparak daha yüksek maliyet ve potansiyel olarak daha yüksek yazma gecikmesi karşılığında bölgesel bir kayba karşı koruma sağlar.
  • Tasarım ilkesi: önemsediğiniz en küçük hata etki alanında tekil hata noktalarından kaçının. RTO/RPO’nuz bir zone arızasından etkilenmemeyi gerektiriyorsa, en az iki zone’a dağıtım yapın. Bölgesel ayakta kalabilirlik için, aktif bileşenleri birden çok region’a dağıtın veya çok bölgeli (multi-region) servisleri kullanın.

• Managed instance groups (MIG) ve kendi kendini onarma

  • Instance’ları tek bir region içindeki zone’lara dağıtmak için bölgesel (regional) MIG’leri tercih edin. Bu, ayrı bir araç gerektirmeden zone kesintilerinin etkisini azaltır.
  • Load balancer sağlık kontrolleri, sağlıksız VM’leri trafikten çıkarır. MIG otomatik onarımı, sağlıksız veya yanıt vermeyen VM’leri değiştirir. Her ikisini de kullanın.
  • Hazırlık (readiness) endpoint’lerini ve bağımlılıkları doğrulayan uygulama seviyesinde HTTP(S) sağlık kontrolleri kullanın. Bir TCP kontrolü yalnızca port erişilebilirliğini doğrular.
  • Otomatik onarımın yanlış yapılandırılmasına bağlı hata modu: yalnızca bir load balancer sağlık kontrolü kullanmak, sorunlu bir instance’a giden trafiği engeller ancak onu yeniden oluşturmaz. Instance’ın değiştirilmesi için MIG’in kendi sağlık kontrolünü ve başlatma (boot) sırasında erken yeniden başlatmaları önlemek için bir başlangıç gecikmesi (initial delay) yapılandırın.

Örnek:

• Yaklaşık 30 saniye sonra kendi kendini onarmayı tetiklemek için 10 saniyelik aralıklarla ve 3 sağlıksız eşik değeriyle bir uygulama sağlık kontrolü oluşturun: gcloud compute health-checks create http hc-app
  –check-interval=10s –timeout=5s
  –unhealthy-threshold=3 –healthy-threshold=1 –request-path=/healthz

• Otomatik onarım için sağlık kontrolünü bölgesel bir MIG’e ekleyin: gcloud compute instance-groups managed update my-rmig
  –region=us-central1 –health-check=hc-app –initial-delay=60

• Çok bölgeli (multi-region) hususlar

  • Global external HTTP(S) Load Balancing, sağlık kontrollerine dayalı otomatik yük devretme (failover) ile birden çok region’daki backend’leri destekler.
  • Region’lar arasında durum (state) senkronizasyonu kritik bir ödünleşimdir. Aktif-aktif mimaride verim (throughput) yüksektir, ancak tutarlılık ve çakışma çözümü tasarlanmalıdır. Aktif-pasif mimari daha basittir ancak daha yavaş yük devretme (failover) süresine ve potansiyel olarak daha büyük bir RPO’ya sahiptir.

Veri Koruma: Veritabanları, Depolama ve Bilişim

• Cloud SQL yüksek erişilebilirlik ve replikalar
  • Yüksek erişilebilirlik yapılandırması, farklı bir zone’da senkron replikasyon ile bir yedek (standby) sunucu konumlandırır. Birincil sunucuda bir arıza olduğunda otomatik yük devretme (failover) gerçekleşir. RTO genellikle birkaç dakikadır; RPO bölge içinde ≈ 0’dır ancak devam eden işlemleri (in-flight transactions) göz önünde bulundurun.
  • Okuma replikaları (read replicas) okuma yükünü azaltır ve olağanüstü durum kurtarma (DR) için bölgeler arası (cross-region) olabilir. Bunlar asenkrondur; replikasyon gecikmesi (replication lag) ve sıfır olmayan bir RPO bekleyin.
  • Yedeklemeler ve PITR
    • Otomatik yedeklemeleri ve belirli bir zamana geri dönmeyi (point-in-time recovery - PITR) etkinleştirin. MySQL için ikili günlük kaydını (binary logging) etkinleştirin; PostgreSQL için PITR saklama süresini (retention) etkinleştirin.
    • Geri yükleme akışları: bozulma veya kullanıcı hatası durumunda, belirli bir zaman damgasında yeni bir örneğe (instance) geri yükleyin, uygulamaları veya replikaları geri yüklenen örneğe yönlendirin ve veriyi doğrulayın.
  • Arıza modları ve ödünleşimler
    • Yüksek erişilebilirlik (HA), mantıksal veri bozulmasına karşı koruma sağlamaz; yedeklemeler ve PITR sağlar.
    • Bölgeler arası replikalar bölgesel kayıplara karşı koruma sağlar ancak gecikme yaşayabilir; kabul edilebilir RPO’nuzu test edin.

Örnek:

• İkili günlük kaydını (MySQL) ve otomatik yedeklemeleri etkinleştirin:

undefined

• Persistent disk (PD) anlık görüntüleri (snapshot) ve makine imajları
  • PD anlık görüntüleri, disklerin artımlı (incremental) ve çökme anıyla tutarlı (crash-consistent) yedekleridir. Depolama konumları yapılandırılabilir ve anlık görüntünün konum kapsamındaki herhangi bir zone’da yeni diskler oluşturmak için kullanılabilirler.
  • Uygulama tutarlı (application-consistent) yedeklemeler elde etmek için, dosya sistemini ve uygulamayı hareketsiz duruma getirin (quiesce) veya anlık görüntüleri veritabanına özgü yedekleme mekanizmalarıyla koordine edin.
  • Makine imajları, diskleri ve örnek meta verilerini (önyükleme diskleri, ekli diskler, örnek özellikleri) yakalar. Daha hızlı filo kurtarma veya “altın” bir sunucu yapılandırmasını klonlamak için makine imajlarını kullanın.
  • Anlık görüntü zamanlama politikaları yedeklemeleri otomatikleştirir; saklama süresini (retention) zorunlu kılar; kritik diskleri buna göre etiketleyin.
  • Geri yükleme iş akışı: anlık görüntüden bir disk oluşturun, yeni bir örneğe bağlayın, başlangıç betiklerini ve hizmet hesaplarını güncelleyin, ardından trafiği yeniden yönlendirmeden önce uygulama bütünlüğünü doğrulayın.

Örnek:

• Bir anlık görüntü oluşturun ve yeni bir diske geri yükleyin:

undefined

undefined

• Cloud Storage replikasyonu, sürüm oluşturma ve saklama
  • Depolama sınıfı seçenekleri: Sık erişilen (hot) veriler için Standard; ayda bir seyrek erişim için Nearline; üç ayda bir erişim için Coldline (yedekleme ve DR için önerilir); uzun süreli, nadiren erişilen veriler için Archive.
  • Regional, Dual-Region ve Multi-Region bucket’lar replikasyon yoluyla dayanıklılık sunar. Turbo replikasyonlu Dual-Region, yeni yazılan nesneler için replikasyon RPO’sunu sınırlayabilir; Multi-Region geniş coğrafi esneklik sunar.
  • Nesne sürüm oluşturma (Object versioning), güncel olmayan sürümleri saklayarak yanlışlıkla silmelere ve üzerine yazmalara karşı koruma sağlar. WORM (Write Once, Read Many) saklama politikasını zorunlu kılmak için saklama politikaları (retention policies) ve bucket kilidi (bucket lock) ile birleştirin.
  • Yanlışlıkla silmeye karşı koruma: Object Versioning’i etkinleştirin, kilitli bir saklama politikası kullanın, yasal veya işleme süreçleri için olay tabanlı bekletmeleri (event-based holds) uygulayın, IAM ve tek tip bucket düzeyinde erişim (uniform bucket-level access) aracılığıyla silmeleri kısıtlayın. Harici, zaman sınırlı erişim için, katı son kullanma tarihlerine sahip imzalı URL’ler (signed URLs) kullanın.

90 gün sonra Coldline’a taşımak ve 365 gün sonra silmek için örnek yaşam döngüsü:

• lifecycle.json

undefined

• Uygula:

undefined

Trafik, Kapasite ve Bağımlılık Esnekliği

• DNS ve trafik yönetimi ile yük devretme

  • İnternete yönelik hizmetler için global harici HTTP(S) Load Balancing’i tercih edin; bu, anycast IP’leri kullanır ve bölgeler arasında sağlık durumuna dayalı yük devretme gerçekleştirir.
  • Özel (private) hizmetler için dahili HTTP(S) veya TCP/UDP yük dengeleyicileri kullanın. Birden çok arka uç (backend) ile zone’lardan bağımsız olacak şekilde tasarım yapın.
  • DNS TTL ödünleşimleri: düşük TTL’ler daha hızlı yük devretme sağlar ancak sorgu yükünü artırır ve önbellekleme davranışı nedeniyle bazı çözümleyiciler (resolver) tarafından göz ardı edilebilir.
  • Sağlık kontrolü tabanlı LB yük devretme, yalnızca DNS ile yapılan yük devretmeden daha hızlı ve daha deterministiktir.
  • Ağırlıklı (weighted) veya yük devretme (failover) DNS politikaları, bölge tahliyesi için son çare bir kontrol düzlemi olabilir ancak önbellek süresinin dolmasına dayanır.

• Kapasite planlaması ve kota tasarımı

  • Zone ve bölge başına minimum sağlıklı kapasiteyi belirleyin. Yük devretme için ek kapasite tamponları (“N+1 zone” kapasitesi) uygulayın.
  • Ölçeklenme olayları veya yük devretme sırasında kapasiteyi garanti etmek için kritik Compute Engine şekilleri (shapes) için bölgesel rezervasyonları (regional reservations) kullanın.
  • Kurtarma sırasında kontrol düzlemi gecikmelerini önlemek için IP adreslerini, yönlendirme kurallarını (forwarding rules), Cloud NAT kapasitesini, bağlantı takibini (connection tracking) ve SSL sertifikalarını önceden sağlayın.
  • Kota artışlarını ihtiyaç duymadan çok önce talep edin; ikincil bölgelerdeki ve tüm bağımlılıklardaki (örneğin, bölge başına Cloud SQL örnekleri, VPC başına yönlendirme kuralları, Pub/Sub verim oranı, Cloud KMS QPS) kotaları doğrulayın.
  • Otomatik ölçeklendirme (Autoscaling) ile ilgili dikkat edilmesi gerekenler: bekleme sürelerini (cooldowns) yapılandırın, gerekirse tahmine dayalı otomatik ölçeklendirmeyi (predictive autoscaling) kullanın ve politika gereği tam olarak bir örneği (instance) tutmak için min/maks sınırları belirleyin.

• Bağımlılık esnekliği

  • Bağlı olunan (upstream) ve size bağlı olan (downstream) hizmetlerin envanterini çıkarın. Her biri için arıza davranışını ve geri dönüş (fallback) mekanizmalarını tanımlayın: önbelleğe alınmış yapılandırma, kısıtlı modlar (degraded modes), devre kesiciler (circuit breakers), işlenemeyen mesaj konularına (dead-letter topics) sahip kuyruklar ve geri basınç (backpressure).
  • Kurtarma bölgelerindeki IAM ve hizmet hesabı (service account) kapsamlarını doğrulayın. Eksik roller, DR olayları sırasında genellikle sessiz arızalara neden olur.
  • Şifreleme anahtarları: Cloud KMS anahtar replikalarının veya çok bölgeli (multi-region) anahtarların veri konumuyla uyumlu olduğundan emin olun. İkincil bölgelerdeki anahtar halkası (key-ring) yerelliğini ve IAM’i planlayın.

Dayanıklılık Operasyonları ve Sürekli İyileştirme

• RTO, RPO, kurtarma planları ve runbook’lar

  • RTO, hizmetin ne kadar hızlı bir şekilde yeniden başlaması gerektiğini tanımlar; RPO ise kabul edilebilir veri kaybını tanımlar. Bunları iş etki analizinden (business impact analysis) türetin.
  • Her sistem bileşenini RTO/RPO’yu karşılayan belirli mekanizmalarla eşleştirin: bölgesel (zonal) arızalar için HA (yüksek erişilebilirlik), bölgeler arası (cross-region) arızalar için bölgeler arası replikasyon, bozulmalar (corruption) için yedeklemeler ve dayanıklılık (durability) için depolama sınıfı/replikasyon.
  • Runbook’ları güncel tutun: kesin adımlar, komutlar, kimlik bilgileri erişimi, sağlık doğrulama kontrolleri ve karar ağaçları. Sürümlenmiş, erişim kontrollü bir depoda saklayın ve düzenli olarak prova edin.
  • Kurtarma doğrulaması: gerçek RTO/RPO’yu ölçmek, veri bütünlüğünü doğrulamak ve iyileştirme aksiyonları toplamak için tatbikatlar planlayın. Hem küçük kapsamlı geri yüklemeleri (tablo, disk) hem de tam site kurtarmayı test edin.

• DR (Felaket Kurtarma) stratejileri ve ödünleşimler

  • Active-active: tüm bölgeler trafiğe hizmet eder; veri senkronizasyonu doğru tasarlanırsa minimum RTO ve düşük RPO. Daha yüksek karmaşıklık ve maliyet; çakışma çözümü (conflict resolution) ve global yük dengeleme gerektirir.
  • Active-passive: birincil bölge aktiftir; ikincil bölge ılıktır (warm) ve replike edilmiş verileri alır. Orta düzeyde maliyet; RTO dakikalar ila on dakikalar arasında; replikasyona bağlı olarak sıfır olmayan RPO.
  • Pilot-light: ikincil bölgede minimum kritik hizmetler çalışır (veritabanı replikasyonu, minimum uygulama ayak izi). RTO saatler sürer; maliyet açısından verimlidir; yük devretme (failover) sırasında işlem gücünü (compute) artırmak için dikkatli bir orkestrasyon gerekir.
  • Cold-standby: altyapı kod olarak tanımlanmış ancak sağlanmamıştır (provisioned). RTO günler sürer; en düşük maliyet; sapma (drift), kotalar ve kapasite kıtlığından kaynaklanan sürpriz riskleri.

• Kaos testi ve arıza simülasyonları

  • Düzenli olarak sanal makine (instance) çökmelerini, işlem takılmalarını, sağlık kontrolü (health check) arızalarını, diskin dolması durumlarını ve bağımlılık kesintilerini simüle edin. Sanal makineleri sonlandırmak, arka uçlara (backend) giden çıkış trafiğini (egress) engellemek veya proxy katmanında gecikme (latency) eklemek için araçlar veya betikler kullanın.
  • Sağlık kontrolü uç noktasını (health endpoint) kasıtlı olarak başarısız kılarak MIG otomatik iyileştirme (autohealing) ve LB (yük dengeleyici) tarafından kaldırma işlemlerini doğrulayın. Değiştirme davranışını ve kurtarma zaman çizelgelerini onaylayın.
  • Bölgesel tahliye (regional evacuation) alıştırması yapın: bir bölgedeki arka uçları boşaltın (drain), global yük dengeleyicinin yük devretmesini (failover) gözlemleyin ve ikincil bölgedeki durum bilgisi olan (stateful) bağımlılıkları doğrulayın.
  • Sürekli iyileştirme: testler sırasında ortalama tespit süresi (mean time to detect), yük devretme süresi ve veri kaybı için metrikleri kaydedin. RTO/RPO’yu azaltan ve manuel adımları ortadan kaldıran düzeltmelere öncelik verin.

Pratik Problem Senaryosu

Brightlane Retail, us-central1 bölgesinde katı erişilebilirlik gereksinimleri ve sipariş verileri için dört saatlik bir RPO ile bir e-ticaret platformu işletmektedir. Yönetim, bölgesel (zonal) bir kesintiyi sıfır kesinti süresiyle ve bölgeler arası (regional) bir kesintiyi minimum müşteri etkisiyle atlatmayı talep etmektedir.

Yaklaşım:

1. HTTP otomatik iyileştirme (autohealing) özellikli bir bölgesel MIG (regional MIG) ve bir global HTTP(S) Load Balancer uygulayın
   • Gerekçe: Bölgesel bir MIG, sanal makineleri (instance) bölgelere (zone) yayar ve uygulama düzeyindeki HTTP sağlık kontrolleri, her biri 10 saniyelik üç başarısız kontrolden sonra kendi kendini iyileştirmeyi (self-healing) sağlar. Global yük dengeleyici, sağlıksız VM’leri otomatik olarak kaldırır ve trafiği sağlıklı bölgelere yönlendirir.
   • Komutlar:

undefined

undefined

2. Bölgeler arası okuma replikası (cross-region read replica) ve PITR ile Cloud SQL HA’yı etkinleştirin
   • Gerekçe: Bölgesel HA (Regional HA), otomatik yük devretme (failover) ile bölgesel (zonal) beka kabiliyeti sağlar. us-east1’deki bir okuma replikası, sıfır olmayan ancak sınırlandırılmış bir RPO ile bölgesel DR (felaket kurtarma) sağlar. PITR’yi (MySQL için ikili günlük kaydı - binary logging) etkinleştirmek, belirli bir zamana geri yüklemeye izin vererek mantıksal bozulmaları (logical corruption) giderir.
   • Komutlar:

undefined

undefined

3. Dual-Region Cloud Storage ve yaşam döngüsü (lifecycle) politikaları ile nesne varlıklarını koruyun

   • Gerekçe: Ürün resimleri ve statik varlıklar, bölgesel dayanıklılık için çift bölgeli (dual-region) bir bucket’ta saklanır. Yaşam döngüsü geçişleri, maliyeti optimize etmek için eski yapıtları (artifact) Coldline’a taşır ve sürüm oluşturma (versioning) ile saklama (retention) politikaları, kritik varlıkların yanlışlıkla silinmesini önler.
   • Adımlar: Nesne Sürüm Oluşturma’yı (Object Versioning) etkinleştirin, kritik bucket’lar için 30 günlük bir saklama politikası belirleyin ve kritik olmayan derleme yapıtları (build artifact) için 90 gün sonra Coldline’a geçiş yapacak ve bir yıl sonra silecek yaşam döngüsü kuralları uygulayın.

4. Durum bilgisi olan (stateful) hizmetler için PD anlık görüntülerini (snapshot) zamanlayın ve makine imajları (machine image) oluşturun

   • Gerekçe: VM disklerinin artımlı anlık görüntüleri (snapshot), hızlı ve çökme anıyla tutarlı (crash-consistent) geri yükleme seçenekleri sunar. Makine imajları, bir bölge yük devretmesi sırasında uygulama sunucularının yeniden oluşturulmasını (rehydration) hızlandırmak için önyükleme (boot) ve yapılandırma bilgilerini yakalar. Anlık görüntü zamanlamaları, tutarlı ve politika tabanlı yedeklemeler sağlar.
   • Komutlar:

undefined

undefined

undefined

5. RTO/RPO’yu tanımlayın ve DR runbook’larını ve IaC’yi kod haline getirin

   • Gerekçe: Web/API için 15 dakikalık hizmet seviyesi RTO’su ve siparişler için dört saatlik RPO belirleyin. Runbook’lar, trafik yük devretme prosedürlerini, Cloud SQL okuma replikasının yükseltilmesini (promotion), DNS acil durum planlarını ve doğrulama adımlarını belirtir. Kod olarak altyapı (Infrastructure as Code - Terraform/Deployment Manager), deterministik yeniden oluşturmaları sağlar ve manuel hatayı azaltır.

6. İkincil bölgede kapasite ve kotaları sağlayın (provision)

   • Gerekçe: Kritik VM şekilleri için rezervasyonlar oluşturun, bir yedek (standby) yük dengeleyici arka ucu, SSL sertifikaları, NAT kapasitesini önceden sağlayın ve us-east1’deki Compute, SQL, yönlendirme kuralları (forwarding rules) ve KMS için kotaları doğrulayın. Bu, yük devretme sırasında kapasite yetersizliğini önler.

7. Kaos tatbikatları aracılığıyla kurtarmayı doğrulayın ve iyileştirmeleri belgeleyin

   • Gerekçe: Üç aylık bölgesel (zonal) arıza tatbikatları MIG ve LB davranışını doğrular; altı aylık bölgesel tahliye (regional evacuation) tatbikatları us-east1’deki okuma replikasını yükseltir, global LB’yi us-east1 arka uçlarına yönlendirir ve RTO/RPO’yu ölçer. Bulgular, manuel adımları azaltmak veya replika kapasitesini artırmak gibi iyileştirmeleri teşvik eder.

Bu adımları izleyerek Brightlane Retail, otomatik kendi kendini iyileştirme (self-healing) ile bölgesel (zonal) yüksek erişilebilirlik ve tanımlanmış, test edilmiş runbook’lar ile bölgesel bir DR (felaket kurtarma) duruşu elde eder. Bu sayede sipariş verilerinin dört saatlik RPO’yu karşılamasını ve uygulama hizmetlerinin hedeflenen RTO sınırları içinde kurtarılmasını sağlar.

← Güvenlik · Tüm alanlar · Maliyet Yönetimi →

Bu soruları çözün → · ExamRoll.io’da süreli pratik →

Google'a göz atın →