Google PCD: Performans, Ölçeklenebilirlik ve Dayanıklılık Mühendisliği — Çalışma kılavuzu

By Laurynas Brazys · 3 September 2026 · #google #PCD #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Developer — Ç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 üzerinde performans, ölçeklenebilirlik ve dayanıklılık mühendisliği; değişken yük altında düşük gecikmeli, uygun maliyetli hizmeti sürdürmeye ve SLO’ları ihlal etmeden hataları tolere etmeye odaklanır. Tasarım, otomatik ölçeklendirme sinyallerini iş yükü özellikleriyle uyumlu hale getirmeli, kuyruk gecikmesini en aza indirmek için veriyi ve işlem gücünü doğru konumlandırmalı ve kademeli arızaları önlemek için aşırı yük kontrolleri, yeniden denemeler ve yük devretme mekanizmaları uygulamalıdır. Bu bölüm, uygulama geliştiricileri için işlem, ağ ve veri katmanlarında önemli olan desenleri, kontrolleri ve ödünleşimleri detaylandırmaktadır.

Ölçeklendirme ve Yük Dağıtımı

Yatay ve dikey ölçeklendirme

Yatay ölçeklendirme, kapasiteyi ve dayanıklılığı artırmak için örnek (instance) veya pod ekler. Durumsuz (stateless) hizmetler ve hızlı esnekliğe ihtiyaç duyduğunuz durumlar için tercih edin. Yönetilen Örnek Grupları (MIG’ler), Cloud Run revizyonları veya GKE Dağıtımlarını (Deployment) kullanın.
Dikey ölçeklendirme, makine boyutunu artırır. Tek iş parçacıklı (single-threaded) veya bellek kısıtlı (memory-bound) iş yükleri için ya da düğümler arası koordinasyonu azaltmak için kullanışlıdır, ancak sınırlı büyüme payı ve daha uzun yeniden başlatma süreleri sunar.
Eşzamanlılık: İstek eşzamanlılığını CPU-bağımlı ve I/O-bağımlı profillere uyacak şekilde ayarlayın. Cloud Run, revizyon başına eşzamanlılığı destekler; çalışma zamanınız engellemeyen (non-blocking) ise GKE podları birden fazla isteğe hizmet edebilir; katı yalıtım için eşzamanlılığı 1 olarak ayarlayın.

Otomatik ölçeklendirme sinyalleri ve sıcak kapasite

MIG otomatik ölçeklendirme; CPU kullanımını, yük dengeleme kullanımını ve Cloud Monitoring aracılığıyla özel metrikleri destekler. Anlık yoğun trafik için ölçeklendirmeyi CPU yerine istek metriklerine (saniye başına istek, kuyruk derinliği) dayandırın.
GKE Yatay Pod Otomatik Ölçeklendiricisi (HPA), CPU, bellek veya özel/harici metriklere (ör. Pub/Sub kuyruk uzunluğu) göre ölçeklenebilir. Doğru boyutlandırma için Dikey Pod Otomatik Ölçeklendiricisini (VPA) kullanın, ancak sık değişimi (churn) önlemek için hızla ölçeklenen ön uçlarda VPA canlı güncellemelerinden kaçının.
Cloud Run, eşzamanlı istek yüküne ve isteğe bağlı olarak özel metriklere göre ölçeklenir. Sıcak kapasite sağlayarak soğuk başlangıçlardan (cold start) kaçının: minimum örnek sayısını yapılandırın, boşta eşzamanlılığı düşük tutun ve gerekirse sentetik sağlık ping’leri ile önceden ısıtma yapın.
MIG’lerdeki Tahmine dayalı otomatik ölçeklendirme ve Deployment/Revision üzerinde minimum replika ayarlamak, günlük yoğun saatlerdeki provizyon gecikmesini maskelemeye yardımcı olur.

Yük dengeleme, küresel trafik dağıtımı, sağlık kontrolleri ve yük devretme

