사례2건

2건 중 1~2번째

1. IL-0230 쿠버네티스 업그레이드 도중 메인 운영 클러스터의 서비스 간 통신이 끊겨 모든 고객의 작업이 시작되지 않았다

   CircleCI2023

   증상

   2023-03-14 18:00 UTC 쯤 한 서비스에서 통신 오류가 늘기 시작했다. 곧 모든 고객의 파이프라인이 늦게 시작하다가 끝내 작업이 돌지 않았고, 18:19 UTC 에 상태 페이지에 작업 시작 지연이 올라왔다.

   서비스 중단간헐적 연결 실패DNS 조회 실패

   촉발

   3월 14일 17:40 UTC 쯤 인프라 팀이 전날 되돌렸던 구성 요소들을 다른 방식으로 다시 업그레이드했다. 전날 kube-proxy 를 되돌린 뒤로 iptables 동기화가 조금씩 실패하던 상태에서 업그레이드를 이어 가자 동기화 오류가 한꺼번에 치솟았다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   kube-proxykubeletCoreDNS클라이언트 쪽 DNS 리졸버와 캐시

   기여 요인

   부분 배포롤백 무효모니터링 사각지대수동 조치 악화

   감지

   팀은 3월 14일 18:00 UTC 에 한 서비스의 통신 오류가 늘어나는 것을 보고 장애를 알아챘다. 장애 통화에 사람이 더 들어오면서 영향이 여러 서비스로 퍼진 것을 확인했다. 3월 13일 롤백 뒤에 로그에 나온 소수의 Sync 실패 오류는 그때 알아채지 못했다.

   조치

   • 모든 노드를 차례로 재시작해 노드마다 iptables 규칙 집합을 새로 만들었고, 23:00 까지 모든 노드 교체를 마쳤다.
   • contexts 나 machine executor 를 쓰는 작업이 회복되지 않아 별도의 의존성 풀을 재시작했고, 3월 15일 01:15 UTC 에 모든 작업이 정상으로 돌았다.
   • 작업이 다시 돌기 시작하자 쌓인 작업을 처리하려고 용량을 늘렸다.
   • 망가진 큐 몇 개를 고치려고 RabbitMQ 노드를 재시작했다.

   후속 조치

   • 앞으로의 업그레이드에서 이런 위험을 크게 줄이도록 쿠버네티스 업그레이드 절차를 고친다.
   • 이번 장애 때 kube-proxy 가 낸 동기화 오류를 잡는 지표와 알림을 더했다.
   • RabbitMQ 인프라의 복원력을 높일 방법을 검토한다.

   교훈

   이번 장애를 촉발한 원인은 하나가 아니었다. 네트워크는 모든 것의 바탕이어서 쿠버네티스 업그레이드는 본래 위험하다. 여러 사건이 맞물려 터진 이번 경우에는 팀이 세워 둔 위험 완화 방법이 듣지 않았다.

   사례 보기
2. IL-0004 새 Cortex 클러스터에서 기본 우선순위를 받은 파드가 우선순위가 없는 운영 Ingester 를 연쇄적으로 선점해 Hosted Prometheus 쓰기가 실패했다

   Grafana Labs2019

   증상

   2019년 7월 19일 금요일, Grafana Cloud 의 Hosted Prometheus 서비스가 장애를 겪었다. 오류 예산 기반 Prometheus 알림이 장애 시작 4분 안에 당직자를 호출했다.

   파드 축출오류율 상승서비스 중단OOMKilled

   촉발

   7월 19일 한 엔지니어가 큰 고객을 위한 전용 Cortex 클러스터를 새로 띄웠다. 새 클러스터 설정에는 새로 도입한 파드 우선순위 지정이 없어서, 모든 파드가 기본값인 medium 우선순위를 받았다. 쿠버네티스 클러스터에는 새 Cortex 클러스터를 올릴 자원이 부족했다.

   원인

   설정 변경

   구성 요소

   파드 우선순위와 선점

   기여 요인

   부분 배포자동화 증폭리뷰 누락여유 용량 부재재시도 폭주

   감지

   새로 도입한 오류 예산 기반 Prometheus 알림이 장애 시작 4분 안에 당직자를 호출했다.

   조치

   • 쿠버네티스 클러스터를 늘려 새 Cortex 클러스터와 기존 운영 Cortex 클러스터가 모두 들어가게 했다.
   • Cortex 앞의 인증 리버스 프록시에서 난 OOM 을 찾아 고쳤다.

   후속 조치

   • 운영 Ingester 에 high 우선순위 지정을 반영했다.
   • 클러스터 전역 설정처럼 네임스페이스 밖에 있는 객체의 배포는 더 많은 사람이 리뷰한다.
   • 네임스페이스 밖 설정 변경에는 모두 설계 문서를 요구한다.
   • 인증 리버스 프록시의 규모 조정을 자동화해 과부하 때 OOM 이 나지 않게 한다.
   • 한꺼번에 몰려드는 재시도를 막으려고 Prometheus 의 기본 백오프와 확장 동작을 조사한다.

   교훈

   운영 Ingester 에 high 우선순위를 지정하기 전에 medium 을 기본 우선순위로 만들지 말았어야 했다. 운영 Ingester 의 high 지정도 더 일찍 배포했어야 했다. 팀은 이 변경이 설계 문서를 쓸 만큼 크지 않다고 보고 GitHub 이슈에서만 논의했다. 좋은 점도 있었다. Cortex 는 자원이 충분해지자 추가 조치 없이 스스로 회복했다. 팀은 새 로그 수집 시스템인 Grafana Loki 로 Ingester 가 정상적으로 종료됐는지 확인했다.

   사례 보기

원인별2