A financial trading firm processes high-frequency market order validation using worker instances in a Compute Engine Managed Instance Group (MIG) consuming jobs from a Cloud Pub/Sub queue. During market opening bursts, transaction volume spikes up to baseline. During recent load testing, worker instances failed to scale out quickly enough because scaling was driven solely by CPU utilization while threads blocked on I/O operations, and rapid scale-out attempts triggered resource allocation failures due to regional project limits. Which TWO actions should the Cloud Architect recommend to optimize capacity planning and workload scaling for this architecture? (Select TWO answers)
- Reconfigure the Managed Instance Group autoscaling policy to use a Cloud Monitoring metric based on Cloud Pub/Sub unacknowledged message count or queue depth.Answer
- Audit regional vCPU resource quotas in advance of peak trading events and submit quota increase requests for the target region.Answer
- CMigrate the worker workload to Google Cloud Spanner to automatically increase regional Compute Engine vCPU quotas during scaling events.
- DReplace the Compute Engine Managed Instance Group with a multi-zone Google Kubernetes Engine (GKE) cluster maintaining CPU-based Horizontal Pod Autoscaler policies.
Answer
The Cloud Architect should reconfigure the Managed Instance Group autoscaling policy to scale based on Cloud Pub/Sub queue depth metrics rather than CPU utilization, and proactively audit and request regional vCPU quota increases before peak events.
For queue-based, I/O-bound worker workloads, autoscaling must be tied to queue backlog (such as Pub/Sub unacknowledged messages) rather than CPU utilization. Additionally, capacity planning requires preemptive verification and increases of regional vCPU quotas so that automated scaling does not hit quota caps during burst events.
Step-by-Step Solution
Key Concept
Queue-Based Autoscaling and Quota Management