Google PCD: İşlem, Konteynerler ve Sunucusuz Çalışma Zamanı Platformları — Ç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, sunucusuz (serverless), container ve sanal makineleri kapsayan çok sayıda çalışma zamanı platformu sunar. Doğru platformu seçmek; istek desenleri, durum yönetimi, derleme ve sürüm disiplini, operasyonel model ve ağ kısıtlamaları gibi iş yükü özelliklerine bağlıdır. Bu bölümde Cloud Run, App Engine, Cloud Functions, Google Kubernetes Engine (GKE) ve Compute Engine için tasarım ilkeleri, hata modları ve artıları/eksileri ile birlikte imajlar, kimlik, ağ, yapılandırma ve operasyonlar için destekleyici hizmetler ele alınmaktadır.

Sunucusuz (Serverless) Çalışma Zamanları: Cloud Run, App Engine, Cloud Functions

Cloud Run

• Model: HTTP isteklerini işleyen tam yönetimli container’lar veya tamamlanana kadar çalışan container’laştırılmış Job’lar.
• Revizyonlar ve trafik: Her dağıtım (deploy), değiştirilemez (immutable) bir revizyon oluşturur. Trafiği revizyonlar arasında yüzdelik olarak bölmek, anında geri alma (rollback) imkanıyla canary ve blue-green desenlerini mümkün kılar. Örnek:

  gcloud run services update-traffic my-svc --to-revisions rev-green=90,rev-blue=10

• Eş zamanlılık ve ölçeklendirme: Varsayılan eş zamanlılık 80’dir; CPU’ya bağlı veya thread-safe olmayan kodlar için 1’e ayarlayın. Daha yüksek eş zamanlılık, cold-start (soğuk başlangıç) etkisini ve maliyeti azaltır, ancak istek başına CPU/bellek yetersizse kuyruk gecikmesini (tail latency) artırabilir. Cloud Run, gelen istek oranına göre sıfıra ve yukarı doğru ölçeklenir; cold-start’ları azaltmak ve maliyeti sınırlamak için min/max instance’lar ile kontrol edin.
• CPU tahsisi: İstekler arasında arka plan işleri için ek faturalandırma maliyetiyle “CPU her zaman tahsisli” seçeneğini tercih edin; aksi takdirde CPU yalnızca istekler işlenirken tahsis edilir.
• Job’lar: Cloud Run Job’ları, görev başına maksimum yeniden deneme ve genel zaman aşımları ile tamamlanana kadar N paralel görev çalıştırır; ETL, toplu (batch) ve fan-out işleme için uygundur. Hata modları arasında, birçok görevin aynı bağımlılığı hedeflediğinde backend’lerde hot-spotting (yoğunlaşma) oluşması yer alır; rate limiting (hız sınırlama) ve backoff (gecikmeli yeniden deneme) ile yeniden denemeler ekleyin.
• Ağ: Herkese açık (public), IAM aracılığıyla kimlik doğrulamalı veya Serverless VPC Access ve Private Service Connect aracılığıyla VPC arkasında özel (private).

App Engine

• Ortamlar:
  • Standard: Korumalı (sandboxed), hızlı ölçeklenme, dil başına sabit çalışma zamanları; otomatik ölçeklendirme ile düşük cold-start gecikmesi; kısıtlı dosya sistemi, istek zaman aşımları ve gelen istek boyutu limitleri. Büyük yüklemeler için Cloud Storage imzalı URL’lerini kullanın.
  • Flexible: Docker tabanlı, VM benzeri yetenekler, özel çalışma zamanları, Standard’a göre daha yavaş ölçeklenme, arka plan thread’lerini ve yerel diske yazmayı destekler.
• Servisler ve versiyonlar: Bir servis (mikroservis) birden çok versiyon barındırabilir; trafiği Cloud Run’a benzer şekilde versiyonlar arasında yüzdelik olarak yönlendirin. Harici bir yük dengeleyici olmadan basit, merkezi yönlendirme için belirli yolları veya host’ları servislere yönlendirmek için dispatch.yaml kullanın.
• Ölçeklendirme: Standard’da manuel, temel veya otomatik; Flexible’da VM sayısına dayalı ölçeklendirme. Artıları/Eksileri: Agresif otomatik ölçeklendirme yanıt verme süresini iyileştirir ancak maliyeti ve backend çekişmesini artırabilir.
• Yaygın tuzaklar: Kotasız sınırsız instance ölçeklenmesi, bağımlı sistemleri (downstream) bunaltabilir; kotalar ve circuit breaker’lar (devre kesiciler) uygulayın.

