사례29건

29건 중 9~13번째

1. IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.

   Barush Mendez2025

   증상

   2025년 3월 3일 14:15:34부터 홈랩 쿠버네티스에 올린 서비스에 접속되지 않았다. 운영자가 서비스에 들어가려다 직접 알아챘고, 알아채기까지 3시간이 걸렸다.

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

   촉발

   정전 때문에 마스터 노드가 재부팅됐다.

   원인

   소프트웨어 결함

   구성 요소

   GPU 드라이버리눅스 커널쿠버네티스 API 서버

   기여 요인

   초기 신호 무시늦게 드러난 변경단일 장애점모니터링 사각지대

   감지

   운영자가 서비스에 접속하려다 직접 알아챘다. 자동 알림이 없어서 알아채기까지 3시간이 걸렸다.

   조치

   • 원격 접속이 되지 않아 모니터를 연결해 부팅 로그를 보고 커널 패닉을 확인했다.
   • 이전 커널 버전으로 부팅해 시스템을 되살렸다.
   • sudo apt-get remove --purge '^nvidia-.*' 로 망가진 패키지를 지우고 sudo dpkg --configure -a 로 패키지 설정 문제를 고쳤다.
   • dpkg -l | grep -v ^ii 로 남은 망가진 패키지를 찾아 sudo apt-get remove --purge <package_name> 으로 하나씩 지웠다.
   • sudo apt-get install -f 로 빠진 의존성을 채우고 sudo apt-get install --reinstall linux-headers-$(uname -r) 로 커널 헤더를 다시 설치했다.
   • 머신을 재부팅해 커널 패닉이 사라진 것을 확인했다.

   후속 조치

   • GPU 드라이버 설치가 완전히 성공했는지 확인하고, 오류가 나면 바로 변경을 되돌린다.
   • 단일 장애 지점을 없애도록 클러스터를 고가용성 구성으로 옮긴다.
   • 고가용성 구성에서 Kube-API 를 로드 밸런서 뒤에 둔다.
   • 장애를 기록하고 해결 과정을 추적할 티켓 시스템을 만든다.
   • 미리 정해 둔 문제 해결 절차를 만들어 홈랩 장애 대응 시간을 줄인다.
   • Prometheus 와 Grafana 같은 인프라 모니터링을 넣어 문제를 미리 잡는다.
   • 주요 서비스에 HTTP, TCP 검사를 거는 블랙박스 모니터링을 넣어 쿠버네티스 클러스터 밖에서도 장애를 잡는다.

   교훈

   드라이버 빌드 실패를 그대로 두면 몇 주 뒤 재부팅 때 터질 수 있다. 자동 알림이 없어서 발견과 복구가 늦었다. 마스터 노드가 하나뿐이라 노드 하나의 고장이 클러스터 전체 장애가 됐다. 원인을 찾은 뒤에는 비교적 간단히 고쳤고, 데이터 손실은 없었다.

   사례 보기
