Soru

Zorluk: ZorRelease Management and Deployment Strategies (Blue-Green, Canary, Rolling)

An enterprise gaming company hosts its multiplayer matchmaking service on Google Cloud Run. The engineering team is executing a canary deployment strategy using Cloud Deploy to roll out a major version update with revision-based traffic splitting. Shortly after directing 10% of production traffic to the new revision, users assigned to the existing revision begin encountering severe database query failures because the release pipeline applied a breaking schema migration to Cloud SQL prior to traffic shifting. Which architectural modification should the cloud architect implement to enable zero-downtime releases during database schema updates?

  1. Implement an expand-contract (additive) schema migration strategy that retains existing database fields until all old application revisions are fully decommissioned.Cevap
  2. B
    Configure the deployment pipeline to execute destructive schema changes simultaneously with the initial 10% traffic split trigger.
  3. C
    Replatform the matchmaking microservice to Google Kubernetes Engine (GKE) Autopilot with an ingress service mesh to handle live database translation.
  4. D
    Request an automated regional Cloud SQL vCPU quota increase in the pipeline stage immediately preceding the canary traffic split step.

Cevap

Implement an expand-contract (additive) schema migration strategy that retains existing database fields until all old application revisions are fully decommissioned.
During canary and blue-green releases, multiple application versions run simultaneously and query the same shared database. Adopting an expand-contract (phase 1: expand additively, phase 2: deploy code, phase 3: contract old fields) schema migration strategy ensures complete backward compatibility, allowing older revisions to function without error while the canary revision is verified.

Adım Adım Çözüm

1
Analyze the cause of deployment failure during traffic splitting.
Identified that applying destructive schema changes directly breaks backward compatibility for instances running the older revision.
During canary deployments, multiple application revisions query the same database concurrently.
2
Evaluate schema evolution patterns suitable for zero-downtime canary releases.
Determine that database migrations must follow an expand-contract pattern (add new fields first, migrate data, contract old fields later).
This guarantees that legacy revisions remain operational while the canary revision receives a portion of production traffic.
3
Select the correct architectural solution.
Enforce additive database schema updates prior to shifting traffic, deferring breaking cleanups until old revisions are fully retired.
Ensures complete backward compatibility and zero downtime during the release window.

Anahtar Kavram

Database schema backward compatibility in canary deployments (Expand-Contract Pattern)
Bu soruyu puanla