사례4건

4건 중 1~4번째

1. IL-0348 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 끊기고 여러 제품이 오래 불안정했다

   Scaleway2025

   증상

   2025-03-10 16:23 UTC 무렵 FR-PAR 리전의 모든 제품에서 공용 인터넷 연결이 크게 흔들렸다. 인터넷 트래픽 대부분이 사실상 버려졌고, FR-PAR-2 가용 영역과 나머지 PAR 리전 사이의 공용 인터넷 연결이 심하게 끊겼다.

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

   촉발

   Scaleway 네트워크 팀이 FR-PAR 리전 백본에 새 데이터 센터를 붙이던 중 라우터 구성을 잘못 넣었다. 이 실수로 OpCore DC3 와 DC5 사이의 1Tbps 넘는 트래픽이 100Gbps 링크 하나로 돌아갔다.

   원인

   운영 실수

   구성 요소

   백본망오브젝트 스토리지DNS 서버와 레코드

   기여 요인

   자동화 증폭

   감지

   라우터 구성 실수는 빨리 발견되어 4분 안에 롤백됐다.

   조치

   • 잘못 넣은 라우터 구성을 4분 안에 롤백해 16:27 UTC 에 올바른 구성을 되돌렸다.

   후속 조치

   • 변경 관리를 고쳐 동료 검토와 운영 공지 절차를 강화한다.
   • 백본 수준의 네트워크 구성을 적용하기 전에 안전장치와 시험을 더 거치도록 운영 절차를 고친다.
   • Object Storage 동기화 소프트웨어의 문제를 찾아 수정을 만들고 시험했으며, 이 수정을 배포하고 있다.

   사례 보기
2. IL-0228 라우터 설정 변경 중 인터넷 전체 라우팅 테이블이 IGP 로 광고돼 OVHcloud 전 세계 네트워크의 IPv4 라우팅이 멈췄다.

   OVHcloud2021

   증상

   2021-10-13 09:20 CET 에 네트워크 설정을 바꾸던 중 문제가 생겼고, 09:21 CET 에 팀이 라우터 성능 문제를 감지해 곧바로 에스컬레이션했다. IPv6 트래픽은 계속 정상으로 오갔다.

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

   촉발

   늘어나는 DDoS 공격에 맞서 방어 설정을 강화하려고 미국 Vint Hill 데이터 센터의 라우터에 계획된 변경을 하던 중이었다. 이때 라우터가 BGP 경로를 OSPF 로 재분배하는 설정을 조절하려던 명령을 제대로 해석하지 못했다.

   원인

   설정 변경

   구성 요소

   내부 라우팅BGP 라우팅백본망

   기여 요인

   롤백 무효과도한 영향 범위

   감지

   변경 작업 중이던 09:21 CET 에 팀이 라우터 성능 문제를 감지하고 곧바로 에스컬레이션 절차를 시작했다.

   조치

   • 연결을 격리해 서비스를 최대한 빨리 되살리려고, 10:02 CET 에 데이터 센터 기술자에게 광 장비 연결을 먼저 끊어 달라고 요청했다.
   • 10:10 CET 에 고장 라우터의 전원을 끄기로 했고, 10:18 CET 에 장비를 껐다. 네트워크가 수렴하는 데 2분이 걸렸고 10:20 CET 에 첫 서비스가 돌아왔다.
   • 10:30 CET 부터 남은 서비스를 모두 되살리려고 연결 안정화 작업을 시작했다. 10:57 CET 에 기술적으로 위기가 끝났다.

   후속 조치

   • 명령줄을 그대로 적용하는 이 종류의 장비에서 변경 절차를 다시 평가한다.
   • 평가 결과에 맞춰 관련 변경 절차를 강화한다.

   사례 보기
