사례6건

6건 중 1~5번째

1. IL-0540 센터 사이를 잇는 라우터의 포트에서 큰 패킷이 유실돼 지방행정전산서비스와 정부24가 하루 넘게 멈췄다

   Korea Ministry of the Interior and Safety2023

   증상

   2023년 11월 17일 금요일 오전, 지방자치단체가 쓰는 지방행정전산서비스와 정부24가 멈췄다. 장애 당시 로그를 보면 통합인증서버의 네트워크 세션이 비정상 상태였다. 네트워크 장비인 L4 장비가 비정상 상태로 바뀌었다는 로그도 여러 번 반복해 남았다.

   서비스 중단패킷 손실지연 시간 증가

   원인

   하드웨어 고장

   구성 요소

   NIC·케이블·스위치 포트 링크

   기여 요인

   모니터링 사각지대그레이 실패

   조치

   • 11월 18일 04시에 정상 작동하지 않던 L4 장비를 고성능 장비로 바꾸고, 기능 테스트와 부하 테스트로 안정성을 확인한 뒤 오전 9시에 정부24 서비스를 다시 열었다.
   • 대전센터 라우터 중 광주센터와 연결된 포트의 불량을 찾아, 11월 19일 오전 7시에 다른 포트로 연결을 옮겨 지연을 없앴다.
   • 정부 서비스를 다시 연 다음 날 아침에 문제가 생긴 라우터의 모듈을 바꿔 끼웠다.

   후속 조치

   • 비슷한 포트 불량이 있을 수 있는 오래된 장비를 전수 점검한다.
   • 국민에게 장애 상황을 빨리 알리지 못한 문제를 풀기 위해 장애가 났을 때의 처리 매뉴얼을 보완한다.
   • 여러 수단을 써서 장애로 멈춘 서비스의 복구 상황을 빠르게 알린다.
   • 장애 징후를 빨리 잡도록 중요 서비스 시스템과 연관 장비를 함께 보는 통합 모니터링 체계를 만든다.
   • 상설 장애대응반을 꾸려 중요 장애에 투입해 문제를 일찍 해결한다.
   • 핵심 디지털정부 서비스가 멈춘 상황에서도 행정서비스를 제공할 수 있도록 행정조치 방안을 마련하고 대응 매뉴얼을 만든다.
   • 국가전산망 마비를 재난과 사고의 유형으로 명시해 예방부터 복구까지 체계적으로 관리한다.
   • 여러 정보시스템이 연계된 환경에 맞는 위기대응체계를 만들고, 이를 총괄하는 범정부 장애 예방·대응 컨트롤타워를 강화한다.
   • 공공정보화사업의 추진 절차와 사업관리체계를 고치고, 내용연수가 지나 잠재적 위험이 높은 하드웨어와 소프트웨어를 빨리 교체하며, 기술력 높은 기업이 참여할 수 있게 사업대가를 현실화한다.
   • 정보시스템 개발과 운영을 외주용역에 기대는 지금의 체계를 고치고, 디지털 분야의 우수한 인재가 정부에 들어오게 한다.
   • 국가정보자원관리원에 입주한 시스템의 이중화, 재복구 시스템, 네트워크 구성 같은 기술 구조를 전면 검토하고, 조직 진단으로 조직 구성과 인사 운영의 개선 방안을 마련한다.
   • 제조사와 협의해 장비 안의 부품 고장을 더 일찍 발견하고 모니터링하는 체계를 만든다.

   교훈

   라우터 장비의 기본 모니터링은 하고 있었고 전산실에서는 매일 눈으로도 점검했지만, 이번 문제는 모듈 안의 특수한 부분에서 생겨 미리 잡아내지 못했다. 이중화는 장비 하나가 완전히 작동하지 않을 때 다른 장비가 대신하는 구조여서, 모듈 일부만 고장 난 이번 경우에는 제대로 작동하지 않았다. 고장 난 포트가 전체 서비스에 영향을 주는 위치에 있어 파급이 컸다. 장애가 L4 장비의 OS 업데이트 바로 뒤에 나서 업데이트가 원인처럼 보였지만, OS 를 되돌린 뒤에도 같은 문제가 나서 원인이 아닌 것으로 드러났다.

   사례 보기
2. IL-0508 SourceHut 의 주 데이터베이스 서버 remilia.sr.ht 가 하드웨어 고장으로 연결이 끊겨 모든 서비스가 중단됐다

   SourceHut2023

   증상

   13:40 UTC 무렵 SourceHut 서비스 대부분을 사용할 수 없다는 경보가 한꺼번에 울렸다. 그 가운데 하나는 주 데이터베이스 서버인 물리 호스트 remilia.sr.ht 를 사용할 수 없다는 경보였다.

   서비스 중단

   촉발

   주 데이터베이스 서버 remilia.sr.ht 의 하드웨어가 고장 났다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스

   기여 요인

   단일 장애점디버그 접근 제한

   감지

   13:38 에 Prometheus 가 remilia 의 지표 수집에 실패했고, 13:40 무렵 대부분의 서비스와 remilia.sr.ht 를 사용할 수 없다는 경보가 울렸다.

   조치

   • 데이터센터 직원에게 연락이 닿지 않아 데이터센터 근처의 비상 연락 담당자를 불렀고, 담당자가 데이터센터로 출발했다.
   • 현장에 도착한 비상 연락 담당자가 데이터센터 직원의 진단을 확인한 뒤 디스크를 cirno1.sr.ht 와 바꿔 끼우고 서버를 띄웠다.

   후속 조치

   • 오프사이트 데이터베이스 백업이 장애 조치용 데이터베이스 호스트로도 쓰일 수 있게 고친다. 이 일은 이미 끝났다.
   • EU 이전 작업 전체의 우선순위를 다시 높인다.
   • 새 데이터베이스 장애 조치 구성을 만든다.
   • 빌드 용량을 메우려고 EU 에 새 빌드 워커를 둔다.
   • 앞으로를 대비해 하드웨어 목록을 더 꼼꼼히 기록한다.

   사례 보기
