사례9건

9건 중 6~9번째

1. IL-0489 Kubernetes 위 3노드 MySQL 클러스터에 노드를 다시 붙이다 메타데이터가 깨져 Magic Pages 고객 사이트가 내려갔다

   Magic Pages2025

   증상

   2025-01-15 09:55 CET 무렵부터 11:36 CET까지 데이터베이스 장애로 Magic Pages의 고객 웹사이트가 영향을 받았다. 노드 세 대로 된 MySQL 클러스터에서 내려간 노드를 다시 붙이려 하자 데이터베이스 서버가 메타데이터 정보가 없다는 모호한 오류를 냈다.

   서비스 중단

   촉발

   그날 앞서 MySQL 클러스터의 세 노드 중 하나가 내려갔고, 창업자가 그 노드를 클러스터에 다시 붙이려 했다.

   원인

   의존성 장애

   구성 요소

   데이터베이스영구 볼륨과 스테이트풀셋

   기여 요인

   수동 조치 악화단일 장애점모니터링 사각지대

   조치

   • PVC 프로비저닝 문제를 풀려고 스토리지 서버를 재시작했다. 재시작은 몇 초 만에 끝났다.
   • 스토리지가 돌아온 뒤 클러스터 메타데이터를 다시 만들 수 있도록 MySQL 노드들이 복원되고 서로 동기화되기를 약 45분 기다렸다.
   • 깨진 클러스터 메타데이터를 정리했다.
   • 데이터베이스 노드로 트래픽을 보내는 MySQL Router를 다시 배포했다.

   후속 조치

   • 스토리지 시스템의 상태 모니터링을 강화한다.
   • MySQL Router의 장애 조치 절차를 개선한다.
   • 상태 페이지가 믿을 만한 정보를 보이도록 문제를 조사하고 고친다.

   교훈

   고가용성 구성 덕분에 데이터는 잃지 않았고 첫 노드 장애도 클러스터가 문제없이 넘겼다. 하지만 중복 구성인데도 클러스터 메타데이터가 단일 장애 지점이었다. PVC 상태를 더 잘 모니터링했다면 비슷한 문제를 막을 수 있었고, 45분 걸린 복구는 더 줄일 여지가 있다. 상태 페이지는 고객 사이트 실패를 감지하도록 설정했는데도 이 장애를 바로 알아채지 못했다.

   사례 보기
2. IL-0021 GKE 의 COS 노드가 NVIDIA GPU 드라이버를 403 Forbidden 으로 받지 못해 새로 만든 GPU 노드를 쓸 수 없었다

   Google Cloud2024

   증상

   2024-03-12 US/Pacific 08:00 부터 GKE 에서 Container-Optimized OS 를 쓰는 GPU 노드가 일부 NVIDIA GPU 드라이버를 받지 못했다. 새로 만들거나 다시 만든 노드는 GPU 드라이버가 작동하지 않았고, 그 드라이버를 쓰는 워크로드가 돌지 못했다.

   GPU 인식 불가노드 NotReady

   원인

   의존성 장애

   구성 요소

   GPU 드라이버노드 운영체제 이미지노드 풀

   기여 요인

   자동화 증폭

   감지

   보고서는 Google 이 장애를 어떻게 알아챘는지 적지 않았다. GKE 사용자는 GPU 노드에서 드라이버를 설치할 때 "Failed to download GPU driver installer, status: 403 Forbidden" 오류를 보고 이 장애를 알아볼 수 있었다.

   조치

   • GPU 드라이버 다운로드를 시도하는 자동 노드 재생성을 멈췄다.
   • 드라이버를 공급하는 파트너와 함께 스토리지 버킷 접근 문제를 해결했다.

   교훈

   상태 페이지 보고서는 교훈이나 후속 조치를 적지 않았다.

   사례 보기
