사례2건
2건 중 1~2번째
- 증상
2026년 8월 24일 16:56 UTC 부터 DigitalOcean 의 Cloud Control Panel, 공개 API, 그리고 이 둘에 기대는 제품 관리 시스템에서 요청 오류율이 올라갔다. 여러 제품의 생성 요청을 포함한 모든 API 요청에서 5xx 오류가 늘었고, 사용자가 cloud.digitalocean.com 에 들어가지 못하기도 했다.
- 촉발
아이덴티티, 인증, 인가 서비스를 받치는 데이터베이스 계층을 계획에 따라 이전하는 인프라 작업을 하던 중이었다. 이 이전 작업 때문에 핵심 인가 쿼리 하나의 실행 지연이 늘었다.
- 원인
- 구성 요소
- 기여 요인
- 감지
16:58 UTC 에 자동 모니터링이 비정상적인 오류율과 지연을 잡아냈다. 보고서는 영향이 시작되고 5분 안에 감지했다고 적었다.
- 조치
- 인가 트래픽을 정상으로 동작하는 처리 경로 하나로 몰아 보냈다.
- 주요 호출자의 hedging 을 잠시 껐다.
- 두 번째 구간에서 나머지 영향받은 서비스 전체의 재시도와 요청 증폭 동작을 껐다.
- 느린 인가 쿼리를 받을 읽기 용량을 더했다.
- 후속 조치
- 상위 서비스 전반에 자동 서킷 브레이커를 배포했다. 서킷 브레이커는 하위 의존 서비스가 나빠진 것을 감지하면 hedged retry 와 재시도 증폭을 자동으로 막는다.
- 모든 컨트롤 플레인 서비스에 재시도 억제와 서킷 브레이커가 똑같이 적용되는지 아키텍처 전반을 점검하는 작업을 마쳤다.
- 의존 서비스가 느려질 때 요청 큐가 포화되지 않도록 요청을 빠르게 실패시키는 로드 셰딩을 넣었다.
- 고객이 영향을 받기 전에 큐가 쌓이기 시작한 것을 알아채는 텔레메트리 알림을 더했다.
- 주 데이터베이스가 느려지면 핵심 인가 구성 요소가 기능을 줄인 모드로 동작하도록 설정했다. 이 모드에서는 비동기로 갱신되는 최종 일관성 복제본을 읽는다.
- 증상
2017-04-05 10:24 EDT 에 공개 서비스가 동작하지 않는다는 알림이 들어왔다. 제어판과 API 를 쓸 수 없었다. 돌고 있던 Droplet 은 계속 동작했지만, 새 Droplet 이나 다른 자원을 만들거나 관리할 수는 없었다.
- 촉발
자동 테스트를 돌리는 프로세스가 운영 환경 자격 증명을 쓰도록 잘못 설정돼 있었고, 그 결과 주 데이터베이스가 지워졌다.
- 원인
- 구성 요소
- 기여 요인
- 감지
10:24 EDT 에 공개 서비스가 동작하지 않는다는 알림이 들어왔고, 3분 뒤 마스터의 운영 데이터베이스가 지워진 것을 확인했다.
- 조치
- 10:34 EDT 에 시간 지연 레플리카에서 복구를 시작했다.
- 11:53 에 시간 지연 레플리카의 백업을 마쳤다.
- 12:34 에 백업을 마스터로 복사하고 복원을 시작했다.
- 13:31 에 마스터 복구를 마쳤고 레플리카로 백업을 복사하는 일을 이어 갔다. 15:20 에 모든 시스템이 복원됐다.
- 후속 조치
- 같은 일이 다시 없도록 특정 작업에서 주 시스템에 접근할 수 있는 권한을 크게 줄인다.
- 데이터베이스 서버 사이의 네트워크 연결을 업그레이드한다.
- 복구 속도를 높이도록 하드웨어를 바꾼다.
- 개발자 실수를 막는 안전장치를 더 검토한다.
- 데이터 복구 절차를 개선한다.
- 고객에게 영향을 주는 장애가 날 때 실시간 정보를 더 잘 전할 방법을 찾는다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 백업과 스냅숏. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.