Cloud Functions

• Olay güdümlü işleyiciler (handler’lar): HTTP, Pub/Sub, Cloud Storage veya Eventarc olayları tarafından tetiklenir. Cloud Run’ın yürütme modelinden, VPC çıkış (egress) kontrolünden ve eş zamanlılıktan yararlanmak için 2. nesli kullanın; 1. nesil her seferinde bir isteği işler.
• Yeniden denemeler ve Idempotency: Arka plan (background) fonksiyonları hata durumunda yeniden denenebilir; çift işlemeyi önlemek için idempotent handler’lar tasarlayın ve tekilleştirme anahtarları (de-duplication keys) kullanın. HTTP tetikleyicileri platform tarafından yeniden denenmez; istemci tarafında exponential backoff ile yeniden denemeler uygulayın.
• Çalışma zamanı yapılandırması: Ortam değişkenleri, Secret Manager entegrasyonu ve fonksiyon başına eş zamanlılık/maksimum instance sayısı. Kontrolden çıkan maliyetleri sınırlamak için zaman aşımları (timeout) ayarlayın. Büyük bağımlılıklara sahip uzun cold-start’lara dikkat edin; paketleri küçük tutun.

Google Kubernetes Engine üzerinde Container’lar

Workloads

• Deployment’lar: Rolling update’ler ile durumsuz (stateless) pod’lar. Surge/unavailable limitleri ile güvenli dağıtımlar (rollout) sağlayın:

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

• StatefulSet’ler: Durumlu (stateful) servisler için sıralı, kararlı ağ kimlikleri ve kalıcı birimler (persistent volume).
• DaemonSet’ler, Job’lar, CronJob’lar: Node seviyesinde agent’lar ve toplu (batch) iş yükleri.

Servisler ve Ingress

• Servis tipleri:
  • Sadece dahili kullanım için ClusterIP.
  • Basit harici erişim için NodePort (operasyonel olarak sınırlı).
  • Bölgesel harici/dahili yük dengeleme için LoadBalancer.
• Ingress: HTTP(S) yönlendirme ve TLS sonlandırma; L7 politikaları için yönetilen denetleyicilere (controller) sahip Gateway API veya Ingress’i tercih edin. Hata modu: Güvenlik duvarı (firewall) nedeniyle sağlık kontrollerinin (health check) başarısız olması; yük dengeleyici IP aralıklarına backend node’larına erişim izni verin.

Otomatik Ölçeklendirme ve Node Pool’ları

• Horizontal Pod Autoscaler (HPA): Pod’ları CPU, bellek veya özel metriklere göre ölçeklendirir; erişilebilirliği korumak için Pod Disruption Budget’lar ile birleştirin.
• Vertical Pod Autoscaler (VPA): Pod isteklerini/limitlerini doğru boyutlandırır; geri besleme döngülerini (feedback loop) önlemek için aynı boyutta HPA+VPA’yı aynı anda kullanmaktan kaçının.
• Cluster Autoscaler: Bekleyen pod kaynak isteklerini karşılamak için node ekler/kaldırır.
• Node pool’ları: Havuzları iş yükü sınıfına göre ayırın. Zamanlama (scheduling) için taint/toleration’ları ve etiketleri (label) kullanın. Kesintiye toleranslı, maliyete duyarlı iş yükleri için spot/preemptible makineleri karıştırın. Throttling’i (kısılma) önlemek için pod başına limitlere yetecek kadar bellek bant genişliği/CPU’ya sahip makine türleri seçin.

Sağlık ve Dağıtımlar (Rollout)

• Liveness, readiness ve startup probe’ları, hazır olmayan pod’lara trafik gönderilmesini engeller ve kilitlenmiş (deadlocked) container’ları yeniden başlatır. Sıkı liveness probe’ları zincirleme yeniden başlatmalara neden olabilir; başlangıç gecikmelerini (initial delay) ve hata eşiklerini (failure threshold) ayarlayın.
• kubectl rollout undo ile geri alın (rollback). Canary için, birden çok Deployment ve Ingress/Gateway aracılığıyla Servis seviyesinde trafik bölme kullanın.

Uygulama İş Yükleri için Compute Engine

VM tasarımı