Dünya çapında anycast VIP, HTTP/2 ve HTTP/3 ve Cloud CDN ile uç noktada sonlandırma için küresel harici Application Load Balancer’ı kullanın. Arka uçlar (Backend’ler) örnek grupları, bölgesel/alan (zonal/regional) NEG’ler, sunucusuz NEG’ler (Cloud Run/Functions) veya GKE Ingress olabilir.
Sağlık kontrolleri, trafiği sağlıksız arka uçlardan uzaklaştırır. Sağlık uç noktalarınızın, alt hizmet kesintilerinde döngüsel arızaları önlemek için bağımlılıkları dar bir kapsamda (ör. süreç ve kritik yerel kaynaklar) doğruladığından emin olun.
Güvenlik duvarı izin listeleri, sağlık denetleyicilerine izin vermelidir. Port 80’e yapılan kontroller başarısız olursa, Google’ın aralıklarına izin verin:

undefined

Yük devretme: Sağlık kontrolü hatası durumunda trafiği alternatif bölgelere yönlendiren birincil/yedek arka uç hizmetleri veya trafik politikaları yapılandırın. DNS seviyesinde yük devretme için, HTTP olmayan uç noktalar için sağlık kontrolleriyle birlikte Cloud DNS politikalarını kullanın.

Gecikme ve Verimlilik

Gecikme bütçeleri

Her katman (istemci, uç, uygulama, veri) için uçtan uca gecikme bütçesi ayırın. Ortalamaları değil, p95/p99 değerlerini izleyin. Hizmetler arası katkıda bulunanları ve sıra başı engellemesini (head-of-line blocking) bulmak için Cloud Trace’i kullanın. Üst hizmetin iptalinin kapasiteyi serbest bırakması için RPC’lere son teslim tarihleri (deadline) uygulayın.

Önbelleğe alma ve CDN kullanımı

Önbellekleri katmanlandırın: istemci/tarayıcı önbelleği, CDN ucu (Cloud CDN) ve bölgesel/bellek içi önbellekler (Memorystore veya süreç içi). Önbellek anahtarlarını ve vary başlıklarını dikkatlice seçin. TTL’leri (Yaşam Süreleri) verinin güncelliğine ve eski veri riskine göre ayarlayın; güvenli olduğunda 404’ler için negatif önbelleğe almayı düşünün.
Kaynak (origin) yükünü ve kuyruk gecikmesini azaltmak için statik varlıkları Cloud CDN arkasındaki Cloud Storage’dan sunun. Kontrollü erişim için imzalı URL’ler/başlıklar kullanın.

Bağlantının yeniden kullanımı

Çoklama (multiplexing) ve başlık sıkıştırma için HTTP/2 veya gRPC’yi tercih edin. El sıkışma (handshake) ek yükünü azaltmak için keep-alive’ları ve bağlantı havuzlamayı (connection pooling) etkinleştirin. NAT portu tükenmesine dikkat edin; istemci bağlantı havuzlarını ve boşta kalma zaman aşımlarını ayarlayın ve uygunsa VM başına Cloud NAT portlarını boyutlandırın.

Veri yükü (payload) verimliliği

Belirli bir boyut eşiğinin üzerindeki metin tabanlı veri yükleri için ikili (binary) kodlamalar (ör. protobuf) kullanın ve sıkıştırın (gzip/brotli). İstek/yanıt alanlarını dikkatlice tasarlayın; sayfalama yapın, sunucu tarafında filtreleyin ve aşırı veri çekmekten (over-fetching) kaçının. Gereksiz transferleri önlemek için ETags ve koşullu istekler (If-None-Match) kullanın. Cloud Storage için, nesil önkoşullarını (generation preconditions) ve kısmi içerik için Range okumalarını kullanın.

Aşırı Yük ve Dayanıklılık Desenleri

Hız sınırlama, geri basınç, kuyruklama ve toplu işleme

