Google PCD: Maliyet, Yönetişim ve Sürdürülebilir Uygulama Operasyonları — Ç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ış

Modern Google Cloud uygulama geliştirmede maliyet, yönetişim ve sürdürülebilir operasyonlar ayrılmaz bir bütündür. Amaç, harcamaları görünür kılmak ve kontrol etmek, ekonomik olarak ölçeklenen hizmetler tasarlamak ve ortamları güvenli, uyumlu ve temiz tutan koruma mekanizmalarını (guardrails) performans ve güvenilirliği dengelerken uygulamaktır. Bu bölüm, pratik mekanizmaları (faturalandırma ve etiketler, otomatik ölçeklendirme ayarları, kotalar ve politikalar), iş yüküne özgü ekonomiyi (Cloud Run, GKE, veri platformları) ve kullanıcı deneyiminden ödün vermeden atıl kaynak israfını ve karbon etkisini azaltan sürdürülebilirlik odaklı seçimleri detaylandırmaktadır.

Maliyet Kontrolleri ve Görünürlük

• Faturalandırma hesapları, etiketler, maliyet dağıtımı, bütçeler, uyarılar ve görünürlük
  • Sahipliği ayırmak ve ayrıntılı izinleri etkinleştirmek için her iş birimi veya fon kaynağı başına özel bir faturalandırma hesabı kullanın. Ayrıntılı analiz, tahmin ve geri ödeme (chargeback) için faturalandırma verilerini BigQuery’ye aktarın.
  • Etiketler, maliyet ilişkilendirmesi için kaynaklar üzerindeki anahtar-değer çiftleridir. Etiket anahtarlarını (team, app, env, cost-center) standartlaştırın ve kuruluş politikası (organization policy) ve CI kontrolleri aracılığıyla zorunlu kılın. Not: Etiketler geriye dönük değildir; etiketlenmemiş kaynaklar raporları saptırır.
  • Faturalandırma hesabı ve proje seviyelerinde bütçeler ve uyarılar kullanın. Eşikleri (ör. yüzde 50, 90, 100) ve tahmine dayalı tetikleyicileri birleştirin. Bütçe bildirimlerini Pub/Sub’a yönlendirin ve Chat/Ops araçlarına iletin. Bütçeler uyarır; zorlama yapmazlar.
  • Paylaşılan platformlar (ör. GKE, BigQuery) için, ad alanı (namespace) veya iş (job) başına etiketler kullanın ve gösterim (showback)/geri ödeme (chargeback) sağlamak için bunları loglara ve kullanıma ekleyin.

Örnek: etiket ekleme

undefined

• Kotalar, limitler, tüketim tahmini ve kapasite yönetişimi
  • Kotalar servisleri korur ve kontrolsüz maliyetleri sınırlar. Servis kotalarını düzenli olarak gözden geçirin, proje başına doğru boyutlandırın ve lansmanlardan önce artış talep edin. Beklenen en yüksek kullanımı kotalarla karşılaştıran dağıtım öncesi kontroller uygulayın.
  • Faturalandırma dışa aktarımı (Billing export) ve ürün kullanım telemetrisini (Cloud Monitoring metrikleri, log tabanlı metrikler) kullanarak harcamaları tahmin edin. Senaryoları (beklenen QPS, taranan veri) modelleyin ve üretim öncesi (pre-production) ortamda doğrulayın.
  • Hata modları: bir olay veya ürün lansmanı sırasında kotaya takılmak, kısıtlamaya (throttling) (429/403), kısmi kesintilere veya sessiz bozulmaya yol açar. Aşırı tahsis edilmiş kotalar, hatalı işlerin etki alanını (blast radius) artırır.

Örnek: Compute Engine kotalarını listeleme

undefined

Esneklik ve İşlem Ekonomisi

