사례2건

2건 중 1~2번째

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-0059 kubeadm이 만든 etcd 정적 파드의 liveness probe가 실패해 kubelet이 약 2분마다 etcd를 재시작했고, 단일 마스터 클러스터의 API 서버가 계속 끊겼다

   NRE Labs2018

   증상

   2018년 12월 4일 아침 8시 회의 중 운영자가 NRE Labs의 일일 통계를 보다가 레슨 사용량이 떨어진 것을 알아챘다.

   컨트롤 플레인 무응답프로브 실패서비스 중단

   촉발

   kubeadm이 etcd 정적 파드 매니페스트에 넣은 liveness probe가 실패하기 시작했다. 이 probe는 etcdctl로 foo 키를 조회한다. failureThreshold가 8, timeoutSeconds가 15라서 약 2분 동안 실패가 이어지면 kubelet이 etcd를 재시작한다. probe가 왜 실패하기 시작했는지는 끝내 밝히지 못했다.

   원인

   unknown

   구성 요소

   etcdkubelet쿠버네티스 API 서버

   기여 요인

   단일 장애점기본 설정 방치수동 조치 악화초기 신호 무시모니터링 사각지대

   감지

   운영자가 아침 회의 중 NRE Labs 일일 통계를 보다가 레슨 사용량이 떨어진 것을 보고 알았다. 클러스터 모니터링은 갖추지 않은 상태였고, 원문은 모니터링이 우선순위에서 밀려 있었다고 적었다.

   조치

   • kubeadm이 만든 etcd 매니페스트에서 liveness probe 부분을 통째로 지우고, 다음 etcd 재시작 때 kubectl apply로 반영했다.

   후속 조치

   • 단일 마스터 클러스터에 모니터링을 갖춘다.
   • 장애가 나면 트위터를 보라고 안내하는 점검 페이지를 Google Cloud Functions에 만든다. 계획된 작업이든 아니든 일이 생기면 트래픽을 그 페이지로 돌린다.

   교훈

   모든 인프라를 코드로 관리한 덕에 클러스터를 금방 다시 만들 수 있었다. 하지만 원인을 모른 채 지우면 증거도 함께 사라진다. 단일 마스터로 운영한다면 모니터링이 더 중요하다. kubectl 출력에서 Running만 보지 말고 재시작 횟수까지 읽어야 한다. 복잡한 원인을 기대하기 전에 기본부터 의심하고, 장애의 급박함에 밀려 성급한 결정을 내리지 않는다. 사이트를 반쯤 망가진 채로 두지 말고 점검 페이지로 상황을 알려야 한다.

   사례 보기

원인별2