2. IL-0127 Llama 3 405B 사전 학습 54일 동안 학습 작업이 예기치 않게 419번 중단되었고, 주된 원인은 GPU 와 HBM3 메모리 고장이었다

   Meta2024

   증상

   Meta 는 최대 16K 개의 H100 GPU 로 Llama 3 405B 를 사전 학습했다. 54일 동안의 기록에서 학습 작업은 모두 466번 중단되었고, 그중 419번이 예기치 않은 중단이었다. 나머지 47번은 펌웨어 업그레이드 같은 자동 유지보수나, 설정과 데이터셋 갱신 같은 운영자 작업에 따른 계획된 중단이었다.

   학습 작업 실패GPU 인식 불가NCCL 타임아웃

   원인

   하드웨어 고장

   구성 요소

   GPU 하드웨어·메모리NCCLPyTorch

   기여 요인

   단일 장애점

   감지

   PyTorch 의 NCCL flight recorder 가 모든 통신 이벤트와 집합 연산마다 걸린 시간을 링 버퍼에 기록했고, NCCLX 워치독이나 하트비트 타임아웃이 나면 추적 데이터를 자동으로 덤프했다. NCCLX 는 통신 라이브러리 상태를 감시하다가 멈춤을 감지하면 자동으로 타임아웃시켰고, 실패한 집합 연산의 내부 상태 스냅샷을 남겼다. 느린 GPU 는 의심스러운 통신에 우선순위를 매겨 보여 주는 도구로 찾았다. 대개 상위 몇 개만 조사해도 찾아낼 수 있었다.

   조치

   • 대부분의 중단은 자동화가 처리했고, 사람이 크게 손을 대야 했던 것은 54일 동안 세 번뿐이었다.

   후속 조치

   • 작업 시작 시간과 체크포인트 시간을 줄였다.
   • PyTorch 의 NCCL flight recorder 로 모든 통신 이벤트와 집합 연산 시간을 기록하고, NCCLX 워치독이나 하트비트 타임아웃이 나면 추적 데이터를 자동으로 덤프하게 했다.
   • 계산이 많이 드는 추적과 메타데이터 수집은 운영 중에 필요할 때만 켜게 했다. 켜고 끄는 일은 코드를 배포하거나 작업을 재시작하지 않고 온라인 설정 변경으로 하게 했다.
   • PyTorch 가 NCCLX 의 내부 상태에 접근하게 해 멈춤을 더 빨리 감지하고 멈춘 위치를 찾게 했다. 실패한 집합 연산의 끝난 전송과 남은 전송은 스냅샷으로 남기게 했다.

   교훈

   동기식 학습은 GPU 하나의 고장에도 작업 전체가 멈출 수 있어 고장에 약하다. 하드웨어 고장은 멈춤으로만 나타나지 않고 느린 straggler 로도 나타나며, straggler 하나가 GPU 수천 개를 느리게 만들 수 있다. 이 규모에서는 기온과 전력망 같은 환경 요인도 학습 성능과 운영에 영향을 준다.

   사례 보기
3. IL-0169 FR-PAR 의 Scaleway Kubernetes API 가 메모리 부족으로 쓰러져 노드 인증이 막히고 Kapsule 노드가 NotReady 가 됐다.

   Scaleway2024

   증상

   2024-01-24 23:48 CET, FR-PAR 리전에서 Kapsule 과 Kosmos 고객 클러스터의 일부 노드가 NotReady 로 바뀌었다. 같은 시각 API Gateway 로 들어오는 요청이 크게 치솟았다.

   노드 NotReadyOOMKilled간헐적 타임아웃모니터링 중단

   촉발

   FR-PAR 에서 동시에 몰린 배포가 Scaleway Kubernetes API 의 메모리를 바닥냈다.

   원인

   용량 한계

   구성 요소

   컨테이너 메모리 한도kubelet

   기여 요인

   단일 장애점재시도 폭주

   감지

   23:48 에 API Gateway 부하가 늘어난 것이 감지됐고, 00:00:10 에 내부 에스컬레이션을 거쳐 당직 엔지니어가 맡았다.

   조치

   • 관리형 Kubernetes 서비스의 메모리 한도와 가비지 컬렉션 임계값을 곧바로 올렸다.
   • 늘어난 부하를 받도록 주요 서비스에 복제본을 추가로 배포했다.
   • 레지스트리 캐시를 비우고, 클러스터가 안정되는 동안 지켜봤다.
   • 장애 뒤에도 계속 모니터링하며 서비스 설정을 조정했다.

   후속 조치

   • 로컬 인증 캐시를 구현한다.
   • 노드 인증 방식을 더 개선한다.
   • 모니터링을 강화하고 레이트 리밋 전략을 조정했으며 장애 대응 절차를 개선했다.

   교훈

   탄탄한 모니터링과 빠른 대응 체계가 중요하다. Kubernetes API 가 노드 인증까지 맡고 있어서 API 의 메모리 부족이 곧장 노드 NotReady 로 번졌다. Scaleway 는 이를 막으려고 로컬 인증 캐시와 노드 인증 개선을 계획했다.

   사례 보기