• Doğru boyutlandırma, otomatik ölçeklendirme, istek tabanlı faturalandırma, taahhütlü kullanım ve spot kapasite

  • Cloud Monitoring ve Recommender öngörülerini kullanarak vCPU ve belleği doğru boyutlandırın; yük testleriyle doğrulayın. Yetersiz kaynak tahsisi, gecikme ani artışlarına ve OOM/CPU kısıtlamasına neden olur; aşırı kaynak tahsisi ise harcama israfına yol açar.
  • Otomatik ölçeklendirme, capex benzeri aşırı kaynak sağlamayı esnek opex’e dönüştürür. Kapasiteyi taleple eşleştirmek için GKE için HPA/VPA ve sunucusuz (Cloud Run) için istek başına otomatik ölçeklendirme kullanın.
  • İstek tabanlı faturalandırma (Cloud Run, Cloud Functions, GKE Autopilot) maliyeti kullanımla uyumlu hale getirir ve boştaki süreyi azaltır. İstek başına ek yüklere ve soğuk başlatmalara dikkat edin; uygun olan yerlerde minimum instance sayısını ayarlayın.
  • Taahhütlü kullanım, kararlı durumdaki temel iş yükleri içindir. Compute Engine için kaynak tabanlı CUD’leri ve uygun yönetilen/sunucusuz ürünler için esnek CUD’leri kullanın. Değişken iş yükleri için aşırı taahhütte bulunmayın.
  • Spot kapasite, kesintiye uğrayabilir, hataya dayanıklı işler için işlem maliyetini düşürür. Her zaman düzgün sonlandırma işleyicileri (graceful termination handlers) uygulayın; yedekliliği ve hızlı checkpoint almayı sürdürün. Kısa bir bildirimle herhangi bir zamanda sonlandırılmayı bekleyin.

• Cloud Run eş zamanlılık (concurrency) ve minimum instance takasları

  • Eş zamanlılık (concurrency), tek bir instance’ın aynı anda kaç isteğe hizmet verebileceğini kontrol eder.
    • Daha yüksek eş zamanlılık, kullanım oranını ve maliyet verimliliğini artırır ancak container içindeki hat başı engellemesi (head-of-line blocking) nedeniyle kuyruk gecikmesini (tail latency) yükseltebilir.
    • 1’lik bir eş zamanlılık değeri istekleri izole eder (CPU’ya bağlı veya thread-safe olmayan kodlar için kullanışlıdır) ancak genellikle instance sayısını ve maliyeti artırır.
  • Minimum instance’lar, temel bir harcama maliyeti karşılığında soğuk başlatmaları azaltır ve gecikmeyi yumuşatır. Yalnızca SLO’ların gerektirdiği durumlarda kullanın ve bu taban seviyeyi talep desenleriyle doğrulayın.

Örnek: Cloud Run yapılandırması (service.yaml) apiVersion: serving.knative.dev/v1 kind: Service metadata: name: img-api annotations: autoscaling.knative.dev/minScale: “2” spec: template: spec: containerConcurrency: 40 containers: - image: gcr.io/PROJECT/img-api resources: limits: memory: “512Mi”

• GKE kaynak talepleri (requests) ve limitleri (limits), cluster autoscaler davranışı ve boştaki kaynakların temizlenmesi
  • Talepler (requests) zamanlamayı (scheduling) belirler; limitler (limits) ise en yüksek kullanımı sınırlar. Talepleri gözlemlenen kararlı durum ihtiyacına yakın, limitleri ise kısa süreli ani artışlara izin vermek için bunun biraz üzerinde ayarlayın. Çok düşük limitler CPU kısıtlamasına neden olur; çok düşük bellek limitleri ise OOMKilled hatasına yol açar. Gerçekliğin çok üzerindeki talepler kapasiteyi atıl bırakır ve zamanlamayı engeller.
  • Cluster Autoscaler, zamanlanamayan pod’lara (yetersiz toplam talep (request) nedeniyle) dayanarak node havuzlarını ölçeklendirir. PodDisruptionBudgets’a uyar ve belirli pod’ları (ör. yerel depolamaya sahip veya kısıtlayıcı PDB’leri olan) çıkaramaz (evict), bu da küçülmeyi engelleyebilir. DaemonSet’ler ve node taint’leri/affinity’leri de ölçeklenme verimliliğini engelleyebilir.
  • Horizontal Pod Autoscaler, ölçeklendirmeyi CPU/bellek veya özel metriklere bağlar; Vertical Pod Autoscaler ise zaman içinde talepleri (requests) doğru boyutlandırır. Salınımdan (oscillation) kaçınmak için HPA ve VPA’yı koordine edin; VPA’yı uygun şekilde tavsiye (recommend) veya otomatik (auto) modlarında kullanın.
  • Boştaki kaynakların temizlenmesi: kullanılmayan load balancer’ları, persistent disk’leri, snapshot’ları ve statik IP’leri silin. Boştaki varlıkları tespit edip kaldırmak için Active Assist önerilerini ve otomatik temizleyicileri kullanın.

