An enterprise financial institution operates a critical transaction ledger service on Compute Engine Managed Instance Groups (MIGs). The application is heavily network I/O-bound and database connection-bound during peak trading hours. During recent market volatility, transaction latency spiked significantly because the MIG autoscaler failed to add instances, even though overall CPU utilization remained low at approximately . When the operations team attempted an emergency manual scale-out to absorb the load, instance creation failed due to exceeding the regional compute API resource limits. Which combined auto-scaling configuration and capacity planning strategy should a Cloud Architect implement to ensure system reliability during sudden market volatility events?
- Configure the MIG autoscaler using a custom Cloud Monitoring metric that tracks active database connection pool utilization, and proactively request regional quota increases alongside target capacity reservations prior to high-volatility periods.Cevap
- BMigrate the ledger workload to Google Kubernetes Engine (GKE) with a Horizontal Pod Autoscaler (HPA) targeting CPU utilization, relying on Cluster Autoscaler to dynamically provision node capacity on demand.
- CLower the MIG autoscaler target CPU utilization threshold from down to to trigger earlier scaling, relying on Compute Engine's automatic just-in-time quota adjustment mechanisms.
- DRetain CPU-based MIG autoscaling while adding a secondary metric for memory utilization, and configure compute instances across multiple global regions without requesting quota adjustments.