Hız sınırlarını uçta (edge) (IP/coğrafi/servis tabanlı hız sınırlaması için Cloud Armor) ve API katmanında (Apigee kotaları, API istemci token’ı başına) uygulayın. Adil paylaşım için sunucu tarafında token-bucket veya leaky-bucket algoritmalarını hayata geçirin.
Geri basınç (Backpressure): Bağımlı servislerin (downstream) hızını aşmayın. Kuyrukları kullanın (en az bir kez olay teslimi için Pub/Sub; kuyruk ve hedef başına kısıtlamalar, zamanlama ve yeniden denemeler için Cloud Tasks). İstemcileri geri püskürtmek için 429 Too Many Requests veya Retry-After başlığıyla birlikte 503 yayınlayın.
Toplu işleme (Batching), verimlilik karşılığında artan gecikmeyi göze alarak verimi (throughput) artırabilir ve çağrı başına ek yükü azaltabilir (örneğin, veritabanlarına yapılan toplu değişiklikler veya toplu Pub/Sub onayları). Toplu iş boyutunu ve maksimum bekleme süresini ayarlayın.

Aşırı yük koruması

Her RPC’ye zaman aşımları (timeout) ve son teslim tarihleri (deadline) uygulayın. Hata veren bağımlılıklara iş göndermeyi durdurmak ve hızlı geri dönüş (fallback) mekanizmalarını etkinleştirmek için devre kesiciler (circuit breaker) kullanın. Temel işlevselliği korumak için kuyruk derinliği, CPU veya gecikme SLO’su ihlaline dayalı yük atma (load shedding) uygulayın.

Dayanıklı yeniden denemeler, üssel geri çekilme (exponential backoff), sapma (jitter), idemopotentlik ve yinelenen işlem yönetimi

Yalnızca güvenli olduğunda yeniden deneyin: ağ zaman aşımları, 5xx veya belgelenmiş yeniden denenebilir kodlar (örneğin, Cloud Storage 429/5xx). Belirtilmedikçe 400/401/403 gibi 4xx hatalarında asla yeniden denemeyin.
Senkronize yeniden denemelerden kaçınmak için sapmalı kesilmiş üssel geri çekilme (truncated exponential backoff with jitter) kullanın. Tam sapmayı (full jitter) tercih edin. Örnek:

undefined

Idempotentliği sağlayın. Yinelenen işlemleri tolere etmek için idempotentlik anahtarları (örneğin, benzersiz bir işlem ID’si) ve upsert’ler/koşullu yazmalar kullanın. Pub/Sub için messageId veya uygulama anahtarlarını kullanarak tekilleştirin; işleyicileri (handler) en az bir kez teslimat (at-least-once delivery) için güvenli olacak şekilde tasarlayın. Cloud Storage yazma işlemleri için, üzerine yazmaları önlemek amacıyla generation-match ön koşullarını kullanın.

Atıl kaynakların yavaşça devreye alınması (ramp-up)

Bazı servisler uyarlanabilir (adaptive) limitler uygular. Cloud Storage için, ani artışlar sırasında geçici 429/5xx hatalarını azaltmak amacıyla daha önce atıl olan bucket’lardaki istek oranlarını kademeli olarak artırın. Tam yüke geçmeden önce üreticileri (producer) kısıtlayın ve kontrollü trafikle bucket’ları ısıtın (warm up).

Yüksek Erişilebilirlik, Veri, Felaket Kurtarma ve Test

Çoklu alan (multi-zone), bölgesel (regional), çoklu bölge (multi-region); aktif-aktif ve aktif-pasif karşılaştırması

Dağıtımları hata etki alanlarına (failure domains) yayın. Alan (zone) arızalarına karşı tolerans için bölgesel MIG’ler veya bölgesel GKE kümeleri kullanın. Global hizmetler için, global yük dengeleyici ile birden fazla bölge kullanın.
Aktif-aktif, RTO’yu ve gecikme süresini azaltır ancak çakışmasız veri ve dikkatli tutarlılık yönetimi gerektirir. Aktif-pasif, yazma semantiğini basitleştirir ancak daha yüksek RTO’ya ve potansiyel soğuk kapasiteye neden olur.

RTO, RPO, yedekleme, geri yükleme ve felaket kurtarma testi