Örnek: Talepleri/limitleri olan GKE deployment’ı apiVersion: apps/v1 kind: Deployment metadata: name: api spec: replicas: 3 template: spec: containers: - name: api image: gcr.io/PROJECT/api:stable resources: requests: cpu: “500m” memory: “512Mi” limits: cpu: “1” memory: “768Mi”

Veri, Analitik ve Ağ Maliyet Yönetimi

• Depolama sınıfları, yaşam döngüsü kontrolleri, veritabanı ölçeklendirme ve ağ çıkış (egress) tasarımı
  • Erişim desenine göre Cloud Storage sınıflarını seçin: Sık erişilen (hot) veriler için Standard; daha seyrek erişilen (colder) veriler için Nearline, Coldline veya Archive. Daha soğuk katmanlar için geri getirme (retrieval) ve erken silme (early-delete) minimumlarına dikkat edin.
  • Yaşam döngüsü (lifecycle) kuralları, geçişleri ve silmeleri otomatikleştirir. Çok bölgeli (multi-region) gecikmenin kabul edilebilir olduğu durumlarda dayanıklılık (resilience) için çift bölgeli (dual-region) kullanın; ağ çıkışını ve gecikmeyi azaltmak için işlem (compute) ve veriyi aynı yerde konumlandırın.
  • Veritabanı ölçeklendirme:
    • Cloud SQL: dikey olarak dikkatli bir şekilde ölçeklendirin; okuma işlemleri için okuma replikaları (read replicas) kullanın; depolama için otomatik ölçeklendirmeyi (autoscaling) etkinleştirin; sorgu planları ve bağlantı havuzu (connection pooling) kullanın. Yüksek yazma performansı (throughput), parçalama (sharding) veya Spanner/Bigtable’a geçiş gerektirebilir.
    • Spanner: düğüm (node) ekleyerek yatay ölçeklendirme; yüksek erişilebilirlik (availability) ve küresel okumalar için çok bölgeli (multi-region) yapılandırmalar; dengeli yük için şemaları ve anahtarları tasarlayın.
    • Bigtable: etkin nokta (hotspot) oluşumunu önlemek için satır anahtarlarını (row keys) tasarlayın; küme düğümlerini ve depolamayı ayrı ayrı ölçeklendirin.
  • Ağ çıkışı (Network egress): bölgeler arası (cross-region) trafikten kaçının; mümkün olduğunda istemcileri ve verileri aynı bölgeye yerleştirin. İnternet ölçeğindeki içerikler için Cloud CDN, hibrit bağlantılar için Cloud Interconnect/Peering ve Google API’lerine özel olarak erişmek için Private Google Access veya Private Service Connect kullanın. Gereksiz bölgeler arası (cross-zone/regional) trafik, maliyeti ve gecikmeyi artırır.

Örnek: Cloud Storage yaşam döngüsü cat > policy.json « ‘EOF’ { “rule”: [ { “action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30} }, { “action”: {“type”: “Delete”}, “condition”: {“age”: 365} } ] } EOF gsutil lifecycle set policy.json gs://my-bucket

