사례2건
2건 중 1~2번째
- 증상
2024년 8월 5일 16:30 UTC 부터 DigitalOcean 의 모든 리전에서 이벤트 처리가 실패해 Droplet 이벤트가 실패했고, 리소스 생성과 Cloud Control Panel, API 를 통한 관리가 멈췄다. Droplet 같은 기존 고객 리소스는 계속 온라인이었고 접근할 수 있었다.
- 촉발
새 데이터센터를 더하는 데이터스토어 클러스터 롤아웃에서 잘못된 복제 설정이 배포됐다. 이 설정은 키가 하나도 없는 새 데이터센터에 데이터스토어의 모든 키 소유권 100%를 줬다.
- 원인
- 구성 요소
- 기여 요인
- 감지
16:35 UTC 에 서비스 디스커버리를 쓸 수 없다는 첫 보고가 내부에서 올라왔다. 데이터스토어 클러스터 롤아웃이 시작되고 5분 뒤였다.
- 조치
- 17:16 UTC 에 복제 설정 변경을 되돌리고, 데이터스토어 소유자가 된 리전에 되돌린 설정을 적용했다.
- 18:25 UTC 부터 되돌린 설정을 알아채거나 적용하지 못한 리전을 찾아, 엔지니어가 그 리전의 노드에 직접 설정을 적용하고 데이터스토어 repair 를 돌렸다.
- 남은 실패 이벤트를 정리하고, 아직 타임아웃되지 않은 대기 이벤트를 처리했다.
- 후속 조치
- 이런 확장 유지보수는 선언한 유지보수 시간 안에 하고, 고객 영향 가능성은 상태 페이지의 유지보수 공지로 알린다.
- 이런 배포의 절차 문서를 현재 요구 사항에 맞게 고치고, 새 배포의 단계마다 할 일과 기대하는 결과를 분명하게 적는다.
- 이번에 손으로 한 과정을 자동화해 사람의 실수 가능성을 줄인다.
- 여러 팀이 내부 데이터스토어의 현재 토폴로지가 알맞은지, 그리고 내부 서비스 디스커버리의 가용성을 지키도록 리전 단위로 나누거나 여러 계층으로 구성할 방법이 있는지 검토한다.
- 증상
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 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.