Google PCD: Buluta Özgü Uygulama Mimarisi ve Hizmet Seçimi — Ç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 üzerindeki buluta özgü uygulama mimarisi; durum bilgisi tutmayan (stateless), dayanıklı, yatay olarak ölçeklenen, operasyonel yükü en aza indiren ve uygun olduğunda yönetilen hizmetleri benimseyen hizmetler oluşturmaya odaklanır. Etkili hizmet seçimi; kontrol, taşınabilirlik, performans, maliyet ve operasyonel sorumluluk arasındaki ödünleşimleri anlamayı gerektirir. Bu bölüm, küresel kullanıcılar için öngörülebilir güvenilirlikle uygulamalar tasarlamanıza, modernize etmenize ve işletmenize yardımcı olan ilkeleri ve desenleri sunar.

Buluta Özgü İlkeler ve Mimari Seçimleri

• On iki faktörlü ve durum bilgisi tutmayan (stateless) tasarım

  • Kod tabanı, bağımlılıklar ve derleme-yayınlama-çalıştırma: Tam bağımlılıkları sabitleyin, değiştirilemez (immutable) yapılar oluşturun ve derleme (build) ile yayınlama (release) süreçlerini ayırın. Konteyner imajları ve Cloud Build işlem hatları, tekrarlanabilir yayınları zorunlu kılar.
  • Yapılandırmanın ortamda tutulması: Ortam değişkenleri, Secret Manager, Kubernetes Secrets veya Compute Engine için örnek (instance) meta verilerini kullanarak yapılandırmayı dışsallaştırın. Kimlik bilgilerini veya dağıtıma özgü ayarları imajların içine gömmeyin. Compute Engine yönetilen örnek grupları için, dağıtıma özgü değerler için örnek şablonu meta verilerini kullanın.
  • Destekleyici hizmetler: Veritabanlarını, kuyrukları ve önbellekleri ekli kaynaklar olarak ele alın. Operasyonel yükü azaltmak için yönetilen hizmetleri (Cloud SQL, Cloud Spanner, Firestore, Memorystore, Pub/Sub) tercih edin.
  • Durum bilgisi tutmayan (stateless) süreçler: Yeni örnekler (instance) ekleyerek ölçeklenin; oturum durumunu (session state) harici olarak saklayın (Memorystore for Redis, Firestore veya Spanner). Logları stdout/stderr’e veya Cloud Logging aracısı tarafından toplanan log dosyalarına yazın.
  • Harcanabilirlik: Hızlı başlatma/kapatma, süratli ölçeklendirme ve kademeli güncellemeleri (rolling updates) mümkün kılar. Düzgün kapatma (graceful shutdown) için SIGTERM sinyalini işleyin.
  • Olay akışları olarak loglar: Yapılandırılmış loglar yayınlayın; veri alımı (ingestion) için Cloud Logging’i ve uyarı (alerting) için Cloud Monitoring’i kullanın.

