Google PCNE: Yük Dengeleme, Cloud CDN ve Global Trafik Yönetimi — Çalışma kılavuzu

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

Şunun bir parçası: Google Professional Cloud Network 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ış

Bu bölüm, dayanıklı, performanslı ve güvenli hizmetler sunmak için Google Cloud Load Balancing, Cloud CDN ve küresel trafik yönetiminin birlikte nasıl çalıştığını açıklar. Yük dengeleyici aileleri ve seçimi, proxy ile passthrough davranışları arasındaki farklar, arka uç (backend) ve yönlendirme bileşenleri, yük devretme (failover) ve kapasite yönetimi, Cloud CDN önbellekleme ve kaynak (origin) korumaları, anycast ve bölgeler arası tasarımlar, DNS yönlendirmesi ve sağlık kontrolleri (health checks), gözlemlenebilirlik ve sağlam küresel giriş noktaları için tasarım desenlerini kapsar.

Yük dengeleyici aileleri, seçim ve veri düzlemi davranışı

Google Cloud, farklı kapsama, protokole ve veri düzlemi özelliklerine sahip harici ve dahili yük dengeleyiciler sunar. Doğru olanı seçmek, protokol ihtiyaçlarını, coğrafyayı ve operasyonel kontrolleri uyumlu hale getirir.

• Harici proxy L7 (küresel): HTTP(S) ve gRPC için External Application Load Balancer. TLS’i sonlandırır, L7 politikalarını uygular, URL haritalarını, Cloud CDN’i, Cloud Armor’ı, istek/yanıt özelliklerini ve anycast IPv4/IPv6’yı destekler. Gelişmiş yönlendirme, güvenlik ve önbellekleme gerektiren, internete yönelik web API’leri/siteleri için en iyisidir.

• Harici proxy L4.5: External TCP Proxy Load Balancer (küresel) ve External UDP Proxy Load Balancer (bölgesel), istemci bağlantılarını sonlandırır ve arka uçlara (backend) proxy’ler. L7 yönlendirmesi olmadan küresel VIP’ye ve L4 özelliklerine (TLS politikası, TCP için istemci IP’sinin başlıklar aracılığıyla korunması) ihtiyaç duyduğunuzda kullanın.

• Harici passthrough L3/L4 (bölgesel): External Network Load Balancer, bağlantıyı sonlandırmadan paketleri iletir. En düşük gecikme süresine sahiptir ve en basit olanıdır; TCP/UDP/ESP/ICMP’yi destekler. Lift-and-shift (olduğu gibi taşıma), heterojen arka uçlar veya proxy sonlandırmasını tolere edemeyen protokoller için uygundur. Klasik NLB, hedef havuzları (target pools) kullanır; daha yeni bölgesel passthrough NLB ise arka uç hizmetlerini (backend services) kullanır.

• Dahili proxy (bölgesel): Internal HTTP(S) Load Balancer (L7) ve Internal TCP Proxy Load Balancer (L4.5), mikroservis kuzey-güney (north-south) ve hizmetten hizmete (service-to-service) kullanım için bir VPC içinde bağlantıları sonlandırır ve proxy’ler. Ana bilgisayar/yol (host/path) yönlendirmesini (HTTP), uygulama aracılığıyla istemcilere mTLS’i ve hizmet başına güvenlik politikalarını destekler.

• Dahili passthrough (bölgesel): Internal TCP/UDP Load Balancer, istemci IP’sini koruyarak ve MAGLEV hashing kullanarak bağlantıları özel RFC1918 üzerinden arka uçlara dağıtır. Bölge (zone) duyarlı dağıtım ve düşük ek yük (overhead) gerektiren doğu-batı (east-west) hizmetleri (veritabanları, özel protokoller) için idealdir.

Katman ve sonlandırma arasındaki ödünleşimler:

