Google ACE: Maliyet Yönetimi, Performans ve Kapasite Optimizasyonu — Ç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 maliyet yönetimi ve performans/kapasite optimizasyonu; sürekli görünürlük, doğru boyutlandırma kararları ve kaynak kullanımını iş hedefleriyle uyumlu hale getiren bir yönetişim gerektirir. Etkili bir uygulama; finansal kontrolleri (bütçeler, tahsis), teknik kaldıraçları (otomatik ölçeklendirme, rezervasyonlar, yaşam döngüsü politikaları), mimari seçimleri (veri yerelliği, replikasyon) ve operasyonel geri bildirimi (telemetri, yük testleri) bir araya getirir. Bu bölüm; işlem, depolama, veri işleme, ağ, veritabanları, kotalar ve performans mühendisliği alanlarındaki temel araçları, ödünleşimleri ve başarısızlık senaryolarını detaylandırmaktadır.

Maliyet Görünürlüğü, Bütçeler ve Tahsis

• Faturalandırma raporları ve dışa aktarımları:

  • Hızlı trend ve SKU dökümleri için Cloud Billing Reports’u kullanın; ayrıntılı, sorgulanabilir maliyet ve kullanım verileri için Cloud Billing veri dışa aktarımını BigQuery’ye etkinleştirin. Bu, standart SQL ile günlük/aylık tahminleri, anomali tespitini ve çok projeli toplamaları destekler.
  • Fiyatlandırma tablosu dışa aktarımı, liste fiyatlarını SKU maliyetleri ve kredilerle mutabık kılmaya yardımcı olur.
  • Başarısızlık senaryoları: Yalnızca konsol görünümlerini kullanmak ayrıntı düzeyini sınırlar; BigQuery’ye veri aktarmamak, geçmişe dönük modellemeyi ve doğru showback/chargeback uygulamalarını engeller.

• Bütçeler ve uyarılar:

  • Faturalandırma hesapları, projeler, klasörler, servisler veya etiket/tag filtreleri kapsamında bütçeler oluşturun; gerçekleşen ve tahmini maliyet üzerinden eşik uyarıları (ör. %50/%90/%100) yapılandırın. Otomatik eylemleri (ör. üretim dışı ortamları duraklatma) tetiklemek için Pub/Sub aracılığıyla bildirim kanallarını kullanmayı düşünün.
  • Ödünleşim: Agresif otomatik kapatmalar harcamayı azaltır ancak üretim yollarına uygulanırsa güvenilirliğe zarar verebilir.

• Tahsis için etiketler ve tag’ler:

  • Kaynak etiketlerini ve Resource Manager tag’lerini (env, app, owner, cost-center) tutarlı bir şekilde uygulayın. Tag’ler, kuruluş politikalarını destekler ve sağlam bir tahsis için faturalandırma filtrelerinde görünür.
  • Yönetişim: Organization Policy, dağıtım şablonları ve CI/CD kontrollerini kullanarak etiket/tag politikalarını zorunlu kılın.
  • Başarısızlık senaryoları: Tutarsız anahtarlar veya eksik etiketler tahsis modellerini bozar; araçlar tutarsızsa devralınan tag’ler tüm kaynak türlerine uygulanmaz.

• Maliyet tahsis modelleri:

  • Showback/chargeback genellikle bir hiyerarşi kullanır: proje → servis/SKU → etiket/tag. Paylaşılan platform maliyetleri (ör. load balancer’lar, VPC çıkış trafiği), log’lar/metrikler aracılığıyla ölçülen istek sayısı, aktarılan GB veya CPU-saat gibi tetikleyicilere göre paylaştırılabilir.
  • Ödünleşim: Basit modellerin (eşit paylaşım) çalıştırılması kolaydır ancak yoğun kullanıcıları yanlış fiyatlandırabilir; ayrıntılı modeller güvenilir telemetri ve daha fazla ek yük gerektirir.

Kısa örnek (Maliyet tahmini için BigQuery deneme çalıştırması):

• bq query –use_legacy_sql=false –dry_run ‘SELECT … FROM proj.ds.tbl WHERE dt >= “2026-08-01”’

İşlem Verimliliği ve Yaşam Döngüsü Optimizasyonu