• Mimari ödünleşimleri

  • Monolit
    • Artıları: Basitleştirilmiş geliştirme/test, daha az ağ sınırı, tek bir dağıtım birimi.
    • Eksileri: Daha yavaş bağımsız teslimat, ölçeklenme kısıtlamaları, alanlar (domain) arasında sıkı bağlılık.
    • Hata modları: Tek bir yoğun yol (hot path), paylaşılan kaynakları tüketebilir; regresyonlar tüm özellikleri etkiler.
  • Modüler monolit
    • Artıları: Net iç modül sınırları, hizmetlere doğru yeniden yapılandırma (refactoring) yolu, tek bir dağıtılabilir birim.
    • Eksileri: Hâlâ monolitik dağıtım ve veritabanı ile sınırlıdır.
    • Hizmetleri ayırmadan önce alan sınırlarını olgunlaştıran ekipler için kullanın.
  • Mikroservisler
    • Artıları: Bağımsız dağıtılabilirlik, hedefe yönelik ölçeklendirme, ekip özerkliği, uygun bölmeleme (bulkhead) ile hata yalıtımı.
    • Eksileri: Dağıtık sistemlerin karmaşıklığı, tutarlılık, gözlemlenebilirlik ve operasyonel ek yük.
    • Hata modları: Senkron çağrılar yoluyla zincirleme hatalar; şema kayması; yoğun trafikli (chatty) ağlar.
  • Olay güdümlü
    • Artıları: Gevşek bağlılık, asenkron dayanıklılık, doğal arabelleğe alma (buffering), loglar/akışlar aracılığıyla denetlenebilirlik.
    • Eksileri: Hata ayıklama karmaşıklığı, nihai tutarlılık (eventual consistency), sıralama ve tam olarak bir kez (exactly-once) anlamsallığı zordur.
    • Pub/Sub, en az bir kez teslimat (at-least-once delivery) sağlar; etkisiz (idempotent) tüketiciler tasarlayın.
  • Sunucusuz (Serverless) (Cloud Run, Cloud Functions, App Engine)
    • Artıları: Minimum operasyon, sıfıra kadar ölçeklenme, istek başına otomatik ölçeklendirme, entegre güvenlik ve telemetri.
    • Eksileri: Çalışma süresi ve eşzamanlılık limitleri, soğuk başlangıçlar (cold starts), platforma özgü kısıtlamalar.
    • Düzensiz (bursty) iş yükleri, mobil/web arka uçları (backend) ve olay işleme için kullanın.

İletişim Desenleri ve Hizmet Seçimi

• Senkron ve asenkron çağrılar

  • Senkron
    • Anında sonuç gerektiren istek/yanıt (request/response) API’leri için kullanın.
    • Protokoller: gRPC (HTTP/2, akış (streaming), kompakt Protobuf; mobil bant genişliği ve güçlü sözleşmeler (contract) için mükemmel), HTTP/JSON (geniş uyumluluk; daha basit hata ayıklama).
    • Riskler: Sıkı bağlılık ve gecikme artışı; zaman aşımları (timeout), sapmalı (jitter) yeniden denemeler ve devre kesiciler (circuit breaker) kullanın.
  • Asenkron
    • İş ertelenebildiğinde veya toplu olarak işlenebildiğinde Pub/Sub veya Cloud Tasks kullanın.
    • Faydaları: Ani yükselişleri yumuşatır, hataları yalıtır, nihai tamamlama yoluyla kullanıcı tarafından algılanan gecikmeyi iyileştirir.
    • Riskler: Etkisizlik (idempotency) ve telafi edici eylemler gerektirir; devam eden işe yönelik görünürlüğün oluşturulması gerekir.

• Google Cloud’da hizmet seçim kriterleri

  • Kontrol ve taşınabilirlik
    • Compute Engine: Tam VM kontrolü ve özel imajlar; daha yüksek operasyonel yük.
    • GKE: Taşınabilir konteynerler ve service mesh seçenekleri; sağlam otomatik ölçeklendirme; paylaşılan sorumluluk.
    • Cloud Run: Minimum operasyon ile konteynerler için yüksek taşınabilirlik; sıfıra kadar ölçeklenme; istek odaklı.
    • App Engine: Dahili yönlendirme ve ölçeklendirme özelliklerine sahip, görüş bildiren (opinionated) bir PaaS; belirli diller için en hızlı yol.
  • Ölçek ve gecikme
    • Uç (edge) hızlandırma için Cloud CDN ile Global HTTP(S) Load Balancing.
    • Veri Depoları:
      • Cloud Spanner: Global tutarlılık, yatay ölçeklenme, çok bölgeli %99.999 erişilebilirlik.
      • Cloud SQL: Yönetilen ilişkisel veritabanı, bölgesel, bölgeler arası dahil okuma replikaları (read replica).
      • Firestore: Çok bölgeli global erişilebilirliğe sahip doküman veritabanı, tek dokümanlar için güçlü tutarlılık.
      • Cloud Bigtable: Geniş sütunlu (wide-column) kullanım durumları için düşük gecikmeli, devasa ölçek.
      • Memorystore: Yoğun yollar (hot path) ve oturumlar için düşük gecikmeli önbellek.
  • Operasyonel sorumluluk
    • Temel konular (erişilebilirlik, yama yönetimi, yedeklemeler, yükseltmeler) için yönetilen hizmetleri tercih edin.
    • Kendi kendine yönetilen (self-managed) çözümler esneklik sunar ancak operasyonel yükü ve hata yüzeyini artırır (ör. kendi barındırdığınız Kafka vs Pub/Sub).
  • Veri hareketi ve entegrasyon
    • Düşük gecikmeli, özel erişim için VPC-native bağlantı, Private Service Connect ve dahili HTTP(S) Load Balancing kullanın.
    • Hizmet keşfi (Service discovery): Bir küme içindeki Kubernetes Service adları; VM’ler için Compute Engine dahili DNS.

