사례13건

13건 중 1~5번째

1. IL-0133 폭풍으로 데이터센터 냉각이 멈춰 us-central1 리전 전체가 내려갔고, 디스크 핫플러그 버그로 Managed Kubernetes 컨트롤 플레인 약 140개의 복구가 길어졌다.

   Nebius2026

   증상

   2026년 8월 19일 09:40 UTC 무렵부터 InfiniBand 패브릭 성능 저하와 GPU 과열 알림이 쌓이기 시작했고, 10:00 이 조금 지나 첫 고객 제보가 들어왔다. 10:15 에 핵심 부품 온도 알림으로 온콜 엔지니어가 호출됐다.

   컨트롤 플레인 무응답서비스 중단모니터링 중단

   촉발

   폭풍과 관련된 사건이 데이터센터 건물에 영향을 줘 건물 관리 시스템이 꺼지고 냉수 냉각 루프가 멈췄다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각클라우드 블록 스토리지etcdInfiniBand 패브릭

   기여 요인

   단일 장애점모니터링 사각지대한계 경보 부재런북 부재장애 중첩

   감지

   시설을 감시하는 건물 관리 시스템이 같은 사건으로 꺼져 시설 수준의 알림이 없었다. 대시보드에는 09:15 무렵부터 온도 상승이 보였지만 이 지표에 알림이 없어 나중에야 확인했다. 09:40 무렵부터 InfiniBand 패브릭 저하와 GPU 과열 알림이 쌓였고, 엔지니어가 실제로 반응한 첫 신호는 10:15 의 핵심 부품 온도 알림이었다. 장애는 10:21 에 선언됐다.

   조치

   • 시설 운영사가 냉각을 수동 우회 모드로 돌리고 랙 뒷문을 열어 열을 뺐다.
   • 차단된 랙에 컨트롤 플레인 랙부터 전원을 다시 넣었다.
   • 리전 인프라 컨트롤 플레인을 손으로 되살렸다.
   • 블록 스토리지 호스트 구성 요소를 재시작해 갑작스러운 전원 차단으로 남은 디스크 연결 상태를 지웠다.
   • 개별 장애에 맞춰 둔 VM 복구 속도 제한을 리전 규모 복구에 맞게 손으로 올렸다.
   • 접근할 수 없는 Managed Kubernetes 클러스터의 컨트롤 플레인 인스턴스를 손으로 시작했다.
   • 영향받은 컨트롤 플레인 인스턴스를 통제된 방식으로 멈췄다 다시 시작하는 완화책을 대규모로 적용했다.
   • 장애로 멈춘 고객 VM 104개를 찾아 시작했다.

   후속 조치

   • 시설 운영사와 함께 회복력 검토를 마친다. 검토 범위는 시설 관리 시스템과 감시 시스템의 이중화, 그 시스템이 고장 나도 냉각 설비가 계속 도는지 여부, 냉각 설비의 전기 보호, 현장 대응 인력이다.
   • 냉각 설비 상태와 실내 온도 추세를 보는 시설 수준의 환경 알림을 만든다. 이 알림은 건물 관리 시스템과 상관없이, 워크로드 증상이 나타나기 전에 온콜 엔지니어를 호출한다.
   • 시설 운영사와 비상 에스컬레이션 경로를 문서로 만든다. 온콜 연락망과 보장된 응답 시간을 담는다.
   • 냉각이 끊겼을 때 워크로드를 끄거나 줄이는 비상 열 부하 감축 절차를 정한다. 기준과 책임자와 방법을 분명히 한다.
   • 서비스 계층마다 책임자를 정하고 의존 순서를 따르는 리전 콜드 스타트 절차를 정식으로 마련한다. 콜드 스타트는 꺼진 리전 전체를 처음부터 다시 올리는 일을 말한다.
   • 리전 단위 복구 훈련을 정기적으로 하고, 핵심 플랫폼 구성 요소와 고객 워크로드인 VM, 스토리지 연결, Managed Kubernetes 클러스터를 처음부터 끝까지 검증한다.
   • Managed Kubernetes 장애를 늘린 디스크 연결 버그를 고치고 모든 운영 리전에 배포했다.
   • Compute 사용자가 인스턴스 복구 정책을 설정하는 방법을 개선하고, 모든 Managed Kubernetes 컨트롤 플레인 노드를 개선된 복구 정책으로 옮긴다.
   • 호스트가 갑자기 고장 난 뒤 남은 스토리지 연결 상태를 자동으로 정리해, 손대지 않아도 디스크를 마운트하고 지울 수 있게 한다.
   • 모니터링 스택의 시작과 복구 경로에서 리전 내부 의존을 없애고, 리전 간 모니터링을 넓혀 리전 자체 모니터링이 약해져도 그 리전을 볼 수 있게 한다.
   • 전역 트래픽 관리에 쓰는 리전 헬스 체크가 실제 서비스 가용성을 반영하게 해, 비정상 리전에서 트래픽을 빼고 너무 일찍 되돌리지 않게 한다.

   교훈

   시설 감시는 감시 대상 시스템과 독립돼 있어야 한다. 폭풍과 관련된 사건 하나가 냉각 설비와 그 고장을 알렸어야 할 건물 관리 시스템을 함께 껐다. 환경 데이터에도 알림이 있어야 한다. 한 시간 뒤에야 울린 알림은 원인이 아니라 결과인 부품 과열을 알린 것이었다. 리전 단위 복구는 연습한 절차여야 한다. 이전 장애 뒤에 개선한 것들은 의도대로 작동했다. 컨트롤 플레인 랙에 먼저 전원을 넣었고, 네트워크 게이트웨이는 전원이 돌아오고 약 두 시간 안에 살아났고, 오브젝트 스토리지는 자동으로 복구됐다. 하지만 의존 계층 사이의 복구 순서는 장애 중에 손으로 정하고 조율해야 했다. 복구 자동화는 개별 장애뿐 아니라 대량 장애에도 맞게 설계해야 한다. 한 번만 시도하는 복구, 보수적인 속도 제한, 장애로 멈춘 인스턴스와 사용자가 멈춘 인스턴스를 구분하지 못하는 점 때문에 대규모 수작업이 필요했다. 모니터링과 트래픽 관리는 리전이 무너져도 함께 무너지지 않아야 한다. 모니터링 구성 요소는 시작 과정도 데이터도 리전 안의 구성 요소에 기대고 있었다. 전역 콘솔 트래픽 관리에 쓰는 리전 헬스 체크는 리전이 정상이 아닌데도 정상이라고 보고해 트래픽을 잠깐 리전으로 되돌렸다.

   사례 보기
