IL-0003 Monzo · 2017-10-27kubernetesaws
2017년 10월 27일 금요일 오후, Monzo 의 입출금 계좌와 선불 카드가 약 1시간 반 동안 장애를 겪었다. Monzo 백엔드는 마이크로서비스 수백 개로 이루어져 있다. 이 서비스들은 컨테이너로 돌고, 쿠버네티스가 AWS 노드 위에서 이 컨테이너들을 관리한다. 쿠버네티스는 서비스 배치 정보를 etcd 에 저장한다. 서비스 사이의 호출은 linkerd 가 라우팅하고 부하를 나누며, linkerd 는 서비스 위치를 쿠버네티스에서 받는다.
장애 2주 전 플랫폼 팀은 etcd 를 새 버전으로 올리면서 노드를 가용 영역 세 곳에 한 대씩 세 대에서 가용 영역마다 세 대씩 아홉 대로 늘렸다. 이 작업은 다운타임 없이 끝났다. 하지만 쿠버네티스와 etcd 클라이언트에는 이런 클러스터 재구성 뒤 요청이 타임아웃 날 수 있는 버그가 있었다. 장애 전날에는 한 팀이 문제를 보이던 새 서비스를 레플리카 0개로 줄였고, 쿠버네티스 서비스는 그대로 남겨 두었다.
14:10 에 결제 서비스 변경을 배포하자 그 서비스로 가는 요청이 모두 실패했다. etcd 클라이언트 버그로 생긴 타임아웃 때문에 linkerd 는 새 파드 위치를 받지 못했고, 롤백해도 오류는 그대로였다. 팀은 linkerd 수백 개를 모두 재시작했고, kubelet 이 설정을 받지 못하자 apiserver 세 개도 재시작했다. 재시작한 linkerd 는 엔드포인트가 없는 빈 서비스를 파싱하지 못해 NullPointerException 을 냈다. 사용 중인 쿠버네티스와 linkerd 버전이 서로 맞지 않았기 때문이다. 15:13 에 서비스 사이 트래픽이 모두 끊겨 플랫폼 전체가 멈췄다.
15:31 에 엔지니어들은 수정 코드를 살펴본 뒤 엔드포인트가 없는 서비스를 지우면 파싱 오류를 피할 수 있다는 것을 알았다. 레플리카 0개로 줄여 둔 그 서비스를 지우자 linkerd 가 서비스 디스커버리 정보를 읽어 들였고 플랫폼이 회복했다. Monzo 는 linkerd 를 모두 재시작한 결정이 좋은 뜻에서 나왔지만 잘못이었고, 또 다른 버전 비호환 문제를 드러내 장애를 키웠다고 밝혔다.
14:10 에 입출금 계좌 결제 처리에 필요한 서비스 하나를 배포하자 그 서비스로 가는 요청이 모두 실패했다. 이때부터 입출금 계좌 고객의 결제가 실패했다. 선불 카드는 이 서비스를 쓰지 않아 아직 영향이 없었다.
14:12 에 변경을 롤백했지만 오류는 그대로였고 결제는 계속 되지 않았다. 14:16 에 내부적으로 장애를 선언했다. 14:18 에 엔지니어들은 linkerd 가 비정상 상태로 보인다는 것을 확인하고, 문제 있는 노드를 찾아 재시작하는 내부 도구를 썼다. linkerd 는 새 파드가 네트워크 어디에서 도는지 쿠버네티스에서 갱신받지 못한 상태였고, 프로세스가 더는 없는 IP 주소로 요청을 보내고 있었다.
14:26 에 팀은 linkerd 인스턴스 수백 개가 모두 같은 문제를 겪는다고 보고 전부 재시작하기로 했다. 14:37 에는 재시작한 linkerd 가 뜨지 못했다. 각 노드의 kubelet 이 쿠버네티스 apiserver 에서 설정을 가져오지 못했기 때문이다. 팀은 쿠버네티스나 etcd 에 문제가 더 있다고 의심하고 apiserver 프로세스 세 개를 재시작했고, 그 뒤 linkerd 가 정상적으로 떴다.
15:13 에 linkerd 파드가 모두 재시작됐지만, 초당 수천 건을 처리하던 서비스들로 트래픽이 하나도 들어오지 않았다. 고객은 Monzo 앱에서 피드와 잔액을 새로 고칠 수 없었고, Customer Operations 팀의 내부 도구도 멈췄다. 장애는 플랫폼 전체 장애로 커졌고 자동 알림이 거의 모두 울렸다. 15:27 에 linkerd 가 쿠버네티스 apiserver 의 서비스 디스커버리 응답을 파싱하다 NullPointerException 을 로그에 남기는 것이 보였다.
14:10 배포 직후 그 서비스로 가는 요청이 모두 실패했고 입출금 계좌 결제가 실패하기 시작했다. 14:12 롤백 뒤에도 오류가 계속되자 14:16 에 내부적으로 장애를 선언했다. 15:13 에 플랫폼 전체가 멈추자 자동 알림이 거의 모두 울렸다.
분산 시스템의 대규모 장애는 이해하기 매우 어렵고, 사람이 좋은 뜻으로 한 조치가 오히려 문제를 키울 수 있다. 이번에는 linkerd 를 모두 재시작한 결정이 또 다른 버전 비호환 문제를 드러내 장애를 더 키웠다.
배포가 잦고 노드와 애플리케이션 장애에 자동으로 대응하는 백엔드에서는 네트워크가 매우 동적이다. 그래서 배포와 요청 라우팅 시스템을 믿을 수 있는 것이 무엇보다 중요하다. Monzo 는 인터페이스를 바꿀 때 앞뒤 버전과 호환되게 해서 롤백을 안전하게 할 수 있게 해 두었지만, 이번에는 롤백한 뒤에도 오류가 계속됐다.
IL-0077 Kyverno 1.12 가 만든 ephemeralreports 객체가 쌓여 EKS 의 etcd 데이터베이스가 한도를 넘었고 운영 클러스터가 읽기 전용이 되어 모든 쓰기가 거부됐다Marcin Cuber · 2024 · sev1같은 원인 · 공통 쿠버네티스 API 서버, etcd
IL-0072 etcd 쓰기 지연으로 API 서버가 오래된 데이터를 읽어 클러스터 상태가 두 가지로 번갈아 보였고, 주 운영 클러스터 전체가 약 4시간 멈췄다Nordstrom · 2017같은 원인 · 공통 쿠버네티스 API 서버, etcd
IL-0138 nvidia-dkms-390 드라이버 빌드 실패로 망가진 커널 헤더가 몇 주 동안 방치됐다가, 정전 뒤 재부팅하자 하나뿐인 마스터 노드가 커널 패닉에 빠져 홈랩 쿠버네티스 클러스터가 6일 동안 멈췄다.Barush Mendez · 2025같은 원인 · 공통 쿠버네티스 API 서버
IL-0112 나중에 회수된 EKS 노드 AMI 로 노드를 교체한 뒤 노드가 PLEG is not healthy 를 보고하며 NotReady 를 오갔고 파드 네트워크 타임아웃이 났다DFDS · 2022같은 원인 · 공통 kubelet
IL-0139 Calico 네트워크 정책을 쓰는 GKE 클러스터를 1.22 이상으로 업그레이드하자 경쟁 조건 때문에 CNI 정리가 Unauthorized 로 실패해 파드가 Terminating 이나 Pending 에 멈췄다.Google Cloud · 2022같은 원인 · 공통 kubelet
https://incidentlib-mcp.benchlet.com/mcpAPI 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.
IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.Grafana Labs · 2020같은 원인 · 공통 etcd
같은 원인 · 공통 kubelet
같은 원인 · 공통 쿠버네티스 API 서버