Kubernetes Service örneği (küme içi isim keşfi): apiVersion: v1 kind: Service metadata: name: image-resize spec: selector: app: image-resize ports:

• port: 80 targetPort: 8080 type: ClusterIP

Sınırlar, Uyumluluk ve Güvenilirlik Desenleri

• Alan sınırları ve sahiplik

  • Sınırlı bağlamları (bounded context) tanımlamak için alan odaklı tasarım (domain-driven design) kullanın. Her servis kendi verisine sahiptir ve sözleşme (contract) olarak API’ler/olaylar yayınlar.
  • Servisler arasında paylaşılan veritabanlarından kaçının; iyi tanımlanmış arayüzler ve olay yayılımı (event propagation) kullanın.
  • Sahiplik, her servis için nöbet (on-call), SLO’lar, sürüm yayınlama sıklığı (release cadence) ve bütçe sorumluluğunu içerir.

• API sözleşmeleri ve geriye dönük uyumluluk

  • API’leri açıkça sürümleyin (ör. yolda veya başlıkta v1). Eklemeli değişiklikleri tercih edin; mevcut alanları veya davranışları bozan değişikliklerden (breaking changes) kaçının.
  • Tüketici odaklı sözleşme testleri (consumer-driven contract tests) ve canary sürümleri kullanın.
  • Kullanım metriklerini (telemetry) takip ederek ve belirli bir zaman çizelgesiyle kullanımdan kaldırın (deprecate).
  • Mobil istemciler için, eski sürümlerin uzun süre kullanılacağını (long tail) varsayın; birden çok API sürümünü eş zamanlı olarak sürdürün.

• Hata yalıtımı ve esneklik

  • Bulkhead’ler (Perdeler): Kaynakları servise veya öncelik sınıfına göre yalıtın (ayrı node havuzları, instance grupları, kotalar). Düşük öncelikli bir özelliğin kritik yolları tüketmesini önleyin.
  • Devre kesiciler (Circuit Breaker): Bir bağımlılığa yönelik art arda gelen hatalardan sonra devreyi açar; yükü azaltır (shed load) ve kurtarma için bir zaman aralığı tanır. Service mesh (ör. Envoy), ağ geçidi (gateway) politikaları veya kütüphaneler aracılığıyla uygulayın.
  • Zaman aşımları ve yeniden denemeler: Jitter ile kesikli üssel geri çekilme (truncated exponential backoff) kullanın; işleyicilerin (handler) idempotent olduğundan emin olun.
  • Kademeli indirgeme (Graceful Degradation): Zaman aşımlarında kritik olmayan kullanıcı arayüzü bileşenlerini atlayın; hata yerine önbelleğe alınmış veya yaklaşık veriler sunun.
  • Sağlık kontrolleri (Health Check) ve hazır olma probları (Readiness Probe): Trafiği yalnızca hazır olan instance’lara yönlendirin; kendi kendini iyileştirme (self-healing) için canlılık problarını (liveness) kullanın.

Örnek kesikli üssel geri çekilme (HTTP 429): retry = 0 max_retry = 5 base = 0.5 while retry < max_retry: resp = fetch_gcs_object() if resp.status_code == 200: break if resp.status_code in (429, 500, 503): sleep = min(8, base * (2 ** retry)) + random.uniform(0, 0.25) time.sleep(sleep) retry += 1 else: raise Exception(“Non-retryable error”)

Global ve Operasyonel Hususlar