• Proxy L7/4.5, ek atlamalar (hops) ve olası başlık/NAT değişiklikleri pahasına gelişmiş yönlendirme, TLS yük boşaltma (offload), gözlemlenebilirlik, Cloud Armor/CDN ve bölgeler arası yük devretme (failover) sağlar. Genel giriş noktaları ve hizmet ağları (service mesh) için uygundur.
• Passthrough L3/L4, istemci IP’sini uçtan uca korur ve gecikmeyi en aza indirir, ancak L7 özellikleri yoktur ve daha az gözlemlenebilirlik kancasına (hook) sahiptir. Oturum (session) davranışı hash tabanlıdır; sağlık kontrolleri daha basittir.

Kapsam ve IP aileleri:

• Küresel anycast VIP’ler, External Application LB ve External TCP Proxy LB için mevcuttur ve her yerden erişilebilen tek bir IPv4/IPv6 adresi sağlar. Bölgesel LB’ler, bölgesel unicast VIP’leri kullanır. Genel hizmetler için IPv6 erişimi, harici bir küresel yük dengeleyicinin bir IPv6 adresiyle yapılandırılmasıyla sağlanır.

Seçim kriterlerinden öne çıkanlar:

• Ana bilgisayar/yol (host/path) yönlendirmesi, yönlendirmeler (redirects), Cloud CDN, Cloud Armor veya gRPC ihtiyacı: External Application LB.
• L7 olmadan küresel TCP ihtiyacı: External TCP Proxy LB.
• Proxy’leri sevmeyen protokoller (ör. bazı eski UDP/TFTP): Harici veya Dahili passthrough.
• HTTP yönlendirmeli özel hizmetten hizmete (service-to-service) iletişim: Internal HTTP(S) LB.
• VPC içi trafik için maliyeti/atlamaları (hops) en aza indirme: Dahili passthrough.

Arka uç servisleri, yönlendirme nesneleri, sağlık durumu ve trafik yapışkanlığı

Temel veri düzlemi nesneleri:

• Backend services: Arka uçları (örnek grupları, bölgesel NEG, hibrit NEG, sunucusuz NEG), sağlık kontrollerini, dengeleme modunu, kapasiteyi, oturum benzeşimini, zaman aşımını ve yük devretme politikasını tanımlar. Proxy LB’ler ve daha yeni geçişli (passthrough) LB’ler için gereklidir.
• Target pools: Klasik harici NLB için eski bir yapıdır. Basit TCP/UDP dağıtımları ve lift-and-shift sırasında heterojen VM’ler için uygundur.
• Adlandırılmış portlar: Örnek grupları üzerinde mantıksal adları (ör. http) port numaralarına eşleyen ve backend services ile URL haritaları tarafından referans alınan anahtarlardır. Grup üyeleri arasında tutarlılık sağlayın.

Sağlık kontrolleri ve yük devretme:

• Türler: HTTP(S), HTTP/2, gRPC, TCP, SSL. Sadece işletim sistemine erişilebilirliği değil, servisin gerçek hazır olma durumunu doğrulayan bir kontrol seçin.
• Kapsam: Sağlık kontrolleri bölgeseldir; her arka ucun, hizmet verdiği bölgeye göre kapsamı belirlenmiş bir sağlık kontrolü olmalıdır.
• Yük devretme politikası: Backend service, birincil ve yük devretme arka uçlarını belirleyebilir. Trafik, birincil arka uç sağlıksız olduğunda veya kapasitesi dolduğunda (eğer kapasiteye bağlı yük devretme etkinleştirilmişse ve eşik karşılanıyorsa) devreder. “Thundering herd” etkisinden kaçınmak için bağlantı boşaltma (draining) ve kapasite rezervasyonunu göz önünde bulundurun.

URL haritaları ve yönlendirme:

• URL haritası, harici veya dahili HTTP(S) LB’ye eklenir ve ana makine kuralları ile yol eşleştiricilerini tanımlar.
• Varsayılan servis: Hiçbir kuralla eşleşmeyen istekler için tümünü yakalayan arka uç; ayarlanmamışsa 404 döndürülür.
• Yönlendirmeler ve yeniden yazmalar: Yönlendirmeden önce HTTPS yönlendirmeleri, standart ana makine yönlendirmeleri veya yol yeniden yazmaları gerçekleştirmek için URL haritası eylemlerini kullanın.

