IL-0561 DigitalOcean · 2026-08-24database
DigitalOcean 의 Cloud Control Panel 과 공개 API 에서 두 차례에 걸쳐 요청이 최대 25% 실패했다
2026년 8월 24일 DigitalOcean 은 아이덴티티, 인증, 인가 서비스를 받치는 데이터베이스 계층을 계획에 따라 이전하고 있었다. 16:56 UTC 에 핵심 인가 쿼리 하나가 평소 기준보다 훨씬 느려졌다. 쿼리 지연이 늘자 여러 상위 서비스가 자동으로 hedged retry 를 보냈다. 이렇게 불어난 요청이 인증 서비스 풀의 처리량을 넘어서 큐가 쌓였고, 인가 경로 전체로 요청 타임아웃이 연쇄로 번졌다.
첫 구간에서 엔지니어들은 재시도 설정을 조정하고, 인가 트래픽을 정상인 처리 경로 하나로 몰고, 주요 호출자의 hedging 을 잠시 껐다. 18:52 에 서비스가 돌아왔다. 21:30 에 트래픽을 평소의 여러 경로 구성으로 되돌리자, 남아 있던 쿼리 지연과 hedging 을 끄지 않은 호출자의 재시도가 겹쳐 큐가 다시 포화됐고 두 번째 구간이 시작됐다. 팀은 나머지 영향받은 서비스에서도 재시도와 요청 증폭 동작을 끄고, 느린 쿼리에 읽기 용량을 더했다. 23:09 에 서비스가 안정됐다.
두 구간에서 인증된 요청의 평균 약 10% 가 실패했고 최고 오류율은 25% 였다. 활성 고객 계정의 2% 미만이 API 나 Cloud Control Panel 요청 실패를 한 번 이상 겪었다. Droplet, 네트워크 라우팅, Volumes 는 영향을 받지 않았고 데이터 손실은 없었다. 데이터베이스 이전은 끝까지 마쳤다.
- 심각도
- –
- 영향 범위
- Cloud Control Panel, Public API, Kubernetes cluster authentication, Container Registry and Serverless / AI Inference endpoints failed requests at about 10% on average and 25% at peak; Droplets, network routing and Volumes were not affected
- 영향 사용자
- fewer than 2% of active customer accounts saw at least one failed API or Control Panel request
- 지역
- –
- 감지까지
- 2m
- 복구까지
- 6h 13m
증상
2026년 8월 24일 16:56 UTC 부터 DigitalOcean 의 Cloud Control Panel, 공개 API, 그리고 이 둘에 기대는 제품 관리 시스템에서 요청 오류율이 올라갔다. 여러 제품의 생성 요청을 포함한 모든 API 요청에서 5xx 오류가 늘었고, 사용자가 cloud.digitalocean.com 에 들어가지 못하기도 했다.
영향을 받은 관리 영역은 Cloud Control Panel, 공개 API, Kubernetes 클러스터 인증, Container Registry, Serverless 와 AI Inference 엔드포인트였다. Serverless Inference 사용자는 API 를 호출하거나 해당 서비스에 접근할 때 403 과 503 오류를 받을 수 있었다.
오류는 6시간 동안 두 구간에 나뉘어 나타났고, 실제로 서비스가 나빴던 시간은 합쳐서 3.5시간이었다. 첫 구간은 16:56 에 시작해 18:52 에 끝났다. 그사이 18:33 에는 지연과 오류율이 조금 나아졌고 일부 사용자는 Cloud Control Panel 에 다시 들어갈 수 있을 것이라는 공지가 상태 페이지에 올라왔다. 21:30 에 트래픽을 평소 구성으로 되돌리자 같은 포화가 다시 일어나 두 번째 구간이 시작됐고, 23:09 에 끝났다. 두 구간을 합친 평균 실패율은 인증된 요청의 약 10% 였고, 최고 오류율 25% 는 두 번째 구간에서 나왔다.
실행 중인 Droplet, 네트워크 라우팅, 블록 스토리지인 Volumes 는 사고 내내 정상으로 동작했다. 이미 맺어진 연결은 문제가 난 인가 경로를 거치지 않기 때문이다.
원인
- 촉발
- 아이덴티티, 인증, 인가 서비스를 받치는 데이터베이스 계층을 계획에 따라 이전하는 인프라 작업을 하던 중이었다. 이 이전 작업 때문에 핵심 인가 쿼리 하나의 실행 지연이 늘었다.
감지
16:58 UTC 에 자동 모니터링이 비정상적인 오류율과 지연을 잡아냈다. 보고서는 영향이 시작되고 5분 안에 감지했다고 적었다.
조치
- 인가 트래픽을 정상으로 동작하는 처리 경로 하나로 몰아 보냈다.
- 주요 호출자의 hedging 을 잠시 껐다.
- 두 번째 구간에서 나머지 영향받은 서비스 전체의 재시도와 요청 증폭 동작을 껐다.
- 느린 인가 쿼리를 받을 읽기 용량을 더했다.
후속 조치
- 상위 서비스 전반에 자동 서킷 브레이커를 배포했다. 서킷 브레이커는 하위 의존 서비스가 나빠진 것을 감지하면 hedged retry 와 재시도 증폭을 자동으로 막는다.
- 모든 컨트롤 플레인 서비스에 재시도 억제와 서킷 브레이커가 똑같이 적용되는지 아키텍처 전반을 점검하는 작업을 마쳤다.
- 의존 서비스가 느려질 때 요청 큐가 포화되지 않도록 요청을 빠르게 실패시키는 로드 셰딩을 넣었다.
- 고객이 영향을 받기 전에 큐가 쌓이기 시작한 것을 알아채는 텔레메트리 알림을 더했다.
- 주 데이터베이스가 느려지면 핵심 인가 구성 요소가 기능을 줄인 모드로 동작하도록 설정했다. 이 모드에서는 비동기로 갱신되는 최종 일관성 복제본을 읽는다.
교훈
–
출처
- https://status.digitalocean.com/incidents/4qwm6pzlx1z3 · official-status · 보관본
관련 사례
IL-0574운영 환경의 DB 접속 경로를 Amazon RDS Proxy로 바꾼 지 몇 분 만에 Aurora MySQL writer CPU가 100%에 이르고 에러가 났다Safie · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0179DEBUG 로그가 쏟아지자 동기 로깅을 하던 요청 스레드들이 가득 찬 stdout 파이프에서 멈춘 채 DB 커넥션을 쥐고 있어, HikariCP 커넥션 풀이 고갈되고 요청이 30초 주기로 한꺼번에 실패했다.MUSINSA · 2026같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0283Cloudflare 네트워크 전체에서 코어 프록시가 Bot Management 피처 파일을 읽다 실패해 사이트 방문자들이 HTTP 5xx 오류 페이지를 받았다Cloudflare · 2025같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
IL-0392데이터센터 전환을 앞두고 원형 복제를 설정하던 중 Wikimedia x1 섹션의 eqiad·codfw 사이 MariaDB 복제가 6분 멈췄다Wikimedia Foundation · 2024같은 원인 · 공통 데이터베이스
IL-0367Central US 의 Azure Storage 가 VM 디스크 요청을 거부해 VM 과 그 위의 SQL Database, Cosmos DB 가 멈췄다Microsoft Azure · 2024같은 원인 · 공통 데이터베이스
IL-0511Vault 가 새로 발급한 데이터베이스 자격 증명이 SCRAM 으로 만들어져 pgbouncer 가 RDS 에 로그인하지 못하고 xPro 운영 사이트가 멈췄다MIT Open Learning · 2023같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
같은 원인 · 공통 데이터베이스
내 클러스터에도 있는지 확인하기
AI 도구와 스크립트용
- 이 사례의 JSON: https://incidentlib-api.benchlet.com/cases/IL-0561
- 가장 비슷한 사례들: https://incidentlib-api.benchlet.com/cases/IL-0561/similar
- MCP 서버(Streamable HTTP, 키 없음):
https://incidentlib-mcp.benchlet.com/mcp
API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.