2. IL-0023 InfiniBand 포트 하나가 한 번 내려갔다 복구되면서 7시간째 돌던 학습 작업이 NCCL 타임아웃으로 죽었다

   Databricks2026

   증상

   Databricks AI 의 한 학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 실패했다.

   학습 작업 실패NCCL 타임아웃링크 플래핑

   촉발

   RDMA NCCL 집합 통신에 쓰던 InfiniBand 포트 하나가 한 번 내려갔고, 다시 올라오기까지 NCCL_IB_TIMEOUT 보다 오래 걸렸다.

   원인

   의존성 장애

   구성 요소

   NCCLInfiniBand 패브릭PyTorch

   기여 요인

   모니터링 사각지대기본 설정 방치

   감지

   학습 작업이 시작 7시간 만에 NCCL 타임아웃으로 죽으면서 드러났다. 연속 헬스 체크가 InfiniBand 포트 플래핑을 감시하고 있었지만, 포트가 한 번만 내려갔다 올라와서 임계값에 걸리지 않았다. 원인은 작업이 죽은 뒤 조사로 찾았다.

   조치

   • NCCL_IB_TIMEOUT 기본값을 짧은 포트 다운을 더 잘 견디도록 조정했다.
   • 워치독을 기다리지 않고, 포트 다운 신호가 오면 작업을 종료한 뒤 체크포인트에서 다시 시작하게 했다.
   • 이번 조사를 gpu-monitor 에 반영했다. gpu-monitor 의 RDMA 패브릭 포트 다운 점검은 플랩 횟수가 아니라 누적 다운 시간을 기준으로 한다.

   후속 조치

   • NCCL_IB_TIMEOUT 기본값을 더 잘 견디도록 조정했다.
   • 워치독이 터질 때까지 GPU 를 놀리지 않고, 포트 다운 신호가 오면 작업을 종료한 뒤 체크포인트에서 다시 시작하게 했다.
   • gpu-monitor 에서 RDMA 패브릭 포트 다운 감지를 플랩 횟수가 아니라 누적 다운 시간 기준으로 잡게 했다.

   교훈

   NCCL 타임아웃을 PyTorch 워치독 값으로만 생각하면 안 된다. InfiniBand 전송 계층의 NCCL_IB_TIMEOUT 은 기본값이 실제로 약 7초로, 대부분의 팀이 생각하는 것보다 훨씬 짧다. 이 값이 먼저 터지면 워치독 설정과 관계없이 작업이 죽는다. 링크 상태를 볼 때도 플랩 횟수가 아니라 누적 다운 시간을 봐야 한다. 한 번뿐인 긴 플랩도 며칠짜리 학습을 죽일 수 있다.

   사례 보기
