Google PCD: API Tasarımı, Entegrasyon ve Olay Güdümlü Geliştirme — Çalışma kılavuzu
Ş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’da modern uygulama entegrasyonu, iyi tasarlanmış senkron API’leri, dayanıklı asenkron ve olay güdümlü desenlerle birleştirir. Amaç, net sözleşmeler, güçlü kimlik, tutarlı hata yönetimi ve operasyonel kontroller sağlamaktır; bu sayede hata, ölçeklenme veya değişiklik durumlarında bile gecikme süresi düşük, kullanılabilirlik ise yüksek tutulur. Bu bölüm; protokol ve API seçimlerini, ağ geçitlerini ve kimlik doğrulamayı, mesajlaşma ve olay yönlendirmeyi, arka plan işlerini, orkestrasyonu, servisler arası kimlik ve güveni, güvenilirlik desenlerini, güvenli webhook’ları ve güvenli şema evrimini kapsar.
API Tasarımı ve Yönetimi
Doğru protokolü seçin:
- REST: İnsan dostu, HTTP üzerinden önbelleğe alınabilir, halka açık ve iş ortağı API’leri için harikadır. Kaynak odaklı tasarım, standart metotlar, ETags ve HATEOAS yalnızca değerli olduğunda kullanılmalıdır. Dezavantajı: protobuf’a göre daha az kesin sözleşmeler; potansiyel olarak fazla/eksik veri çekme (over/under-fetching).
- gRPC: Protobuf sözleşmeleri, çift yönlü akış (bidi streaming), verimli ikili (binary) taşıma; düşük gecikmeli, dahili servisten servise çağrılar için çok uygundur. Dezavantajı: tarayıcı desteği gRPC-Web gerektirir; halka açık istemciler için gözlemlenebilirlik ve uyumluluk daha zor olabilir.
- GraphQL: Bileşik görünümler için gidiş-dönüş (round-trip) sayısını azaltan esnek sorgulama. Dezavantajı: karmaşık resolver’lar, N+1 riskleri, önbellekleme zorlukları ve erişim kontrolü nüansları.
Sürümleme ve sayfalama:
- Eklemeli, geriye dönük uyumlu değişiklikleri tercih edin. URI tabanlı ana sürümler (ör. /v1) ve alanlar (fields) ile özellik bayrakları (feature flags) aracılığıyla küçük revizyonlar kullanın. Net zaman çizelgeleriyle kullanımdan kaldırın (deprecate).
- Yoğun veri değişimi (churn) altında tutarsız sayfaları önlemek için kararlı imleçler (cursor) veya nextPageToken ile sayfalama yapın; büyük veri setleri için offset kullanmaktan kaçının.
Doğrulama ve hatalar:
- REST istek/yanıt şemaları için OpenAPI ve gRPC için protobuf doğrulama kurallarını kullanın.
- Tutarlı bir hata modeli benimseyin: standart HTTP durum kodlarıyla eşleştirin; gRPC için google.rpc.Status (kod, mesaj, detaylar) kullanın. Makine tarafından ayrıştırılabilir hata nedenleri ve bir korelasyon ID’si ekleyin. Dahili bilgileri sızdırmaktan kaçının.
API yönetim seçenekleri:
- API Gateway: OpenAPI/gRPC arka uçları (Cloud Run, Cloud Functions, GKE, Compute Engine) için hafif, yönetilen bir ağ geçidi. Kimlik doğrulama, API anahtarları, JWT doğrulaması, kotaları destekler. Sunucusuz (serverless) ve basit kontrol düzlemleri (control planes) için iyidir.
- Cloud Endpoints (ESPv2): Servisinizle birlikte dağıtılır; OpenAPI veya gRPC kod dönüştürme (transcoding), kimlik doğrulama, kotalar ve metrikleri destekler. Proxy’yi iş yüküyle aynı yerde konumlandırmanın tercih edildiği durumlar için iyidir.
- Apigee: Gelişmiş politikalarla (ani artış engelleme (spike arrest), kotalar, arabuluculuk (mediation), dönüşüm, OAuth sağlayıcıları, para kazanma (monetization), geliştirici portalı) tam yaşam döngüsü API yönetimi. Karmaşık iş ortağı ekosistemleri ve kuzey-güney (north-south) kontrolü için en iyisidir.
Kimlik doğrulama ve kotalar:
- Son kullanıcılar için: OAuth 2.0 veya Firebase Authentication; servisler için: Google imzalı ID jetonları (OIDC) veya OAuth servis hesabı jetonları (2-legged).
- Arka uçları korumak için kotaları ve ani artış engellemeyi istemcilere yakın bir yerde (Apigee) ve tüketici başına (API anahtarları veya istemci kimlik bilgileri) uygulayın.
Cloud Run arka ucu ve OIDC ile minimal bir API Gateway OpenAPI örneği:
openapi: 3.0.0
info: {title: orders, version: 1.0.0}
paths:
/v1/orders:
get:
security: [{firebase: []}]
x-google-backend: {address: https://orders-xyz-uc.a.run.app}
responses: {"200": {description: OK}}
components:
securitySchemes:
firebase:
type: http
scheme: bearer
bearerFormat: JWT
x-google-issuer: https://securetoken.google.com/PROJECT_ID
x-google-audiences: PROJECT_ID
Asenkron Mesajlaşma ve Olay Yönetimi
Pub/Sub temelleri:
- Topic’ler ve subscription’lar, yayıncıları (publisher) ve tüketicileri (consumer) birbirinden ayırır. Teslimat en az bir kez (at-least-once) yapılır; yinelenen mesajlar ve yeniden sıralama meydana gelebilir.
- İşlem uzun sürdüğünde onayları (acknowledgment) kullanın ve onay son tarihlerini (ack deadline) uzatın; bellek baskısını önlemek için istemci akış kontrolü (client flow control) uygulayın.
- Sıralama: her anahtar için sıralı teslimatı garanti etmek üzere mesaj sıralamayı etkinleştirin ve bir sıralama anahtarı (ordering key) sağlayın; mümkün olduğunda her anahtar için tek bir aktif yayıncı bulundurun.
- İşlenemeyen mesajlar (Dead letter): “zehirli” mesajları içermesi ve sonsuz yeniden denemeleri önlemesi için işlenemeyen mesaj topic’lerini (dead-letter topics) yapılandırın; izleyin ve önceliklendirin.
Topic, subscription ve DLQ oluşturma:
gcloud pubsub topics create orders
gcloud pubsub topics create orders-dlq
gcloud pubsub subscriptions create orders-sub \
--topic=orders \
--dead-letter-topic=orders-dlq \
--max-delivery-attempts=5 \
--ack-deadline=30
Tüketici mantığı: bir kez etkili (idempotent) işleyiciler ve tekilleştirme (örneğin, messageId veya uygulama düzeyinde bir idempotency anahtarı ile) uygulayın; geçici hataları geri çekilme (backoff) ile yeniden deneyin; kurtarılamayan mesajları DLQ’ya taşıyın ve uyarı oluşturun.
Eventarc ve CloudEvents:
- Eventarc, Google Cloud servislerinden, özel kaynaklardan ve Denetim Günlüklerinden (Audit Logs) gelen olayları Cloud Run, Cloud Functions veya GKE’ye yönlendirir. Olaylar CloudEvents zarfını (id, source, type, subject, time) kullanır.
- Gürültüyü ve maliyeti azaltmak için tetikleyici (trigger) düzeyinde niteliklere (type, subject, location) göre filtreleme yapın. En az ayrıcalık (least privilege) ilkesi için adanmış servis hesapları kullanın.
Cloud Storage nesne sonlandırması için bir Eventarc tetikleyicisi oluşturma:
gcloud eventarc triggers create index-new-objects \
--destination-run-service=media-indexer \
--destination-run-region=us-central1 \
--event-filters="type=google.cloud.storage.object.v1.finalized" \
--event-filters="bucket=my-assets-bucket" \
--service-account=eventarc-router@PROJECT_ID.iam.gserviceaccount.com
Dezavantajları:
- Pub/Sub, yüksek verim (throughput) için çekme (pull) optimizasyonlu ve dayanıklıdır; Eventarc, kontrol etmediğiniz üreticilerden yönlendirmeyi basitleştirir ve servisinize standartlaştırılmış meta verilerle itme (push) yapar.
- Katı sıralama veya maliyette kesin sınırlar için, yayıncılarda bölümleme (partitioning) ve hız sınırlamayı (rate-limiting) düşünün; çok düşük gecikmeli yayılım (fanout) için, abone eşzamanlılığını (subscriber concurrency) dikkatlice ayarlayın.
Orkestrasyon, Arka Plan İşleri ve Uzun Süren Süreçler
Cloud Tasks:
- Güvenilir arka plan HTTP çağrıları için itme kuyrukları (push-queues). Arka uçları korumak için kuyruk başına gönderme hızını (dispatch rate) ve eşzamanlılığı (concurrency) ayarlayın. Yeniden denemeleri üssel geri çekilme (exponential backoff) ve maksimum deneme sayısı ile yapılandırın.
- Belirleyici bir görev adı (deterministic task name) veya bir Idempotency-Key başlığı ile bir kez etkililiği (idempotency) sağlayın ve sunucu tarafında tekilleştirme yapın. Hızlı bir şekilde (2xx) yanıt verin ve gerekirse ağır işleri asenkron olarak gerçekleştirin.
Hız limitleri ve yeniden denemelerle bir kuyruk oluşturma:
gcloud tasks queues create payments-queue \
--max-dispatches-per-second=50 \
--max-concurrent-dispatches=200 \
--max-attempts=10 \
--min-backoff=5s \
--max-backoff=300s
Workflows:
- HTTP ve Google Cloud bağlayıcıları (connector) arasında çok adımlı iş süreçlerini yönetir (orkestre eder). Kısmi başarısızlıklar için telafi edici eylemleri (saga deseni) modelleyin; dağıtık işlemlerden (distributed transactions) kaçının.
- Adım düzeyinde zaman aşımları ve yeniden deneme politikaları kullanın; kesintilerden sonra devam edebilmek için durumu yeniden denemeler boyunca kalıcı hale getirin. Uzun süren işlemleri yoklayın (poll) ve son tarihte (deadline) iptal edin.
Telafi taslağı:
main:
params: [orderId]
steps:
- charge:
call: http.post
args: {url: ${paymentsUrl}/charge, auth: {type: OIDC}, body: {orderId: ${orderId}}}
result: chargeRes
- reserveInventory:
try:
steps:
- reserve:
call: http.post
args: {url: ${inventoryUrl}/reserve, auth: {type: OIDC}, body: {orderId: ${orderId}}}
except:
as: e
steps:
- refund:
call: http.post
args: {url: ${paymentsUrl}/refund, auth: {type: OIDC}, body: {paymentId: ${chargeRes.body.id}}}
- raise: ${e}
Operasyonel rehberlik:
- Tek bir servise hassas hız kontrollü, “ateşle ve unut” (fire-and-forget) tarzı arka plan HTTP işlemleri için Cloud Tasks’i tercih edin. Yayılım (fanout) ve çoklu tüketiciler için Pub/Sub kullanın. Dallanma mantığı ve telafi ile birkaç çağrıyı koordine etmeniz gerektiğinde Workflows kullanın.
Kimlik, Güvenilirlik ve Entegrasyonlar
Servisten servise kimlik ve token yayılımı:
- Cloud Run/Functions/Compute Engine/GKE iş yükleri, en az ayrıcalık ilkesine sahip servis hesapları kullanmalıdır. GKE’de, düğüm düzeyinde kimlik bilgilerinden kaçınmak için Workload Identity kullanın.
- Cloud Run’dan Cloud Run’a yapılan çağrılarda, hedef URL ile eşleşen bir kitleye (audience) sahip ID token ile çağrı yapın. Kimliği yalnızca aşağı akış (downstream) hizmetinin çağıran adına hareket etmesi gerektiğinde yayın; aksi takdirde çağrılanın servis hesabını kullanın.
Cloud Run’da bir ID token alma:
AUD="https://inventory-xyz-uc.a.run.app"
TOKEN=$(curl -s -H "Metadata-Flavor: Google" \
"http://metadata/computeMetadata/v1/instance/service-accounts/default/identity?audience=${AUD}")
curl -H "Authorization: Bearer ${TOKEN}" "${AUD}/v1/check"
Senkron bağımlılıklar ve dayanıklılık:
- İstemci zaman aşımlarını yukarı akış (upstream) zaman aşımlarından daha düşük ayarlayın; her atlama (hop) için bir bütçe belirleyin. Yalnızca idempotent (tekrarlanabilir) işlemleri, kesilmiş üstel geri çekilme (truncated exponential backoff) ve sapma (jitter) ile yeniden deneyin. Toplam yeniden deneme süresini sınırlayarak tekrar deneme fırtınalarından kaçının.
- Bir yukarı akış hizmeti sağlıksız olduğunda hızlıca başarısız olmak için devre kesiciler (circuit breakers) kullanın; GKE/Apigee/Envoy’da bekleyen maksimum istek sayısını, hata durumunda çıkarma (ejection on failure) ve sağlık denetimlerini (health probes) yapılandırabilirsiniz. Mantıklı yedek mekanizmalar sağlayın veya kademeli olarak performansı düşürün (degrade gracefully).
- Geçici hataları (429, 408, 500–503) yeniden denenebilir davranışla eşleştirin; 4xx hatalarını (408/429 hariç) yeniden denenemez olarak kabul edin.
Webhook’lar ve üçüncü taraf entegrasyonları:
- Gelen istekleri, paylaşılan gizli anahtar (shared secret) veya imzalı JWT içeren bir HMAC imza başlığı kullanarak doğrulayın; daha yüksek güvence için mTLS kullanın. Gizli anahtarları Secret Manager’da saklayın ve düzenli olarak rotasyona tabi tutun.
- Hızlıca onaylayın (acknowledge); yoğun işlemleri ayrıştırmak için Cloud Tasks’e kuyruğa ekleyin veya Pub/Sub’a yayınlayın. Arka uç (backend) sistemlerini korumak için gelen IP’leri veya anahtarları hız sınırlamasına tabi tutun.
- Giden webhook’lar: güvenli yeniden denemelere izin vermek için bir Idempotency-Key ekleyin ve uzak TLS sertifikalarını ve ana bilgisayar adlarını (hostname) doğrulayın.
Şema evrimi ve uyumluluk:
- REST/JSON: eklemeli alanlar güvenlidir; mevcut alanları asla yeniden amaçlandırmayın veya türünü/anlamını değiştirmeyin. Kullanımdan kaldırılmış (deprecated) alanları işaretleyin ve belirli bir süre boyunca hizmet vermeye devam edin.
- Protobuf/gRPC: alan numaralarını asla yeniden kullanmayın; ayrılmış (reserved) etiketler kullanın; isteğe bağlı (optional) alanları tercih edin; varsayılan değer atama ve varlık semantiği (presence semantics) uyumluluk için önemlidir.
- Olaylar: bir dataVersion ekleyin ve CloudEvents niteliklerini (attributes) kararlı tutun; genişletmeler için yer ayırın. Pub/Sub ile, yayınlama zamanında doğrulama yapmak için Pub/Sub Schema’yı (Avro/Protobuf) kullanmayı düşünün.
- Test: tüketici odaklı kontrat testleri (consumer-driven contract tests), emülatörler (Pub/Sub, Datastore/Firestore) veya izole projeler ve kanarya (canary) sürümleri kullanın. Gizli kalmış hataları ortaya çıkarmak için CI’da geçici (ephemeral) ortamlar ve gerçekçi kotalar kullanarak entegrasyon testleri çalıştırın.
Yığın genelinde güvenlik ve kotalar:
- Kimlik doğrulamayı (auth) uçta (API Gateway/Apigee/Endpoints) ve servisin kendisinde zorunlu kılın. Tüketici başına kotalar ve ani artışları durdurma (spike arrest) uygulayın. İstemci geri çekilme (backoff) ve kotalarını ayarlamak için 401/403 ani artışlarını ve 429 oranlarını izleyin.
- Uçtan uca gözlemlenebilirlik için bileşenler arasında istek kimliklerini (request ID) loglayın ve izleme başlıklarını (Traceparent veya X-Cloud-Trace-Context) yayın.
Pratik Problem Senaryosu
AcmeRetail, Google Cloud üzerinde bir tıkla-gel al servisi oluşturuyor. Bir React web uygulaması, sipariş vermek için halka açık bir API’yi çağırıyor; arka uç servisleri envanteri rezerve etmeli, ödemeleri almalı ve mağazaları bilgilendirmelidir. Ekibin düşük gecikmeli API’lere, güvenilir arka plan işlemlerine, olay güdümlü güncellemelere ve kısmi hatalarda güvenli geri alma (rollback) mekanizmalarına ihtiyacı var.
Yaklaşım:
- Bir Cloud Run sipariş servisinin önünde API Gateway aracılığıyla halka açık bir REST API sunun.
- Gerekçe: JSON ile REST, tarayıcılar için basittir; API Gateway, Firebase Auth’tan gelen JWT’leri doğrular, istemci başına API anahtarlarını ve kotaları uygular ve bağlantıyı uçta sonlandırır. Cloud Run, trafik artışlarıyla otomatik olarak ölçeklenir.
- Dahili sıcak yollar (hot path) için (siparişlerden envantere, fiyatlandırmaya) servisten servise çağrıları gRPC ile uygulayın.
- Gerekçe: gRPC, serileştirme ek yükünü azaltır ve sıkı kontratlar sağlar. Servisler arasında Workload Identity (GKE) veya servis hesapları (Cloud Run) ve OIDC kullanın. Zaman aşımları, idempotent okumalar için iki yeniden deneme ve sapma (jitter) ile 300 ms olarak ayarlanmıştır.
- Sipariş sagasını (order saga) düzenlemek için Workflows kullanın: ödemeyi al, envanteri rezerve et, teslim alma görevi oluştur; hata durumunda telafi et.
- Gerekçe: Merkezi orkestrasyon, uzun süren adımları ve telafileri yönetir. Eğer rezervasyon başarısız olursa, Workflows bir geri ödeme tetikler ve istemciye 409 kodu döndürür.
- Alan (domain) olaylarını, aşağı akış (downstream) tüketicileri (analitik, mağaza bildirimleri) için
ordersveinventoryadlı Pub/Sub konularına yayınlayın.
- Gerekçe: Sıkı bağlılık olmadan yayılım (fanout). Aboneler,
orderIdile anahtarlanmış idempotentlik uygular. Aboneliklerin,max-delivery-attempts=10olan işlenemeyen mesaj konuları (dead-letter topics) vardır ve DLQ büyümesinde uyarılar tetiklenir.
- İlgili Cloud Storage ve Firestore değişikliklerinde, Eventarc aracılığıyla bir Cloud Run bildirim servisine mağaza bildirimlerini tetikleyin.
- Gerekçe: Eventarc, nitelik (attribute) filtreleri kullanarak yalnızca gerekli olayları yönlendirir; CloudEvents tutarlı meta veriler sağlar. Bildirim servisi, oranı ve yeniden denemeleri kontrol etmek için Cloud Tasks kullanarak üçüncü taraf SMS/E-posta sağlayıcılarına gönderim yapar.
- Ödeme sağlayıcısının webhook’larını, API Gateway’in önünde duran özel bir Cloud Run uç noktasıyla ele alın; HMAC imzalarını doğrulayın ve işleme için Cloud Tasks kullanın.
- Gerekçe: Hızlı 200 onayı, sağlayıcının yeniden denemelerini azaltır; Tasks, geri çekilme (backoff) ile yeniden denemeleri garanti eder. Gizli anahtarlar Secret Manager’da saklanır; istek gövdeleri OpenAPI şemasına göre doğrulanır.
- Güvenilirlik desenlerini uygulayın: ödeme sağlayıcısına yapılan giden çağrılar için Apigee veya Envoy’da devre kesiciler (circuit breakers); sağlayıcı SLA’larının altında ayarlanmış istemci zaman aşımları; 429/5xx hataları için kesilmiş üstel geri çekilme (truncated exponential backoff) ile yeniden denemeler.
- Gerekçe: Basamaklı (kaskad) arızaları ve tekrar deneme fırtınalarını önler, üçüncü taraf limitlerine uyar ve geçici aşırı yüklenmeyi kademeli performans düşüşüne (graceful degradation) dönüştürür.
- Şema evrimi kontrollerini benimseyin: ayrılmış (reserved) alanlara sahip dahili gRPC için Protobuf; REST yanıtları eklemeli JSON değişiklikleri kullanır; Pub/Sub, yayınlama zamanında Protobuf şema doğrulaması kullanır.
- Gerekçe: Tüketici uyumluluğunu sürdürür. Her birleştirmede (merge) Cloud Build üzerinde kontrat ve entegrasyon testleri çalışır; kanarya (canary) dağıtımları, gerçek trafiği güvenli bir şekilde doğrular.
- Gözlemleyin ve işletin: API Gateway ve servisler arasında izleme başlıklarını (trace headers) yayın; hata oranları ve DLQ boyutu için Cloud Logging metriklerini dışa aktarın; SLO yanması (burn) ve 429/5xx anormalliklerinde uyarı verin.
- Gerekçe: Regresyonların, kota sorunlarının veya sağlayıcı olaylarının hızlı tespiti; SRE’ler kotaları ve geri çekilme (backoff) politikalarını hızla ayarlayabilir.
← İşlem · Tüm alanlar · Uygulama Verisi →
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 →