Her iş yükü için RTO (hizmeti kurtarma süresi) ve RPO (tolere edilebilir veri kaybı) tanımlayın. Bunları platform yetenekleriyle eşleştirin:
- Cloud Spanner: Sıfıra yakın RPO için beş 9 (%99,999) erişilebilirlik ve senkron replikasyon ile çoklu bölge (multi-region) desteği.
- Cloud SQL: Bölge içinde Yüksek Erişilebilirlik (High Availability); Felaket Kurtarma (DR) için bölgeler arası replikalar kullanın, PITR’ı etkinleştirin ve yük devretme/geri alma (failover/failback) talimatnamelerini doğrulayın.
- Firestore ve Bigtable, bölgesel ve çok bölgeli seçenekler sunar; RTO/RPO’yu karşılayacak şekilde seçim yapın.
- Cloud Storage çift veya çok bölgeli (dual- or multi-region) bucket’lar coğrafi yedeklilik sağlar; geri yükleme prosedürlerini ve imzalı URL’lerin yeniden oluşturulmasını doğrulayın.
DR Testi: Yük devretme (failover) tatbikatlarını düzenli olarak yapın. Yedekleri izole bir ortama geri yükleyerek doğrulayın, DNS/trafik devretme provaları yapın ve gerçek RTO/RPO’yu ölçün.

Veritabanı ve depolama performansı, indeks tasarımı, yoğun erişim noktaları (hot keys) ve çekişme (contention)

Cloud Spanner: Hotspot’a neden olan monotonik artan birincil anahtarlardan kaçının. Yerellik için iç içe geçmiş tablolar (interleaved tables), okuma desenleri için ikincil indeksler ve kilit çakışmalarını azaltmak için sınırlı işlemler (bounded transactions) kullanın. Node’ları QPS ve depolama için boyutlandırın; üretim ortamında çoğunluk (quorum) ve genişleme payı için en az üç node bulundurun.
Cloud SQL: Sorguları analiz edin, kapsayan indeksler (covering indexes) ekleyin, uzun işlemlerden kaçının ve bağlantı havuzları (connection pools) kullanın. InnoDB veya Postgres ayarlarını akıllıca yapın; okuma ağırlıklı iş yükleri için okuma replikalarını (read replicas) ölçeklendirin.
Bigtable: Yükü eşit dağıtmak için satır anahtarları (row keys) tasarlayın (salting veya alan ters çevirme). Varsa, bölgeler arasında yüksek erişilebilirlik için çoklu küme yönlendirmesi (multi-cluster routing) kullanın.
Firestore: Çok alanlı sorgular için bileşik indeksler (composite indexes) kullanın; çok sayıda yazma işleminin aynı belge yolunu hedeflediği durumlarda hotspot oluşumuna dikkat edin.
Cloud Storage: Yeni nesneler için yazma sonrası güçlü okuma tutarlılığı (strong read-after-write); yüksek verim için paralel yüklemeler ve parçalara ayırma (chunking) kullanın. Boştaki bucket’lara trafiği kademeli olarak artırın; yoğun okuma işlemleri için CDN edge (uç) noktasını tercih edin. Aynı büyük, salt okunur veri setine ihtiyaç duyan çok sayıda VM için, düşük maliyetle hızlı yerel erişim sağlamak amacıyla salt okunur modda bir kalıcı diski birden fazla örneğe bağlayın.

Yük testleri, kaos deneyleri, hata enjeksiyonu ve kapasite planlaması

