그래프
사례2건
2건 중 1~2번째
- 증상
2023년 11월 17일 금요일 오전, 지방자치단체가 쓰는 지방행정전산서비스와 정부24가 멈췄다. 장애 당시 로그를 보면 통합인증서버의 네트워크 세션이 비정상 상태였다. 네트워크 장비인 L4 장비가 비정상 상태로 바뀌었다는 로그도 여러 번 반복해 남았다.
- 원인
- 구성 요소
- 기여 요인
- 조치
- 11월 18일 04시에 정상 작동하지 않던 L4 장비를 고성능 장비로 바꾸고, 기능 테스트와 부하 테스트로 안정성을 확인한 뒤 오전 9시에 정부24 서비스를 다시 열었다.
- 대전센터 라우터 중 광주센터와 연결된 포트의 불량을 찾아, 11월 19일 오전 7시에 다른 포트로 연결을 옮겨 지연을 없앴다.
- 정부 서비스를 다시 연 다음 날 아침에 문제가 생긴 라우터의 모듈을 바꿔 끼웠다.
- 후속 조치
- 비슷한 포트 불량이 있을 수 있는 오래된 장비를 전수 점검한다.
- 국민에게 장애 상황을 빨리 알리지 못한 문제를 풀기 위해 장애가 났을 때의 처리 매뉴얼을 보완한다.
- 여러 수단을 써서 장애로 멈춘 서비스의 복구 상황을 빠르게 알린다.
- 장애 징후를 빨리 잡도록 중요 서비스 시스템과 연관 장비를 함께 보는 통합 모니터링 체계를 만든다.
- 상설 장애대응반을 꾸려 중요 장애에 투입해 문제를 일찍 해결한다.
- 핵심 디지털정부 서비스가 멈춘 상황에서도 행정서비스를 제공할 수 있도록 행정조치 방안을 마련하고 대응 매뉴얼을 만든다.
- 국가전산망 마비를 재난과 사고의 유형으로 명시해 예방부터 복구까지 체계적으로 관리한다.
- 여러 정보시스템이 연계된 환경에 맞는 위기대응체계를 만들고, 이를 총괄하는 범정부 장애 예방·대응 컨트롤타워를 강화한다.
- 공공정보화사업의 추진 절차와 사업관리체계를 고치고, 내용연수가 지나 잠재적 위험이 높은 하드웨어와 소프트웨어를 빨리 교체하며, 기술력 높은 기업이 참여할 수 있게 사업대가를 현실화한다.
- 정보시스템 개발과 운영을 외주용역에 기대는 지금의 체계를 고치고, 디지털 분야의 우수한 인재가 정부에 들어오게 한다.
- 국가정보자원관리원에 입주한 시스템의 이중화, 재복구 시스템, 네트워크 구성 같은 기술 구조를 전면 검토하고, 조직 진단으로 조직 구성과 인사 운영의 개선 방안을 마련한다.
- 제조사와 협의해 장비 안의 부품 고장을 더 일찍 발견하고 모니터링하는 체계를 만든다.
- 교훈
라우터 장비의 기본 모니터링은 하고 있었고 전산실에서는 매일 눈으로도 점검했지만, 이번 문제는 모듈 안의 특수한 부분에서 생겨 미리 잡아내지 못했다. 이중화는 장비 하나가 완전히 작동하지 않을 때 다른 장비가 대신하는 구조여서, 모듈 일부만 고장 난 이번 경우에는 제대로 작동하지 않았다. 고장 난 포트가 전체 서비스에 영향을 주는 위치에 있어 파급이 컸다. 장애가 L4 장비의 OS 업데이트 바로 뒤에 나서 업데이트가 원인처럼 보였지만, OS 를 되돌린 뒤에도 같은 문제가 나서 원인이 아닌 것으로 드러났다.
- 증상
14:43 UTC 에 네트워크 스위치 하나가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 장애 동안 API 쿼리 성공률이 한때 75%까지 떨어졌고, 대시보드는 평소보다 최대 80배 느려졌다.
- 촉발
14:43 UTC 에 제어 플레인 데이터 센터의 네트워크 스위치 하나가 일부만 동작하는 상태에 빠졌다. LACP 와 BGP 는 계속 돌았지만 받은 패킷 일부를 전달하지 못했고, 스위치는 6분 뒤 스스로 회복했다.
- 원인
- 구성 요소
- 기여 요인
- 감지
14:43 UTC 에 스위치가 ping 에 응답하지 않는다는 알림이 울리기 시작했다. 그 뒤 엔지니어들이 주 인증 데이터베이스가 과부하에 걸린 것을 확인했다.
- 조치
- SSL 인증서를 엣지로 보내는 속도와 메일 발송 같은 기능을 줄여 주 인증 데이터베이스가 늘어난 부하를 감당할 여유를 만들었다.
- 읽기 복제본으로 처리할 수 있는 API 트래픽을 손으로 보조 데이터 센터로 돌렸다. API 가용성이 크게 나아졌다.
- 대시보드 사용자의 불편이 커지자 인증 호출을 모두 주 데이터 센터로 되돌렸고, 성능이 떨어진 상태에서도 최대한 버티도록 주 데이터베이스를 계속 손봤다.
- 21:20 UTC 에 첫 데이터베이스 복제본이 다시 만들어지자마자 자동으로 서비스에 투입됐고, 성능이 정상으로 돌아왔다.
- 줄였던 서비스를 모두 다시 올려 밀린 비동기 처리가 따라잡게 했고, 한동안 지켜본 뒤 장애 종료를 선언했다.
- 후속 조치
- 새 primary 를 승격하면 데이터베이스 복제본을 모두 다시 만들어야 하는 클러스터 관리 시스템의 제약을 고친다. Cloudflare 는 글을 쓸 무렵 이 결함을 이미 고쳤다고 밝혔다.
- 트래픽을 다른 데이터 센터로 돌려야 할 때 유연하게 대응하지 못하는 사용자 세션 시스템을 다시 설계한다.
- 자동 복구 조치의 설정 값을 다시 검토한다. 적어도 데이터베이스 하나에서는 복제본을 primary 로 승격하는 절차를 그렇게 빨리 시작하지 않도록 장애 직후 설정을 바꿨다.
- 이 장애에 얽힌 시스템마다 자기가 의존하는 시스템의 고장을 더 잘 견디도록 계속 조정한다.
- 교훈
모든 시스템에 이중화가 있었지만, 고장 난 시스템들은 완전히 멈추지 않고 성능이 떨어진 채로 동작했다. 그래서 뒤이어 일어난 일들을 미리 모델링하고 예상하기가 훨씬 어려웠다. 1분 만에 복제본을 승격하는 자동 조치는 Cloudflare 가 자랑하던 기능이었지만, 적어도 데이터베이스 하나에서는 그 조치가 원래 문제보다 더 큰 피해를 낼 수 있었다. 대부분의 범용 클러스터 관리 시스템은 비잔틴 장애를 견디는 프로토콜을 쓰지 않고 RAFT 처럼 단순한 프로토콜을 쓴다. 드문 장애 유형에 약하다고 알려진 단순한 프로토콜이 구현과 디버깅이 어려운 복잡한 프로토콜보다 안전한 경우가 많다고 Cloudflare 는 보았다.
이 2건에서 가장 많이 나오는 구성 요소: NIC·케이블·스위치 포트 링크, 코디네이션 키-값 저장소. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.
원인별2
하드웨어 고장1건
- 구성 요소