• BigQuery sorgu kontrolleri, veri saklama ve analitik kullanım maliyeti
  • Taranan bayt miktarını kontrol edin: her zaman bölüm (partition) / küme (cluster) anahtarlarına göre filtreleyin; SELECT * kullanımından kaçının; tekrarlanan sorgular için somutlaştırılmış görünümler (materialized views) ve sonuç önbelleğini (result caching) kullanın; mümkün olduğunda yaklaşık birleştirmeler (approximate aggregations) kullanın.
  • Faturalandırılacak maksimum bayt (maximum bytes billed) ile tarama maliyetini sınırlayın ve acil olmayan işler için iş önceliğini (job priority) toplu (batch) olarak ayarlayarak çakışmayı ve maliyeti azaltın.
  • Fiyatlandırma modelini seçin: düzensiz (sporadic) iş yükleri için isteğe bağlı (on-demand); sürekli yüksek hacimli iş yükleri için taahhütlü rezervasyonlar (slots). Ekipleri izole etmek için ayrı rezervasyonlar ve atamalar kullanın.
  • Veri saklama (Data retention): yönetişim (governance) için veri kümesi/tablo ve bölüm sona erme (expiration) sürelerini ayarlayın; arşivleme için katmanlı depolama veya dışa aktarma (export) uygulayın.
  • Hata modları: bölümlenmemiş (unpartitioned) büyük tablolar maliyetleri patlatır; bölüm filtresi olmayan sorgular tüm tabloları tarar; aşırı agresif sona erme süreleri gerekli verileri siler; aşırı slot çekişmesi (contention) SLA’yı düşürür.

Örnek: sorgu maliyetini sınırlama bq query –use_legacy_sql=false –maximum_bytes_billed=1000000000
‘SELECT user_id, COUNT(*) FROM proj.ds.events WHERE _PARTITIONDATE >= DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) GROUP BY user_id’

Kurumsal Yönetişim ve Ortam Hijyeni

• Kuruluş politikaları, kaynak adlandırma, etiketleme ve proje ayrımı

  • Koruma mekanizmalarını (guardrails) uygulamak için kuruluş politikalarını kullanın: kaynak konumlarını kısıtlayın, harici IP’lere izin vermeyin, CMEK kullanımını zorunlu kılın, izin verilen servisleri sınırlayın, VPC eşlemesini denetleyin ve gerektiğinde OS Login’i zorunlu hale getirin. Kuruluş veya klasör düzeyinde uygulayın ve istisnaları hiyerarşi aracılığıyla modelleyin.
  • Kaynak adlandırmasını; ortam, proje, uygulama ve bölge bilgilerini içerecek şekilde standartlaştırın (ör. app-env-region-suffix). CI kontrolleri veya policy-as-code aracılığıyla zorunlu kılın.
  • Farkları ayırt edin:
    • Etiketler (Labels): faturalandırma/operasyon ilişkilendirmesi için.
    • Etiketler (Tags) (birinci sınıf): kaynaklara eklenir ve IAM Koşullarında ve kuruluş politikası hedeflemesinde kullanılır.
    • Ağ etiketleri (Network tags): Compute Engine üzerindeki güvenlik duvarı kuralları için.
  • Proje ayrımı: ortamları (prod, staging, dev) ve hassas iş yüklerini izole edin. Merkezi ağ yönetimi ve en az ayrıcalık ilkesine sahip hizmet projeleri için Shared VPC kullanın. Bu, etki alanını (blast radius) daraltır ve IAM’i basitleştirir.

• Ortam yaşam döngüsü, geçici (ephemeral) test ortamları ve temizlik otomasyonu

  • Ortamları IaC (Terraform) aracılığıyla sağlayın ve her PR (pull request) için geçici ortamları etkinleştirin. TTL etiketleri ayarlayın ve birleştirme (merge) veya hareketsizlik sonrası otomatik olarak ortamı kaldırın.
  • Etikete/yaşa göre eski kaynakları tarayıp silmek için Cloud Scheduler ile Cloud Run işlerini veya Functions’ı kullanın. Denetimleri yönlendirmek için envanteri Cloud Asset Inventory aracılığıyla dışa aktarın.
  • Hata modları: terk edilmiş sandbox’lar maliyete neden olur; eksik TTL veya etiketler temizliği engeller; aşırı agresif temizlik aktif kaynakları silebilir—izin listeleri (allowlists) ve ek süreler (grace periods) ekleyin.