Yük testi: Gerçekçi trafik şekillerini ve veri dağılımlarını simüle edin. Önbellekleri ve otomatik ölçekleyicileri önceden ısıtın (warm up); yük altında ve ölçeklendirme olayları sırasında p95/p99 gecikme süresini test edin. Üretim karmaşıklığındaki davranışı doğrulamak için canlı trafiğin küçük bir bölümünü gölge yığınlara (shadow stacks) yansıtın.
Kaos ve hata enjeksiyonu: Etki alanını (blast radius) ve dayanıklılığı gözlemlemek için pod’ları/VM’leri sonlandırın, bir alanı (zone) kordona alın, hizmet ağına (service mesh) (ör. Envoy/Istio) gecikme/hatalar enjekte edin. Devre kesicilerin (circuit breakers) ve yeniden denemelerin beklendiği gibi davrandığını doğrulayın.
Kapasite planlaması: Geçmiş talebi ve planlanan olayları kullanarak tahmin yapın. N+1 hataları ve yeniden dengeleme için genişleme payı bırakın. Otomatik ölçekleyici bekleme sürelerini ve maksimum oranları beklenen ani artışlarla hizalayın; öngörülebilir zirveler sırasında önceden kaynak ayırın.

Yönetilen hizmetler ve özel mimariler arasındaki erişilebilirlik ödünleşimleri

Bilişim (Compute): Cloud Run, sıfıra kadar hızlı ölçeklenme ve düşük operasyonel yük sunar ancak soğuk başlangıçlara (cold starts) ve istek eşzamanlılık kısıtlamalarına sahiptir. GKE, daha yüksek operasyonel maliyetle ayrıntılı kontrol ve taşınabilirlik sağlar. Compute Engine VM’leri, en yüksek operasyonel yük ile maksimum kontrol sunar.
Veri: Cloud Spanner, daha yüksek maliyet ve şema katılığı ile küresel tutarlılık ve yüksek erişilebilirlik sağlar. Cloud SQL, daha basit operasyonlarla geleneksel RDBMS’lere uyar ancak sınırlı HA/ölçeklenebilirliğe sahiptir. Bigtable, düşük gecikmeli, devasa ölçekli anahtar-değer/zaman serisi verilerinde mükemmeldir. Firestore, güçlü tutarlılık ve global seçeneklerle esnek şemalar sunar.
Ağ: Global yük dengeleyiciler ve Cloud CDN, yüksek düzeyde erişilebilirdir ve Google’ın edge ağında çalışır; kendin yap (DIY) proxy’ler özelleştirme sunar ancak operasyonel ve arıza riski yaratır.
Daha yüksek temel erişilebilirlik ve DDoS’a karşı dayanıklılık için yönetilen hizmetleri tercih edin, ancak tasarımınızda kotaları, soğuk başlangıçları ve hizmete özgü semantikleri hesaba katın.

Pratik Problem Senaryosu

Global bir e-ticaret şirketi olan NimbusMart’ın, Kuzey Amerika, Avrupa ve Asya-Pasifik’teki kullanıcılar için beş 9 (%99,999) erişilebilirliğe ve en aza indirilmiş okuma gecikmesine sahip, düşük gecikmeli bir ürün kataloğu API’sine ihtiyacı var. Yazma işlemleri küresel olarak tutarlı olmalıdır. Ani indirim (flash sale) dönemlerinde trafik ani artışlar gösteriyor ve geçmişteki olaylar arasında basamaklı yeniden denemeler ve kaynak (origin) sunucu aşırı yüklenmesi yer alıyor.

Yaklaşım:

En az üç node içeren nam-asia-eur1 kullanarak çok bölgeli (multi-regional) bir Cloud Spanner örneği oluşturun.

Gerekçe: Beş 9 erişilebilirlikle küresel olarak tutarlı okuma/yazma işlemleri sunar ve okuma gecikmesini azaltmak için replikaları kullanıcıların yakınına yerleştirir. Minimum üç node, çoğunluk (quorum) sağlamlığı ve yeniden dengeleme için genişleme payı sağlar.

Global harici Application Load Balancer’ın arkasında birden çok bölgede durumsuz (stateless) bir API katmanı uygulayın.

Gerekçe: Anycast VIP ve global yönlendirme, bağlantı kurma süresini azaltır ve kullanıcıları en yakın sağlıklı bölgeye yönlendirir. Durumsuz hizmetler, yatay ölçeklendirmeyi ve yük devretmeyi (failover) kolaylaştırır.