• Global kullanıcılar için çok bölgeli (multi-region) desenler

  • Global ön uç (front end): Anycast IP ve statik içerik için Cloud CDN ile global harici HTTP(S) Yük Dengeleme kullanın. Kaynak (origin) yükünü azaltmak için negatif önbelleğe alma (negative caching) ve doğrulama yapılandırın.
  • Veri düzlemi (data plane):
    • Beş 9’luk (%99,999) veritabanı kullanılabilirliği ve minimuma indirilmiş global okuma gecikmesi için çok bölgeli (multi-regional) bir Cloud Spanner örneği (ör. nam-asia-eur1) kullanın ve işlem (compute) ile yeter sayı (quorum) için yeterli sayıda düğüm (node) sağlayın (üretim için minimum üç düğüm).
    • Katı global tutarlılık gerektirmeyen okuma ağırlıklı desenler için, bölgeler arası okuma replikaları olan bölgesel bir birincil (primary) veritabanı düşünün; kıtalar arasında daha yüksek yazma gecikmesini kabul edin.
  • Uygulama düzlemi (application plane):
    • Durumsuz (stateless) servisleri otomatik ölçeklendirme (GKE veya Cloud Run) ile birden çok bölgeye dağıtın. Bölge başına arka uç servisleri (backend services) ve ağ uç nokta grupları (network endpoint groups) kullanın.
    • Veri yerleşimi (data residency) ve uyumluluk kısıtlamalarına uyarak gecikmeye göre yönlendirme yapın.
  • Önbellekler (Caches): Okuma trafiğini absorbe etmek ve kaynakları (origin) korumak için Memorystore veya uç (edge) önbelleklerini kullanıcılara yakın yerleştirin.

• Yönetilen (Managed) ve kendi kendine yönetilen (self-managed)

  • Metrikler için Cloud Monitoring, loglar için Cloud Logging, gecikme ve CPU/bellek darboğazları (hotspot) için Cloud Trace/Profiler kullanın. SLO yanma oranları (burn rate) için uyarı politikaları ve dış kullanılabilirlik için çalışma süresi denetimleri (uptime check) oluşturun.
  • Mevcut bir gözlemlenebilirlik platformu kayıt sistemi (system of record) olarak kalması gerekiyorsa, düşük gecikmeli uyarılar için önce Cloud Logging ile veri alın, ardından havuzlar (sink) aracılığıyla harici platforma dışa aktarın.

• Modernizasyon ve artımlı geçiş (incremental migration)

  • Boğucu (Strangler) deseni: Monoliti bir ağ geçidi (gateway) ile ön cepheye alın; belirli uç noktaları (endpoint) yeni servislere yönlendirin. Yetenekleri kademeli olarak değiştirin.
  • Soyutlama ile dallanma (Branch by abstraction): Bir bağımlılığın etrafına bir arayüz (interface) getirin ve arkasındaki uygulamayı değiştirin (ör. veritabanı veya depolama).
  • Bozulma önleyici katman (Anti-corruption layer): Eski veri modelleri ile yeni sınırlı bağlamlar (bounded context) arasında çeviri yapın.
  • Veri taşıma (Data migration): Geriye dönük doldurma (backfill) için doğrulamalı çift yazma (dual write) veya olay kaynağı (event sourcing) kullanın; geri basınç (backpressure) kontrolleriyle geçişleri (cutover) planlayın.
  • Aşamalı teslimat (Phased delivery): İş riskini en aza indirmek için özellikleri aşamalar halinde değiştirin; SLO’ları sürekli ölçün.