Örnek: HTTPS yönlendirmesi ve varsayılan arka uç içeren minimal bir URL haritası

• example.com için bir ana makine kuralı oluşturun, HTTP’yi HTTPS’e yönlendirin, /static yolunu CDN etkin bir backend bucket’a yönlendirin ve varsayılan olarak bölgesel bir backend service’e yönlendirin.

Oturum benzeşimi ve boşaltma:

• Benzeşim seçenekleri LB türüne bağlıdır. Yaygın seçenekler:
  • Hiçbiri: Durumsuz (stateless) servisler için en iyisidir; yük dağılımını en üst düzeye çıkarır.
  • İstemci IP’si: L4/L7 genelinde kaynak IP’ye göre yapışkandır; birden çok protokolün (ör. HTTP ve TFTP) aynı arka uca birlikte yapışkan olması gerektiğinde kullanın.
  • Oluşturulan çerez (Yalnızca L7): LB, bir arka uca kalıcılık sağlamak için bir çerez ayarlar; NAT arkasındaki istemcilerde istemci IP’sine göre daha iyi dağılım sağlar.
• Artıları ve eksileri: Oturum benzeşimi, tek bir noktada yoğunlaşmaya (hotspotting) neden olabilir ve otomatik ölçeklendirmeyi karmaşıklaştırabilir. Mümkün olan yerlerde durumsuz (stateless) mimariyi tercih edin.
• Bağlantı boşaltma: Küçülme (scale-in) veya bir arka ucun kaldırılması sırasında LB, mevcut bağlantıların düzgün bir şekilde kapanmasına izin vermek için boşaltma zaman aşımına uyar. Sıfırlamaları (reset) önlemek için boşaltma süresini beklenen en uzun isteğinize göre ayarlayın.

Kapasite ve otomatik ölçeklendirme:

• Dengeleme modları: Kullanıma (ör. CPU), saniye başına istek sayısına (RPS) veya bağlantı sayısına dayanır. Her arka uç kapasitesini bildirir; doygunluk oluştuğunda LB yükü devreder veya başka bir arka uca yönlendirir.
• Otomatik ölçeklendirme: Yönetilen örnek grupları (Managed instance groups), sinyallere (CPU, özel metrikler) göre ölçeklenir. Büyüme gecikmesi (scale-out lag), LB’nin kapasitesi biterse 503 hatasına neden olabilir; minimum replika sayısı ile önceden ısıtma yaparak veya günlük (diurnal) trafik için tahmine dayalı otomatik ölçeklendirme kullanarak bunu önleyin.
• Yük devretme ve taşma: Kapasiteye bağlı yük devretmeyi uygun bir eşikle etkinleştirmek, sorunsuz bir şekilde bölgeler arası taşmaya olanak tanır.

Arka uçlarda güvenlik:

• Örnek etiketlerini veya servis hesaplarını hedefleyen güvenlik duvarı kuralları kullanarak arka uç erişimini kısıtlayın. Yalnızca Google yük dengeleyici ve sağlık kontrolü kaynak aralıklarından gelen trafiğe ve dahili istemciler için doğrudan erişim gerekiyorsa onaylanmış istemci aralıklarınıza izin verin.

Örnek: istemcileri ve sağlık kontrollerini arka uç etiketli bir grupla kısıtlama

• Örnekleri application ile etiketleyin.
• İstemci CIDR’larınızdan ve Google sağlık kontrolü aralıklarından gelen tcp:80 trafiği için, application etiketini hedefleyen bir gelen trafiğe izin verme kuralı oluşturun.
• Reddedilen trafiği loglarda görebilmek için varsayılan olarak reddetme (deny-by-default) ilkesi önerilir.

Cloud CDN, önbellek politikası ve origin koruması

Cloud CDN, yanıtları uç POP’larda (Point of Presence) önbelleğe alarak gecikmeyi azaltmak ve origin’in yükünü almak için harici Application Load Balancer ile entegre olur.

Önbellek modları ve TTL’ler:

