{"id":"IL-0374","org":"DigitalOcean","date":"2024-08-05","docs":[],"title":{"en":"DigitalOcean creates and management actions failed globally when its service discovery datastore lost quorum","ko":"DigitalOcean 내부 서비스 디스커버리가 전 리전에서 멈춰 생성, 이벤트 처리, 제어판과 API 관리가 실패했다"},"domain":["database"],"impact":{"scope":"Creates, event processing and management through the Cloud Control Panel and the API for Droplets, networking, login and authentication, Block Storage snapshots, Spaces and CDN, Managed Kubernetes and Managed Databases; existing resources stayed available","users":"unknown","region":"Global"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://status.digitalocean.com/incidents/222822dwq709","kind":"official-status","archived":"https://web.archive.org/web/20250612144318/https://status.digitalocean.com/incidents/222822dwq709"}],"summary":{"en":"DigitalOcean was adding a new datacenter to the datastore that powers its internal service discovery. The replication configuration deployed for it named the new datacenter, which held zero keys, as the owner of 100% of the keys in the datastore. The configuration propagated globally at once, the datastore nodes lost quorum in every region, and clients could no longer read from or write to the datastore, which cascaded to every service that finds its dependencies through service discovery.\n\nEngineers identified the lack of quorum and datastore ownership as the blocking issue at 16:42 UTC and the replication change as its cause at 17:00 UTC, then reverted the configuration at 17:16 UTC and ran it against the region that had become the datastore owner. Some regions picked up the corrected configuration and recovered. For the regions that had not, engineers applied the configuration directly on the nodes from 18:25 UTC and ran local repairs on the data to make sure it was aligned before moving on to the next region. After failed events were cleaned up and pending events that had not yet timed out were processed, the platform stabilised at 19:10 UTC. The replication configuration deployment had taken place outside a normal maintenance window.","ko":"DigitalOcean 의 내부 서비스 디스커버리는 데이터스토어 하나에 기댄다. 2024년 8월 5일 16:30 UTC 에 새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃이 시작됐고, 정규 유지보수 시간 밖에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 모든 키의 소유권 100%를 줬다. 설정은 곧바로 전 세계로 퍼져 모든 리전에서 데이터스토어 노드의 쿼럼을 깨뜨렸다. 서비스 디스커버리의 클라이언트는 데이터스토어를 읽고 쓰지 못했고, 내부 서비스는 의존하는 서비스를 찾지 못했다. 그 결과 전 세계에서 리소스 생성, 이벤트 처리, 여러 제품의 관리가 멈췄다. 기존 고객 리소스의 가용성은 영향을 받지 않았다.\n\n엔지니어들은 16:42 UTC 에 쿼럼과 소유권 문제를 찾았고, 17:00 UTC 에 새 데이터센터를 더한 복제 설정 변경을 근본 원인으로 확인했다. 17:16 UTC 에 그 변경을 되돌려 데이터스토어 소유자가 된 리전에 적용했다. 일부 리전은 새 설정을 받아들이고 회복하기 시작했지만, 늦게 받아들이는 리전도 있었다. 18:25 UTC 부터 엔지니어들은 그런 리전의 노드에 직접 설정을 적용하고 로컬에서 데이터스토어 repair 를 돌려 데이터를 맞춘 뒤 다음 리전으로 넘어갔다. 남은 실패 이벤트를 정리하고 대기 중인 이벤트를 처리하자 19:10 UTC 에 플랫폼이 안정됐다."},"trigger":{"en":"During the rollout of a new datastore cluster in a new datacenter, a replication configuration was deployed against the datastore behind internal service discovery that gave the new datacenter, which held zero keys, 100% ownership of all keys.","ko":"새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 데이터스토어의 모든 키 소유권 100%를 줬다."},"severity":"unknown","symptoms":["service-unavailable","cluster-creation-stuck"],"timeline":{"detected_after":"5m","resolved_after":"2h 40m"},"date_kind":"incident","detection":{"en":"Service discovery unavailability was first reported internally at 16:35 UTC, five minutes after the rollout of the new datastore cluster began.","ko":"16:35 UTC 에 서비스 디스커버리를 쓸 수 없다는 첫 보고가 내부에서 올라왔다. 데이터스토어 클러스터 롤아웃이 시작되고 5분 뒤였다."},"components":["coordination-store","service-discovery","database-replication"],"root_cause":"config-change","remediation":[{"text":{"en":"Reverted the replication configuration and ran it against the region that had become the datastore owner","ko":"17:16 UTC 에 복제 설정 변경을 되돌리고, 데이터스토어 소유자가 된 리전에 되돌린 설정을 적용했다."}},{"text":{"en":"Applied the configuration by hand on the nodes of lagging regions and ran local data repairs","ko":"18:25 UTC 부터 되돌린 설정을 알아채거나 적용하지 못한 리전을 찾아, 엔지니어가 그 리전의 노드에 직접 설정을 적용하고 데이터스토어 repair 를 돌렸다."}},{"text":{"en":"Cleaned up failed events and processed pending events that had not timed out","ko":"남은 실패 이벤트를 정리하고, 아직 타임아웃되지 않은 대기 이벤트를 처리했다."}}],"action_items":[{"text":{"en":"Perform this kind of datastore extension inside a declared maintenance window, announced on the status page","ko":"이런 확장 유지보수는 선언한 유지보수 시간 안에 하고, 고객 영향 가능성은 상태 페이지의 유지보수 공지로 알린다."}},{"text":{"en":"Update the process documentation for this type of deployment, stage by stage","ko":"이런 배포의 절차 문서를 현재 요구 사항에 맞게 고치고, 새 배포의 단계마다 할 일과 기대하는 결과를 분명하게 적는다."}},{"text":{"en":"Automate the manual steps used in this deployment to reduce human error","ko":"이번에 손으로 한 과정을 자동화해 사람의 실수 가능성을 줄인다."}},{"text":{"en":"Evaluate the internal datastore topology and whether to regionalise or layer it","ko":"여러 팀이 내부 데이터스토어의 현재 토폴로지가 알맞은지, 그리고 내부 서비스 디스커버리의 가용성을 지키도록 리전 단위로 나누거나 여러 계층으로 구성할 방법이 있는지 검토한다."}}],"contributing":["blast-radius-too-wide"],"recurrence_of":null,"symptoms_text":{"en":"From 16:30 UTC on 5 August 2024, DigitalOcean's internal services could not discover the other services they depended on. Creates, event processing and the management of DigitalOcean products failed in all regions through the Cloud Control Panel and the API, while existing customer resources such as Droplets stayed online.\n\nThe first visible effect was a complete disruption of reads and writes to the datastore behind internal service discovery, whose nodes lost quorum in every region. Droplet creates and updates, network creates, login and authentication, Block Storage volume snapshot creation, Spaces and CDN creates, Spaces updates, Managed Kubernetes cluster creates and Managed Databases creates failed. Other services also rely on service discovery to talk to each other, so customers may have seen further impact when managing them through the Cloud Control Panel or the API.\n\nEvents failed with a distinct timeout at first. After the replication configuration was reverted at 17:16 UTC, some events failed faster, and the error changed from a timeout to a failure to find endpoints. Some regions took longer to pick up the reverted configuration and kept failing until engineers applied it on their nodes by hand.","ko":"2024년 8월 5일 16:30 UTC 부터 DigitalOcean 의 모든 리전에서 이벤트 처리가 실패해 Droplet 이벤트가 실패했고, 리소스 생성과 Cloud Control Panel, API 를 통한 관리가 멈췄다. Droplet 같은 기존 고객 리소스는 계속 온라인이었고 접근할 수 있었다.\n\n내부 서비스들이 자신이 의존하는 다른 서비스를 제대로 찾지 못했다. 처음 보인 영향은 서비스 디스커버리 뒤에 있는 데이터스토어의 I/O 계층이 완전히 멈춘 것이었고, 클라이언트는 데이터스토어를 읽고 쓰지 못했다.\n\n이벤트를 쓰는 Droplet 생성과 업데이트, 네트워크 생성, 로그인과 인증, Block Storage 볼륨 스냅샷 생성, Spaces 와 CDN 생성, Spaces 업데이트, Managed Kubernetes 클러스터 생성, Managed Databases 생성이 영향을 받았다. 이벤트 흐름 밖의 서비스도 서비스 디스커버리로 서로 통신하기 때문에, 고객이 Cloud Control Panel 이나 API 로 여러 서비스를 관리할 때도 영향이 있었을 수 있다.\n\n16:42 UTC 에 엔지니어들은 데이터스토어에 쿼럼이 없고 소유권이 막혀 있다는 문제를 찾았다. 17:16 UTC 에 설정을 되돌리자 일부 이벤트는 더 빨리 실패하기 시작했고, 오류도 분명한 타임아웃 오류에서 엔드포인트를 찾지 못했다는 오류로 바뀌었다. 일부 리전은 되돌린 설정을 늦게 받아들였고, 19:10 UTC 에 남은 실패 이벤트가 풀리며 플랫폼이 안정됐다."},"updated_at":"2026-11-14T12:34:02.642685Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0374","org_slug":"digitalocean"}