사례2건

2건 중 1~2번째

1. IL-0233 eu-west1 에서 Managed Kubernetes 의 거의 모든 파드가 네트워크 연결을 잃었고 롤백으로도 돌아오지 않았다

   Nebius2025

   증상

   2025-03-13 eu-west1 리전에서 Managed Services for Kubernetes 고객의 파드가 거의 모두 13:36 에서 18:11 UTC 사이에 적어도 한동안 네트워크 연결을 잃었다. Nebius 팀은 15:13 UTC 에 문제를 알아챘다. eu-north1 리전은 영향을 받지 않았다.

   네트워크 도달 불가

   촉발

   eu-west1 에 배포한 VPC 컨트롤 플레인 구성 요소의 릴리스가 새 기능에 필요한 route distinguisher 값을 바꿨다. 이 변경으로 오래전부터 코드에 있던 버그가 실제로 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 컨트롤 플레인BGP 라우팅

   기여 요인

   롤백 무효자동 테스트 공백모니터링 사각지대

   조치

   • 문제가 난 노드에서 구성 요소를 재시작하면 그 노드가 풀린다는 것을 찾고, 영향을 받은 모든 노드에서 구성 요소를 한 번에 한 노드씩 재시작하기 시작했다.
   • 17:57 UTC 에 구성 요소 재시작만으로 고쳐진다고 확신하고 병렬 재시작을 시작했다. 18:11 UTC 에 영향이 완전히 해소되었다.

   후속 조치

   • 버그 자체를 바로잡는다.
   • 경로 수가 어긋나면 울리는 알림을 더한다.
   • 데이터 플레인의 패킷 drop 수를 보는 알림을 더한다.
   • 호스트 VPC 구성 요소를 재시작하지 않고도 엔드포인트를 초기화하는 방법을 만든다.
   • VPC 의 상시 e2e 테스트 가상 머신을 카나리 호스트로 옮긴다.
   • Managed Services for Kubernetes 용 상시 e2e 테스트를 더한다.
   • e2e 테스트를 더 자주 돌린다.
   • 중요하지 않은 내부 서비스가 가장 먼저 업데이트를 받는 배포 단계를 새로 둔다.

   교훈

   문제를 재현하려면 두 조건이 함께 맞아야 해서 테스트 환경과 카나리의 e2e 테스트로는 잡지 못했다. 기술 지표가 평소 값에서 벗어날 때 울리는 알림이 모자라 대응이 늦어졌다. 이번 경우에는 경로 수와 패킷 drop 수가 민감하게 반응한 지표였다.

   사례 보기
2. IL-0003 etcd 클러스터 재구성 뒤 쿠버네티스 버그로 linkerd 가 서비스 위치 갱신을 받지 못했고, linkerd 를 모두 재시작하자 엔드포인트가 없는 서비스를 파싱하지 못하는 오류가 드러나 플랫폼 전체가 멈췄다

   Monzo2017

   증상

   14:10 에 입출금 계좌 결제 처리에 필요한 서비스 하나를 배포하자 그 서비스로 가는 요청이 모두 실패했다. 이때부터 입출금 계좌 고객의 결제가 실패했다. 선불 카드는 이 서비스를 쓰지 않아 아직 영향이 없었다.

   오류율 상승오래된 엔드포인트 라우팅서비스 중단

   촉발

   14:10 에 엔지니어가 입출금 계좌 결제 처리에 필요한 서비스에 변경을 배포했다. 2주 전 etcd 클러스터를 재구성한 뒤로 쿠버네티스와 etcd 클라이언트 버그가 요청 타임아웃을 낼 수 있는 상태였고, 이 때문에 linkerd 는 배포 뒤 새 파드의 위치를 받지 못했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd쿠버네티스 API 서버Linkerdkubelet

   기여 요인

   롤백 무효수동 조치 악화장애 중첩모니터링 사각지대단일 장애점

   감지

   14:10 배포 직후 그 서비스로 가는 요청이 모두 실패했고 입출금 계좌 결제가 실패하기 시작했다. 14:12 롤백 뒤에도 오류가 계속되자 14:16 에 내부적으로 장애를 선언했다. 15:13 에 플랫폼 전체가 멈추자 자동 알림이 거의 모두 울렸다.

   조치

   • 14:12 에 배포한 변경을 롤백했지만 오류는 계속됐다.
   • 고객 영향을 줄이려고 장애 때 쓰는 내부 백업 절차를 가동해 대부분의 고객이 계속 카드를 쓸 수 있게 했다.
   • 14:26 에 linkerd 인스턴스 수백 개를 모두 재시작하기 시작했고, 이 조치가 장애를 키웠다.
   • 14:37 에 kubelet 이 apiserver 에서 설정을 받지 못하자 apiserver 프로세스 세 개를 재시작했다.
   • 15:27 에 플랫폼 팀이 새 linkerd 버전을 배포하기 시작했다. 이 버전에는 비호환 문제를 고친 코드가 들어 있었고, 스테이징에서 몇 주째 시험하던 버전이었다.
   • 15:31 에 엔드포인트가 없는 쿠버네티스 서비스를 지워 linkerd 가 서비스 디스커버리 정보를 읽게 했고, 플랫폼이 회복했다.

   후속 조치

   • 클러스터 재구성 뒤 타임아웃을 일으킬 수 있는 쿠버네티스 버그를 고친다.
   • 파싱 오류를 고친 새 linkerd 버전을 배포한다.
   • 영향을 받은 구성 요소에 더 나은 헬스 체크, 대시보드, 알림을 만들어 무엇이 잘못됐는지 더 분명한 신호를 주고 사람의 실수를 막는다.
   • 장애를 내부와 외부에 더 분명하고 빠르게 알리도록 절차를 개선한다.

   교훈

   분산 시스템의 대규모 장애는 이해하기 매우 어렵고, 사람이 좋은 뜻으로 한 조치가 오히려 문제를 키울 수 있다. 이번에는 linkerd 를 모두 재시작한 결정이 또 다른 버전 비호환 문제를 드러내 장애를 더 키웠다. 배포가 잦고 노드와 애플리케이션 장애에 자동으로 대응하는 백엔드에서는 네트워크가 매우 동적이다. 그래서 배포와 요청 라우팅 시스템을 믿을 수 있는 것이 무엇보다 중요하다. Monzo 는 인터페이스를 바꿀 때 앞뒤 버전과 호환되게 해서 롤백을 안전하게 할 수 있게 해 두었지만, 이번에는 롤백한 뒤에도 오류가 계속됐다.

   사례 보기

원인별1