• Örnek şablonları (Instance templates); makine türünü, imajı, diskleri, hizmet hesabı kapsamlarını, başlangıç betiklerini ve meta verileri tanımlar. İmajları minimum düzeyde tutun; belirlenimci (deterministic) bir başlatma için başlangıç betiklerini veya Packer ile oluşturulmuş imajları kullanın.
• Diskler: Gecikmeye duyarlı uygulamalar için dengeli (balanced) veya SSD kalıcı diskleri kullanın. Düşük gecikme ve hızlı başlatma için, birden çok örneğe eklenmiş salt okunur bir kalıcı disk aracılığıyla yönetilen bir örnek grubu (managed instance group) genelinde büyük, salt okunur veri kümelerini paylaşın.
• Ağ (Networking): Yük dengeleyiciler (load balancers) kullanırken durum denetleyicileri (health checkers) için güvenlik duvarı kuralları oluşturun. Örnek:

  gcloud compute firewall-rules create allow-lb \
    --network my-net --allow tcp \
    --source-ranges 130.211.0.0/22,35.191.0.0/16 --direction INGRESS

Yönetilen Örnek Grupları (MIG’ler)

• CPU’ya, yük dengeleyicinin saniye başına istek sayısına, özel metriklere veya zamanlamalara göre otomatik ölçeklendirme (Autoscaling). Sürekli ve istikrarsız ölçeklendirmeyi (thrashing) önlemek için bekleme süreleri (cool-down) ayarlayın.
• Durum denetimleriyle otomatik onarım (Autohealing), sağlıksız VM’leri yeniden başlatır; 500 hataları sunmaktan kaçınmak için, durum denetimi yolunun yalnızca bağlantı noktası erişilebilirliğini değil, uygulamanın hazır olup olmadığını test ettiğinden emin olun.
• Kademeli (rolling) güncellemeler ve blue-green: Yeni bir örnek şablonu oluşturun ve örneklerin bir alt kümesine kanarya (canary) güncellemesi başlatın. Hatalar artarsa, önceki şablona geri dönün (rollback). Çalışma süresi denetimleri (Uptime checks) ve SLO tabanlı uyarılar, bozulmaları hızla tespit eder.

Günlükleme ve izleme

• Kod değişikliği yapmadan uygulama günlüklerini toplamak için aracıları (agent) yükleyin; Cloud Logging’e gönderin ve Cloud Monitoring aracılığıyla uyarı oluşturun. Minimum kesintiyle canlı tanılama için Debug Logpoints’i kullanın.

Derleme, Kimlik, Ağ, Gizli Bilgiler ve Operasyonlar

Artifact Registry ve imajlar

• Konteyner imajları ve dil yapıtları (language artifacts) için Artifact Registry kullanın. Güvenlik açığı taramasını ve kaynak kökeni (provenance) oluşturmayı etkinleştirin. İmajları küçük tutun:
  • Derleme ve çalışma zamanı ortamlarını ayırmak için çok aşamalı derlemeler (multi-stage builds) kullanın.
  • Son imajda geliştirme araçlarından kaçının; işletim sistemi ve paket sürümlerini sabitleyin. Örnek:

  FROM golang:1.22 AS build
  WORKDIR /src
  COPY . .
  RUN CGO_ENABLED=0 go build -o app

  FROM gcr.io/distroless/base-debian12
  COPY --from=build /src/app /app
  ENTRYPOINT ["/app"]

• Yükseltme (Promotion): İmajları değişmez (immutable) bir şekilde etiketleyin (ör. app:1.3.7, app:prod-20240901) ve Artifact Registry’de yeniden etiketleyerek yükseltin; üretimde değişken (mutable) latest etiketinden kaçının. Yükseltmeleri entegrasyon ve kanarya (canary) testi sonuçlarıyla denetleyin.

Çalışma zamanı kimliği ve en az ayrıcalık ilkesi

• Her iş yükü için gereken minimum IAM rollerine sahip özel bir hizmet hesabı atayın. Editor gibi geniş kapsamlı rollerden kaçının. GKE’de, Workload Identity aracılığıyla Kubernetes ServiceAccount’larını Google hizmet hesaplarıyla eşleştirin. Sunucusuz platformlar için, çalışma zamanı hizmet hesabını açıkça belirtin ve varsayılan-token kapsamlarını kaldırın.

VPC bağlayıcıları ve hizmet ağı

