사례1건

1건 중 1~1번째

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 는 복구 절차를 더 자동화해야 비슷한 상황에서 대응 시간을 크게 줄일 수 있다고 정리했다.

   사례 보기

원인별1