사례10건

10건 중 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-0084 베어메탈 업체 vSwitch 의 패킷 드롭으로 Namespace 의 fra3 리전이 빠져 전 세계 용량이 모자랐고, 다음 날에는 컨트롤 플레인 노드의 느린 NVMe 쓰기로 쿠버네티스 API 서버 CPU 가 치솟아 zrh1 이 멈췄다.

   Namespace2024

   증상

   10월 17일부터 fra3 리전에서 패킷이 드문드문 버려지기 시작했다. 처음 이틀은 TCP 와 QUIC 의 재전송이나 컨트롤 플레인의 재시도로 대부분 넘어갔지만, 시스템이 조금씩 불안정했다. 이런 실패는 비결정적이라 겉으로 잘 드러나지 않았다.

   간헐적 연결 실패지연 시간 증가컨트롤 플레인 지연서비스 중단

   촉발

   fra3 에서 베어메탈 업체의 vSwitch 를 지나는 패킷이 무작위로 드문드문 버려지기 시작했다. 두 번째 장애는 컨트롤 플레인 노드 하나의 느린 NVMe 가 쿠버네티스의 변경 속도를 더는 따라가지 못하면서 일어났다.

   원인

   클라우드 제공자 장애

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   용량 계획 부재여유 용량 부재장애 중첩

   감지

   패킷 드롭은 비결정적이라 바로 보이지 않았다. 주요 상호작용에 잡아 둔 백분위 지연 SLO 의 에러 버짓이 줄어드는 것을 보고 영향을 알아챘다.

   조치

   • fra3 의 고객 트래픽을 모두 다른 리전으로 돌렸다.
   • vSwitch 대신 Wireguard 로 업체의 물리 머신 하나하나를 zrh1 클러스터에 연결했다.
   • 각 머신을 새 신원, 새 인증서, 새 저장 데이터 암호화 키로 다시 깔았고, 복구를 앞당기려고 캐시를 버렸다.
   • 팀 일부가 데이터셋을 더 분산된 방식으로 복제해 머신을 다시 까는 작업을 앞당겼다.
   • 준비된 머신을 묶음으로 새 리전에 넣고, 충분히 모이자 리전을 컴퓨트 풀에 다시 넣었다.
   • 두 번째 장애에서 워크로드를 zrh1 밖으로 돌렸다.
   • 실패하던 컨트롤 플레인 노드의 핵심 상태를 더 큰 노드로 복제하고, 새 노드가 같은 IP 주소로 옛 노드의 역할을 넘겨받게 했다.

   후속 조치

   • 장애 동안 실행된 모든 인스턴스의 요금을 고객에게 크레딧으로 환급했다.
   • 비슷한 상황이 다시 와도 고객에게 영향을 주지 않도록 백업 리전과 대안을 만든다.

   교훈

   비결정적인 네트워크 드롭은 재시도에 가려져서 SLO 기반 모니터링으로 긴 시간을 봐야 영향이 드러난다. 핵심 인프라의 문제를 직접 고칠 수단을 갖고 있어야 한다. 큰 장애 직후에는 같은 종류의 원인에 매이기 쉽다. 이번 두 번째 장애는 전혀 다른 종류였다. 미리 해 둔 모의 위기 훈련 덕분에 대응을 바로 체계적으로 시작할 수 있었다.

   사례 보기
