사례2건

2건 중 1~2번째

1. IL-0380 AWS us-east-1 의 InfluxDB Cloud 클러스터에서 압축 중에 일부 데이터가 빠져 쿼리에 나오지 않았다

   InfluxData2026

   증상

   2월 9일 데이터 가용성 문제일 수 있다는 첫 티켓이 들어왔다. 2월 10일 상태 페이지는 쿼리 문제를 조사 중이며 최근 데이터 일부가 쿼리 응답에 나오지 않는다고 알렸다.

   데이터 유실응답 품질 저하지연 시간 증가

   촉발

   2월 9일 아주 큰 파티션의 압축을 개선하려는 코드 변경을 prod101-us-east-1 에 배포했다.

   원인

   배포 결함

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏

   기여 요인

   안전하지 않은 실패 동작리뷰 누락자동 테스트 공백스테이징 불일치

   감지

   2월 9일 데이터 가용성 문제일 수 있다는 첫 티켓이 들어와 조사를 시작했다. 2월 10일 티켓이 더 들어온 뒤 근본 원인을 찾았다.

   조치

   • 2월 10일 압축 변경을 롤백해 더 번지지 않게 했다.
   • 최근 데이터를 클러스터의 쓰기를 모두 기록한 Kafka 로그에서 먼저 되살렸다.
   • 2월 17일 과거 데이터를 더 효율적으로 복원하도록 복원 절차를 고쳤다.
   • 과거 데이터를 TSM 스냅숏에서 복원했다.
   • 실시간 쓰기와 쿼리를 방해하지 않도록 클러스터를 켠 채로 조금씩 복원했다.

   후속 조치

   • 압축기처럼 중요한 스토리지 구성 요소를 바꾸는 변경의 테스트 범위를 넓히고, 운영 규모의 작업량을 더 잘 반영하는 테스트 시나리오를 더한다.
   • 압축 과정의 안전장치를 강화해 실패를 찾아내고 안전하게 처리하게 한다.
   • 대규모 복원 중에 TTBR 이 높아지거나 쿼리가 느려질 가능성을 줄이도록 복원 작업 흐름과 운영 절차를 검토한다.
   • 클러스터 전체 복원이 빨라지도록 백업과 복원 전략을 다시 본다.

   사례 보기
2. IL-0538 사쿠라 클라우드 스토리지의 일괄 삭제 작업이 고객이 쓰던 디스크 53개를 지웠고 되살리지 못했다

   Sakura Internet2012

   증상

   2012년 1월 5일 긴급 점검에서 스토리지의 불필요한 파일 시스템을 한꺼번에 지운 뒤, 고객이 사용 중이던 사쿠라 클라우드 디스크 53개가 함께 지워졌다. 이 디스크들은 백업에서도 되살릴 수 없었다.

   데이터 유실

   촉발

   스토리지 부하가 너무 높아 통상 절차로는 삭제가 실행되지 않자, 이 점검만을 위해 배치 명령을 새로 만들어 불필요한 파일 시스템을 한꺼번에 지웠다. 리뷰와 테스트를 충분히 거치지 않은 이 명령이 예비로 미리 만들어 둔 파일 시스템을 생성에 실패한 디스크로 잘못 분류했다.

   원인

   운영 실수

   구성 요소

   클라우드 블록 스토리지데이터베이스 백업과 스냅숏

   기여 요인

   리뷰 누락미검증 백업

   후속 조치

   • 불필요한 파일 시스템을 지우는 절차를 단순하게 바꾼다.
   • 리뷰와 테스트를 충분히 거치지 않은 스크립트는 실행하지 않는다는 원칙을 철저히 지킨다.

   사례 보기

원인별2