• Sürdürülebilirlik odaklı mimari ve maliyet, performans ve güvenilirliği dengeleme

  • Boşta kalma süresini azaltmak ve kaynak kullanımını iyileştirmek için yönetilen (managed) ve sunucusuz (serverless) hizmetleri tercih edin.
  • Uyumlu olduğunda daha düşük karbon yoğunluğuna sahip bölgeleri seçin; mümkün olduğunda, toplu iş yüklerini daha yüksek karbonsuz enerji dönemlerinde çalışacak şekilde zamanlayın.
  • Ağ enerjisini azaltmak için veri yoğunluğunu (data gravity) ve önbelleğe almayı (caching) optimize edin. Yetersiz kullanımı düşürmek için otomatik ölçeklendirmeyi ve eş zamanlılığı (concurrency) ayarlayın. Aşırı işlem gücü veya G/Ç (IO) tetikleyen israfçı kod yollarını kaldırmak için profil oluşturma (profiling) kullanın.
  • Dengeleme: yalnızca SLO’ların gerektirdiği yerlerde minimum örnek (instance) veya replika ekleyin; kuyruk gecikmesini (tail latency) eş zamanlılığa (concurrency) karşı ve yedekliliği (redundancy) spot kullanımına karşı değerlendirin. SLO tabanlı yük testleri ve maliyet/performans modellemesi ile doğrulayın.

Pratik Problem Senaryosu

Bir e-ticaret şirketi olan NimbusMarket, ani indirim (flash sale) dönemlerinde yoğun trafik artışları ve büyüyen analiz harcamaları yaşıyor. Müşteri API’lerini Cloud Run’da, arka plan işçilerini (workers) GKE’de ve ürün analizlerini BigQuery’de çalıştırıyorlar. Yönetim, %99,9’luk API SLO’sundan ödün vermeden maliyetlerde yüzde 25’lik bir azalma talep ediyor.

Yaklaşım:

1. Maliyet görünürlüğü sağlayın ve koruma mekanizmaları oluşturun

   • Faturalandırma hesabı için %60, %90 ve %100’de tahmin uyarıları olan bütçeler oluşturun ve Pub/Sub bildirimlerini nöbetçi ekibe (on-call) yönlendirin.
   • Etiketleri (takım, uygulama, ortam, maliyet-merkezi) standartlaştırın ve Terraform planları üzerinde CI ile zorunlu kılın; kaynak konumlarını onaylanmış bölgelerle kısıtlayan bir kuruluş politikası ekleyin. Gerekçe: Bütçeler erken uyarı sağlar; etiketler takım bazında raporların önünü açar; politikalar yanlışlıkla yüksek egress maliyetli bölgelerin kullanılmasını önler ve uyumluluğu artırır.

2. Ekonomik ölçeklenme için Cloud Run’ı optimize edin

   • Durum bilgisi olmayan (stateless) API için, 30 ms ortalama CPU süresi ve engellemeyen G/Ç (non-blocking IO) doğrulandıktan sonra, containerConcurrency değerini 40 olarak ayarlayın. Normal saatlerde soğuk başlatmaları (cold starts) önlemek için minScale=2 olarak yapılandırın; gece saatlerinde minScale’i 0’a düşürmek için zamanlanmış bir politika ayarlayın. Gerekçe: Daha yüksek eş zamanlılık, kaynak kullanımını iyileştirir ve örnek sayısını azaltır; minimum sayıda sürekli çalışan örnek, normal çalışma saatleri dışında kaldırılan sınırlı bir taban maliyetle SLO’ları korur.

3. GKE iş yüklerini doğru boyutlandırın ve verimli otomatik ölçeklendirmeyi etkinleştirin

   • Profil oluşturmaya dayanarak işçi pod’larına 500m CPU/512Mi istek (requests) ve 1 CPU/768Mi limit (limits) uygulayın. Kuyruk derinliği ve işlem gecikmesi üzerinden HPA’yı ve istekleri yinelemeli olarak iyileştirmek için VPA’yı tavsiye modunda (recommend mode) etkinleştirin. PodDisruptionBudgets’ın küçülmeye (scale-down) izin verdiğini doğrulayın. Havuzda (pool) birden çok daha küçük düğümle (node) Cluster Autoscaler’ı etkinleştirin. Gerekçe: Doğru istekler, etkili zamanlama ve otomatik ölçeklendirmeyi yönlendirir; HPA, kapasiteyi birikmiş iş (backlog) ile hizalar; VPA, sapmayı önler; birden çok küçük düğüm, atıl kapasiteyi azaltır ve ölçeklenme olaylarını hızlandırır.

