Incident Library

IL-0289 updown.io · 2019-04-03database

updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답해 사이트와 모니터링 데몬이 거의 멈췄는데 자동 페일오버가 일어나지 않았다

2019년 4월 3일 2:30 am CEST 에 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답하기 시작해 웹사이트와 모니터링 데몬이 거의 다 멈췄다. 하트비트 검사는 계속 빠르게 답했기 때문에 MongoDB 의 자동 페일오버가 문제를 보지 못했고, 대기 중인 보조 서버가 주 서버로 선출되지 않았다. 운영자는 자고 있다가 8:45 에야 문제를 알았다. 운영자는 주 서버의 I/O 문제를 확인하고 보조 서버가 넘겨받을 준비가 됐는지 본 뒤 주 서버를 강제로 step down 시켰다. 8:56 에 플랫폼 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다. 원인은 RAID5 로 묶은 SSD 3개 가운데 하나였고, 이 디스크를 어레이에서 빼자 서버 성능이 원래대로 돌아왔다.

그 뒤 며칠 동안 보조 서버가 주 서버 역할을 하면서 장애가 더 이어졌다. 4월 4일 3:56 am 에는 매일 도는 clamscan 백신 검사와 MongoDB 가 메모리를 다 써, 커널의 OOM Killer 가 MongoDB 를 죽였다. 운영자는 8:40 에 MongoDB 를 재시작하고 스왑 공간을 더했다. 4월 5일 3:56 부터 5:30 까지는 clamscan 이 다시 MongoDB 를 느리게 했다. DNS 자동 페일오버가 이 서버를 죽은 것으로 보고 트래픽을 꺼져 있던 주 서버로 돌려, 일부 사용자가 연결 오류를 겪었을 수 있었다. 운영자는 clamscan 과 DNS 페일오버를 껐고, 4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿔 응답 시간을 되돌렸다.

호스팅 업체가 4월 6일 밤 SSD 를 바꿨지만, 같은 날 밤 다른 SSD 하나가 같은 방식으로 죽어 운영자는 다시 교체를 요청했다. 두 디스크 모두 정격 내구 수명을 한참 넘긴 것으로 보였다. 두 번째 SSD 는 4월 16일에 교체됐고, 관찰 기간을 거쳐 4월 22일에 원래 서버를 다시 주 서버로 돌렸다. 운영자는 MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만들었다. 2019년 11월 6일 세 번째 SSD 가 죽었을 때 이 스크립트 덕분에 중단 시간이 10분 아래로 줄었다.

심각도
–
영향 범위
The updown.io website and monitoring daemons were almost fully down from 2:30 am to 8:56 am CEST, then ran with lower performance on the less powerful secondary
영향 사용자
–
지역
–
감지까지
6h 15m
복구까지
6h 26m

증상

2019년 4월 3일 2:30 am CEST 부터 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답했다. 웹사이트와 모니터링 데몬이 거의 전부 멈췄다.

MongoDB 의 하트비트 검사는 계속 빠르게 응답했다. 그래서 대기 중인 보조 서버가 있었는데도 자동 페일오버가 문제를 감지하지 못했고 보조 서버가 주 서버로 선출되지 않았다.

주 서버를 살펴보니 디스크 I/O 성능에 문제가 있었다. atop 출력에서 디스크 3개의 사용률을 뜻하는 busy 와 평균 지연을 뜻하는 avgio 를 보니, RAID5 로 묶은 SSD 3개 가운데 하나가 원인이었다.

증상 지연 시간 증가서비스 중단장애 조치 실패

원인

원인 하드웨어 고장

구성 요소 데이터베이스데이터베이스 장애 조치 관리자
기여 요인 –
촉발
주 MongoDB 서버의 RAID5 를 이루는 SSD 3개 가운데 하나가 고장 나기 시작해 디스크 I/O 가 크게 느려졌다.

감지

MongoDB 의 자동 페일오버는 하트비트가 계속 빠르게 응답해 문제를 감지하지 못했다. 운영자는 자고 있다가 8:45 am CEST 에야 문제를 알아챘다.

조치

후속 조치

교훈

–

출처

참고 문서

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 데이터베이스 장애 조치 관리자. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.