그래프
사례3건
3건 중 1~3번째
- 증상
2023년 11월 17일 금요일 오전, 지방자치단체가 쓰는 지방행정전산서비스와 정부24가 멈췄다. 장애 당시 로그를 보면 통합인증서버의 네트워크 세션이 비정상 상태였다. 네트워크 장비인 L4 장비가 비정상 상태로 바뀌었다는 로그도 여러 번 반복해 남았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 11월 18일 04시에 정상 작동하지 않던 L4 장비를 고성능 장비로 바꾸고, 기능 테스트와 부하 테스트로 안정성을 확인한 뒤 오전 9시에 정부24 서비스를 다시 열었다.
- 대전센터 라우터 중 광주센터와 연결된 포트의 불량을 찾아, 11월 19일 오전 7시에 다른 포트로 연결을 옮겨 지연을 없앴다.
- 정부 서비스를 다시 연 다음 날 아침에 문제가 생긴 라우터의 모듈을 바꿔 끼웠다.
- 후속 조치
- 비슷한 포트 불량이 있을 수 있는 오래된 장비를 전수 점검한다.
- 국민에게 장애 상황을 빨리 알리지 못한 문제를 풀기 위해 장애가 났을 때의 처리 매뉴얼을 보완한다.
- 여러 수단을 써서 장애로 멈춘 서비스의 복구 상황을 빠르게 알린다.
- 장애 징후를 빨리 잡도록 중요 서비스 시스템과 연관 장비를 함께 보는 통합 모니터링 체계를 만든다.
- 상설 장애대응반을 꾸려 중요 장애에 투입해 문제를 일찍 해결한다.
- 핵심 디지털정부 서비스가 멈춘 상황에서도 행정서비스를 제공할 수 있도록 행정조치 방안을 마련하고 대응 매뉴얼을 만든다.
- 국가전산망 마비를 재난과 사고의 유형으로 명시해 예방부터 복구까지 체계적으로 관리한다.
- 여러 정보시스템이 연계된 환경에 맞는 위기대응체계를 만들고, 이를 총괄하는 범정부 장애 예방·대응 컨트롤타워를 강화한다.
- 공공정보화사업의 추진 절차와 사업관리체계를 고치고, 내용연수가 지나 잠재적 위험이 높은 하드웨어와 소프트웨어를 빨리 교체하며, 기술력 높은 기업이 참여할 수 있게 사업대가를 현실화한다.
- 정보시스템 개발과 운영을 외주용역에 기대는 지금의 체계를 고치고, 디지털 분야의 우수한 인재가 정부에 들어오게 한다.
- 국가정보자원관리원에 입주한 시스템의 이중화, 재복구 시스템, 네트워크 구성 같은 기술 구조를 전면 검토하고, 조직 진단으로 조직 구성과 인사 운영의 개선 방안을 마련한다.
- 제조사와 협의해 장비 안의 부품 고장을 더 일찍 발견하고 모니터링하는 체계를 만든다.
- 교훈
라우터 장비의 기본 모니터링은 하고 있었고 전산실에서는 매일 눈으로도 점검했지만, 이번 문제는 모듈 안의 특수한 부분에서 생겨 미리 잡아내지 못했다. 이중화는 장비 하나가 완전히 작동하지 않을 때 다른 장비가 대신하는 구조여서, 모듈 일부만 고장 난 이번 경우에는 제대로 작동하지 않았다. 고장 난 포트가 전체 서비스에 영향을 주는 위치에 있어 파급이 컸다. 장애가 L4 장비의 OS 업데이트 바로 뒤에 나서 업데이트가 원인처럼 보였지만, OS 를 되돌린 뒤에도 같은 문제가 나서 원인이 아닌 것으로 드러났다.
- 증상
s3 의 주 데이터베이스 마스터 db1075 가 응답하지 않아 s3 의 모든 위키가 쓰기를 받지 못하고 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 정상이었다. Icinga 가 IRC 에 HOST DOWN 을 알렸고 사용자들이 #wikimedia-operations 에 문제를 알렸다.
- 촉발
db1075 의 RAID 백업 배터리인 BBU 가 고장 나면서 호스트가 완전히 멈췄다.
- 원인
- 구성 요소
- 기여 요인
- 감지
db1075 의 HOST DOWN 이 보고되면서 문제가 분명해졌다. 하지만 HOST DOWN 알림은 IRC 로만 가고 호출을 보내지 않았다. 알림은 IRC 와 호출로 보내졌고, 첫 SMS 호출은 18:56 UTC 에 나갔다. 사용자들도 #wikimedia-operations 에 문제를 알렸고, 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다.
- 조치
- BBU 문제이고 호스트가 응답하지 않는 것을 확인한 뒤 19:02 UTC 에 idrac 으로 호스트를 재부팅했다.
- MySQL 이 19:03 에 InnoDB 복구를 시작해 19:06 에 마쳤다.
- 19:07 에 db1075 의 read_only=ON 을 직접 풀었다.
- 19:16 에 puppet 을 다시 직접 돌려 성공했고, pt-heartbeat 가 시작되면서 장애가 끝났다.
- 후속 조치
- 마스터를 쓸 수 없을 때 레플리카를 옮기는 스크립트를 만들거나 고친다. 이번에는 필요하지 않았지만 앞으로의 장애에서는 필요할 수 있다.
- MediaWiki 의 heartbeat 방식을 고친다. pt-heartbeat 가 슈퍼유저를 쓰지 않게 하고, 단일 장애점을 없애고, puppet 없이 실제 마스터로 자동 전환되게 한다.
- 이미 BBU 문제를 겪은 같은 배치의 호스트들을 어떻게 할지 정한다.
- db1075 에 쓸 새 BBU 를 산다.
- db1075 를 마스터에서 뺀다.
- 읽기 전용이거나 마스터를 쓸 수 없는 동안 MediaWiki 가 쏟아내는 스팸을 해결한다.
- 주 데이터베이스 마스터가 HOST DOWN 일 때 호출이 가게 한다.
- Netbox 에서 하드웨어 오류를 더 잘 추적한다.
- 교훈
BBU 고장이 호스트 전체를 멈추게 해서는 안 됐지만 HP 호스트에서는 전에도 그런 일이 있었다. puppet 으로 띄우는 pt-heartbeat 와 아직 다 뜨지 않은 MySQL 사이의 경합으로 수동 puppet 실행이 실패했는데 아무도 알아채지 못했다. 그 때문에 모든 것이 올라온 뒤에도 복제 지연이 보고돼 장애가 8분 더 길어졌다. 알림은 잘 동작했고 idrac 으로 재부팅한 것도 통했다. 호스트가 깨끗하게 돌아오지 않았다면 새 레플리카를 마스터로 올리는 장애 조치를 손으로 해야 했다.
IL-0289updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답해 사이트와 모니터링 데몬이 거의 멈췄는데 자동 페일오버가 일어나지 않았다updown.io2019- 증상
2019년 4월 3일 2:30 am CEST 부터 updown.io 의 주 MongoDB 서버가 쿼리에 평소보다 약 200배 느리게 응답했다. 웹사이트와 모니터링 데몬이 거의 전부 멈췄다.
- 촉발
주 MongoDB 서버의 RAID5 를 이루는 SSD 3개 가운데 하나가 고장 나기 시작해 디스크 I/O 가 크게 느려졌다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
MongoDB 의 자동 페일오버는 하트비트가 계속 빠르게 응답해 문제를 감지하지 못했다. 운영자는 자고 있다가 8:45 am CEST 에야 문제를 알아챘다.
- 조치
- 보조 서버가 넘겨받을 준비가 됐는지 확인한 뒤 주 서버를 강제로 step down 시켰다. 8:56 am CEST 에 웹과 데몬 전체가 돌아왔지만, 보조 서버의 사양이 낮아 성능은 떨어졌다.
- I/O 문제를 일으킨 SSD 를 RAID 어레이에서 빼자 서버가 원래 성능으로 돌아왔다.
- 호스팅 업체에 SSD 교체 일정을 잡는 티켓을 열었다.
- 4월 6일 12:48 pm 에 보조 서버를 더 높은 사양의 서버로 바꿨고, 그 뒤 응답 시간이 정상으로 돌아왔다.
- 후속 조치
- MongoDB 팀이 이 문제를 곧 고칠 것 같지 않아, MongoDB 가 살아 있지만 응답하지 않는 상황을 찾아 자동으로 step down 시키는 스크립트를 만든다.
- 더 조사할 것이 없다고 확인되면 옛 보조 서버를 내리고 지운다.
- 새 보조 서버가 며칠 동안 주 서버 역할을 버틸 수 있는지, clamscan 이 도는 밤까지 포함해 확인한다.
- 주 서버가 정상으로 돌아오면 자동 step down 스크립트를 시험한다.
- updown.io 의 제대로 된 상태 페이지를 만든다.
- MongoDB 가 Storage Node Watchdog 을 커뮤니티 에디션에도 제공하자 이를 켜서 한동안 시험했다. 잘 동작해 직접 만든 스크립트는 지웠다.
이 3건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 복제. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.