• Origin başlıklarını kullan: Origin’inizden gelen Cache-Control ve Expires başlıklarına uyar. Doğruluk için tercih edilir.
• Önbelleğe almayı zorla: Statik içerik için isteğe bağlı olarak origin başlıklarını geçersiz kılarak veya yoksayarak, yapılandırılmış varsayılan bir TTL ile tüm yanıtları önbelleğe alır. Dinamik verileri önbelleğe almaktan kaçınmak için dikkatli kullanın.
• Önbelleği atla: Asla önbelleğe alınmaması gereken yollar için kullanışlıdır.

Önbellek anahtarları:

• Anahtar alanları arasında protokol, ana makine (host), yol, sorgu parametreleri, başlıklar ve çerezler bulunur. Gerektiğinde sorgu dizesi politikasını (tümünü dahil et, seçilenleri dahil et veya yoksay), seçici başlık ve çerez dahil etmeyi ve cihaz segmentasyonunu yapılandırın.
• İsabet oranını en üst düzeye çıkarmak için anahtarları minimumda tutun; yalnızca sunumu değiştiren alanlara göre farklılaştırın.

İmzalı istekler:

• İmzalı URL’ler: Belirli kaynaklara zaman sınırlı erişim sağlamak için süre sonu ve yol kapsamı içeren bir HMAC veya RSA imzası ekleyin. Nesne başına yetkilendirme ile hızlandırıcı olarak CDN kullanımı için iyidir.
• İmzalı çerezler: Bir çerez ile bir dizi yola yetki verin; tüm site genelinde erişimi kısıtlanmış içerikler için kullanışlıdır.
• Tekrar oynatma (replay) riskini azaltmak için anahtarları rotasyona tabi tutun ve kısa geçerlilik süreleri uygulayın.

Sıkıştırma ve doğruluk:

• İstekler bir Via başlığı içerdiğinde bile origin’ler sıkıştırma yapmalıdır. Origin “sıkıştırmayı desteklerken” CDN sıkıştırılmamış nesneler sunuyorsa, Via başlığı mevcut olduğunda origin’in sıkıştırma yapacak şekilde yapılandırıldığını doğrulayın.

Origin güvenliği:

• Uç proxy’lerden origin’lere modern TLS politikalarıyla HTTPS kullanın.
• Origin erişilebilirliğini sınırlayın: Yalnızca Google load balancer ve health check kaynak aralıklarından ve bilinen özel üreticilerden gelen trafiğe izin veren backend güvenlik duvarı kuralları. Backend örnekleri rastgele genel girişi (ingress) kabul etmemelidir.
• L7 DDoS/WAF, hız sınırlama ve tehdit tespiti için Cloud Armor ile eşleştirin. Yanlış pozitifleri (false positive) azaltmak için yeni kuralları önizleme modunda kullanın.
• TTL süresi dolmadan önce temizlemeniz gerektiğinde, önbellek geçersizleştirme API’lerini kullanarak içeriği kasıtlı olarak geçersiz kılın. Dinamik içerik için kısa TTL’leri ve yeniden doğrulamayı (ETag/If-None-Match) tercih edin.

Hata modları ve ödünleşimler:

• Gereğinden geniş önbellek anahtarları önbelleği boşa harcar ve isabet oranını düşürür; gereğinden dar anahtarlar yanlış varyantların sunulması riskini taşır.
• Dinamik verileri zorla önbelleğe almak, kişiselleştirilmiş içeriğin sızmasına neden olabilir.
• İmzalı URL’ler/çerezler uç noktadaki erişimi korur, ancak origin’in atlanması yine de ağ politikası aracılığıyla engellenmelidir.

Global trafik yönetimi, DNS yönlendirmesi, gözlemlenebilirlik ve dayanıklı giriş noktaları

Anycast ön uçları ve bölgeler arası yük devretme:

• External Application LB ve external TCP Proxy LB, istemcileri en yakın Google edge’ine çekmek için global anycast VIP’leri kullanır. Trafik daha sonra kapasiteye sahip en sağlıklı ve en yakın arka uca proxy’lenir. Sorunsuz yük devretme ve taşma için tutarlı sağlık kontrolleri ve kapasite ayarlarına sahip birden çok arka uç bölgesi yapılandırın.
• İkincil bölgelerde kapasiteyi önceden sağlayarak soğuk başlangıç cezalarından kaçının; otomatik ölçeklendiricinin min/maks değerlerini LB kapasite eşikleriyle koordine edin.