• Tasarım gözden geçirmeleri ve ödünleşim (trade-off) değerlendirmeleri

  • Güvenlik: Tehdit modellemesi, IAM en az ayrıcalık (least privilege) ilkesi, gömülü anahtarlar yerine servis hesapları (service account) (GCE/GKE/Cloud Run üzerinde Application Default Credentials kullanın), gereken yerlerde CMEK, özel bağlantı, WAF ve hız limitleri (rate limit), güvenlik açığı ve web güvenliği taraması.
  • Güvenilirlik: SLO’ları ve hata bütçelerini (error budget) tanımlama, çok bölgeli yük devretme (failover) planları, kapasite payı (headroom), kaos tatbikatları (chaos drill), bağımlılık haritaları.
  • Performans: Kuyruk gecikmesi (tail latency) analizi, uç (edge) ve kaynakta (origin) yük testi, bağlantının yeniden kullanımı (HTTP/2, gRPC), sıkıştırma, önbelleğe alma stratejisi.
  • Maliyet: Kaynakları doğru boyutlandırma, otomatik ölçeklendirme politikaları, taahhütlü kullanım indirimleri (committed use discount), anlık yoğunlaşan (bursty) iş yükleri için sıfıra ölçeklenme (scale-to-zero), dışa aktarım (egress) ve CDN ile yükü hafifletme.
  • Operasyonlar: Runbook’lar, geri almalar (rollback), aşamalı teslimat (progressive delivery) (canary, blue/green), kod olarak ilke (policy as code), yedeklemeler ve felaket kurtarma (DR) testleri, olay müdahale (incident response) entegrasyonu.

Pratik Problem Senaryosu

Nimbus Retail, kişiselleştirilmiş görseller, dünya çapında p95’te 200 ms’nin altında katı gecikme hedefleri ve sipariş veritabanı için %99,999 kullanılabilirlik gereksinimi olan global bir e-ticaret platformu başlatıyor. Ayrıca, uyarı hızını artırırken mevcut SIEM’lerini de korumaları gerekiyor.

1. Cloud Spanner kullanarak global, yüksek düzeyde kullanılabilir bir veritabanı oluşturun

• Eylem: nam-asia-eur1’de en az üç düğümle çok bölgeli (multi-regional) bir Spanner örneği oluşturun ve yerellik (locality) için tabloları uygun iç içe geçmiş (interleaved) şemalara bölün.
• Gerekçe: Çok bölgeli Spanner, üç kıtadaki replikalar aracılığıyla beş 9’luk kullanılabilirlik ve düşük okuma gecikmesi sunar; üç veya daha fazla düğüm, yeterli işlem (compute) ve replika yeter sayı (quorum) kapasitesi sağlar.

Örnek:

undefined

2. Ön uç (Frontend) ve API’nin global dağıtımı

• Eylem: Statik varlıklar için Cloud CDN ile global harici HTTP(S) Yük Dengeleme ve bölgesel arka uçlara (us-central1, europe-west1, asia-east1’deki GKE servisleri) dinamik yönlendirme kullanın.
• Gerekçe: Anycast VIP, RTT’yi (Round-Trip Time) en aza indirir; CDN, görselleri kullanıcılara yakın bir yerde önbelleğe alır; arka uç servisleri (backend services) istekleri en yakın sağlıklı bölgeye dağıtır.

3. GKE üzerinde küme içi keşif (in-cluster discovery) ile durumsuz (stateless) servisler

• Eylem: Görüntü yeniden boyutlandırma ve API servislerini GKE üzerinde, küme içinde isme dayalı erişim için yatay pod otomatik ölçeklendirme (horizontal pod autoscaling) ve ClusterIP Servisleri ile dağıtın; genel uç noktaları (endpoint) bir Ingress aracılığıyla kullanıma sunun.
• Gerekçe: Durumsuz (stateless) pod’lar elastik ölçeklendirmeye olanak tanır; Kubernetes Service, pod IP’lerini soyutlar ve kararlı DNS sağlayarak istemci bağımlılığını (coupling) azaltır.

4. Olay güdümlü (Event-driven) görüntü işleme

• Eylem: Görüntü işleme görevlerini Pub/Sub’a yayınlayın; Cloud Storage’da depolanan nesneleri işlemek için push aracılığıyla abone olunan Cloud Run servislerini çalıştırın. GCS 429/5xx hatalarında sapmalı kesik üssel geri çekilme (truncated exponential backoff with jitter) uygulayın.
• Gerekçe: Pub/Sub, ani yük artışlarını (spike) tamponlar ve hataları izole eder; Cloud Run, mesaj başına ölçeklenir; geri çekilme (backoff), hata çoğalmasını azaltır ve bucket’ların kademeli olarak ısınmasına (warm up) yardımcı olur.