3. IL-0134 AUS01 데이터센터에 전력 문제가 생겨 GPU 노드 246대와 스파인 스위치, VAST 스토리지가 한꺼번에 재부팅됐고, 워크로드가 실패하고 NFS 마운트가 끊겼다.

   Lambda2026sev1

   증상

   2026년 2월 14일 21:06 UTC 에 AUS01 데이터센터의 GPU 노드가 모두 동시에 재부팅됐다. 노드는 곧 다시 올라왔지만, 계획에 없던 재부팅이었고 여러 고객이 영향을 받았다.

   GPU 인식 불가스토리지 연결 끊김

   촉발

   AUS01 데이터센터에 전력 문제가 생겨 전원이 끊겼다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각InfiniBand 패브릭공유 네트워크 파일 시스템

   기여 요인

   –

   조치

   • 컴퓨트 패브릭과 InfiniBand 연결을 복구해 스파인 스위치 4대 전부와 대부분의 리프 스위치를 다시 온라인으로 올렸다.
   • UPS 이중화를 일부 복구하고, 스토리지와 보호 전원을 완전히 되살리는 작업을 이어 갔다.
   • AUS01 의 모든 노드 전원을 올리고 물리 점검을 마친 뒤 스토리지를 다시 올렸다.
   • us-west-3 의 Starbase 와 스토리지에 의존하는 다른 서비스를 복구했다.
   • NFS 마운트가 stale 상태이거나 비어 있는 고객에게 VM 을 재부팅하라고 안내했고, VM 재부팅으로 풀리지 않으면 하이퍼바이저 재부팅이 필요하다고 알렸다.

   교훈

   전원이 끊겨 GPU 노드와 함께 네트워크 스파인과 공유 스토리지까지 재부팅되면, 노드 자체가 다시 뜨는 것보다 전체 복구가 훨씬 오래 걸린다. GPU 노드는 곧 다시 올라왔지만, 팀은 패브릭을 먼저 되살렸고 스토리지는 물리 점검을 마친 뒤에야 다시 올렸다. 일부 VM 에는 stale 상태의 NFS 마운트가 남아, Lambda 는 고객에게 VM 을 재부팅하고 그래도 안 되면 하이퍼바이저를 재부팅하라고 안내했다.

   사례 보기