• Serverless VPC Access bağlayıcıları, Cloud Run, Cloud Functions ve App Engine’den gelen giden trafiği (egress) bir VPC’ye yönlendirir. Giden trafik modunu seçin:
  • Yalnızca özel aralıklar: RFC1918 ve VPC’ye bağlı hizmetlere ulaşmak için kullanılırken, genel (public) giden trafik doğrudan çıkar.
  • Tüm trafik: Belirlenimci (deterministic) giden trafik IP’leri ve kısıtlanmış giden trafik politikaları için bağlayıcı ve Cloud NAT üzerinden yönlendirilir.
• Özel (Private) bağımlılıklar: Cloud SQL için Private IP’yi ve Google API’leri veya iş ortağı hizmetleri için Private Service Connect’i tercih edin. Bağlayıcıların bölgeyle eşleştiğinden ve aktarım hızı (throughput) için boyutlandırıldığından emin olun; kısıtlamayı (throttling) önlemek için bağlayıcı CPU’sunu izleyin.

Yapılandırma, gizli bilgiler ve sağlık kontrolleri

• Gizli olmayan yapılandırma için ortam değişkenleri kullanın. Gizli bilgileri Secret Manager’da saklayın ve çalışma zamanında bağlayın veya enjekte edin; anahtarları düzenli olarak döndürün. GKE’de, Secret Manager için Secrets ve CSI sürücüsünü kullanın. App Engine ve Cloud Run’da, hizmet hesabına belirli gizli bilgilere erişim verin.
• Sağlık kontrolleri:
  • Cloud Run: çökme durumunda örnek (instance) yeniden başlar; istek seviyesinde kontroller ve gecikme SLI’ları kullanın.
  • App Engine: yerleşik sağlık kontrolleri; Flexible ortamı için liveness/readiness kontrollerini özelleştirin.
  • GKE: liveness/readiness/startup problarını yapılandırın.
  • Yük Dengeleyicilerin (LB) arkasındaki Compute Engine: uygulamaya özgü uç noktalarla HTTP(S) sağlık kontrolleri kullanın.

Sorun giderme, geri alma ve sürüm yayınlama desenleri

• Cloud Run ve App Engine’de trafik bölme ile mavi-yeşil (blue-green) ve kanarya (canary) dağıtımları; GKE’de paralel Deployment’lar veya aşamalı teslimat denetleyicileri kullanın; MIG’lerde örneklerin kanarya alt kümelerini kullanın. Her zaman SLO hata bütçesi ve gecikmeye dayalı iptal kriterleri tanımlayın.
• Yaygın hata modları:
  • Sıfıra ölçeklenme (scale-to-zero) veya büyük çaplı dağıtımlar sonrası ani ve yoğun trafik (thundering herds); minimum örnek sayısı, ısınma (warmup) prosedürleri ve hız sınırlama (rate limiting) ile azaltın.
  • Arka uç (backend) kotalarının veya bağlantı limitlerinin aşılması; üssel geri çekilme (exponential backoff) ve devre kesiciler (circuit breakers) uygulayın.
  • Büyük imajlar veya bağımlılıklar nedeniyle soğuk başlangıçlar (cold starts); imajları küçültün ve istemcileri önceden başlatın.

Pratik Problem Senaryosu

Acme Retail, bir imaj yeniden boyutlandırma API’sini kendi yönettiği VM’lerden, düşük gecikmeli yanıtlar, bölgesel bir Cloud Storage bucket’ına özel erişim ve güvenli kanarya (canary) sürümleri sunan, ölçeklenebilir, maliyet etkin bir platforma taşımayı planlıyor.

Yaklaşım

1. Hizmeti küçük bir konteyner imajı olarak paketleyin ve Artifact Registry’de yayınlayın.

• Gerekçe: Küçültülmüş, çok aşamalı bir Docker derlemesi, soğuk başlangıçları ve ağ transferini en aza indirir. Artifact Registry, taramaları ve yükseltme iş akışlarını merkezileştirir.

2. API’yi, minimum örnek sayısı 2, eşzamanlılık (concurrency) 40 ve CPU her zaman tahsisli (always allocated) seçeneği devre dışı olacak şekilde Cloud Run’a dağıtın.