3. IL-0525 Equinix 암스테르담 전원 점검 중 업링크가 하나뿐인 스위치가 꺼져 OpenStreetMap.org 가 7시간 27분 멈춤

   OpenStreetMap Foundation2022

   증상

   2022년 6월 11일 20:18 UTC 부터 OpenStreetMap.org 에 접속할 수 없었다. Equinix 가 암스테르담 데이터센터 AM6 의 전원 A 계통 점검을 시작하고 18분 뒤였고, 암스테르담에 있는 www, API, wiki, planet 서비스가 모두 인터넷과 끊겼다.

   네트워크 도달 불가서비스 중단

   촉발

   2022년 6월 11일 20:00 UTC 에 Equinix 가 암스테르담의 OpenStreetMap 서버에 전원을 대는 전원 A 계통의 5년 주기 점검을 시작했다.

   원인

   하드웨어 고장

   구성 요소

   네트워크 스위치데이터센터 전력·냉각

   기여 요인

   단일 장애점디버그 접근 제한모니터링 사각지대

   조치

   • 운영 팀은 더블린으로 페일오버하거나 업링크를 Switch-2 로 옮기지 않고 Equinix 전원 점검 시간이 끝날 때까지 기다렸다. 장애는 6월 12일 03:45 UTC 에 끝났다.

   후속 조치

   • 진행 중인 장애를 알리는 데 걸리는 시간을 줄인다. 장애 알림은 https://twitter.com/OSM_Tech 로 낸다.
   • 스위치의 PSU 와 팬 상태를 모니터링하고 알림을 건다.
   • Cisco SG550X-48 스위치 Switch-1, Switch-2 와 Cisco Redundant Power System 을 이중 전원을 갖춘 Juniper EX4300 스위치로 바꾼다. 부품 공급 부족으로 설치가 늦어졌고, 2022년 7월 19일 기준 모든 부품이 현장에 도착해 설치를 기다린다.
   • 이중 전원을 받는 대역 외 접속 장비인 4G 모뎀 시리얼 콘솔 서버를 암스테르담에 둔다. 2022년 6월 20~22일 현장 방문 때 설치를 마쳤다.
   • 이중 업링크를 설치한다. 2022년 7월 19일 기준 아직 설치되지 않아 운영 팀이 계속 챙기고 있다.
   • 지금은 실수하기 쉬운 수동 절차인 사이트 페일오버를 더 쉽고, 손이 덜 가고, 덜 위험하게 만든다.
   • 운영 SRE 를 위한 당번 호출 시스템을 들인다. 2022년 7월 19일 기준 업체와 협상 중이다.
   • 한 사람이 24시간 내내 당번을 설 수 없으므로 장기적으로 SRE 팀을 늘린다.
   • 전원, 네트워크, 상위 링크, 서비스 장애에 대비한 장비 페일오버 시험을 계속하고 정식 절차로 만든다.

   사례 보기
4. IL-0370 Frankfurt 에서 노드 하드웨어 장애 뒤 Render Postgres 데이터베이스가 다른 노드에서 시작하지 못해 최대 1시간 5분 멈췄다

   Render2022

   증상

   Frankfurt 의 한 노드에 있던 사용자 Postgres 데이터베이스가 모두 완전히 멈췄다. Render 는 Frankfurt 의 Postgres 데이터베이스 가용성 문제 보고를 받았다.

   서비스 중단스토리지 연결 끊김

   촉발

   외부 클라우드 제공자가 준 노드에 하드웨어 문제가 생겨 2022년 5월 23일 08:30 AM UTC 에 상태 검사에 실패했다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스클라우드 블록 스토리지

   기여 요인

   단일 장애점

   감지

   데이터베이스가 시작 도중 한 상태에서 15분 이상 넘어가지 못하면 울리는 알림이 08:57 AM UTC 에 당번 엔지니어를 자동으로 호출했다. 장애가 시작되고 27분 뒤였다.

   조치

   • 엔지니어가 09:27 AM UTC 쯤 문제의 노드를 손으로 종료했다. 그러자 디스크가 건강한 노드에 붙었고, 09:35 AM UTC 에 모든 데이터베이스 인스턴스가 돌아왔다.

   후속 조치

   • 당번 엔지니어를 더 일찍 호출하는 알림을 만든다.
   • 알맞은 조치를 더 빨리 찾을 수 있게 하고, 결국 그 조치를 자동화해 복구 시간을 줄인다.
   • 장애 절차를 검토해 상태 페이지가 실제 가용성을 최대한 정확하게 보여 주게 한다.
   • Postgres 고가용성 기능을 만든다. 2022년 4분기쯤 나올 예정이고, 이 기능을 켠 사용자는 프라이머리가 있는 노드에 하드웨어 문제가 나도 장애 시간이 아주 짧아진다.

   교훈

   Render 는 하드웨어 문제가 드물지만 언젠가는 일어나는 일이라고 봤다. 그래서 대책을 탐지를 앞당기고 복구 시간을 줄이는 데 맞췄다.

   사례 보기
5. IL-0289 updown.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 을 커뮤니티 에디션에도 제공하자 이를 켜서 한동안 시험했다. 잘 동작해 직접 만든 스크립트는 지웠다.

   사례 보기

원인별1