4. IL-0135 UPS 를 바이패스 모드로 둔 정기 점검 중 전원이 예비 전원으로 넘어가면서 데이터센터 한 열이 정전됐고, 그 열의 GPU VM 이 모두 꺼졌다.

   Crusoe Cloud2023

   증상

   2023년 11월 15일 20:31 UTC 에 us-northcentral1 리전 데이터센터의 한 열에서 정전이 나 그 리전 VM 의 일부가 꺼졌다. 상태 페이지는 us-northcentral1-a 의 일부 VM 을 쓸 수 없다고 알렸다.

   GPU 인식 불가서비스 중단

   촉발

   UPS 를 바이패스 모드로 두고 정기 점검을 하던 중, 점검과 관계없는 이유로 전원이 주 전원에서 예비 전원으로 넘어갔다.

   원인

   의존성 장애

   구성 요소

   데이터센터 전력·냉각

   기여 요인

   단일 장애점장애 중첩

   감지

   정전은 20:31 UTC 에 났고, 21:07 UTC 에 상태 페이지가 us-northcentral1-a 의 일부 VM 을 쓸 수 없다고 처음 알렸다. 21:31 UTC 에는 영향받은 VM 을 찾아냈다고 올렸다.

   조치

   • 팀이 정전으로 영향받은 VM 을 찾아냈다.
   • 전원이 돌아온 뒤 영향받은 VM 을 차례로 재시작했고, 마지막 VM 은 11월 16일 00:20 UTC 에 다시 켜졌다.

   후속 조치

   • 앞으로 점검할 때 고객에게 영향이 갈 가능성을 최소로 줄이도록 UPS 점검 표준 운영 절차를 검토한다.
   • 앞으로 짓는 데이터센터에는 UPS 를 이중으로 둔다.
   • 장애가 났을 때 평균 해결 시간인 MTTR 을 더 줄이도록 복구 절차를 계속 개선한다.

   교훈

   UPS 를 바이패스 모드로 둔 점검 시간에는 그 열에 전원 전환을 받아 줄 장치가 없다. 하나뿐인 UPS 가 점검 중일 때 다른 이유로 전원이 바뀌자 열 전체가 꺼졌고, 그래서 Crusoe 는 새 데이터센터에 이중 UPS 를 두기로 했다.

   사례 보기
