IL-0133 Nebius · 2026-08-19kubernetesai-infra
2026년 8월 19일 08:30 UTC 무렵, 폭풍과 관련된 사건으로 us-central1 리전이 들어 있는 데이터센터 건물의 건물 관리 시스템이 꺼지고 냉수 냉각 루프가 멈췄다. 능동 냉각이 끊긴 데이터 홀은 약 두 시간 만에 과열됐고, 서버와 네트워크 스위치와 랙 전원 장치가 열 보호로 꺼지기 시작했다. 흡기 온도는 최고 58.5 °C 까지 올랐다. 시설을 감시하는 시스템이 바로 그 건물 관리 시스템이어서 시설 수준의 알림은 운영사에도 Nebius 에도 가지 않았다. Nebius 는 10:15 부품 과열 알림으로 처음 움직였고 10:21 에 장애를 선언했다. 시설 운영사가 냉각을 수동 우회 모드로 돌렸고, 사건이 시작되고 약 여섯 시간 뒤 온도가 안정됐다. 그동안 GPU 와 CPU 컴퓨트, VM 외부 연결, 오브젝트와 블록과 파일 스토리지, Managed Kubernetes, Token Factory, 관리형 플랫폼 서비스, 리전 콘솔과 API 가 모두 영향을 받았고 실행 중이던 VM 의 약 3분의 1이 중단됐다.
플랫폼 복구는 시설 복구보다 훨씬 오래 걸렸다. 리전 인프라 컨트롤 플레인은 전원이 돌아와도 스스로 살아나지 않아 약 두 시간 동안 손으로 되살려야 했다. 자동 VM 복구는 인스턴스마다 한 번만 시도하고 속도 제한이 걸려 있었다. 리전에서 돌던 인스턴스의 약 3분의 1에 자동 복구가 걸렸고 그중 약 3분의 1만 성공했다. 나머지는 갑자기 꺼진 호스트에 남은 디스크 연결 상태 때문에 주로 스토리지 연결 오류로 실패했고, 실패한 시도는 다시 시도되지 않았다.
가장 오래 걸린 것은 Managed Kubernetes 였다. 컨트롤 플레인은 상태를 보조 데이터 디스크에 두는데, 관리형 디스크 핫플러그 기능의 버그 때문에 인스턴스를 복구할 때 이 데이터 디스크가 연결되지 않은 채로 남을 수 있었다. 그래서 복구된 컨트롤 플레인 인스턴스 수백 개가 데이터 디스크 없이 올라왔고 클러스터는 계속 내려가 있었다. 18:17 에 원인을 찾았고, 영향받은 컨트롤 플레인 인스턴스를 통제된 방식으로 멈췄다 다시 시작하는 완화책을 18:30 까지 한 클러스터에서 시험했다. 19:36 에서 19:55 사이에 이를 대규모로 적용해 컨트롤 플레인에 접근할 수 없는 클러스터가 55개에서 8개로 줄었고, 21:58 에 모든 클러스터가 정상으로 보고됐다. 장애는 8월 20일 08:38 에 완전히 완화됐다. 버그는 그 뒤 고쳐져 모든 리전에 배포됐다.
2026년 8월 19일 09:40 UTC 무렵부터 InfiniBand 패브릭 성능 저하와 GPU 과열 알림이 쌓이기 시작했고, 10:00 이 조금 지나 첫 고객 제보가 들어왔다. 10:15 에 핵심 부품 온도 알림으로 온콜 엔지니어가 호출됐다.
10:40 에서 11:00 사이에 랙 전원 장치가 과열로 차단되면서 리전 컨트롤 플레인과 네트워크 게이트웨이를 올린 랙까지 내려갔다. 리전 S3 엔드포인트 요청은 10:40 무렵부터 실패했고, Token Factory 에 배포된 모델은 10:37 무렵부터 일부 또는 전부 쓸 수 없었다. 11:00 에는 리전 VM 의 외부 연결이 완전히 끊겼다. 리전 전체에서 Managed Kubernetes 사용자 클러스터의 컨트롤 플레인에 접근할 수 없게 됐고, 리전 콘솔과 공개 API 도 쓸 수 없었다. 고객용 지표와 로그는 비거나 빠졌고, 리전 안의 구성 요소에 기대던 대응팀의 모니터링도 약해졌다.
전원이 돌아온 뒤에도 Managed Kubernetes 는 쉽게 살아나지 않았다. 15:43 에서 16:05 사이의 첫 복구에서 컨트롤 플레인의 절반가량이 돌아왔지만, 나머지는 복구에 실패하거나 비정상 상태로 올라왔다. 16:15 무렵 팀은 약 140개 클러스터에 접근할 수 없다고 추정했고, 컨트롤 플레인 인스턴스를 손으로 시작해 17:00 무렵 4분의 1을 더 살렸다. 18:11 에도 79개 클러스터는 컨트롤 플레인에 접근할 수 없었고 컨트롤 플레인 데이터인 etcd 를 읽을 수 없었다. 블록 스토리지에서도 갑자기 꺼진 호스트의 디스크 일부가 오래된 연결 상태로 남아 마운트도 삭제도 되지 않았다.
나중에 대시보드를 돌아보니 09:15 무렵부터 리전 온도가 오르는 것이 보였지만 이 지표에는 알림이 없었다. 건물 관리 시스템이 꺼져 시설 쪽 알림도 오지 않았다.
시설을 감시하는 건물 관리 시스템이 같은 사건으로 꺼져 시설 수준의 알림이 없었다. 대시보드에는 09:15 무렵부터 온도 상승이 보였지만 이 지표에 알림이 없어 나중에야 확인했다. 09:40 무렵부터 InfiniBand 패브릭 저하와 GPU 과열 알림이 쌓였고, 엔지니어가 실제로 반응한 첫 신호는 10:15 의 핵심 부품 온도 알림이었다. 장애는 10:21 에 선언됐다.
시설 감시는 감시 대상 시스템과 독립돼 있어야 한다. 폭풍과 관련된 사건 하나가 냉각 설비와 그 고장을 알렸어야 할 건물 관리 시스템을 함께 껐다. 환경 데이터에도 알림이 있어야 한다. 한 시간 뒤에야 울린 알림은 원인이 아니라 결과인 부품 과열을 알린 것이었다.
리전 단위 복구는 연습한 절차여야 한다. 이전 장애 뒤에 개선한 것들은 의도대로 작동했다. 컨트롤 플레인 랙에 먼저 전원을 넣었고, 네트워크 게이트웨이는 전원이 돌아오고 약 두 시간 안에 살아났고, 오브젝트 스토리지는 자동으로 복구됐다. 하지만 의존 계층 사이의 복구 순서는 장애 중에 손으로 정하고 조율해야 했다. 복구 자동화는 개별 장애뿐 아니라 대량 장애에도 맞게 설계해야 한다. 한 번만 시도하는 복구, 보수적인 속도 제한, 장애로 멈춘 인스턴스와 사용자가 멈춘 인스턴스를 구분하지 못하는 점 때문에 대규모 수작업이 필요했다.
모니터링과 트래픽 관리는 리전이 무너져도 함께 무너지지 않아야 한다. 모니터링 구성 요소는 시작 과정도 데이터도 리전 안의 구성 요소에 기대고 있었다. 전역 콘솔 트래픽 관리에 쓰는 리전 헬스 체크는 리전이 정상이 아닌데도 정상이라고 보고해 트래픽을 잠깐 리전으로 되돌렸다.
IL-0134 AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.같은 원인 · 공통 데이터센터 전력·냉각, InfiniBand 패브릭
같은 원인 · 공통 InfiniBand 패브릭
같은 원인 · 공통 InfiniBand 패브릭
같은 원인 · 공통 데이터센터 전력·냉각
같은 원인 · 공통 InfiniBand 패브릭