Cases7 cases

6 to 7 of 7

1. IL-0279 One failed Redis Cluster replica left only about 1 in 21 calls to Grab's Apollo service succeeding for a minute

   Grab2019

   Symptoms

   On 15 February 2019 a slave node of the AWS ElastiCache Redis Cluster behind Apollo, Grab's driver-side state machine for transport bookings, failed and had to be replaced. For about one minute only roughly 1 in 21 calls to Apollo succeeded, a call failure rate above 95% against the Redis Cluster, and Grab rides were significantly down.

   High error rateStale endpoint routing

   Trigger

   A slave node of Apollo's Redis Cluster failed and needed to be replaced.

   Root cause

   Software defect

   Component

   In-memory cache

   Contributing factor

   Unverified assumption

   Lessons

   Having several replicas did not protect Apollo, because the client side, not the Redis Cluster server, caused the failure. Grab suggests three ways to avoid it: a separate Redis Cluster client used only for pipelining with RouteByLatency set to true, so pipelined reads go through the master nodes when latency is under 1ms, watching master CPU because they take more load; checking the error of each command in a pipeline instead of failing the whole call, so successful queries are not affected; and changing the Go-Redis library so that the pipeline path reloads the nodes' state when an error happens, as defaultProcessor already does.

   View case
2. IL-0388 A Google Cloud live migration took a Discord Redis primary offline, and the failover broke API instances and then guilds

   Discord2017

   Symptoms

   At about 14:01 PDT on 13 October 2017, Discord engineers were alerted to anomalies by real-time metrics and monitoring. A Redis instance that was the primary of a highly available cluster used by the API services had dropped offline after Google Cloud Platform migrated it automatically, and some API instances did not handle the failover to the secondary node correctly.

   Failover failureHigh latencyService outage

   Trigger

   Google Cloud Platform automatically migrated the Redis instance that was the primary of a highly available cluster used by the API services, and the node incorrectly dropped offline.

   Root cause

   Software defect

   Component

   In-memory cacheDatabaseCDN and edge network

   Contributing factor

   Unpatched known bugOverlapping failuresMonitoring blind spot

   Detection

   Real-time metrics and monitoring alerted engineers at 14:01 PDT. The second phase was seen at 15:41 as another anomaly in monitoring, and end user reports of servers appearing offline were escalated at 15:42.

   Remediation

   • Ran a rolling restart of all API instances to clear the Redis connection issues
   • Corrected the misconfigured edge caching rule for the expensive API route
   • Disabled the problem API endpoint on the edge network
   • Recovered the Cassandra cluster
   • Ran a second rolling restart of all API instances for the latency left by the Cassandra issues
   • Removed the misbehaving guilds node from the service hashring
   • Forcefully restarted the misbehaving guilds node
   • Restarted the whole service, forcing all users to reconnect
   • Blocked traffic that relied on the failing push component to reduce its load
   • Corrected the API setting that lets users reconnect quickly and safely

   Action items

   • Fix the known issues with Redis failover within the coming weeks
   • Change the cached route so this type of error does not degrade other services
   • Monitor the signals that would have warned of the cascading failure
   • Improve the reliability and failure handling of the affected services
   • Roll out an update of the library with the suspected flaws

   View case

By root cause1