Incident RCA

Write and read outage in AWS: Frankfurt, EU-Central-1, AWS: Oregon, US-West-2-1 and AWS: Virginia, US-East-1

Summary

On Feb 24, 2023 at 19.30 UTC, we deployed a software change to multiple production clusters, which caused a significant percentage of writes and queries to fail in our larger clusters.  The duration of the outage was different for each cluster as was the level of disruption (percentage of writes and queries that failed during the incident). The table below summarizes the time ranges during which the service was impacted in each cluster (all in UTC time).

Cause of the Incident

Our software is deployed via a CD pipeline to three staging clusters (one per cloud provider) where a suite of automated tests are run.  If those tests pass, then it is deployed into an internal cluster where another round of testing occurs, and finally it is deployed to all of our production clusters in parallel.  This is our standard software deployment methodology for our cloud service. On February 24, 2023, an engineer made a change to a health-check to ensure that our query and write pods can reach the vault within the cluster (where credentials are managed). In the past, it was possible for a query or write pod to get stuck, if it lost access to the vault. To address that problem, a health check was added so that if a pod could not reach the vault, the pod would stop/restart automatically. This health check was tested in all three staging clusters, and worked fine. The change was promoted to our internal cluster, which also worked fine. The change was then promoted to our production clusters.  In the larger clusters, when the pods were restarted (with the new health check in place) too many pods made health-check calls to the vault in quick succession.  These calls overwhelmed the vault, and it was unable to service all the requests. As the health check failed, the pods attempted to recover by restarting, which put an even heavier workload on the vault, from which it was unable to recover.

Recovery

As soon as we detected the problem, and identified the offending software change, we rolled back to an earlier version of our production software, and redeployed that in all the production clusters. In our smaller clusters, this happened quickly, without any significant customer impact. In our three largest clusters (the clusters listed above), as the vault was deadlocked, we were unable to deploy the new software without manually restarting the vault instances, and then gradually restarting the services that depend on the vault. This is what caused it to take longer to recover in these clusters.

Future mitigations

1. We are re-implementing the offending health check so that we can detect a stuck pod without putting such a burden on the vault.
2. As the vault is a critical element of our service, we are adding an extra peer review step to all software changes that interact with the vault.
3. We are enhancing the vault configuration to have the vault more gracefully degrade when overloaded.
4. We are enhancing our runbooks so that we can more quickly intervene with manual steps if the regular deployment/rollback process fails, to reduce our overall time-to-recover when a cluster fails to recover normally.