사례2건

2건 중 1~2번째

1. IL-0424 eu-north1 리전의 VM 282대가 한꺼번에 재시작했고 그중 164대가 2~3시간 동안 켜지지 않았다

   Nebius2024

   증상

   UTC+1 기준 13:48 에 eu-north1 리전의 VM 282대가 한꺼번에 재시작했다. 14:03 에 멈춘 VM 이 많다는 알림이 울렸고, 같은 때 고객이 Slack 으로 첫 신고를 보냈다.

   예기치 않은 VM 재시작서비스 중단

   촉발

   UTC+1 기준 13:48 에 VM 복구 순서에 결함이 있는 새 릴리스를 eu-north1 에 배포했다.

   원인

   배포 결함

   구성 요소

   클라우드 컴퓨트 컨트롤 플레인

   기여 요인

   미검증 가정자동화 증폭

   감지

   내부 모니터링이 멈춘 VM 을 감지해 14:03 에 알림을 울렸고, 곧바로 온콜 엔지니어에게 전화가 갔다. 같은 때 고객이 Slack 으로 첫 신고를 보냈다. 팀은 15분 안에 영향을 파악하고 인시던트를 공식으로 선언했다.

   조치

   • 근본 원인을 찾으면서 피해가 더 번지지 않도록 자동 복구 작업을 모두 멈췄다.
   • 영향받은 VM 을 재시작에 성공한 VM 과, 멈춰서 손으로 살려야 하는 VM 의 두 그룹으로 나눴다.
   • 15:00 부터 15:37 까지 상황을 더 나쁘게 만들지 않는 복구 계획을 세우고, 그 방법을 개별 VM 에서 먼저 시험했다.
   • 멈춘 VM 을 정지해 걸려 있던 프로세스를 모두 끊은 뒤 몇 대씩 묶어 차례로 다시 시작했다. 15:37 부터 16:39 까지 VM 163대를 이렇게 복구했다.

   후속 조치

   • 배포 전 검증에 복구 시나리오 테스트를 더한다.
   • VM 상태 변경을 더 엄격하게 검증한다.
   • 복구 작업에 속도 제한을 둔다.
   • VM 활동의 모니터링과 이상 탐지를 강화한다.
   • 배포 절차에 안전 점검을 더한다.
   • 대규모 VM 이벤트가 나면 더 빨리 에스컬레이션한다.
   • 고객 알림과 고객 소통을 개선하고, 사고 대응이 매끄럽도록 내부 소통 절차를 다듬는다.

   교훈

   단계별로 나눠 복구한 방식은 효과가 있었지만 사람이 직접 손대고 면밀히 지켜봐야 했다. Nebius 는 복구 절차를 더 자동화해야 비슷한 상황에서 대응 시간을 크게 줄일 수 있다고 정리했다.

   사례 보기
2. IL-0229 손상된 SmartEdge 데이터 파일을 받은 bunny.net 의 전 세계 DNS 서버가 크래시를 되풀이해 플랫폼 대부분이 2시간 넘게 멈췄다.

   bunny.net2021

   증상

   2021-06-22 UTC 8:25 에 업데이트를 내보내고 몇 분 만에 전 세계에 있는 100대 가까운 bunny.net DNS 서버가 거의 모두 죽었다. bunny.net 은 트래픽의 60% 넘게 잃었고, 수백 Gbit 의 처리량이 사라졌으며, 750,000개가 넘는 웹사이트가 영향을 받았다.

   컨테이너 재시작 반복DNS 조회 실패서비스 중단요청 오라우팅부하 불균형

   촉발

   2021-06-22 UTC 8:25 에 최적화 데이터베이스의 다운로드 크기를 줄이려는 업데이트가 손상된 파일을 Edge Storage 에 올렸다. DNS 서버가 이 파일을 읽자 BinaryPack 직렬화 라이브러리가 stack overflow 예외를 일으켰고, 예외 처리를 건너뛴 채 DNS 프로세스가 종료됐다.

   원인

   배포 결함

   구성 요소

   DNS 서버와 레코드CDN 과 엣지 네트워크오브젝트 스토리지

   기여 요인

   순환 의존단일 장애점자동화 증폭롤백 무효수동 조치 악화

   감지

   팀은 무슨 일인지 알아채는 데 시간이 걸렸다. 업데이트 10분 뒤에야 DNS 서버가 다시 시작했다가 죽기를 되풀이하고 있고, 이 상태로는 되살릴 방법이 없다는 것을 알았다.

   조치

   • UTC 8:45 에 SmartEdge 시스템을 끄는 업데이트를 DNS 노드에 손으로 배포했다. 하지만 손상된 GeoDNS 데이터베이스 때문에 요청이 Madrid 로 몰렸다.
   • 9:40 무렵 임시 조치로 모든 요청을 가장 큰 리전인 Frankfurt 로 보내는 라우팅 업데이트를 준비해 DNS 서버 몇 대에 손으로 배포했다. 트래픽의 상당 부분이 돌아왔다.
   • 자체 시스템을 쓰지 않으려고 배포 시스템과 파일을 모두 외부 클라우드 스토리지 서비스로 옮겼다.
   • 10:15 에 배포 시스템과 DNS 소프트웨어를 새 스토리지에 연결하도록 바꾸고 배포했다. 10:30 에 트래픽이 돌아왔지만 잘못된 GeoDNS 데이터베이스 버전 때문에 요청은 여전히 Madrid 로 갔다.
   • 10:45 에 외부 서비스를 거쳐 데이터베이스를 동기화하고 최신 파일 세트를 배포해 서비스를 되살렸다. 11:00 에 상황이 안정되기 시작했다.

   후속 조치

   • 긴급 수정으로 BinaryPack 라이브러리를 단계적으로 걷어 낸다.
   • 앞으로 쓰는 외부 라이브러리를 더 폭넓게 시험한다.
   • 내부 API 를 외부의 독립 서비스로 완전히 옮긴다. 그 서비스가 내려가면 업데이트를 못 하지만, bunny.net 시스템이 내려가도 무너지는 인프라에 갇히지 않고 빠르게 대응할 수 있다.
   • 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 걸친 단일 장애 지점이 되지 않게 하는 방법을 조사한다.
   • DNS 시스템이 모든 백업 데이터의 로컬 사본을 갖추고 장애를 자동으로 감지하게 해, 시스템끼리 최대한 독립시키고 장애가 연쇄로 번지지 않게 한다.

   교훈

   bunny.net 은 내부 인프라의 핵심 부분까지 모든 시스템이 서로 기대도록 설계했다. 그 때문에 손상된 파일 하나가 여러 겹의 이중화를 무너뜨리고 복구할 길까지 막았다. 자체 인프라를 자기 생태계 안에 지으면 한 곳의 장애가 연쇄로 번질 수 있다. 업데이트는 카나리 방식으로 잘게 배포하려 했지만, 중요하지 않다고 본 소프트웨어 하나가 여러 클러스터에 동시에 걸친 단일 장애 지점이 됐다. 급하게 고치는 동안 오타와 실수가 늘었고, 결국 침착하게 모든 것을 다시 확인한 뒤의 마지막 배포로 복구했다.

   사례 보기

원인별1