{"id":"IL-0278","org":"Redis","date":"2016-02-08","docs":[],"title":{"en":"A weekly update put a Redis Cloud management process into an infinite loop, and most nodes of a GCP cluster failed","ko":"주간 소프트웨어 업데이트 뒤 GCP 의 Redis Cloud 클러스터 노드 대부분이 동시에 응답하지 않아 그 클러스터의 데이터베이스가 내려갔다"},"domain":["database","gcp"],"impact":{"scope":"Redis Cloud databases on the GCP cluster us-central1-1-1.gce.garantiadata.com were unavailable; over 95% of affected users were back by 19:30 UTC and all by 20:38 UTC","users":"Redis Cloud users with databases endpoints ending in us-central1-1-1.gce.garantiadata.com","region":"us-central1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://redis.io/blog/february-8th-outage-post-mortem/","kind":"blog","archived":"https://web.archive.org/web/20260715160101/https://redis.io/blog/february-8th-outage-post-mortem/"}],"summary":{"en":"Redis Cloud clusters run Redis's cluster tools on bare-metal or virtual servers, each cluster hosting many isolated databases, and are built to survive the failure of a single node. Each week the DevOps team deploys an upgrade of non-critical cluster components, first to one cluster with sanity and stability testing and then one cluster at a time, cloud by cloud; the week's rollout began at 10:30 UTC. At 17:30 UTC it reached the GCP cluster us-central1-1-1.gce.garantiadata.com, where it exposed a serious bug in one of the cluster's management processes. The process locked into a resource-intensive infinite loop, and after several minutes of thrashing each server became unresponsive. One node failed at 17:41 UTC and failed over automatically; four more stopped responding at 17:45 UTC, and with a majority of nodes down the cluster could not recover by itself.\n\nBetween 17:45 and 19:30 UTC the team shut down and terminated all nodes, deleted the cluster's endpoints from its DNS zone, built new nodes from scratch without the weekly update and reconnected the original nodes' storage to them. Databases without persistence were bootstrapped and available at once; databases with persistence were bootstrapped and recovered from storage into memory, taking longer the bigger they were. Throttled DNS deletes whose retries failed had to be cleaned up by hand, which lengthened the downtime. By 19:30 UTC over 95% of affected users had service again, and at 20:38 UTC the last and largest database finished recovering from persistence.","ko":"Redis Cloud 클러스터는 베어메탈이나 가상 서버 위에 클러스터 도구를 배포해 만들고, 클러스터 하나가 여러 데이터베이스를 격리된 채로 올린다. 클러스터는 노드 하나의 장애는 서비스 중단 없이 견딘다. 2월 8일 10:30 UTC 에 DevOps 팀이 서비스에 영향을 주지 않는 클러스터 구성 요소의 주간 업그레이드를 시작했다. 업그레이드는 한 클러스터에 먼저 배포해 정상성과 안정성을 시험한 뒤 클러스터 하나씩, 클라우드 하나씩 넓혀 간다.\n\n17:30 UTC 에 업그레이드가 GCP 클러스터 us-central1-1-1.gce.garantiadata.com 에 배포되자, 업데이트에 들어 있던 버그로 클러스터 관리 프로세스 하나가 자원을 많이 쓰는 무한 루프에 갇혔고 서버가 응답하지 않게 됐다. 17:41 에 첫 노드가 죽었을 때는 자동 장애 조치가 성공했지만, 17:45 에 노드 네 대가 더 응답하지 않았다. 노드의 과반이 죽어 자동 복구가 불가능했고 팀은 수동 복구에 들어갔다.\n\n팀은 클러스터의 모든 노드를 내려 종료하고, 클러스터의 엔드포인트를 DNS 영역에서 지우고, 주간 업데이트를 뺀 새 노드를 처음부터 만들었다. 원래 노드가 쓰던 저장소는 새 노드에 다시 붙였다. 영속성이 없는 데이터베이스는 띄우자마자 쓸 수 있었고, 영속성이 있는 데이터베이스는 띄운 뒤 저장소에서 메모리로 복구했다. 큰 데이터베이스일수록 복구가 오래 걸렸다. 복구 중에 DNS 제공자가 도구의 삭제 요청을 스로틀링했다. 도구가 스로틀링된 요청을 제대로 재시도하지 못해 DNS 항목을 손으로 지워야 했고, 그만큼 장애가 길어졌다. 19:30 UTC 에 영향받은 사용자 가운데 95% 를 넘는 사용자가 돌아왔고, 20:38 UTC 에 가장 큰 마지막 데이터베이스가 복구돼 서비스가 완전히 정상이 됐다."},"trigger":{"en":"The weekly upgrade of Redis Cloud's non-critical cluster components reached its first Google Cloud Platform cluster, us-central1-1-1.gce.garantiadata.com, at 17:30 UTC.","ko":"2016년 2월 8일 17:30 UTC 에 서비스 소프트웨어의 주간 업그레이드가 GCP 클러스터 us-central1-1-1.gce.garantiadata.com 에 처음 배포됐다."},"severity":"unknown","symptoms":["service-unavailable","failover-failed"],"timeline":{"detected_after":null,"resolved_after":"2h 53m"},"date_kind":"incident","detection":null,"components":["cache","failover-manager","dns-server"],"root_cause":"deploy-rollout","remediation":[{"text":{"en":"Shut down and terminated all nodes of the cluster","ko":"클러스터의 모든 노드를 내리고 종료했다."}},{"text":{"en":"Deleted all of the cluster's endpoints from its DNS zone, removing by hand the entries left by throttled deletes","ko":"클러스터의 모든 엔드포인트를 클러스터의 DNS 영역에서 지웠다. DNS 제공자가 삭제 요청을 스로틀링해 남은 항목은 손으로 지웠다."}},{"text":{"en":"Provisioned new cluster nodes from scratch without the weekly update","ko":"주간 업데이트를 뺀 새 클러스터 노드를 처음부터 만들었다."}},{"text":{"en":"Reconnected the original nodes' storage to the new nodes so persistence-enabled databases could be recovered","ko":"원래 노드가 쓰던 저장소를 새 노드에 다시 붙여, 영속성이 있는 데이터베이스를 복구할 수 있게 했다."}},{"text":{"en":"Bootstrapped and launched the databases, recovering the ones with persistence from storage","ko":"데이터베이스를 모두 띄웠고, 영속성이 있는 데이터베이스는 저장소에서 복구했다."}}],"action_items":[{"text":{"en":"Suspend all automatic weekly upgrades until a procedure that prevents this kind of outage is in place","ko":"이번 같은 장애를 막는 절차를 갖출 때까지 자동 주간 업그레이드를 모두 멈춘다."}},{"text":{"en":"Revalidate the QA processes for DevOps code deployments","ko":"DevOps 코드 배포의 QA 절차를 다시 검증한다."}},{"text":{"en":"Improve the tooling so it handles throttling of DNS requests","ko":"DNS 요청이 스로틀링될 때 도구가 이를 처리하도록 개선한다."}}],"contributing":["overlapping-failures"],"recurrence_of":null,"symptoms_text":{"en":"On 8 February 2016 at 17:45 UTC, four nodes of the Redis Cloud cluster us-central1-1-1.gce.garantiadata.com on Google Cloud Platform stopped responding, four minutes after a first node had failed. The databases whose endpoints end in us-central1-1-1.gce.garantiadata.com went down.\n\nThe first node failed at 17:41 UTC and an automated failover handled it successfully. When four more nodes stopped responding at 17:45 UTC, a majority of the cluster had failed and automatic recovery was no longer possible, so the DevOps team started a manual recovery. During that recovery the DNS provider throttled the delete requests generated by Redis's tools, and the retries of the throttled requests were not handled correctly, leaving DNS entries that had to be removed by hand before the cluster could be relaunched.","ko":"2016년 2월 8일 17:45 UTC 에 Google Cloud Platform 의 Redis Cloud 클러스터 us-central1-1-1.gce.garantiadata.com 에서 큰 장애가 났다. 데이터베이스 엔드포인트가 us-central1-1-1.gce.garantiadata.com 으로 끝나는 사용자들이 데이터베이스를 쓰지 못했다.\n\n17:30 UTC 에 주간 업데이트가 이 클러스터에 배포된 뒤, 클러스터 관리 프로세스 하나가 자원을 많이 쓰는 무한 루프에 갇혔다. 서버는 몇 분 동안 스래싱을 겪다가 응답하지 않게 됐다.\n\n17:41 UTC 에 클러스터의 첫 노드가 죽었고, 자동 장애 조치가 곧바로 일어나 성공했다. 17:45 UTC 에 노드 네 대가 더 응답하지 않았다. 클러스터 노드의 과반이 죽어 자동 복구가 불가능했다."},"updated_at":"2026-11-14T12:33:52.990743Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0278","org_slug":"redis"}