Yük dengeleyicinin erişilebilirliği için sağlık kontrolleri ve güvenlik duvarı kuralları yapılandırın.

Gerekçe: Sağlık kontrolleri, sağlıksız arka uçlara (backend) yönlendirmeyi engeller. Kontrollerin başarılı olması için Google sağlık kontrolü IP aralıklarına izin verin:

undefined

Hazırda bekleyen (warm) kapasite ile istek metriklerine dayalı otomatik ölçeklendirme uygulayın.

Gerekçe: Ani indirim (flash-sale) trafiğine tepki vermek için MIG’leri veya GKE HPA’yı CPU yerine QPS/gecikme süresine göre ölçeklendirin. Soğuk başlangıçları (cold starts) önlemek ve bilinen olaylardan önce tahmine dayalı otomatik ölçeklendirmeyi etkinleştirmek için bölge başına minimum replika sayısını koruyun.

Cloud Storage’da depolanan statik ürün medyası için Cloud CDN ekleyin.

Gerekçe: Edge (uç) önbellekleme, kaynak (origin) sunucunun yükünü alır, kuyruk gecikmesini (tail latency) azaltır ve uygulama ile depolama katmanlarındaki ani artışların büyümesini (burst amplification) hafifletir. İmzalı URL’ler ve uygun önbellek anahtarları/TTL’ler kullanın.

Edge’de ve hizmette aşırı yük koruması ve hız sınırlaması (rate limiting) uygulayın.

Gerekçe: Kötü niyetli ani artışları absorbe etmek için Cloud Armor hız limitlerini yapılandırın. Hizmet içinde, istemci başına token-bucket limitleri kullanın ve gecikme süresi SLO’ları tehdit edildiğinde düşük öncelikli istekleri reddedin. Her alt akış (downstream) çağrısına son tarih (deadline) uygulayın.

Kesilmiş üstel geri çekilme (truncated exponential backoff) ve tam sapma (full jitter) ile dayanıklı yeniden denemeler kullanın; işlem kimlikleri (operation IDs) ile idemopotentliği sağlayın.

Gerekçe: Kısmi arızalar sırasında ezici kalabalık (thundering herd) etkisini ve yinelenen yazma işlemlerini önleyin. İdempotentlik anahtarları güvenli yeniden denemeleri sağlar; depolama işlemleri için koşullu ön şartlar kullanın.

Kabul edilebilir durumlarda ani artışları yumuşatma ve asenkronluk için bir yazma kuyruğu oluşturun.

Gerekçe: Pub/Sub, kritik olmayan yazma işlemlerindeki (ör. analitik olayları) ani artışları tamponlar, üreticileri Spanner’dan ayırarak birincil yazma yollarını aşırı yükten korur.

SLO’ları ve gecikme süresi bütçelerini tanımlayın; izleme (tracing) ve gösterge tabloları (dashboard) oluşturun.

Gerekçe: Katman başına bütçeler optimizasyona rehberlik eder. Hata bütçeleri içeren Cloud Monitoring SLO’ları ve Cloud Trace, p99 gecikme süresine bölgeler arası ve veri katmanı kaynaklı katkıları ortaya çıkarır.

Felaket Kurtarma (DR) talimatnameleri oluşturun ve yük devretmeyi (failover) test edin.

Gerekçe: Çok bölgeli Spanner ve çok bölgeli bilişim kaynakları ile bölge tahliye tatbikatları yapın. Trafik boşaltma ve yeniden artırma zaman çizelgeleriyle RTO’yu doğrulayın ve yük devretme sırasında otomatik ölçekleyicilerin ve CDN’in doğru davrandığını onaylayın.

Bu tasarım, bilişim ve veri topolojisini hizalayarak, aşırı yük kontrollerini uygulayarak ve kanıtlanmış ölçeklenebilirlik ve dayanıklılık sağlayan yönetilen hizmetleri kullanarak küresel erişilebilirlik ve düşük gecikme hedeflerini karşılar.

← Gözlemlenebilirlik · Tüm alanlar · Test →

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