• Doğru boyutlandırma ve özel makine türleri:
  • CPU/bellek kullanım yüzdeliklerine göre VM’leri doğru boyutlandırmak için Recommender API/konsolunu kullanın. Kullanılmayan kapasite için ödeme yapmaktan kaçınmak amacıyla, sabit ve standart altı ihtiyaçlar (ör. 2 vCPU/10 GB RAM) için özel makine türlerini tercih edin.
  • Başarısızlık senaryoları: Gecikmeye duyarlı veya anlık yoğunluk yaşayan servislerin boyutunu küçültmek, kısıtlamaya (throttling

Performans Ölçümü ve Optimizasyon Yönetişimi

• Ölçüm ve yük testi:

  • Gecikme, hata oranı ve doygunluk (saturation) için SLI/SLO’lar oluşturun. Cloud Monitoring panolarını, çalışma süresi denetimlerini (uptime checks) ve uyarıları kullanın. Yoğun kullanılan yolları (hot paths) ve kilit çekişmesini (lock contention) bulmak için izleme (Cloud Trace) ve profil oluşturma (Cloud Profiler) araçlarını entegre edin.
  • Gerçekçi trafik modelleri, veri kardinalitesi ve düşünme süreleri (think times) ile yük testi yapın. Autoscaler parametrelerini, ısınma (warm-up) ve hazır olma kapılarını (readiness gates) doğrulayın. Kapasite payını (capacity headroom) ve kurtarma süresini (recovery time) gözlemlemek için failover ve kaos senaryolarını dahil edin.
  • Darboğaz teşhisi: CPU, bellek, disk, ağ ve bağımlı aşağı akış (downstream) sistemleri genelinde USE yöntemini (Kullanım, Doygunluk, Hatalar - Utilization, Saturation, Errors) kullanın; loglar ve izlerle (traces) ilişkilendirin.

• Maliyet, güvenlik ve güvenilirliği dengeleyen yönetişim:

  • FinOps koruma mekanizmaları (guardrails): Zorunlu etiketler/tag’ler; tahmin uyarıları içeren bütçeler; merkezileştirilmiş fatura dışa aktarımları ve maliyet gözden geçirme periyotları. Recommender bulgularını (boştaki IP’ler/diskler, doğru boyutlandırma) sahip SLA’ları ile birlikte biriktirme listesine (backlog) ekleyin.
  • Güvenlik: Özel bağlantıyı (harici IP olmadan) tercih edin, veri sızdırma riskleri için VPC Service Controls kullanın—özel yolların çıkış (egress) modellerini ve maliyetleri değiştirebileceğini unutmayın. Bekleme (at rest) ve aktarım (in transit) sırasında verileri şifreleyin; KMS kullanımını maliyet modellerine dahil edin.
  • Güvenilirlik: CUDs veya BigQuery rezervasyonları aracılığıyla temel kapasiteyi rezerve edin; SLO’lar için ani artış payı (burst headroom) bırakın; düzenli olarak ‘game day’ tatbikatları yapın. Kritik yollar için Spot veya agresif autoscaling’in ne zaman kabul edilemez olduğunu belgeleyin.
  • Değişiklik yönetimi: Maliyeti etkileyen parametreleri (autoscaler limitleri, BigQuery rezervasyonları, LB topolojisi) gözden geçirme ve geri alma (rollback) planları ile birlikte kod olarak ele alın (as code).

Pratik Problem Senaryosu

Contoso Media, artan maliyetler ve trafik zirveleri sırasında zaman zaman yaşanan gecikme SLO ihlalleri ile karşılaşan çok bölgeli bir video analiz platformu işletmektedir. Yönetim, API için 300 ms’lik p95 gecikme SLO’sundan ve gecelik toplu iş (batch) tamamlaması için 2 saatlik SLA’dan ödün vermeden %20 maliyet düşüşü istemektedir.

1. Maliyet ve performans temellerini (baseline) oluşturun

• Eylem: Cloud Billing dışa aktarımını BigQuery’ye etkinleştirin ve SKU maliyetlerini Cloud Monitoring SLI’ları (gecikme, CPU, çıkış yapılan baytlar) ile ilişkilendiren panolar oluşturun. Taranan baytları tahmin etmek için en iyi 20 sorgu üzerinde bq dry runs komutunu çalıştırın.
• Gerekçe: Temeller (baseline), yüksek etkili hizmetleri belirler ve harcamaları performans etkenleriyle eşleştirerek hedefli optimizasyona olanak tanır.

2. Tahsis etiketlemesini ve bütçeleri zorunlu kılın

• Eylem: Dağıtım şablonları aracılığıyla etiketleri/tag’leri (ortam, hizmet, sahip, maliyet-merkezi) zorunlu kılın; her ortam için bir FinOps Pub/Sub konusuna (topic) tahmin uyarıları gönderen bütçeler belirleyin.
• Gerekçe: Eksiksiz tahsis verileri ve proaktif uyarılar, aşırı harcamalardan önce hızlı sahiplenme ve düzeltici eylem sağlar.

3. Temel işlem gücünü doğru boyutlandırın ve taahhüt edin

• Eylem: İstikrarlı hizmetlere Recommender VM doğru boyutlandırma önerilerini uygulayın; kararlı durum kapasitesini 1 yıllık bölgesel CUD’lere dönüştürün; ani artışlar için autoscaler maksimum değerinde %20–30’luk bir tampon bırakın.
• Gerekçe: Doğru boyutlandırma ve taahhütler, öngörülebilir yüklerde birim maliyeti düşürürken SLO’lar için kapasite payını korur.

4. Otomatik ölçeklendirmeyi (autoscaling) ve hazır olmayı (readiness) optimize edin

• Eylem: MIG’ler için, otomatik ölçeklendirme sinyallerini istek tabanlı veya özel QPS/gecikme metriklerine değiştirin, bekleme süresini (cool-down) 120–180 saniyeye ayarlayın ve sağlık denetimi (health check) başlangıç gecikmesini uygulamanın ısınma süresiyle (warm-up) hizalayın. Hızlı küçülmeyi önlemek için içeri ölçeklendirme (scale-in) kontrollerini etkinleştirin.
• Gerekçe: İş yüküne duyarlı sinyaller ve stabilizasyon, maliyeti şişiren ve gecikmeyi olumsuz etkileyen kararsızlığı (thrash) ve aşırı kaynak sağlamayı (overprovisioning) önler.

5. Ağ çıkışını (egress) ve yük dengeleyici (load balancer) ek yükünü azaltın

• Eylem: Hizmetler arasındaki harici IP iletişimini kaldırın; tüm doğu-batı (east-west) trafiğinin dahili yük dengeleme kullandığından emin olun; yoğun iletişim kuran (chatty) hizmetleri bölgeler içinde birlikte konumlandırın; statik varlıkları uçta (edge) önbelleğe alın.
• Gerekçe: Dahili yollar, gereksiz çıkışı (egress) ortadan kaldırır ve L7 işlemeyi azaltarak gecikmeyi ve maliyeti iyileştirir.

6. Depolama yaşam döngüsü ve arşivleme

• Eylem: Soğuk (cold) yapıtları 90 günde Coldline’a taşımak ve 365 günde silmek için Cloud Storage yaşam döngüsü kuralları uygulayın; paylaşılan bucket’larda ‘istek sahibi öder’ (requester-pays) ayarını yapın; nadiren erişilen veriler için minimum depolama süresi sonuçlarını gözden geçirin.
• Gerekçe: Katmanlandırma ve saklama, uyumluluğu korurken depolama ve geri getirme maliyetlerini azaltır.

7. BigQuery sorgu ve kapasite ayarı

• Eylem: Büyük olgu (fact) tablolarını tarihe göre bölümleyin (partition), yüksek seçiciliğe (high-selectivity) sahip sütunlara göre kümeleyin (cluster); SELECT * yerine sütun projeksiyonları kullanın; en sık yapılan toplamalar (aggregations) için materialize edilmiş görünümler (materialized views) oluşturun; yoğun ETL zamanları için küçük bir rezervasyon satın alın ve toplu iş (batch) artışları sırasında esnek slotları (flex slots) kullanın.
• Gerekçe: Bölümleme/kümeleme, taranan bayt miktarını azaltır; kapasite rezervasyonları, kritik iş yükleri için performansı ve maliyeti stabilize eder.

8. Veritabanı ölçeği ve replikaları

• Eylem: Okuma ağırlıklı Cloud SQL hizmetleri için okuma replikaları ekleyin; bağlantı havuzunu (connection pooling) ayarlayın; depolama için otomatik yeniden boyutlandırmayı ayarlayın; RTO/RPO’yu doğrulamak için failover testi yapın. Bigtable için, autoscaler’ı etkinleştirin ve hotspot anahtar sorunlarını giderin.
• Gerekçe: Replikalar okuma yükünü alır ve yazma yollarını korur; otomatik ölçeklendirme, manuel olarak aşırı kaynak sağlamadan verimi (throughput) taleple uyumlu tutar.

9. Kotalar, eşzamanlılık (concurrency) ve geri basınç (backpressure)

• Eylem: Jitter ile üstel geri çekilme (exponential backoff) uygulayın; Pub/Sub abone akış kontrolünü (flow control) yapılandırın; verim (throughput) ve gecikmeyi dengelemek için Cloud Run eşzamanlılığını (concurrency) ayarlayın; aşağı akış (downstream) sınırlarına devre kesiciler (circuit breakers) ekleyin.
• Gerekçe: Doğru geri basınç (backpressure), SLO’ları düşüren ve maliyeti şişiren zincirleme arızaları ve kontrolden çıkmış yeniden denemeleri önler.

10. Sürekli doğrulama ve yönetişim

• Eylem: Aylık yük testleri ve kaos tatbikatları yapın; SLO/hata bütçelerini takip edin; Recommender ve maliyet anormalliklerini, sahipleri ve bitiş tarihleriyle birlikte sprint planlamasına entegre edin.
• Gerekçe: Yinelemeli doğrulama, iş yükleri geliştikçe tasarrufların devam etmesini ve SLO’ların yeşil kalmasını sağlar.

← Güvenilirlik · Tüm alanlar

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

Google'a göz atın →