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

사례3건

3건 중 1~3번째

  1. 증상

    2024년 11월 30일 00:17 UTC 부터 Wasabi 의 모든 스토리지 리전에서 Wasabi Cloud Storage 와 Web Console 로 가는 클라이언트 연결 시도가 실패했고, 모든 API 호출이 HTTP 5XX 오류로 끝났다. 상태 페이지에는 00:20 UTC 에 전 리전의 네트워크 오류를 조사하고 있으며 Console 과 S3 서비스 접속이 오류를 낼 수 있다는 글이 올라왔다.

    원인
    구성 요소
    기여 요인
    –
    조치
    • 엔지니어링팀과 운영팀이 내부 서버가 여러 데이터베이스 인스턴스로 요청을 나눠 보내도록 직접 설정해 서비스를 되살렸다.
    • 서비스가 돌아온 뒤 내부 메시징 큐를 복구하고 클라이언트 요청을 제대로 처리하는 자동 작업을 다시 돌려 근본 원인을 바로잡는 작업을 했다.
  2. 증상

    2017년 1월 24일 17:53 UTC 부터 Stack Exchange 네트워크가 약 5분 동안 읽기 전용으로 동작했다. 그 뒤 Stack Overflow 를 포함한 사이트 전체가 12분 동안 내려갔다.

    촉발

    주 SQL Server 인 NY-SQL02 에서 SQL Server 프로세스가 bugcheck 를 일으켰다.

    원인
    구성 요소
    기여 요인
    조치
    • NY-SQL02 의 SQL 서비스를 재시작해 네트워크를 읽기 전용으로 되살렸다.
    • SQL 상태를 점검한 뒤 사이트를 읽기·쓰기 모드로 되돌렸다.
    • 메모리가 384GB 라서 메모리 덤프가 끝나기를 기다리지 않고 네트워크를 먼저 살렸다.
    • NY-SQL02 를 운영에서 빼 메모리 시험을 포함한 점검에 들어갔다. 평소 부하는 모두 NY-SQL01 이 받게 했다.
    • 이 기회에 SQL 클러스터를 2016 SP1 CU1 로 올렸다.
  3. 증상

    2014년 7월 19일 토요일 오전 9시 30분 프로그램과 클립 메타데이터를 내주는 시스템의 데이터베이스 부하가 치솟아, 애플리케이션 서버로 가는 메타데이터 요청이 많이 실패하기 시작했다. BBC iPlayer, BBC iPlayer Radio, bbc.co.uk 다른 곳의 오디오·비디오 재생이 영향을 받았다.

    원인
    구성 요소
    기여 요인
    조치
    • 가장 먼저 실패한 캐시 계층을 복구했다.
    • 캐시 계층 실패가 되풀이되는 동안 홈페이지를 비상 모드로 여러 번 바꿨고, 캐시가 완전히 안정됐다고 확신할 때까지 비상 페이지를 띄워 뒀다.
    • 메타데이터 시스템의 성능이 계속 나빠 토요일 오후부터 저녁까지 큰 복구 작업을 했다. 그동안 BBC iPlayer 는 사실상 쓸 수 없었다.
    • 주말 남은 기간은 사이트 대부분이 거의 정상으로 도는 상태로 운영했다. 일요일 저녁 피크 시간에 서비스를 더 위험하게 하지 않으려고 완전 복구는 월요일 아침으로 미뤄 진행했다.
    후속 조치
    • 근본 원인을 완전히 이해했는지 확인하는 조사를 마치고, 이런 중단이 다시 일어날 가능성을 줄이는 조치를 넣는다.
내 클러스터에도 있는지 확인하기

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

원인별1