Incident Library

IL-0424 Nebius · 2024-11-26ai-infra

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

UTC+1 기준 13:48 에 새 릴리스를 eu-north1 에 배포하자 Compute API 서비스가 일부 VM 이 동작하지 않는다고 잘못 판단했다. 새 릴리스는 리소스 변경을 추적하는 시스템이 이벤트를 처리하는 순서를 잘못 가정하고 있었다. Compute API 는 일부 VM 이 사라졌다고 보고 필요 없는 복구 작업을 시작했고, VM 282대가 재시작했다. 당시 시스템은 이만큼 많은 복구 작업을 감당하도록 최적화되어 있지 않았다. 그 결과 196대가 재시작하지 못하고 멈췄다.

14:03 에 내부 모니터링 알림이 울려 온콜 엔지니어에게 전화가 갔다. 팀은 15분 안에 인시던트를 선언하고 대응 팀을 꾸렸다. 팀은 자동 복구 작업을 모두 멈추고, 정상적으로 재시작한 VM 과 손으로 살려야 하는 VM 을 나눴다. 15:00 에 근본 원인을 찾은 뒤 개별 VM 에서 복구 절차를 시험했고, 15:37 부터 16:39 까지 VM 163대를 몇 대씩 묶어 차례로 복구했다. 17:40 에 영향받은 VM 이 모두 정상으로 켜진 것을 확인하고 인시던트를 끝냈다.

심각도
–
영향 범위
282 VMs in eu-north1 restarted, 196 got stuck, and 164 stayed offline for about 2 to 3 hours, interrupting customer workloads
영향 사용자
–
지역
eu-north1
감지까지
15m
복구까지
3h 52m

증상

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

재시작한 282대 가운데 86대는 13:50 에 자동으로 다시 올라왔지만 196대는 재시작에 실패하고 멈춘 상태로 남았다. 사용자가 그중 32대를 직접 재시작하거나 지웠고, 나머지 164대는 켜지지 않은 채 약 2~3시간 동안 오프라인이었다.

팀은 14:21 에 원인을 분석하기 시작했고, 상황을 더 나쁘게 만들지 않으면서 피해를 줄일 방법도 함께 찾았다. 근본 원인은 15:00 에 찾았다.

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

원인

원인 배포 결함

구성 요소 클라우드 컴퓨트 컨트롤 플레인
기여 요인 미검증 가정자동화 증폭
촉발
UTC+1 기준 13:48 에 VM 복구 순서에 결함이 있는 새 릴리스를 eu-north1 에 배포했다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

–

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 클라우드 컴퓨트 컨트롤 플레인. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.