4. IL-0187 Spring Cloud Config Server 가 잠깐 내려가자 이를 헬스 체크에 포함한 모든 앱의 Liveness Probe 가 실패해 쿠버네티스가 파드를 계속 죽이고 다시 띄우면서 한 계열사 서비스가 마비됐다.

   Yonghyun Kim2025

   증상

   Config Server 업그레이드로 서버가 잠깐 응답하지 않는 동안, 클라이언트 앱 전부가 Liveness Probe 요청에 Config Server 와 연결되지 않는다며 실패로 응답했다.

   프로브 실패컨테이너 재시작 반복서비스 중단

   촉발

   Config Server 를 다운타임이 있는 방식으로 업그레이드하면서 서버가 잠깐 응답하지 않았다.

   원인

   의존성 장애

   구성 요소

   라이브니스·레디니스 프로브

   기여 요인

   기본 설정 방치자동화 증폭과도한 영향 범위

   교훈

   Liveness Probe 가 앱 자신이 아니라 외부 의존성의 상태까지 판단하면, 잠깐의 외부 장애나 네트워크 문제에도 쿠버네티스가 멀쩡한 앱을 죽인다. 일시적인 부하나 외부 서버 다운은 앱을 죽일 이유가 아니며, Readiness Probe 로 잠시 트래픽만 막으면 된다. 글쓴이는 특별한 이유가 없으면 Liveness Probe 를 끄라고 권한다. 꼭 써야 한다면 헬스 체크 경로에서 DataSourceHealthIndicator, ConfigServerHealthIndicator 같은 외부 Health Indicator 를 빼거나 /healthz 같은 별도 경로를 만들어야 한다. initialDelaySeconds 는 앱이 뜨는 데 걸리는 최대 시간보다 길게, failureThreshold 와 periodSeconds 는 넉넉하게 잡는다. 예를 들어 failureThreshold: 10, periodSeconds: 6 이면 60초 동안 연속으로 실패해야 재시작된다. 글쓴이가 운영한 레브잇 환경은 Liveness Probe 없이 2년 동안 안정적으로 서비스했다.

   사례 보기
5. IL-0162 데이터베이스 업데이트 뒤 LKE 내부 DNS 서비스가 멈춰 사용자가 LKE 클러스터 컨트롤 플레인과 LKE 대시보드에 접속하지 못했다

   Linode2025

   증상

   2025년 4월 1일 Linode Kubernetes Engine, 줄여서 LKE 의 사용자들이 자기 클러스터에 연결하지 못하기 시작했다. 외부에서 클러스터 컨트롤 플레인과 LKE 대시보드에 접근할 수 없었다.

   DNS 조회 실패컨트롤 플레인 무응답

   촉발

   앞서 진행한 데이터베이스 업데이트 때문에 LKE DNS 서비스가 멈췄다.

   원인

   의존성 장애

   구성 요소

   DNS 서버와 레코드애플리케이션 데이터베이스

   기여 요인

   –

   감지

   Linode 는 20시 28분 UTC 상태 페이지에 사용자가 클러스터 컨트롤 플레인에 연결하기 어려울 수 있다고 알리고 조사를 시작했다. 21시 33분 문제를 LKE 의 DNS 기능으로 좁혔고, 22시 29분 근본 원인을 찾았다.

   조치

   • 영향받은 LKE DNS 서비스를 재시작해 클러스터와 LKE 대시보드 접근을 되살렸다.

   후속 조치

   • DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 스스로 회복하도록 개선한다.
   • 비슷한 문제를 더 빨리 찾도록 모니터링을 강화한다.
   • 서로 의존하는 시스템 사이의 변경을 더 잘 조율하도록 배포 절차를 고친다.

   교훈

   DNS 서비스가 의존하는 데이터베이스를 바꾸면 DNS 서비스가 멈출 수 있고, 그러면 클러스터 안은 멀쩡해도 사용자는 컨트롤 플레인에 닿지 못한다. Linode 는 DNS 서비스가 의존하는 시스템과 잠깐 연결이 끊겨도 회복할 수 있어야 하고, 서로 의존하는 시스템의 변경은 함께 조율해야 한다고 정리했다.

   사례 보기

원인별1