3. IL-0221 유지보수 명령이 Facebook 백본 네트워크의 연결을 모두 끊어 데이터 센터와 DNS 서버가 인터넷에서 닿지 않게 됐다.

   Meta2021

   증상

   Facebook 데이터 센터 사이의 서버 연결과 데이터 센터와 인터넷 사이의 서버 연결이 한꺼번에 완전히 끊겼다. DNS 서버는 동작하고 있었지만 인터넷에서 닿지 않아 누구도 Facebook 서버를 찾을 수 없었다. 백본이 통째로 빠지자 DNS 서버가 있는 작은 시설들이 스스로 비정상이라고 판단해 BGP 광고를 거둬들였기 때문이다.

   서비스 중단DNS 조회 실패네트워크 도달 불가

   촉발

   일상적인 유지보수 작업 중에 전 세계 백본 용량의 가용성을 평가하려고 내린 명령이 의도치 않게 백본 네트워크의 모든 연결을 끊었다. 이런 명령을 검사해 실수를 막는 감사 도구가 버그 때문에 이 명령을 멈추지 못했다.

   원인

   운영 실수

   구성 요소

   백본망BGP 라우팅DNS 서버와 레코드

   기여 요인

   자동화 증폭순환 의존디버그 접근 제한

   조치

   • 주 네트워크 접근과 out-of-band 접근이 모두 끊겨, 팀은 엔지니어를 데이터 센터 현장에 보내 문제를 디버깅하고 시스템을 다시 시작하게 했다.
   • 보안 접근 절차를 거쳐 현장 인력이 서버를 다룰 수 있게 된 뒤 문제를 확인하고 백본을 다시 온라인으로 올렸다.
   • storm 훈련에서 얻은 경험을 살려 서비스를 다시 켜면서 늘어나는 부하를 조심스럽게 관리했다.

   후속 조치

   • 전 세계 백본이 끊기는 상황을 storm 훈련으로 시뮬레이션할 방법을 찾는다.
   • 테스트와 훈련, 전반적인 복원력을 강화해 이런 사고가 최대한 드물게 일어나게 한다.

   교훈

   무단 접근을 막으려고 강화한 보안이, 공격이 아니라 스스로 낸 실수에서 비롯된 장애의 복구를 늦췄다. Meta 는 드문 사고에서 복구가 느려지더라도 평소의 보안을 크게 높이는 편이 낫다고 봤다. 서비스, 데이터 센터, 리전 전체를 내리는 storm 훈련이 부하를 다시 올리는 데 도움이 됐지만, 전 세계 백본이 끊기는 상황은 훈련해 본 적이 없었다.

   사례 보기
4. IL-0256 하드웨어 로드 밸런서가 거듭 죽고 대기 장비로 넘어간 뒤 라우터가 동기화하지 못해 Basecamp 전체가 이틀 연속 열리지 않았다

   37signals2020

   증상

   2020년 9월 1일 화요일 Central Time 9:51am 부터 10:08am 까지, UTC 로는 14:51–15:08 의 17분 동안 Basecamp 가 아예 열리지 않았다. 아무것도 동작하지 않는 것처럼 보였고, 다시 열린 뒤에는 모든 것이 정상으로 보였다.

   서비스 중단링크 플래핑지연 시간 증가

   촉발

   2020년 9월 1일 데이터센터 사이 네트워크 회선이 끊긴 것을 복구하는 도중 하드웨어 로드 밸런서 하나가 죽었다. 9월 2일에는 Virginia 데이터센터의 주 로드 밸런서와 보조 로드 밸런서가 차례로 죽었다.

   원인

   소프트웨어 결함

   구성 요소

   온프레미스 로드 밸런서백본망

   기여 요인

   장애 중첩여유 용량 부재

   조치

   • 9월 1일 라우터가 새 로드 밸런서와 자동으로 동기화하지 못하자 손으로 개입해 바로잡았다.
   • 9월 2일 라우터가 동기화하지 못하는 같은 문제가 다시 나자 이번에도 손으로 개입해 고쳤다.

   후속 조치

   • 로드 밸런서 공급사와 함께 장애 원인을 끝까지 밝히고, 1차 평가에서 나온 버그 수정을 적용한다.
   • 하드웨어 로드 밸런서를 교체한다.
   • 데이터센터 사이 이중 네트워크 경로를 다시 깔아 회선이 실제로 다른 경로를 지나게 하고, 네트워크 공급사 사이의 숨은 의존을 없앤다.
   • 비상 대책으로 하드웨어 로드 밸런서에서 소프트웨어 로드 밸런서로 옮기는 것을 검토한다. 하드웨어는 교체에 며칠이 걸리지만 소프트웨어는 몇 분이면 배포할 수 있다.
   • 비상 대책으로 로드 밸런서 구성을 분산해 장애 하나의 영향을 줄이는 것을 검토한다.
   • 시스템의 복원력, 취약함, 위험을 평가하고 평가 과정 자체도 검토한다.

   교훈

   Basecamp 는 여러 겹의 이중화와 복원력을 갖추고 운영 시스템에서 큰 장애 대응을 연습해 왔지만 이번 사고들은 잡지 못했다. 모든 사고를 잡을 수는 없지만, 연쇄 장애가 예상하지 못한 취약함과 어려운 복구 경로를 드러내는 일에는 대비할 수 있다.

   사례 보기

원인별3