Bölgesel dahili trafik yönetimi:

• Internal HTTP(S) LB ve internal passthrough LB bölgeseldir; bir bölge içinde alan çeşitliliği için ve gerektiğinde, bölgesel uç noktaları seçmek için Private Service Connect veya hizmete duyarlı istemcilerle ayrı LB’ler kullanarak çok bölgeli olarak tasarlayın.
• İletişim kuran hizmetleri aynı bölgeye ve VPC’ye yerleştirerek doğu-batı gecikmesini düşük tutun. Minimum maliyet ve operasyonel basitlik için tek bir VPC veya eşlenmiş VPC’ler ile RFC1918 adreslemesini kullanın.

Cloud DNS yönlendirme politikaları ve sağlık kontrolleri:

• Politikalar: Ağırlıklı sıralı (trafik bölme), coğrafi konum (kullanıcıları en yakın bölgesel VIP’ye gönderme) ve yük devretme (birincil/yedek). İş kurallarını karşılamak için politikaları birleştirin.
• Sağlık kontrolleri: Yönlendirmede kullanılan A/AAAA kayıtlarına DNS sağlık kontrolleri (HTTP/HTTPS/TCP) ekleyerek sağlıksız uç noktaların geri çekilmesini sağlayın. Tepkiyi geciktiren çözümleyici önbelleğe almayı (TTL) hesaba katın; daha fazla DNS araması pahasına yük devretme yanıt verebilirliğini artırmak için yönlendirilen kayıtlarda TTL’leri düşük tutun.
• Trafik yönlendirme: Geçişleri aşamalandırmak veya bölgeler arasında yükü kaydırmak için ağırlıklı politikalar kullanın. Split-horizon DNS kullanmadığınız sürece internetten özel adreslere yönlendirmekten kaçının.

Gözlemlenebilirlik ve teşhis:

• Yük dengeleyici günlük kaydı: Tüm LB’ler için günlük kaydını etkinleştirin. HTTP(S) günlükleri istek yöntemi/URI’si, gecikme süresi, önbellek isabeti/ıskası, arka uç hizmeti, URL haritası kuralı, TLS ayrıntıları ve yanıt kodlarını içerir. TCP/UDP günlükleri bağlantı üst verilerini ve sağlık denetimi durumunu sağlar.
• Metrikler: Arka uç sağlığını, kullanımı, RPS’yi, bağlantıları, gecikmeyi, önbellek isabet oranını, 4xx/5xx oranlarını ve kapasite doygunluğunu izleyin. Ani değişiklikler ve sürekli eşikler için uyarı ayarlayın.
• Yaygın HTTP(S) hata kalıpları:
  • 404: URL haritası eşleşmesi yok; ana bilgisayar/yol kurallarını ve varsayılan hizmeti onaylayın.
  • 301/302: Kasıtlı yönlendirmeler; yönlendirme döngülerini doğrulayın.
  • 502: Arka uç bağlantısı veya protokol uyuşmazlığı (ör. HTTP/1.1 vs gRPC); sağlığı ve arka uç protokol yapılandırmasını kontrol edin.
  • 503: Sağlıklı veya kapasitesi olan arka uç yok; sağlık kontrollerini, kotaları ve otomatik ölçeklendirici davranışını doğrulayın.
• İstek izleme: Uygulamanız tarafından yayılan X-Forwarded-For, X-Forwarded-Proto ve izleme kimliklerini kullanın. İstek kimliklerini kullanarak LB günlüklerini arka uç günlükleriyle ilişkilendirin.
• Güvenlik duvarı içgörüleri: İzin verme ve reddetme kurallarında VPC güvenlik duvarı günlüğünü etkinleştirin. Bırakılan paketleri açıkça günlüğe kaydetmek için, günlük kaydı etkinleştirilmiş düşük öncelikli bir tümünü reddet kuralı ekleyin.

Dayanıklı global giriş noktası tasarımı:

• Birden çok bölgesel arka uca öncülük eden bir external Application LB üzerinde tek bir global anycast VIP kullanın. Sunucusuz/VM/konteyner arka uçlarını en az iki bölgeye yerleştirin. Bölgeler arası yük devretme ve taşmayı etkinleştirin, muhafazakar sağlık kontrolleri yapılandırın ve iş yükleriniz için boşaltma (draining) ve zaman aşımlarını ayarlayın.
• Girişi Cloud Armor ve kota sınırlama politikalarıyla koruyun. Kenarda trafik artışlarını absorbe etmek için statik ve önbelleğe alınabilir dinamik içerik için Cloud CDN kullanın.
• Tüm ağlara hizmet vermek için global LB üzerinde çift yığınlı (dual-stack) IPv4/IPv6’yı kullanıma sunun. Sıkı istemci erişimi için, kesin kaynak aralıkları ve örnek etiketleri veya hizmet hesapları ile arka uç güvenlik duvarı kuralları uygulayın.

Örnek: İstemci ve sağlık kontrolü aralıklarını etiketli arka uçlarla kısıtlayan güvenlik duvarı kuralı

• Örnekleri ‘application’ ile etiketleyin.
• tcp:443 için kaynak aralıkları 203.0.113.0/24, 198.51.100.0/24 ve Google sağlık kontrolü aralıkları olan ve ‘application’ı hedefleyen bir gelen (ingress) izin kuralı oluşturun.
• Beklenmedik kaynakları yakalamak için daha düşük öncelikli, günlük kaydı etkinleştirilmiş bir tümünü reddet kuralının mevcut olduğundan emin olun.

Pratik Problem Senaryosu

Acme Retail, statik medyayı verimli bir şekilde sunarken us-east1 ve europe-west1 arasında düşük gecikme süresi, güçlü güvenlik ve şeffaf yük devretme gerektiren global bir e-ticaret platformu başlatıyor. Yalnızca kurumsal ofisler ve bir iş ortağı CDN hazırlık (staging) ağı özel yönetici arayüzüne erişebilmelidir.

1. Ön uç ve arka uçlar

• Genel kullanıma açık mağaza ana bilgisayar adı için çift yığınlı (dual-stack) bir anycast VIP ve TLS sertifikaları ile bir external Application Load Balancer oluşturun.
• Her biri us-east1 ve europe-west1’deki bölgesel bir yönetilen örnek grubuna (MIG) işaret eden iki arka uç hizmeti tanımlayın. Sağlık kontrollerini (HTTPS) etkinleştirin ve dengeleme modunu %80 kapasite eşiği ile kullanıma (utilization) ayarlayın. Gerekçe: Anycast ve çok bölgeli arka uçlar, kullanıcıların en yakın edge’e ulaşmasını ve bir bölge sağlıksız veya doymuşsa sorunsuz bir şekilde yük devretmesini sağlar.

2. URL haritası, yönlendirme ve yeniden yönlendirmeler

• Genel mağaza ve özel yönetici ana bilgisayar adları için ana bilgisayar kurallarıyla bir URL haritası yapılandırın. /static yolunu Cloud CDN etkinleştirilmiş bir arka uç bucket’ına yönlendirin; /api ve / yollarını VM arka uçlarına yönlendirin. Bir HTTP’den HTTPS’ye yeniden yönlendirme ekleyin. Gerekçe: Ana bilgisayar/yol yönlendirmesi, statik trafiği dinamik trafikten ayırır ve güvenli erişimi zorunlu kılar.

3. Cloud CDN politikası

• /static arka uç bucket’ı için, önbellek modunu kaynak başlıklarını (origin headers) kullanacak şekilde ayarlayın ve işlevsel olmayan sorgu parametrelerini yoksayan ve yalnızca Accept-Encoding başlığını içeren bir önbellek anahtarı tanımlayın. Yaygın 404’ler için kısa bir TTL ile negatif önbelleğe almayı etkinleştirin. Gerekçe: İçerik semantiğine uyar, isabet oranını en üst düzeye çıkarır ve yanlış varyantların önbelleğe alınmasını önler.