3. IL-0024 무거운 API 요청이 MongoDB 에 과부하를 걸고 취소되지 않은 요청이 쌓여 Hugging Face Hub 가 사흘 동안 세 번 멈췄다

   Hugging Face2024

   증상

   2024-04-22 CET 8:45 부터 Hugging Face Hub 가 불안정해졌고, 9:30 에는 응답하지 않았다. 대부분의 사용자에게 Hub 웹사이트가 느려지거나 아예 열리지 않았다.

   서비스 중단지연 시간 증가데이터베이스 과부하

   촉발

   *_info_cache 컬렉션을 쓰는 무거운 API 요청이 갑자기 늘었다. 첫 장애 직전에는 https://huggingface.co/api/datasets/lighteval/mmlu/revision/main 호출이 크게 늘었고, 4월 23일 밤에는 https://huggingface.co/api/models/sentence-transformers/all-mpnet-base-v2/revision/main 요청이 늘었다.

   원인

   소프트웨어 결함

   구성 요소

   애플리케이션 데이터베이스모델 허브클러스터 오토스케일러

   기여 요인

   여유 용량 부재재시도 폭주장애 중첩

   감지

   장애는 4월 22일 8:45 부터 Hub 가 불안정해지다가 9:30 에 응답하지 않으면서 드러났다. MongoDB Atlas 지표에서 읽기 전용 노드 두 대가 계속 재시작하는 것이 보였다. 24일 10:03 에는 팀이 수상한 지표를 보고 Hub 가 다시 멈추기 전에 rate limit 을 걸었다. 근본 원인은 URL 별 요청 수 그래프를 새로 만든 뒤에 찾았다.

   조치

   • Java/* user-agent 를 단 요청을 모두 막는 방화벽 규칙을 넣었다.
   • Hub 의 quicksearch 기능을 껐다.
   • MongoDB Atlas 클러스터를 손으로 tier 2 에서 tier 3 으로 올렸다.
   • AWS WAF 로 유지보수 모드를 켜 503 페이지를 띄우고 들어오는 트래픽을 막았다.
   • Hub 파드를 모두 0 으로 줄였다가 다시 올렸다.
   • 아주 엄격한 rate limit 을 걸었다.
   • 요청에 타임아웃을 넣고, 오래 걸리거나 응답 본문이 큰 데이터베이스 쿼리를 다시 짰다.

   후속 조치

   • 요청마다 평소 완료 시간에 맞춘 타임아웃을 넣었다.
   • 장애 중 오래 걸리거나 응답 본문이 큰 요청을 찾아 최적화하고, 잘못 설계된 데이터베이스 쿼리를 다시 짰다.
   • 쓰지 않는 오래된 인덱스를 지워 데이터베이스를 정리했다.
   • 장애 중 새 대시보드와 모니터링 지표를 만들었다.
   • *_info_cache 를 Redis 로 옮긴다.
   • 클라이언트가 요청을 취소하면 데이터베이스 요청도 취소할 수 있게 한다.

   교훈

   Hub 팀은 모든 차트를 봐도 답이 없을 때 URL 별 요청 수라는 새 그래프를 만들어서야 원인을 찾았다. 클라이언트가 떠난 뒤에도 서버가 데이터베이스 요청을 계속 돌리면, 서비스가 느려졌을 때 사용자가 누르는 새로고침이 부하를 몇 배로 키운다. 무거운 요청 몇 가지가 데이터베이스 전체를 흔들 수 있으므로 요청별 타임아웃과 취소가 필요하다. 팀은 이번 일로 어떤 지표를 더 가까이 봐야 장애를 미리 막을 수 있는지 알게 됐다. 원인을 찾는 데 2-3일이 걸렸고, 관계없는 장애가 동시에 겹쳐 복구가 더 힘들었다.

   사례 보기
4. IL-0114 클러스터 용량을 늘리던 중 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트돼 새 파드가 IP 를 받지 못하고 Pending 에 머물렀고, 메인넷 운영 환경의 정산이 약 3.5시간 멈췄다.

   CoW Protocol2024

   증상

   2024년 4월 19일 16:40 UTC 에 메인넷 운영 환경에서 정산이 멈췄다. 핵심 서비스가 내려가 있었다.

   파드 PendingIP 주소 고갈파드 축출서비스 중단

   촉발

   클러스터 용량을 늘리는 IaC 자동화가 돌면서, IaC 에 버전이 고정되지 않은 VPC CNI 플러그인이 자동으로 업데이트됐다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI노드 풀

   기여 요인

   버전 미고정장애 중첩

   감지

   장애는 16:40 UTC 에 정산이 멈추면서 시작됐다. 팀은 23분 뒤인 17:03 UTC 에 CNI 버전 불일치를 원인으로 짚었다.

   조치

   • 19:00 UTC 쯤 쿠버네티스 클러스터 업그레이드를 시작했다.
   • 새 버전의 네트워크 플러그인을 쓰는 노드 그룹을 새로 만들었다.

   교훈

   IaC 스크립트에 버전을 명시해야 의도치 않은 업데이트를 막을 수 있다. 운영 환경일수록 쉽게 되돌릴 수 있는 변경 관리가 필요하다.

   사례 보기
5. 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 를 두기로 했다.

   사례 보기

원인별6