Google PCA: Compute, Uygulama Platformları ve İş Yükü Mimarisi — Çalışma kılavuzu
Şunun bir parçası: Google Professional Cloud Architect — Ç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ış
Bu alan, Google Cloud üzerinde işlem platformlarının nasıl seçileceğini ve tasarlanacağını, uygulamaların nasıl paketlenip dağıtılacağını ve iş yüklerinin güvenilirlik, performans, güvenlik ve maliyet verimliliği için nasıl çalıştırılacağını kapsar. Sanal makineler, Kubernetes, sunucusuz çalışma zamanları, yük dengeleme, dağıtım stratejileri, durum bilgisi olan (stateful) ve özelleştirilmiş işlem ve değişen talebi karşılarken teknik borcu azaltan modernizasyon kalıplarını içerir.
Compute Engine ve VM Tabanlı Mimariler
Compute Engine; işletim sistemleri, ağ ve makine şekilleri üzerinde ayrıntılı kontrol sağlar. İş yükü özelliklerine göre makine ailelerini seçin:
- E2: maliyet optimizasyonlu genel amaçlı; geliştirme/test, düzensiz (bursty) uygulamalar için iyidir.
- N2/N2D: çoğu üretim iş yükü için dengeli fiyat/performans; N2D, güçlü bellek bant genişliğine sahip AMD CPU’ları kullanır.
- C2/C2D/C3: CPU’ya bağlı görevler (ör. yüksek QPS’li API, toplu işlem) için işlem optimizasyonlu.
- M3: büyük bellek içi veri setleri (önbellekler, bellek içi analitik) için bellek optimizasyonlu.
- A3: eğitim/çıkarım (training/inference) için GPU optimizasyonlu (NVIDIA); GPU’ları diğer ailelere de ekleyebilirsiniz.
- Confidential VM’ler (desteklenen CPU’larda) kullanımdaki veriyi minimum kod değişikliğiyle şifreler.
Yönetilen örnek grupları (Managed instance groups - MIG’ler) esneklik ve dayanıklılık sağlar:
- Değişmez (immutable) yapılandırma için Instance Templates ve zone’lar arasında yatay olarak ölçeklenmek için MIG’ler kullanın.
- Otomatik ölçeklendirme (Autoscaling) politikaları: CPU, load balancer kullanımı, Cloud Monitoring metrikleri veya özel metrikler aracılığıyla kuyruk derinliği. Düzensiz yükler altında kararsızlığı (thrash) önlemek için min/maks replika ve bekleme süresi (cooldown) ayarlayın.
- Kademeli güncellemeler (rolling updates) ve kanarya (canary) dağıtımları riski azaltır; durum bilgisi olan (stateful) veya soğuk başlatma (cold-start) süresi uzun servisler için surge ve unavailable ayarlarını ihtiyatlı tutun.
Yük dengeleme ve health check’ler:
- Global external HTTP(S) load balancer, TLS sonlandırması yapar, URL eşlemesini destekler ve web API’leri için standart ön uçtur; doğu-batı (east-west) trafiği için internal HTTP(S) LB kullanılır.
- Health check’ler arka uçlara (backend) ulaşabilmelidir. Yaygın bir hata, engellenen denetimlerin (probe) sürekli instance yeniden başlatmalarına ve trafik kaybına neden olmasıdır. VPC güvenlik duvarı kuralları ve hedef etiketleri (target tags) ile health check kaynak aralıklarının (source ranges) arka uç portlarına erişimine izin verin.
Bir MIG’ye HTTP health check’lerine izin verme örneği:
undefined
VM yaşam döngüsüyle ilgili dikkat edilmesi gerekenler:
- Başlatma (bootstrap) için başlangıç betiklerini (startup scripts) veya imaj meta verilerini kullanın; çalışma zamanı yapılandırmasını imajlara gömmek yerine Secret Manager’da saklayın.
- Preemptible/Spot VM’ler için, sonlandırma bildiriminde işi boşaltmak (drain) üzere bir kapatma betiği (shutdown-script) ekleyin.
- Yapılandırma kaymasını (configuration drift) önlemek için yamaları, önceden hazırlanmış imajlar (baked images) ve kademeli değiştirme (rolling replacement) yoluyla yapın.
- Persistent disk yeniden boyutlandırma çevrimiçi (online) olarak yapılabilir: disk boyutunu artırın, ardından dosya sistemini (ör. ext4’te resize2fs) minimum kesintiyle büyütün.
PD yeniden boyutlandırma örneği:
undefined
undefined
Güvenli kimlik ve gözlemlenebilirlik:
- Instance’lara en az ayrıcalık (least-privilege) ilkesine sahip service account’lar atayın; statik kimlik bilgilerini gömmeyin.
- Cloud Logging ve Cloud Monitoring için Ops Agent’ı kurun. Kuyruk gecikmesini (tail latency) ve yoğun noktaları (hot spots) azaltmak için Cloud Trace ve Cloud Profiler kullanın.
- Denetim (audit) ve metrik verilerini uzun süreli saklama ve analiz için BigQuery veya Cloud Storage’a aktarın.
Toplu ve özelleştirilmiş işlem:
- Maliyeti düşürmek amacıyla hataya dayanıklı (fault-tolerant) toplu işler (batch) için Cloud Batch veya preemptible VM’ler içeren MIG’ler kullanın; kontrol noktası oluşturma (checkpointing) uygulayın.
- ML hızlandırmanın gerekli olduğu yerlerde GPU/TPU ekleyin. Uyumluluk/izolasyon gereksinimlerini karşılamak için adanmış düğüm havuzları (dedicated node pools) veya tek kiracılı düğümler (sole-tenant nodes) kullanın.
- Confidential VM’ler bellekteki hassas verileri korur; ek yükü (overhead) gereksinimlere göre ölçün.
Durum (state) ile ilgili dikkat edilmesi gerekenler:
- Uygulama instance’larını durum bilgisi olmayan (stateless) şekilde tutun; ölçeklenme sırasında kullanıcı tarafından görülebilen anormallikleri önlemek için oturumları (session) paylaşılan bir depolama alanına (ör. Memorystore, Cloud SQL) taşıyın.
- VM’e bağlı durumlar (state) için bölgesel (regional) persistent disk’ler veya replike edilmiş veritabanları kullanın; yük devretme (failover) yollarını test edin.
Kubernetes ve Konteyner Platformları (GKE)
GKE, esnek çalışan düğüm havuzlarına (worker node pools) sahip yönetilen bir kontrol düzlemi (control plane) sunar:
- Bölgesel (regional) kümeler, yüksek erişilebilirlik için kontrol düzlemini ve düğümleri zone’lar arasında çoğaltır; bölgesel (zonal) kümeler ise daha düşük maliyet ve gecikme süresi hassasiyeti için kaynakları tek bir yerde toplar.
- İş yüklerini (ör. genel amaçlı, GPU, yüksek bellekli, spot) bölümlere ayırmak için birden çok düğüm havuzu kullanın. Yerleşimi kontrol etmek ve “gürültücü komşu” (noisy-neighbor) etkilerini azaltmak için taints/tolerations ve affinity/anti-affinity kurallarını uygulayın.
- Otomatik ölçeklendirme katmanları: küme otomatik ölçeklendiricisi (cluster autoscaler) düğüm ekler/kaldırır; Horizontal Pod Autoscaler (HPA), CPU/özel metriklere göre replikaları ölçeklendirir; Vertical Pod Autoscaler (VPA) ise kaynak taleplerini (requests) doğru boyutlandırır. Esneklik için HPA’yı küme otomatik ölçeklendiricisi ile birleştirin.
İş Yükü Zamanlaması ve Servisler:
- Eviction riskini en aza indirmek ve binpacking verimliliğini en üst düzeye çıkarmak için CPU/bellek taleplerini (requests) ve limitlerini doğru boyutlandırın.
- Yükseltmeler sırasında erişilebilirliği korumak için PodDisruptionBudget’ları kullanın.
- Servis türleri: ClusterIP (küme içi), NodePort/LoadBalancer (kuzey-güney) ve global LB ile HTTP(S) yönlendirmesi için Ingress. Canary dağıtımlar için trafiği ayrı Servisler/Ingress backend’leri veya bir service mesh aracılığıyla yönlendirin.
Yükseltmeler ve Dayanıklılık:
- Değişim oranını (churn) kontrol etmek için surge upgrades ve maxUnavailable ayarlarını kullanın; kritik iş yüklerini birden çok zone’a ve havuza sabitleyin.
- İş açısından kritik dönemler için bakım pencereleri/hariç tutma zamanları (maintenance windows/exclusions) ayarlayın.
- Geniş çaplı bir dağıtımdan önce bir ön üretim (pre-production) ortamı ve canary düğüm havuzları ile doğrulama yapın.
İmajlar ve Güvenlik:
- Konteyner imajlarını Artifact Registry’de saklayın; güvenlik açığı taramasını etkinleştirin ve kaynak kökeni (provenance) için binary authorization veya attestations (doğrulama beyanları) kurun.
- Google API’lerine kimlik bilgisi olmadan, en az ayrıcalıkla (least-privilege) erişim için GSA’yı KSA’ya eşlemek üzere Workload Identity kullanın.
- Çalışma zamanı yapılandırmasını CSI sürücüsü aracılığıyla Secret Manager’dan çekin; CMEK ile şifrelenmedikçe ve RBAC sıkı bir şekilde yapılandırılmadıkça, çok hassas değerler için Kubernetes Secret’larını kullanmaktan kaçının.
Sürüm Dağıtımı (Rollout) ve Geri Alma (Rollback):
- Küçük adımlarla ve sağlık denetimleriyle (health probes) Deployment rolling update’lerini tercih edin; toleransı düşük sistemler için, tek bir Servis arkasındaki iki Deployment aracılığıyla blue-green yöntemini kullanın ve etiketleri/seçiciyi (labels/selector) değiştirin.
- Her zaman readiness ve liveness probe’larını tanımlayın; yanlış yapılandırılmış probe’lar, dağıtımlar sırasında zincirleme yeniden başlatmalara (cascading restarts) veya trafiğin kaybolmasına (blackholes) neden olur.
Sunucusuz (Serverless) ve Olay Güdümlü (Event-Driven) Platformlar
Google Cloud sunucusuz platformları, altyapıyı soyutlarken ölçek, güvenlik ve maliyet üzerinde güçlü kontroller sağlar:
- Cloud Run: Konteyner odaklı (container-native), HTTP isteği veya Eventarc ile tetiklenir. Sıfıra kadar ölçeklenir (scales to zero); yapılandırılabilir eş zamanlılık (concurrency); canary ve geri alma için revizyona göre trafik bölme. Gecikme süresine duyarlı endpoint’ler için soğuk başlangıçları (cold starts) azaltmak üzere minimum instance sayısını (min instances) ayarlayın. Özel giden trafik (private egress) için Serverless VPC Access aracılığıyla VPC ile entegre edin.
- App Engine: Yönlendirmeli bir PaaS (opinionated PaaS). Standard, hızlı ölçeklendirme ve dile göre istek başına eş zamanlılık kısıtlamaları sunar; Flexible ise daha fazla kontrolle sanal makineler üzerinde konteynerler çalıştırır. Instance’a özel oturum durumundan (session state) kaçının; yük altında eski veya yinelenen kullanıcı deneyimlerini önlemek için durumu paylaşılan bir depolama alanına taşıyın.
- Cloud Functions: Olay güdümlü mantık için fonksiyon düzeyinde granülerlik. Hafif mikro işlemler için Pub/Sub, Cloud Storage veya Eventarc tetikleyicilerini kullanın; fonksiyonları idempotent ve durumsuz (stateless) tutun. Mevcut kodu olmayan birleşik batch/stream işlem hatları için Dataflow, otomatik ölçeklendirme ile birleşik işleme sağlar.
Platform Seçimindeki Ödünleşimler:
- Operasyonel kontrol: Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions.
- Taşınabilirlik: konteyner tabanlı (GKE/Cloud Run/App Engine Flex) > VM imajları > fonksiyonlar ve App Engine Standard.
- Gecikme süresi: Düşük kuyruk gecikmesi (low tail latency) için min instances ayarlı Cloud Run veya GKE; interaktif iş yükleri için soğuk başlangıçlardan (cold starts) kaçının.
- Ölçeklenme: Cloud Functions/Run en hızlı ölçeklenir; GKE HPA artı küme otomatik ölçeklendiricisi; MIG’ler ısınma (warm-up) ve sağlık denetimleri gerektirir.
- Maliyet: Düzensiz (spiky)/düşük kararlı durumlu iş yükleri için sunucusuz kullandıkça öde modeli; kararlı, yüksek verimli servisler için taahhütlü kullanım indirimleriyle (committed use discounts) GKE/VM’ler; batch işleri için preemptible/Spot.
Kimlik ve Yapılandırma:
- Her servis, en az ayrıcalık ilkesine (least privilege) sahip özel bir servis hesabı kullanmalıdır. Cloud Run ve Functions için çalışma zamanı servis hesabını (runtime service account) açıkça belirtin.
- Gizli bilgileri (secrets) Secret Manager’da saklayın ve erişimi IAM aracılığıyla bağlayın; ortam değişkenleri (environment variables) veya volume mount’ları aracılığıyla enjekte edin.
Mimari Desenleri, Dağıtım ve Operasyonlar
Hizmet ayrıştırma ve sınırlar:
- Monolith: en basit dağıtım ve işlemler, ancak bağımsız ölçeklendirmeyi ve etki alanı (blast-radius) kontrolünü sınırlar; çağrı zincirlerinin derinliklerindeki performans sorunlarını maskeleyebilir.
- Modüler monolith: net iç modüller, paylaşılan süreç; dağıtım cezaları olmadan arayüzleri zorunlu kıldığı için iyi bir ara adımdır.
- Microservices: bağımsız dağıtılabilirlik ve ölçeklendirme; ağ gecikmesi, dağıtık işlemler ve tutarlılık zorlukları getirir. Net sınırlı bağlamlar (bounded contexts) ve veri sahipliği tanımlayın; birbirine bağımlılığı (coupling) önlemek için paylaşılan veritabanlarından kaçının.
Modernizasyon desenleri:
- Strangler-fig: trafiğin bir kısmını kademeli olarak yeni bileşenlere yönlendirin, eski uç noktaları (endpoints) yavaş yavaş kullanımdan kaldırın.
- Lift and shift: önce stabilize etmek için konteynerleştirin veya VM’e taşıyın, ardından yeniden düzenleyin (refactor).
- Anti-corruption layer/facade: yeni hizmetler oluştururken eski sözleşmeleri (contracts) izole edin.
- İş değerini en üst düzeye çıkarmak ve riski azaltmak için önce yüksek değişimli, yüksek sürtünmeli alanlara öncelik verin.
Dağıtım ve kullanıma sunma:
- Otomatik testler ve aşamalı ortamlar içeren CI/CD, geri alma (rollback) ihtiyacını azaltır. Kanarya analizi (canary analysis), hata bütçeleri (error budgets) ve aşamalı dağıtım (progressive delivery) ekleyin.
- Blue-green: çift kapasite maliyeti pahasına kesinti süresini en aza indirir ve geri almayı basitleştirir.
- Traffic splitting: Cloud Run/App Engine, revizyonlar/versiyonlar arasında yüzde tabanlı yönlendirmeyi destekler; sıkı SLO hata bütçeleriyle gerçek trafik altında test edin.
Yük dengeleme ve sağlık durumu:
- HTTP için global L7 ve HTTP olmayan protokoller için TCP proxy kullanın; özel hizmetler için dahili LB’ler kullanın. Oturum benzeşimini (session affinity) yalnızca gerektiğinde yapılandırın ve oturum durumunu (session state) dışsallaştırın.
- Sağlık kontrolleri, uygulamanın kullanılabilirliğini yansıtmalıdır (ör. bağımlılıkların sağlığı); veri deposu arızasını maskeleyen basit bir 200 OK, hatalı trafik yönlendirmesine neden olabilir.
Gözlemlenebilirlik ve yönetişim:
- Hizmetler arasında uçtan uca gecikme atfı için izlemeleri (traces) enstrümante edin; logları ve izlemeleri ilişkilendirmek için istek kimliklerinin (request IDs) loglanmasını etkinleştirin.
- Saklama ve denetim ihtiyaçları için logları/metrikleri/denetim izlerini (audit trails) BigQuery veya Cloud Storage’a aktarın; görünümler (views) ve IAM aracılığıyla erişimi güvence altına alın.
- VM logları için Ops Agent’ı kurun; maliyet ve uyumluluğu kontrol etmek için saklama sürelerini ve hedefleri (sinks) tanımlayın.
Güvenli yazılım tedarik zinciri:
- Tarama özelliğiyle Artifact Registry kullanın; imajları minimal tutun. Dockerfile’ları optimize edin: slim tabanları tercih edin, önce bağımlılıkları kurun, ardından derleme önbelleğinden (build cache) yararlanmak için kaynak kodunu kopyalayın.
Ağ ve segmentasyon:
- Yalnızca beklenen akışlara izin vermek için (ör. web → API → DB) VPC güvenlik duvarı etiketleri ve kuralları aracılığıyla katmanlı erişimi zorunlu kılın. Doğrudan web → DB erişimini engelleyin.
Kapasite, Performans ve Özelleştirilmiş İşlem Gücü
Değişken talep için tasarım yapın:
- GCE: CPU doygunluğunun önüne geçmek için öncü göstergelere (kuyruk uzunluğu gibi) göre MIG’leri otomatik ölçeklendirin; bağımlı sistemleri korumak için istek oranı sınırlaması ve geri basınç (backpressure) ekleyin.
- GKE: Saniye başına istek sayısı (requests-per-second) veya özel metriklere dayalı HPA ile küme otomatik ölçeklendiricisini (cluster autoscaler) birleştirin; ölçeklenme gecikmesini önlemek için küçük bir arabellek (buffer) sağlayın.
- Sunucusuz (Serverless): Maliyet ve gecikme süresi arasında denge kurmak için eş zamanlılığı (concurrency) ve minimum örnek sayısını (min instances) ayarlayın; kullanıcıya yakın gecikme süresi için bölgesel dağıtım kullanın.
Dayanıklılık ve test:
- Otomatik ölçeklendirmeyi ve SLO’ları doğrulamak için sentetik yük çalıştırın; sistemin arızalar ve yükseltmeler sırasında kullanılabilirliği sürdürdüğünden emin olmak için kaos testlerini (örneğin, rastgele örnekleri/pod’ları sonlandırma) dahil edin.
- Pod/VM kapanmadan önce bağlantıları boşaltmak (drain) için PodDisruptionBudget’ları ve düzgün sonlandırma kancalarını (graceful termination hooks) yapılandırın.
Performans ve depolama seçimi:
- Yüksek verimli, düşük gecikmeli zaman serisi ve tıklama akışı (clickstream) verisi alımı Bigtable ile iyi eşleşir; hotspot’ları (yoğun erişim noktalarını) önlemek için geniş satırlar ve zamana göre gruplanmış (time-bucketed) anahtarlar tasarlayın.
- Minimum operasyonel değişiklikle Spark/Hadoop için Dataproc kullanın; otomatik ölçeklendirme ile kümeleri doğru boyutlandırın.
- Mevcut kod olmadan saatlik toplu (batch) ve akış (streaming) işlemlerini birleştirmek için, veri hatlarını birleştirmek amacıyla otomatik ölçeklendirme ve pencereleme (windowing) özellikli Dataflow kullanın.
Veri taşıma ve bağlantı:
- Sürekli, yüksek bant genişliğine sahip, özel replikasyon (örneğin, çok terabaytlık veritabanları) için Dedicated Interconnect’i düşünün; dinamik yönlendirme için VLAN eklerini ve Cloud Router’ı kullanın. Geçici veya daha düşük verim gerektiren durumlar için Cloud VPN yeterlidir.
Durumlu (Stateful) iş yükleri:
- GKE üzerinde, kalıcı birimlere (yüksek erişilebilirlik için bölgesel PD’ler) ve sıralı, kararlı kimliklere sahip StatefulSet’ler kullanın; NFS semantikleri için Filestore’u değerlendirin.
- Mümkün olan yerlerde dayanıklılık ve ölçeklendirme için yönetilen veritabanlarını (Cloud SQL, AlloyDB, Spanner) kullanın; okuma replikalarını ve yük devretmeyi (failover) planlayın.
Güvenlik ve uyumluluk:
- Sınırlı performans ek yüküyle kullanımdaki verileri korumak için Confidential VM’leri değerlendirin; iş yükü gereksinimlerine göre değerlendirme yapın.
- Anahtarların müşteri kontrolünde olması gereken yerlerde CMEK kullanın; ortam bazında izolasyonu zorunlu kılın ve dev/test/prod için ayrı projeler kullanın.
Maliyet kontrolleri:
- Kararlı durumdaki işlem gücü için taahhütlü kullanım (committed use) ve sürekli kullanım (sustained use) indirimlerini kullanın; hataya dayanıklı toplu işler için kesilebilir (preemptible)/Spot örnekleri; sunucusuz (serverless) platformlarda sıfıra kadar otomatik ölçeklenmeyi kullanın.
- Monitoring önerileriyle kaynakları doğru boyutlandırın; maliyet sürprizlerinden kaçınmak için boştaki servisleri kaldırın ve log tabanlı metrik kotaları belirleyin.
Gecikme sorunlarını giderme:
- En fazla gecikmeyi ekleyen mikroservisi belirlemek için Cloud Trace kullanın; o servisin kod yolunu, önbelleklemesini (caching) veya veritabanı indekslerini optimize edin. İyileştirmeleri A/B kanarya (canary) testleriyle doğrulayın.
Pratik Problem Senaryosu
FerroLine Logistics, sevkiyat takibi ve müşteri bildirimlerini yöneten bir J2EE monolitini modernize etmeyi planlıyor. İş yükü, bölgesel kesinti zamanlarında anlık yoğunluklar yaşıyor, %99,9 kullanılabilirlik hedefini karşılamalı ve ekip, olay güdümlü (event-driven) özellikleri sunarken minimum operasyonel zahmetle taşınabilirlik istiyor.
- Mevcut sistemi stabilize edin ve gözlemleyin
- Gerekçe: Değişiklik yapmadan önce, geri alma (rollback) riskini azaltmak için temel davranışı ve hataları belirleyin. Cloud Logging ve Monitoring için mevcut VM’lere Ops Agent’ı dağıtın ve yüksek gecikmeli istek yollarında dağıtık izlemeyi (distributed tracing) enstrümante edin. Geçmişe dönük analiz ve SLO raporlaması için logları ve metrikleri BigQuery’ye aktarın.
- Aşamalı bir hedef bölge (landing zone) ve platform karması seçin
- Gerekçe: Kontrol ve hızı dengeleyin. Monoliti, toplu iş bileşenleri için Cloud Run job’ları ve durumsuz (stateless) HTTP API’leri için Cloud Run servisleri olarak bir konteyner halinde taşıyın ve gecikmeye duyarlı uç noktalar için minimum örnek sayısını (min instances) ayarlayın. Durumlu (stateful) Oracle DB’yi başlangıçta Compute Engine üzerinde tutun, dahili API’ler için bölgesel bir dahili HTTP(S) LB’nin arkasına konumlandırın ve gelecekte AlloyDB’ye geçişi planlayın.
- Oturum (session) ve yapılandırma durumunu dışsallaştırın
- Gerekçe: Örneğe özgü oturum sorunlarından kaçınmak ve güvenli otomatik ölçeklendirmeyi sağlamak. En az ayrıcalıkla erişim için gizli bilgileri (secrets) servis başına hesaplarla Secret Manager’da saklayın. Oturum durumunu Memorystore’a ve paylaşılan dosyaları Cloud Storage’a taşıyın. Bu, kullanıcıların yoğun yük altında eski (stale) verileri görmesini engeller.
- Kimlik ve kayıt defteri (registry) kontrolleri oluşturun
- Gerekçe: En az ayrıcalık ve kaynak takibini (provenance) zorunlu kılın. İmajları, güvenlik açığı taraması etkinleştirilmiş olarak Artifact Registry’de saklayın. Her Cloud Run servisine ve GKE iş yüküne (daha sonra ayrıştırılacak bileşenler için) benzersiz bir çalışma zamanı servis hesabı atayın ve yalnızca gerekli rolleri (örneğin, Pub/Sub Publisher) verin.
- Güvenli dağıtım stratejileriyle CI/CD uygulayın
- Gerekçe: Planlanmamış geri almaları azaltın. Birim/entegrasyon testlerini çalıştıran ve hazırlık (staging) ortamına dağıtım yapan bir pipeline oluşturun. Yeni revizyonlara trafiğin %5-10’unu kanarya (canary) olarak yönlendirmek ve hızlı geri almayı etkinleştirmek için Cloud Run trafik bölmeyi (traffic splitting) kullanın. VM tabanlı veritabanı değişiklikleri için, uygulama ve veritabanı dağıtımlarını birbirinden ayırmak amacıyla mavi-yeşil şema geçiş desenlerini kullanın.
- Önce yüksek değişim oranına sahip alanları ayrıştırın
- Gerekçe: Daha düşük riskle artımlı değer. Bir strangler (boğucu) deseni uygulayın: ani yükselişler için HPA’dan ve ayrıştırma (decoupling) için Pub/Sub’dan yararlanmak üzere bildirim teslimatını GKE üzerinde bir mikroservis olarak ayırın. Arayüzler kararlı hale gelene kadar monolitinin geri kalanını Cloud Run üzerinde modüler bir monolit olarak tutun.
- Otomatik ölçeklendirme ve yük atma (load shedding) tasarlayın
- Gerekçe: Zincirleme arızalar olmadan anlık yoğunlukları yönetin. Uç nokta başına Cloud Run eş zamanlılığını (concurrency) ve minimum örnek sayısını (min instances) yapılandırın; kimliği doğrulanmamış ani artışlara karşı koruma sağlamak için global HTTP(S) LB’de Cloud Armor oran limitleri belirleyin. GKE servisleri için, özel metriklere (saniye başına istek) göre HPA’yı etkinleştirin ve küme otomatik ölçeklendiricisi (cluster autoscaler) aracılığıyla küçük bir düğüm arabelleği (node buffer) sağlayın.
- Durumlu (stateful) servisleri ve veri yollarını hazırlayın
- Gerekçe: Dayanıklılık ve performansı sağlayın. GKE bildirim yeniden denemeleri için, yüksek yazma oranlarında geçici teslimat durumunu saklamak amacıyla müşteri-bölge ve zaman gruplarına (time buckets) göre anahtarlanmış bir Bigtable tablosu kullanın. Geçiş sırasında şirket içi (on-prem) ERP’ye özel, tutarlı bağlantı için Cloud Router ile Dedicated Interconnect kullanın.
- Dayanıklılık ve performans testlerini yürütün
- Gerekçe: Tam geçişten önce SLO’ları doğrulayın. Otomatik ölçeklendirme katmanlarını tetiklemek için sentetik, rastgeleleştirilmiş kullanıcı akışları çalıştırın. Rastgele Cloud Run örneklerini sonlandırarak (kontrol düzleminin yeniden oluşturmasına izin vererek) ve GKE pod’larını tahliye ederek (evicting) PodDisruptionBudget’ları ve hazırlık kapılarını (readiness gates) doğrulamak için kaos enjekte edin. Kuyruk gecikmesine (tail latency) en büyük katkıyı yapan unsuru belirlemek ve düzeltmek için Trace kullanın.
- Maliyet ve uyumluluk koruma mekanizmalarıyla çalıştırın
- Gerekçe: Üretimde sürdürülebilir bir şekilde çalıştırın. Servis başına bütçeler ve uyarılar belirleyin, gerektiğinde hassas depolama üzerinde CMEK’i etkinleştirin ve kararlı durum anlaşıldıktan sonra GKE düğüm havuzları (node pools) ve AlloyDB için taahhütlü kullanım indirimlerini kullanın. Denetim verilerini dahili denetçilerle güvenli bir şekilde paylaşmak için log saklama politikalarını ve BigQuery view’larını yapılandırın.
Bu aşamalı yaklaşım, anında kararlılık ve gözlemlenebilirlik sağlar, güvenli dağıtım uygulamalarını tanıtır, monoliti doğal servis sınırları boyunca aşamalı olarak ayrıştırır ve platform seçimlerini kontrol, gecikme süresi, taşınabilirlik, ölçeklendirme ve maliyet hedefleriyle uyumlu hale getirir.
← Organizasyon Tasarımı · Tüm alanlar · Veri Depolama →
Bu soruları çözün → · ExamRoll.io’da süreli pratik →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Sınavınızı geçin →