사례2건

2건 중 1~2번째

1. IL-0484 Slurm 업그레이드 뒤 GPU 설정이 맞지 않고 다운그레이드도 실패해 MIT CSAIL 공용 GPU 클러스터가 수요일 아침까지 멈췄다

   MIT CSAIL2025

   증상

   9월 8일 월요일의 계획된 점검에서 Slurm 24.05를 25.05로 올렸다. 화요일 아침에 업그레이드한 Slurm 패키지가 올바른 GPU 설정에 필요한 기능 없이 컴파일된 것이 드러났다. 클러스터는 정상 서비스로 돌아오지 못했다.

   업그레이드 정체서비스 중단

   촉발

   9월 8일 월요일의 계획된 점검에서 Slurm 24.05를 Slurm 25.05로 올렸고, 새 패키지가 GPU 설정에 필요한 기능 없이 컴파일되어 있었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   Slurm 작업 스케줄러데이터베이스 백업과 스냅숏

   기여 요인

   롤백 무효미검증 백업

   감지

   인프라 그룹은 점검 다음 날인 화요일 아침에 업그레이드한 Slurm 패키지가 GPU 설정에 필요한 기능 없이 컴파일되었다는 것을 발견했다.

   조치

   • 이전에 잘 돌던 Slurm 버전으로 다운그레이드했다.
   • 알려진 상태로 돌아가려고 모든 컴퓨트 노드에 OS를 다시 설치했고, 배포 서비스가 감당하지 못해 중간 상태로 남은 시스템은 하나씩 손봤다.
   • 단순 다운그레이드와 백업 복원이 실패하자 깨끗한 데이터베이스 위에 클러스터를 처음부터 다시 배포했다.

   후속 조치

   • 이번 장애에서 배운 것을 바탕으로 테스트와 배포 절차를 개선한다.

   교훈

   다운그레이드 과정에서 겪은 두 가지 큰 어려움은 배포 절차와 테스트 절차의 결함을 드러냈다. 모든 노드의 OS 재설치는 배포 서비스의 용량을 넘었고, 업그레이드 계획에서 놓친 부분 때문에 단순 다운그레이드와 백업 복원으로는 되돌릴 수 없었다.

   사례 보기
2. IL-0449 EKS 관리형 노드 그룹으로 옮긴 며칠 뒤 파드가 재시작을 되풀이하거나 Terminating 상태에 멈추고 노드를 쓸 수 없게 됐다

   Enigmo2020

   증상

   EKS 클러스터의 파드를 새로 만든 관리형 노드 그룹으로 옮기고 2~3일 지나자, 파드가 갑자기 재시작을 되풀이하거나 제대로 종료되지 못하고 Terminating 상태로 계속 남았다. 노드의 CPU 와 메모리 부하가 높아져 클러스터에서 노드를 쓸 수 없게 됐다.

   파드 Terminating 정체노드 CPU 고부하메모리 압박노드 NotReady업그레이드 정체

   촉발

   EKS 1.16 업그레이드를 앞두고 파드를 버그가 있는 AMI 로 만든 새 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   롤백 무효늦게 드러난 변경

   조치

   • 수정된 AMI 가 나오자 관리형 노드 그룹의 AMI 버전을 바꿨다.
   • CloudFormation 으로 관리형 노드 그룹 업데이트를 실행했다.
   • 업데이트가 도는 동안 kubectl get pods --all-namespaces 로 파드 상태를 지켜봤다.
   • Terminating 상태로 한동안 변화가 없는 파드를 찾을 때마다 kubectl delete pods <pod name> --grace-period=0 --force 로 강제로 지웠다.

   후속 조치

   • 분기나 달마다 각종 모듈의 최신 릴리스를 확인하고 정기적으로 업그레이드해, 서비스 영향을 가장 작게 하는 운영 방법을 찾는다.

   교훈

   Amazon EKS 나 쿠버네티스를 쓰는 한 클러스터 본체와 Ingress Controller 같은 모듈의 업그레이드를 늘 신경 써야 한다. 안정적으로 돈다고 한동안 손대지 않고 두면, 그사이 호환성을 깨는 변경이 담긴 릴리스가 갑자기 발표되는 일이 드물지 않다. 쿠버네티스 마이너 버전은 3개월쯤마다 나오므로 1년에 적어도 한 번은 업그레이드해야 한다.

   사례 보기

원인별1