• Gerekçe: Cloud Run, anında yatay ölçeklendirme ve yönetilen HTTPS sağlar. Küçük bir minimum örnek havuzu, günlük yoğun saatlerdeki soğuk başlangıç gecikmesini azaltır. 40’lık eşzamanlılık, I/O-bağımlı imaj dönüşümleri için maliyet ve kuyruk gecikmesini (tail latency) dengeler. Her zaman açık CPU’yu devre dışı bırakmak, istekler arasında boşta kalan işlem gücü için ödeme yapmayı önler.

3. Bir Serverless VPC Access bağlayıcısı oluşturun ve giden trafiği (egress) yalnızca özel aralıklara ayarlayın; alt ağda Private Google Access’i etkinleştirin ve gerekirse Cloud Storage için bir VPC-SC veya Private Service Connect uç noktası yapılandırın.

• Gerekçe: API, imajları genel (public) giden trafik olmadan özel olarak alıp yazmalıdır. Yalnızca özel aralıklar modu, yalnızca VPC trafiğinin bağlayıcıdan geçmesini sağlayarak genel çağrıların doğrudan ve verimli kalmasını sağlar. Private Google Access veya Private Service Connect, VPC’den Google API’lerine özel erişim sağlar.

4. Özel bir çalışma zamanı hizmet hesabına, hedef Cloud Storage bucket’ına ve gerekli gizli bilgilere en az ayrıcalık ilkesiyle erişim verin.

• Gerekçe: En az ayrıcalık ilkesi, patlama yarıçapını (blast radius) sınırlar. Çalışma zamanı kimliği, belirli bucket üzerinde storage.objectViewer ve storage.objectAdmin rollerini ve ihtiyaç duyulan Secret Manager gizli bilgileri üzerinde accessor rolünü alır.

5. API anahtarlarını ve ortama özel yapılandırmayı Secret Manager ve ortam değişkenlerinde saklayın; gizli bilgileri çalışma zamanında enjekte edin.

• Gerekçe: Merkezi gizli bilgi rotasyonu ve denetlenebilir erişim. Ortam değişkenleri aracılığıyla gizli olmayan yapılandırma, 12 faktör (12-factor) pratiklerini destekler.

6. Cloud Storage’dan gelen 429/5xx yanıtlarını yönetmek için üssel geri çekilme (exponential backoff) ve bir kez etkili (idempotent) yazma işlemleri uygulayın.

• Gerekçe: Ani trafik artışları veya bölgesel olaylar sırasında geçici hatalar meydana gelebilir. Jitter (rastgele gecikme) ile geri çekilme, hem API’yi hem de Cloud Storage’ı tekrar deneme fırtınalarından korur.

7. Bir kanarya (canary) revizyonu yapılandırın ve trafiğin %10’unu ona bölün; hata oranı, P95 gecikmesi ve doygunluğu (saturation) izleyin.

• Gerekçe: Cloud Run’da trafik bölme, güvenli ve aşamalı dağıtım sağlar. SLO tabanlı izleyiciler, hata bütçeleri çok hızlı tükenirse otomatik geri alma tetikleyicileri sağlar.

8. Bağımlı olduğu alt sistemleri (downstream) test eden bir HTTP sağlık uç noktası ekleyin; Cloud Monitoring çalışma süresi kontrolleri (uptime checks) ve log tabanlı metrikler üzerine alarmlar kurun.

• Gerekçe: Uçtan uca sağlık kontrolü, bağımlılık hatalarını erken tespit eder. Çalışma süresi kontrolleri dışarıdan bir bakış açısı sağlar; log tabanlı metrikler uygulamaya özgü hata desenlerini yakalar.

9. Otomatik ölçeklendirme limitleri ve bütçeler belirleyin; harcamayı sınırlamak için maksimum örnek sayısını ayarlayın ve aşırı yük için 429 yanıtı yönetimini tanımlayın.

• Gerekçe: Ölçeklendirmeyi sınırlamak, kontrolsüz maliyeti ve arka uç kaynaklarının tükenmesini önler. Zarif aşırı yük davranışı, hizmet kararlılığını korur.

10. Geri alma (rollback) sürecini belgeleyin: tek bir komutla trafiğin %100’ünü önceki Cloud Run revizyonuna geri kaydırın.

• Gerekçe: Değişmez (immutable) revizyonlar, geri almayı güvenli ve hızlı hale getirerek ortalama kurtarma süresini (MTTR) en aza indirir.

← Buluta Özgü Uygulama Mimarisi ve Hizmet Seçimi · Tüm alanlar · API Tasarımı →

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

Google'a göz atın →