Cases2 cases

1 to 2 of 2

1. IL-0544 Wasabi's database cache stopped responding when its queueing service filled up, and S3 failed in all regions

   Wasabi2024

   Symptoms

   From 10:32 UTC on 6 August 2024, Wasabi's S3 service and user services failed in every region: users had trouble logging into the Web Console and requests to Wasabi regions returned errors.

   Service outageFailover failureIntermittent timeouts

   Trigger

   At 10:32 UTC on 6 August, Wasabi's queueing service reached full capacity, and that made the database cache unresponsive.

   Root cause

   Capacity exhaustion

   Component

   Message brokerIn-memory cacheDatabase

   Contributing factor

   –

   Remediation

   • Restarted the primary database to clear stale connections and cleared the queueing service's queue at the same time, which did not fully restore the database
   • Promoted the secondary database instance to primary, after which S3 was fully operational at 11:20 UTC
   • Restarted the database again between 13:17 and 13:23 UTC to fully incorporate the queueing service library
   • Promoted the original primary database back to production on 7 August, which stopped the user service timeouts
   • Recreated and redeployed the automation cluster that the automation service could not see, which fully restored S3

   View case
2. IL-0386 After a move to Google Cloud, Postgres connection timeouts and memcached i/o timeouts spiked on GKE nodes

   incident.io2023

   Symptoms

   Shortly after incident.io moved its infrastructure fully into Google Cloud, the application saw a larger-than-normal number of Postgres connection timeouts, and new database connections per second were in the hundreds, spiking up and down. At the same time, the memcached instance used for transient data and faster API responses had sporadic connection timeouts.

   Intermittent timeoutsPacket loss

   Trigger

   After the move to Google Cloud, the application opened hundreds of new Postgres connections per second, and an accidental database join made it send thousands of duplicate calls to an external third party in parallel.

   Root cause

   Capacity exhaustion

   Component

   CNI pluginDatabaseIn-memory cache

   Contributing factor

   Unreviewed defaultsOverlapping failures

   Detection

   An incident was declared when the number of Postgres connection timeouts rose above normal. The remaining cache timeouts were traced through the logs of the Kubernetes node that served an affected request, the request's trace and the node's metrics.

   Remediation

   • Doubled the maximum Postgres connection lifespan from 15m to 30m
   • Made the Postgres connection pools static so they always keep N connections open
   • Raised the memcache client's MaxIdleConns from 2 to 20
   • Moved temporarily from Google's hosted memcached to a memcached inside the Kubernetes cluster
   • Shipped the fix for the accidental database join that made thousands of duplicate external calls

   Action items

   • Set more sensible concurrency limits for outbound network calls

   Lessons

   Network timeouts are not always local to one request or pod: when they appear, the whole activity of the node, including other pods on it, needs to be checked. Staying within a provider's rate limits does not keep outbound calls from affecting a node, so outbound network calls need more sensible concurrency limits.

   View case

By root cause1