3. IL-0039 CentOS 저장소 재구성으로 kops nodeup 에 하드코딩된 container-selinux 패키지 주소가 깨져 새 워커 노드가 클러스터에 합류하지 못했다

   FREE NOW2019

   증상

   Prelive 클러스터에 배포하던 개발자들이 #ask-platform 슬랙 채널에 배포가 실패한다고 알렸다. 16:00 에 첫 제보가 왔고 16:06 에 두 번째 제보가 왔다.

   파드 Pending노드 증설 실패

   촉발

   CentOS 저장소가 재구성되면서 container-selinux 패키지의 고정 다운로드 주소를 더는 쓸 수 없게 됐다. kops 는 nodeup 에 이 주소를 하드코딩해 두었고, docker-ce 를 실행하려면 이 패키지가 필요했다.

   원인

   의존성 장애

   구성 요소

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

   기여 요인

   모니터링 사각지대

   감지

   팀은 개발자들이 배포가 실패한다며 #ask-platform 슬랙 채널에 도움을 요청하면서 장애를 알게 됐다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다.

   조치

   • Prelive 노드에서 패키지를 손으로 내려받아 부트스트랩을 끝내고 노드를 클러스터에 합류시켰다.
   • 클러스터 AMI 를 Amazon Linux 2 에서 Debian 으로 바꿔 Prelive 에서 확인한 뒤 모든 클러스터에 적용했다.

   후속 조치

   • 노드가 클러스터에 합류하지 못하는 상황을 알려 주는 알림을 만든다. cluster-autoscaler 가 이 정보를 갖고 있을 수 있다.
   • 노드 시작에 필요한 외부 의존성을 문서로 정리하고 줄일 방법을 찾는다.
   • kops 가 이 문제를 고치면 AMI 를 Amazon Linux 2 Minimal 로 되돌린다.
   • 클러스터 노드 문제 해결 문서를 보강해, 부트스트랩 중에 무슨 일이 일어나고 로그가 어디에 남는지 적는다.

   교훈

   kops 와 Jenkins 로 클러스터 변경을 적용하는 흐름은 잘 동작했다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다. 일부 오토스케일링 그룹의 워커 인스턴스 수와 쿠버네티스에 등록된 워커 노드 수가 오랫동안 달랐는데도 아무도 알아채지 못한 것은 잘못이었다. 문제가 이어지는 동안 운영 환경의 스팟 인스턴스가 대량으로 종료되지 않은 것과 업무 시간에 발견한 것은 운이 좋았다.

   사례 보기
4. IL-0073 Kafka 연결이 끊기자 로깅 사이드카가 Docker 데몬에 부하를 주어 노드가 줄줄이 비정상이 되었고, 재스케줄링으로 생긴 노드 약 41,000개가 Consul gossip 메시를 오염시켜 Vault 와 배포 엔진까지 멈췄다

   Target2019sev1

   증상

   어느 저녁 데이터센터 OpenStack 의 네트워크 하위 시스템을 업그레이드한 뒤 Kafka 연결이 몇 시간 동안 간헐적으로 끊겼다. 개발 환경 워크로드 약 2,000개를 올린 큰 쿠버네티스 클러스터에서 노드들이 쿠버네티스에 비정상이라고 보고하기 시작했다.

   노드 NotReady부하 불균형지연 시간 증가자격 증명 획득 실패

   촉발

   OpenStack 의 네트워크 하위 시스템을 업그레이드하다가 예상과 달리 네트워크가 몇 시간 동안 끊겼고, Kafka 에는 간헐적으로만 닿았다. 그러자 모든 워크로드에 딸린 로깅 사이드카가 한꺼번에 깨어나 노드의 Docker 데몬에 높은 부하를 주었다.

   원인

   의존성 장애

   구성 요소

   컨테이너 런타임서비스 디스커버리텔레메트리 에이전트파드용 자격 증명 중개자

   기여 요인

   과도한 영향 범위자동화 증폭단일 장애점미패치 알려진 버그

   조치

   • Consul 의 gossip 암호화를 켜서 오염된 gossip 메시에서 오는 메시지를 바로 거부하게 했고, 이것으로 Consul 과 Vault 를 되살렸다.
   • 배포 엔진을 안정시킨 뒤 암호화 설정을 반영하려고 개발 환경 전체를 다시 배포했고, 암호화가 설정되지 않은 인스턴스는 종료했다.
   • 큰 클러스터를 다루는 수정이 들어간 Consul 1.2.3 으로 제자리 업그레이드했고, UI 버그 때문에 최종적으로 1.3.0 으로 올렸다. 운영 환경의 오염된 gossip 메시도 이 업그레이드로 빠르게 정리됐다.

   후속 조치

   • 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이므로, 데몬 하나의 장애가 미치는 범위를 줄이는 데 더 힘쓴다. 작은 클러스터를 여러 개 두는 방침과 같은 방향이다.

   교훈

   글쓴이는 작은 클러스터를 여러 개 두라는 자신의 원칙이 옳았다고 확인했다. 더 작은 개발 클러스터와 운영 클러스터의 워크로드는 큰 클러스터처럼 영향을 받지 않았고, 개발과 운영이 한 클러스터에 있었다면 훨씬 큰 일이 났을 것이다. 노드의 워크로드가 함께 쓰는 Docker 데몬은 깨지기 쉬운 장애 지점이다. 워크로드마다 자기 로깅 사이드카와 메트릭 사이드카를 두는 방식이 옳다고도 확신하게 됐다. 이것들이 클러스터 공용 자원이었다면 문제가 거의 틀림없이 더 커졌고 고치기도 훨씬 어려웠을 것이다.

   사례 보기

원인별1