4. Oturum benzeşimi (session affinity) ve boşaltma (draining)

• Genel mağaza için oluşturulmuş çerez (generated-cookie) benzeşimi ayarlayın ve statik varlıklar için hiçbirini ayarlamayın; bağlantı boşaltmayı (connection draining) 60 saniyeye ayarlayın. Gerekçe: Çerezler, geniş dağıtıma izin verirken sepet oturumlarını kararlı tutar; boşaltma, küçülme veya yük devretme sırasında kullanıcı tarafından görülebilen hataları önler.

5. Bölgeler arası yük devretme ve otomatik ölçeklendirme

• Fazla trafiği diğer bölgeye kaydırmak için %90 taşma eşiğiyle kapasiteye bağlı yük devretmeyi (failover-on-capacity) etkinleştirin. MIG otomatik ölçeklendirmesini bölge başına minimum 4 replika ve LB kullanımına uyan CPU hedefleriyle yapılandırın. Gerekçe: Kapasite uçurumlarını önler ve sorunsuz ölçeklendirme için LB ve otomatik ölçeklendirici kararlarını koordine eder.

6. Yönetici arayüzü kısıtlaması

• Özel yönetici ana bilgisayar adı için, yalnızca VPC içinde erişilebilen bir internal HTTP(S) Load Balancer oluşturun. Dahili istemcilerin ILB VIP’sine çözümlenmesi ve harici istemcilerin NXDOMAIN alması için split-horizon Cloud DNS’i yayınlayın. Gerekçe: Yönetici trafiğini genel uç noktaları açığa çıkarmadan özel ve kontrollü tutar.

7. Arka uç güvenlik duvarı ve kaynak (origin) güvenliği

• Yönetici ve web arka uçlarını ‘application’ olarak etiketleyin ve kurumsal ve hazırlık (staging) CIDR’lerinden artı Google yük dengeleyici ve sağlık kontrolü kaynak aralıklarından tcp:443 için bir izin kuralı ekleyin; daha düşük öncelikte günlük kaydı ile bir tümünü reddet kuralı ekleyin. Gerekçe: Yalnızca hedeflenen istemcilerin ve Google altyapısının arka uçlara ulaşabilmesini sağlar ve bırakılan paketler için görünürlük sağlar.

8. Cloud Armor

• Yönetilen WAF kuralları ve /api ani artışları için önizleme modunda bir hız limiti içeren bir güvenlik politikası uygulayın. Gerekçe: L7 koruması ve aşamalı uygulama, ayarlama yaparken riski azaltır.

9. Cloud DNS yönlendirme ve sağlık kontrolleri

• Genel mağaza ana bilgisayar adı için A ve AAAA kayıtlarını ALB anycast VIP’sine yayınlayın. Mavi/yeşil kanarya dağıtımı için, belirlenmiş bir kanarya ana bilgisayar adında ağırlıklı bir politika oluşturun, %5’ini yalnızca europe-west1’e özel ALB’ye ve %95’ini global dağıtıma bölün. Sağlıksızsa kanaryayı geri çekmek için HTTPS sağlık kontrolleri ekleyin ve TTL’yi 20 saniyeye ayarlayın. Gerekçe: DNS tabanlı kanarya, sağlık durumuna duyarlı kaldırma ve hızlı yakınsama ile kademeli maruz kalma sağlar.

10. Gözlemlenebilirlik

• LB ve CDN günlüklerini etkinleştirin; analiz için BigQuery’ye aktarın. 5xx oranı, arka uç kapasitesi, sağlık kontrolü arızaları ve CDN isabet oranı için uyarılar ayarlayın. Yönlendirme hatalarını teşhis etmek için URL haritası testlerini ve istek günlüklerini kullanın; arka uç doygunluğu veya protokol uyuşmazlıkları için 502/503 ani artışlarını inceleyin. Gerekçe: Proaktif izleme ve hızlı teşhis, MTTR’yi en aza indirir ve kullanıcı deneyimini korur.

← Hibrit Bağlantı · Tüm alanlar · Cloud DNS →

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

Google'a göz atın →