사례3건

3건 중 1~3번째

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-0523 TANF-app 의 운영 배포가 PostgreSQL 마이그레이션 실패로 두 달 동안 막힘

   U.S. Department of Health and Human Services2023

   증상

   2023년 9월 7일 TANF-app 의 sprint 80 운영 배포가 실패했고, 9월 20일 sprint 82 배포는 디스크 공간 오류로 실패했다. 그 뒤 11월 9일까지 운영에 배포하지 못했다.

   배포 실패노드 디스크 가득 참

   촉발

   2023년 9월 7일 sprint 80 배포에서 이미 배포된 마이그레이션 search_indexes 0016 을 지웠고, 9월 20일 sprint 82 배포가 이 마이그레이션을 다시 만들어 큰 마이그레이션 0017 과 함께 운영 데이터베이스에서 돌렸다.

   원인

   배포 결함

   구성 요소

   데이터베이스스키마 마이그레이션

   기여 요인

   장애 중첩자동 테스트 공백스테이징 불일치런북 부재

   감지

   운영 배포가 실패하면서 드러났다. 9월 7일 sprint 80 배포와 9월 20일 sprint 82 배포가 차례로 실패했고, 9월 20일 배포에서 디스크 공간 오류가 났다.

   조치

   • 11월 8일 운영 데이터베이스 인스턴스 크기를 키우고 마이그레이션을 다시 돌렸다. 이번에는 빈 문자열을 정수로 바꾸는 오류로 마이그레이션이 실패했다.
   • 운영 데이터베이스의 백업을 만들었다.
   • `search_indexes` 테이블을 모두 비웠다. 팀은 여기서 운영 데이터를 잃는 것을 걱정하지 않았다.
   • sprint 82 릴리스를 다시 배포해 운영을 sprint 82 로 되살렸고, 배포가 다시 가능해졌다.
   • 빈 문자열 버그를 고쳤다.

   후속 조치

   • 데이터베이스 문제 해결 절차를 기술 문서에 더한다.
   • 위키 페이지와 운영 플레이북에 흔한 문제와 대응을 정리한다.
   • Failed-Deployment-Troubleshooting 문서에 데이터베이스 문제 절을 만들고 cf revisions 명령을 적는다.
   • 운영에 직접 한 변경을 모은 GitHub 레포를 만들어, 비슷한 문제가 다시 날 때 길잡이로 쓴다.
   • 운영 디버깅 세션의 터미널 출력을 저장한다.
   • 코드 리뷰에서 지킬 Django 마이그레이션 모범 사례를 만든다.
   • develop 에 머지된 마이그레이션은 고치지 않고, 그 시점부터 모델을 바꾸는 새 마이그레이션을 쓴다.
   • 자동 생성된 마이그레이션 이름을 알아보기 쉬운 이름으로 바꾼다. 이름만 보고 내용을 알 수 없으면 조사하기 어렵다.
   • 자동 생성 마이그레이션은 모델 변경 하나에 하나만 두고, PR 하나에서 모델을 여러 번 바꾸면 마이그레이션을 다시 생성한다.
   • 시험에 쓸 데이터베이스 시딩과 백업을 어떻게 할지 논의 자리를 만든다.

   교훈

   계획에 없던 일이라 많은 개발자가 손을 보태야 했고, 팀이 작아 분야마다 모든 사람이 필요했다. 팀은 문제와 대응을 일찍 문서로 남겨 더 적은 사람으로 대응할 수 있게 하자고 했다. 작업 중인 코드를 raft, qasp, sandbox 환경에 배포한 뒤 마이그레이션을 바꾸면 그 환경에서 충돌이 난다. 대용량 데이터와 공백 채움이 없는 레코드 같은 예외 상황은 시험하지 않았고, 개인정보를 지운 운영 데이터베이스 사본이 있으면 실제 데이터로 더 많이 시험할 수 있다.

   사례 보기
3. IL-0328 배포 뒤 CircleCI 의 모든 executor 에서 작업이 "not running" 상태로 멈췄다

   CircleCI2021

   증상

   2021-11-08 18:50 UTC 배포 직후 오류와 알림이 바로 들어왔고, 모든 executor 에서 고객 작업이 "not running" 상태로 막혔다.

   서비스 중단지연 시간 증가노드 증설 실패클라우드 API 호출 한도 소진

   촉발

   18:50 UTC 에 분배 서비스의 PostgreSQL 데이터베이스에서 필드 타입을 바꾸는 배포를 내보냈다. 이 스키마 변경은 하위 호환되지 않았다.

   원인

   배포 결함

   구성 요소

   데이터베이스노드 풀

   기여 요인

   롤백 무효과도한 영향 범위자동 테스트 공백

   감지

   18:50 UTC 배포 직후 분배 실패와 관련된 오류와 알림이 바로 보였다.

   조치

   • 오류와 알림을 보고 곧바로 변경을 롤백했다. 롤백 뒤에는 두 배포 사이에 쓰인 데이터를 읽지 못해 분배가 계속 실패했다.
   • 분배 시스템이 그 필드를 무시하게 하는 수정을 빠르게 만들고 빌드해 직접 배포했다.
   • 몰려들 작업에 대비해 주 컴퓨트 클러스터를 직접 늘렸다. 이 수동 확장은 CircleCI 장애 대응 절차의 표준 단계다.
   • 작업 큐가 줄어 정상 처리가 이어지는 것을 잠시 지켜본 뒤 장애를 해결로 처리했다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 테스트 전략의 빈틈을 찾아 고친다.
   • 비슷한 배포가 시스템의 모든 작업에 영향을 주지 않도록, 분배 서비스가 예상하지 못한 데이터를 만났을 때의 동작을 바꾼다.
   • 예상하지 못한 장애가 났을 때 더 빨리 복구할 수 있게 한다.

   사례 보기

원인별1