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

사례2건

2건 중 1~2번째

  1. 증상

    2020-07-16 13:26 UTC 부터 Gandi LiveDNS 의 DNS 노드 두 대로 간 질의가 타임아웃으로 실패했다. 상태 페이지에는 13:26 에 FR 고객에게 영향이 있다는 글이 올라갔다.

    촉발

    LiveDNS 노드 두 대의 DNS 서버 소프트웨어에서 버그가 장애를 일으켜 서버가 멈췄다.

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

    DNS 서버에서 LiveDNS 모니터링 알림이 울렸다. 그러나 앞서 다루던 내부 네트워크 사고가 모니터링 시스템에 소음을 많이 만들고 있어 엔지니어들은 이 알림을 오탐으로 잘못 읽었고, 알림을 다시 판단하기까지 시간이 걸렸다.

    후속 조치
    • DNS 서버가 제대로 동작하지 않을 때 노드를 서비스에서 빼는 방식을 고친다.
    • 노드 설정을 고치고, 한 노드가 여러 클러스터의 주소를 알리지 않는지 확인하는 모니터링을 둔다.
    • 모니터링과 내부 교육, 조직 운영을 다시 짠다.
    • DNS 서버 소프트웨어의 버그를 찾아냈고, 고친 판을 배포하고 있다.
  2. 증상

    2016년 2월 8일 17:45 UTC 에 Google Cloud Platform 의 Redis Cloud 클러스터 us-central1-1-1.gce.garantiadata.com 에서 큰 장애가 났다. 데이터베이스 엔드포인트가 us-central1-1-1.gce.garantiadata.com 으로 끝나는 사용자들이 데이터베이스를 쓰지 못했다.

    촉발

    2016년 2월 8일 17:30 UTC 에 서비스 소프트웨어의 주간 업그레이드가 GCP 클러스터 us-central1-1-1.gce.garantiadata.com 에 처음 배포됐다.

    원인
    구성 요소
    기여 요인
    조치
    • 클러스터의 모든 노드를 내리고 종료했다.
    • 클러스터의 모든 엔드포인트를 클러스터의 DNS 영역에서 지웠다. DNS 제공자가 삭제 요청을 스로틀링해 남은 항목은 손으로 지웠다.
    • 주간 업데이트를 뺀 새 클러스터 노드를 처음부터 만들었다.
    • 원래 노드가 쓰던 저장소를 새 노드에 다시 붙여, 영속성이 있는 데이터베이스를 복구할 수 있게 했다.
    • 데이터베이스를 모두 띄웠고, 영속성이 있는 데이터베이스는 저장소에서 복구했다.
    후속 조치
    • 이번 같은 장애를 막는 절차를 갖출 때까지 자동 주간 업그레이드를 모두 멈춘다.
    • DevOps 코드 배포의 QA 절차를 다시 검증한다.
    • DNS 요청이 스로틀링될 때 도구가 이를 처리하도록 개선한다.
내 클러스터에도 있는지 확인하기

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

원인별2