5. IL-0145 Australia East 의 전압 강하로 냉각기가 멈춰 데이터 홀 장비가 꺼지면서, 영역 중복이 아닌 AKS 작업 큐 데이터베이스가 내려가 두 리전의 AKS 생성, 수정, 삭제 작업이 막혔다

   Microsoft Azure2023

   증상

   2023년 8월 30일 10시 30분 UTC 무렵부터 Australia East 리전에서 Azure, Microsoft 365, Power Platform 서비스에 접근하거나 쓰는 데 문제가 생겼다. AKS 에서는 리소스 공급자를 거치는 생성, 조회, 수정, 삭제 작업과 스케일링이 실패했다.

   컨트롤 플레인 무응답오류율 상승서비스 중단

   촉발

   8월 30일 08시 41분 UTC, Australia East 의 영향받은 가용 영역에서 약 18마일 떨어진 전력 설비에 낙뢰가 떨어져 전압 강하가 일어났다. 이 전압 강하로 여러 데이터센터의 냉각 시스템에 있는 냉각기가 멈췄다.

   원인

   클라우드 제공자 장애

   구성 요소

   AKS 컨트롤 플레인애플리케이션 데이터베이스

   기여 요인

   단일 장애점과도한 영향 범위

   감지

   10시 47분 UTC Cosmos DB 영향이 모니터링에 잡혔고, 10시 48분 첫 자동 공지가 Azure Service Health 로 나갔다. 11시 30분 공개 Azure 상태 페이지에 첫 공지가 올라갔고, 11시 36분 Australia East 의 모든 구독에 포털 공지를 보냈다.

   조치

   • 11시 34분 UTC 냉수 온도를 낮추려고 영향받은 데이터 홀의 남은 네트워크, 컴퓨트, 스토리지 장비를 원격으로 내렸다.
   • 12시 12분 UTC 재시작이 막혔던 냉각기 다섯 대를 손으로 다시 켰다.
   • 데이터 홀 안전 점검을 마친 뒤 장비에 단계적으로 전원을 넣어 15시 10분 UTC 모든 장비의 전원을 복구했다.
   • AKS 작업 큐로 쓰는 SQL Database 가 복구되자 다른 조치 없이도 AKS 작업이 되살아났다.

   후속 조치

   • AKS 팀은 작업 큐로 쓰는 SQL Database 데이터베이스를 모두 영역 중복으로 즉시 전환한다. 완료 목표는 2023년 9월이다.
   • AKS 팀은 리전을 넘나드는 SQL Database 큐 사용을 모두 영역 중복 Service Bus 큐로 바꾼다. 완료 목표는 2023년 9월이다.
   • 가용 영역의 부하가 조금씩 늘면서 냉각기 운전 구성이 냉각기 관리 시스템의 타이밍 결함에 취약해져 있었다. 전압 변동 뒤 재시작에 실패하지 않도록 냉각기 관리 시스템의 제어 타이밍 로직을 바꿨다.
   • 여러 냉각기가 한꺼번에 멈췄을 때 손으로 재시작하는 비상 운영 절차에서, 재시작 순서를 냉각기가 붙어 있는 차례가 아니라 데이터 홀 부하를 기준으로 정하도록 바꿨다. 냉각을 모두 되살리는 동안 모든 데이터 홀이 일부라도 냉각을 받아 열 폭주가 늦춰지게 하려는 것이다.
   • 냉각기 관리 시스템을 바꾸기 전까지의 임시 조치로 데이터센터 기술자 인원을 늘려 수동 재시작 절차를 바로 실행할 수 있게 했다.
   • 스토리지 팀은 대규모 복구 과정을 최적화한다. 장애 중에 빨리 판단할 수 있도록 판단에 쓰는 데이터를 늘리고, 더 빨리 실행할 수 있도록 문제 해결 가이드를 고친다. 완료 목표는 2023년 12월이다.
   • Azure Service Fabric 팀은 SQL Database 테넌트 링 복구의 신뢰성을 높인다. 완료 목표는 2023년 12월이다.
   • SQL Database 팀은 자동 장애 조치 그룹의 발동 기준을 검토해 장애 조치가 기대한 시간 안에 일어나게 한다. 완료 목표는 2023년 10월이다.
   • SQL Database 팀은 데이터베이스를 대량으로 옮길 수 있도록 내부 도구를 개선한다. 완료 목표는 2023년 12월이다.
   • Cosmos DB 팀은 단일 리전 쓰기 계정의 서비스 관리형 장애 조치를 최적화해 복구 시간을 줄인다. 완료 목표는 2023년 11월이다.
   • ARM 팀은 스토리지 계층을 차세대 영역 중복 구조로 옮기는 작업을 마친다. 완료 목표는 2023년 12월이다.
   • 장애 관리 팀은 장비 전원을 내려야 하는 상황에 맞춰 준비 태세, 절차, 플레이북을 강화하는 방법을 찾는다. 완료 목표는 2023년 10월이다.

   교훈

   AKS 컨트롤 플레인의 기반 인프라를 여러 가용 영역에 나눠 두어도, 생성, 조회, 수정, 삭제 작업이 거치는 작업 큐 데이터베이스가 영역 중복이 아니면 한 영역의 장애가 리전 전체의 AKS 작업을 멈춘다. 다른 리전이 같은 데이터베이스에 기대고 있으면 장애가 그 리전까지 번진다. 이미 돌고 있는 워크로드는 영향을 받지 않았을 것으로 Microsoft 는 보았지만, 스케일링처럼 리소스 공급자를 거쳐야 하는 일은 모두 막혔다. 영역 중복 스토리지, 그리고 영역 복원력이나 다중 리전 쓰기를 켠 Cosmos DB 계정은 이번 장애에서도 계속 동작했고, 영역 중복 SQL Database 도 프록시 모드로 연결한 일부 고객을 빼면 중단이 없었다.

   사례 보기

원인별11