Incident Library
  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례2건

2건 중 1~2번째

  1. 증상

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

    촉발

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

    원인
    구성 요소
    기여 요인
    감지

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

    조치
    • 2월 10일 압축 변경을 롤백해 더 번지지 않게 했다.
    • 최근 데이터를 클러스터의 쓰기를 모두 기록한 Kafka 로그에서 먼저 되살렸다.
    • 2월 17일 과거 데이터를 더 효율적으로 복원하도록 복원 절차를 고쳤다.
    • 과거 데이터를 TSM 스냅숏에서 복원했다.
    • 실시간 쓰기와 쿼리를 방해하지 않도록 클러스터를 켠 채로 조금씩 복원했다.
    후속 조치
    • 압축기처럼 중요한 스토리지 구성 요소를 바꾸는 변경의 테스트 범위를 넓히고, 운영 규모의 작업량을 더 잘 반영하는 테스트 시나리오를 더한다.
    • 압축 과정의 안전장치를 강화해 실패를 찾아내고 안전하게 처리하게 한다.
    • 대규모 복원 중에 TTBR 이 높아지거나 쿼리가 느려질 가능성을 줄이도록 복원 작업 흐름과 운영 절차를 검토한다.
    • 클러스터 전체 복원이 빨라지도록 백업과 복원 전략을 다시 본다.
  2. 증상

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

    촉발

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

    원인
    구성 요소
    기여 요인
    감지

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

    조치
    • 오류와 알림을 보고 곧바로 변경을 롤백했다. 롤백 뒤에는 두 배포 사이에 쓰인 데이터를 읽지 못해 분배가 계속 실패했다.
    • 분배 시스템이 그 필드를 무시하게 하는 수정을 빠르게 만들고 빌드해 직접 배포했다.
    • 몰려들 작업에 대비해 주 컴퓨트 클러스터를 직접 늘렸다. 이 수동 확장은 CircleCI 장애 대응 절차의 표준 단계다.
    • 작업 큐가 줄어 정상 처리가 이어지는 것을 잠시 지켜본 뒤 장애를 해결로 처리했다.
    후속 조치
    • 같은 장애가 다시 나지 않도록 테스트 전략의 빈틈을 찾아 고친다.
    • 비슷한 배포가 시스템의 모든 작업에 영향을 주지 않도록, 분배 서비스가 예상하지 못한 데이터를 만났을 때의 동작을 바꾼다.
    • 예상하지 못한 장애가 났을 때 더 빨리 복구할 수 있게 한다.
내 클러스터에도 있는지 확인하기

이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 백업과 스냅숏. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1