Cases6 cases

5 to 6 of 6

1. IL-0453 Hakuna API latency spiked every day during the ElastiCache Redis backup as memory filled and the backup went forkless

   Hyperconnect2022

   Symptoms

   The service API latency of Hyperconnect's Hakuna rose sharply at a certain time, periodically. The per-dependency latency analysis in the APM showed that a bottleneck in Redis caused it, but no deployment and no change in traffic pattern could have affected how Redis was used.

   High latencyMemory pressure

   Trigger

   The daily ElastiCache backup on the primary node ran while available memory was insufficient, so ElastiCache used a forkless backup that slowed user requests.

   Root cause

   Capacity exhaustion

   Component

   In-memory cacheDatabase backups and snapshots

   Contributing factor

   No alert on limit

   Detection

   A latency graph showed the service API latency spiking periodically, and the APM's per-dependency latency analysis pointed at Redis.

   Remediation

   • Moved the ElastiCache backup from the primary node to the secondary node
   • Changed the code so data stored without a TTL is stored with one
   • Replaced the Redis Hash CrudRepository usages with a CustomRepository built on RedisTemplate
   • Ran a script that deleted the unneeded data already stored, freeing 58 GB on 3 databases

   Lessons

   The team says its Redis operation and monitoring had gaps, and lists what to watch: use a relational database when data has relationships or must be searched by value; write data that must be durable to on-disk storage rather than Redis; keep available memory at 50% or more when ElastiCache snapshots must be taken; take care that O(n) commands such as DEL on a collection do not stall production Redis; and check regularly for unnecessary I/O between the application and the database. Spring Data Redis repositories, which manage secondary indexes in the framework, suit workloads that need no TTL and need fast queries.

   View case
2. IL-0382 Linode Object Storage in Newark and Atlanta returned 503 Slow Down to all clients under very high inbound traffic

   Linode2022

   Symptoms

   On 19 and 20 October 2022, Linode Object Storage in Newark and Atlanta slowed down, became less available and rate limited many requests with "503 - Slow Down" HTTP responses, after the clusters received extremely high inbound traffic in both request count and bandwidth.

   High error rateMemory pressure

   Trigger

   Extremely high inbound traffic, in both total requests and throughput, reached the Newark and Atlanta Object Storage clusters on 19 and 20 October 2022.

   Root cause

   Capacity exhaustion

   Component

   Object storage

   Contributing factor

   Unpatched known bugExcessive blast radius

   Remediation

   • Fixed the edge rate limiting so it enforces the advertised 750 requests per second per bucket
   • Adjusted Ceph tunables to stop runaway memory use during high-pressure storage events
   • Moved internal Object Storage components hit by resource contention to less busy, higher-performance infrastructure
   • Adjusted performance tunables on internal components and back-end clusters so customers were not rate limited too early

   Action items

   • Refine throughput and bandwidth throttling
   • Scale up the internal Object Storage infrastructure to spread load more efficiently
   • Look for further hardware performance improvements for the internal Object Storage infrastructure
   • Tune the load balancing algorithms to avoid hotspots in the clusters

   Lessons

   Linode's per-bucket rate limiting at the edge is meant to keep excess load off the back end; when it works as intended, the back-end limits, which throttle every client alike, should never come into play.

   View case

By root cause1