Mig Autohealing Separate Health Checks Load Spikes

What separate health checks are

In Google Cloud, Managed Instance Groups (MIGs) utilize health checks for two distinct purposes: load balancing and autohealing. While a load balancer uses health checks to determine where to route user traffic, an autohealing policy uses health checks to determine if a virtual machine (VM) is fundamentally broken and needs to be completely deleted and recreated.

How it meets the requirements

• Gracefully handles temporary load spikes: By making the autohealing health check more conservative (e.g., longer timeouts, higher unhealthy thresholds), temporarily busy VMs are given time to process their backlog and recover without being prematurely killed.
• Automatically recovers from true failures: If an application genuinely crashes or freezes permanently, the conservative autohealing check will eventually fail, triggering the MIG to recreate the instance.
• Maintains responsiveness: The aggressive load balancer health check remains in place, ensuring that new user traffic is swiftly routed away from the busy instances to healthy ones.

Key advantages/capabilities

• Prevents cascading failures caused by the system constantly destroying and rebuilding instances that are merely under heavy load.
• Decouples traffic management from infrastructure lifecycle management.
• Maximizes overall application availability by preserving the cache and state of busy instances.
• Utilizes native Google Cloud managed services without requiring custom scripting.

Why this is optimal

Using a single, aggressive health check for both purposes is a common anti-pattern. An aggressive autohealer mistakes busy instances for failed instances and unnecessarily restarts them. Separating the health checks allows you to tune the load balancer for optimal user experience (fast failover) and tune the autohealer for optimal infrastructure stability (conservative recreation).