5. Gözlemlenebilirlik ve hızlı uyarı

• Eylem: Logları ve metrikleri almak için Cloud Logging ve Cloud Monitoring kullanın, API’ler için çalışma süresi denetimleri (uptime check) tanımlayın ve hata oranları ile gecikme üzerine uyarı politikaları oluşturun. Mevcut SIEM’e dışa aktarmak için bir log havuzu (sink) yapılandırın.
• Gerekçe: Yerel telemetri, düşük gecikmeli uyarılar ve yönetilen çalışma süresi denetimleri sağlar; dışa aktarma, uyarı hızından ödün vermeden merkezi SIEM’i korur.

6. Dışsallaştırılmış yapılandırma ve gizli bilgiler (secret)

• Eylem: Gizli olmayan yapılandırmayı ConfigMap’lerde; gizli bilgileri ve API anahtarlarını GKE için Workload Identity ile Secret Manager’da saklayın. Compute Engine tabanlı herhangi bir iş için, dağıtım başına değerler için sanal makine meta verilerini (instance metadata) kullanın.
• Gerekçe: Dışsallaştırılmış yapılandırma, değiştirilemez imajları (immutable image) ve ortama özgü ayarları mümkün kılar; gizli bilgilerin gömülmesini önler; meta veriler, kod değişikliği olmadan sanal makine farklılıklarını destekler.

7. Hata izolasyonu ve kontrollü indirgeme (graceful degradation)

• Eylem: En iyi çaba (best-effort) kişiselleştirme iş yükleri için ayrı düğüm havuzları (node pool) ile bölme (bulkhead) uygulayın; kişiselleştirme servisleri için istek bütçeleri ve devre kesiciler (circuit breaker) uygulayın. Kullanıcı arayüzünde (UI), bağımlılık zaman aşımlarında kritik olmayan bileşenleri (widget) atlayın.
• Gerekçe: Kapasiteyi izole etmek, en iyi çaba (best-effort) özelliklerinin ödeme (checkout) sürecini kaynak yetersizliğine uğratmasını önler; devre kesiciler etki alanını (blast radius) sınırlar; kontrollü indirgeme, temel kullanıcı yolculuklarını korur.

8. API sözleşmeleri ve uyumluluk

• Eylem: Mobil istemciler (v1) için gRPC sözleşmelerini web için HTTP/JSON kod dönüştürme (transcoding) ile tanımlayın; eklemeli değişiklikleri benimseyin ve mobil dağıtım sırasında en az iki sürümü sürdürün.
• Gerekçe: gRPC bant genişliğini azaltır ve güçlü tipleme (strong typing) sağlar; kod dönüştürme, tarayıcı ve iş ortağı entegrasyonunu kolaylaştırır; sürüm oluşturma, geriye dönük uyumluluğu korur.

9. Güvenlik ve kimlik

• Eylem: Her servis için en az ayrıcalık (least-privilege) ilkesine sahip Google servis hesapları (service account) kullanın; Application Default Credentials’a güvenin. Uç (edge) korumaları için Cloud Armor’ı etkinleştirin ve her yerde TLS’yi zorunlu kılın.
• Gerekçe: Workload identity, anahtar yönetimi risklerini ortadan kaldırır; WAF ve hız limitleri kötüye kullanımı azaltır; aktarım sırasında şifreleme (encryption in transit) varsayılan ve zorunludur.

10. Sürekli teslimat (Continuous delivery) ve sürüm güvenliği

• Eylem: Yük dengeleyicide (load balancer) yüzde tabanlı trafik bölme ile kanarya (canary) sürümlerini ve SLO yanma (burn) uyarılarında otomatik geri almayı (rollback) uygulayın. Bölge başına mavi/yeşil (blue/green) ortamları tutun.
• Gerekçe: Aşamalı teslimat riski sınırlar; bölgesel mavi/yeşil, geri almayı hızlandırır ve sürümlenmiş API’lerle uyumlu güvenli şema geçişlerini mümkün kılar.

Tüm alanlar · İşlem →

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

Google'a göz atın →