4. Hataya dayanıklı toplu işler için Spot kapasitesini benimseyin

   • Görüntü küçültme (thumbnail generation) işlemlerini, ara noktalar oluşturarak (checkpointing) Spot destekli bir düğüm havuzuna taşıyın. Devam eden işleri tamamlamak için preStop kancaları ve kesintiye uğrayan işleri yeniden zamanlamak için bir denetleyici (controller) uygulayın. Gerekçe: Küçültme işlemi tekrarlanabilir (idempotent) ve zaman açısından esnektir, bu da onu kullanıcı deneyimi üzerinde minimum etkiyle Spot tasarrufları için ideal hale getirir.

5. Analiz tarama maliyetlerini azaltın ve iş yüklerini izole edin

   • Olaylar tablosunu event_date ve customer_id’ye göre bölümleyin (partition) ve kümeleyin (cluster). Ham olaylar için 180 gün sonra tablo geçerlilik süresi (expiration) ekleyin. Pazarlama analistlerini, bir slot sınırı olan ayrı bir BigQuery rezervasyonuna atayın; zamanlanmış sorgularında maximum_bytes_billed politikasını zorunlu kılın. Gece raporlarını toplu iş (batch) önceliğine dönüştürün. Gerekçe: Bölümleme ve kümeleme, sorgu başına taranan bayt miktarını sınırlar; geçerlilik süresi, yönetişimi zorunlu kılar; rezervasyonlar, gürültülü komşuları (noisy neighbors) izole eder; toplu iş önceliği, acil olmayan işler için çekişmeyi ve maliyeti azaltır.

6. Depolama yaşam döngüsünü ve egress’i optimize edin

   • Ürün görsellerini müşterilere yakın çift bölgeli (dual-region) bir alanda saklayın; 30 gün boyunca dokunulmayan görselleri yaşam döngüsü kurallarıyla Coldline’a taşıyın; Cloud CDN aracılığıyla sunun. Cloud Run hizmetlerini Cloud SQL ile aynı bölgede konumlandırın ve Google API’lerine Private Service Connect’i etkinleştirin. Gerekçe: CDN, egress maliyetini ve gecikmeyi azaltır; yaşam döngüsü, soğuk içeriği daha ucuz depolamaya kaydırır; aynı yerde konumlandırma, egress’i en aza indirir ve performansı artırır.

7. Temizlik otomasyonu ve sürdürülebilirlik kontrolleri uygulayın

   • Geçici ortamları ttl-hours ile etiketleyin ve süresi dolan kaynakları silen gece çalışan bir Cloud Run işi çalıştırın. Toplu işleri daha düşük karbonlu bir bölgeye taşımayı ve karbon salınımının düşük olduğu saatlerde zamanlamayı değerlendirmek için Carbon Footprint raporlarını kullanın. Gerekçe: Otomatik temizlik, maliyet sızıntılarını önler; karbon odaklı zamanlama, SLO’ları etkilemeden çevresel etkiyi azaltır.

8. SLO odaklı yük testleri ve maliyet modelleri ile doğrulayın

   • Ani indirim (flash-sale) modellerini yeniden canlandıran yük testleri çalıştırın; p95 gecikmesini ve hata bütçelerini (error budgets) doğrulayın. Faturalandırma dışa aktarma panolarını kullanarak öncesi ve sonrası maliyeti karşılaştırın. Gerekçe: Optimizasyonların, hedeflerle uyumlu ölçülebilir tasarruflar sağlarken güvenilirlik hedeflerini karşıladığını onaylar.

Bu adımları uygulayarak NimbusMarket, harcamaları taleple uyumlu hale getirir, boşta kaynak israfını önler ve yönetişimi uygular. Böylece %99,9’luk API SLO’sunu korurken hedeflenen tasarrufları elde eder ve sürdürülebilirlik duruşunu iyileştirir.

← Test · Tüm alanlar

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

Google'a göz atın →