사례10건

10건 중 6~10번째

1. IL-0231 EKS 클러스터의 워커 노드가 모두 꺼지고 새 노드가 뜨지 않아 Stytch API 가 14분 동안 완전히 멈췄다

   Stytch2023

   증상

   2023-02-23 20:48 UTC 에 운영 환경에서 Deployment Replicas Unavailable 알림이 울리기 시작했다. 21:10 UTC 에 운영 Live API 와 Test API 가 내려가 Stytch API 호출이 모두 5XX 를 냈고, 21:17 UTC 에는 Dashboard 와 SDK 도 내려갔다.

   노드 NotReady노드 증설 실패파드 축출파드 Pending서비스 중단

   촉발

   14:21 UTC 에 팀은 쓰지 않는 관리형 노드 그룹을 지우는 변경을 반영했고, 두 엔지니어가 AWS 콘솔에서 스테이징과 운영의 노드 그룹을 지웠다. 노드 그룹을 지우자 AWS 가 뒤에서 그 노드 그룹과 엮인 리소스를 정리하면서 Karpenter 노드도 쓰던 instance profile 을 지웠다.

   원인

   설정 변경

   구성 요소

   Karpenter노드 풀설정 템플릿

   기여 요인

   미검증 가정공용 자격 증명늦게 드러난 변경초기 신호 무시

   감지

   운영에서는 20:48 UTC 에 Deployment Replicas Unavailable 알림이 울렸고, 21:14 UTC 에 지원팀이 장애를 알렸다. 그보다 앞서 16:06 UTC 에 스테이징, 17:48 UTC 에 운영에서 Karpenter 가 instance profile 을 찾지 못한다는 낮은 긴급도 경고가 왔지만 급하지 않은 문제로 분류되었다. 20:26 UTC 에 Karpenter 오류율이 치솟자 팀은 장애 대응을 시작했다.

   조치

   • 노드 그룹 삭제를 되돌려 노드 그룹을 다시 만들었다. 새 파드는 새 노드가 뜨기를 기다려야 해서 충분히 빨리 스케줄되지 않았다.
   • Live API 노드 그룹 하나를 컴퓨팅 크기가 훨씬 큰 노드로 손으로 늘리고, 그 노드 그룹에서 taint 를 지웠다.
   • 애플리케이션의 node selector 를 차례로 지워 파드가 그 노드에 스케줄되게 했다. 몇 분 안에 애플리케이션마다 필요한 수의 노드에 파드가 스케줄되었다.

   후속 조치

   • Karpenter 오류의 심각도를 올려 당직 호출기로 바로 가는 높은 긴급도 알림으로 다룬다.
   • 클러스터 알림의 임계값을 조정해 높은 긴급도 호출이 더 일찍 가게 한다.
   • 노드가 오랫동안 NotReady 나 Unknown 으로 표시되면 알림을 보내 기존 노드의 상태를 더 잘 지켜본다.
   • 스케줄할 수 없는 파드, 사용할 수 없는 레플리카를 비롯한 다른 배포 관련 알림의 임계값을 올린다.
   • Karpenter 가 쓰는 IAM instance profile 을 노드 그룹이 쓰는 IAM profile 과 다른 것으로 바꾼다.
   • 여러 용도로 겹쳐 쓰던 다른 AWS 리소스, 특히 IAM 과 보안 그룹을 나눈다.
   • EKS 와 Karpenter 설정을 크게 고쳐 복잡도를 줄인다. 새 시스템 instance profile 은 Karpenter 가 클러스터마다 고유하고 고정된 이름으로 만들게 한다.
   • 개발팀이 인프라를 바꿀 때 쓸 수 있도록 클라우드 시각화 도구를 들인다.
   • 상태 페이지에 실시간 시스템 지표와 제품 지표를 넣어 Stytch API 가 지금 어떻게 동작하는지 보여 준다.
   • 문서에 없는 동작과 부작용을 AWS 에 문의해 확인한다.
   • 인프라에서 IAM 역할과 보안 그룹을 여러 용도로 겹쳐 쓰던 것을 바로잡는다.

   교훈

   Karpenter 의 자체 관리 노드에 노드 그룹과 같은 IAM 역할을 쓰지 말았어야 했다. 한 IAM 역할을 여러 용도로 겹쳐 쓰면 이번 같은 문제가 그대로 난다. 팀은 Karpenter 를 처음 설정할 때 빠르고 단순하게 하려다 역할을 나누지 않았다. 원인과 결과 사이가 몇 시간 벌어져 있어 장애 전체를 판단하기 어려웠다. AWS 는 이 지연이 예상된 동작이라고 확인했고, 팀은 앞으로 IAM instance profile 을 바꿀 때 이를 고려한다.

   사례 보기
2. IL-0070 dask-gateway로 워커를 대량으로 띄우자 노드가 1분 만에 100대 늘었고, Prometheus가 메모리를 거의 다 쓰던 코어 노드에서 hub 파드를 비롯한 중요한 파드들이 축출되거나 재시작됐다

   2i2c2023

   증상

   2023년 2월 1일 leap 클러스터의 prod 허브에서 노드가 대량으로 늘었고, hub 파드가 알 수 없는 이유로 재시작됐다. 사용자 지원 티켓도 들어왔다.

   파드 축출파드 Pending

   촉발

   한 사용자의 dask-gateway 작업이 1분 사이에 dask-worker 노드를 100대쯤 늘렸고, Prometheus 는 노드 200대쯤의 지표 내보내기 대상을 수집하기 시작했다.

   원인

   용량 한계

   구성 요소

   Prometheus노드 풀

   기여 요인

   여유 용량 부재과도한 영향 범위모니터링 사각지대

   감지

   2i2c Freshdesk에 들어온 사용자 지원 티켓 414로 드러났다. 이후 엔지니어가 Grafana와 클러스터의 노드, event를 살폈다. 조사 내용은 같은 날 UTC+1 기준 저녁 8시에서 9시 사이에 이슈에 정리됐다.

   후속 조치

   • basehub에서 hub와 proxy 파드의 CPU와 메모리 요청을 넉넉히 설정한다. 이슈 #2127이다.
   • Grafana의 OOMKiller 대시보드가 제대로 동작하게 고친다. 이슈 #2213이다.
   • LEAP 클라우드 인프라를 공유 노드 구성으로 옮긴다. 이슈 #2209다.
   • ingress-nginx와 Prometheus의 리소스 요청과 한도를 고친다. Prometheus 서버는 메모리 요청을 한도와 같게 맞춘다. 이슈 #2324다.
   • Prometheus가 daskhub 워커 파드를 수집하도록 넣은 설정이 필요한지 다시 본다. 이슈 #2366이다.

   교훈

   Prometheus 서버처럼 메모리를 많이 쓰는 파드가 요청보다 훨씬 많이 쓰면 같은 노드의 중요한 파드가 축출된다. 노드가 한꺼번에 100대 늘면 Prometheus가 수집할 대상도 함께 늘어난다. hub와 proxy처럼 중요한 파드는 실제 사용량보다 요청을 넉넉히 잡아야 축출과 CPU 부족을 피할 수 있다. 쿠버네티스 event는 60분이 지나면 사라지므로, OOMKill 여부를 나중에 확인하려면 따로 기록해 두어야 한다.

   사례 보기
3. IL-0442 운영 중인 KEEL 쿠버네티스 클러스터에서 priority 0 파드가 한꺼번에 선점되어 istio-ingressgateway 를 비롯한 파드가 재시작되고 서비스가 잠시 끊겼다

   LIFULL2021

   증상

   새 PriorityClass 를 적용하고 low PriorityClass 파드의 선점을 확인한 직후 팀에 알림이 대량으로 왔다. 알림은 외부 모니터링에서 왔고, 클러스터 밖에서 들어오는 요청의 오류율이 급격히 올라가 있었다.

   파드 축출오류율 상승

   촉발

   운영 중인 KEEL 클러스터에 globalDefault: true 이고 value: 1000 인 medium PriorityClass 를 배포했다.

   원인

   설정 변경

   구성 요소

   파드 우선순위와 선점인그레스 컨트롤러

   기여 요인

   미검증 가정

   감지

   외부 모니터링에서 클러스터 밖 요청의 오류율이 급격히 올랐다는 알림이 팀에 대량으로 왔다.

   후속 조치

   • PriorityClass 를 여섯 개로 다시 정의했다. low 와 low-nonpreempting 은 value: -10, medium 과 medium-nonpreempting 은 value: 0, high 와 high-nonpreempting 은 value: 10 이고, nonpreempting 쪽에는 preemptionPolicy: Never 를 뒀다. globalDefault: true 는 value 가 0 인 medium 에 두어, 나중에 PriorityClass 를 설정해도 기존 파드가 선점되지 않게 했다. cluster-autoscaler 는 priority 가 --expendable-pods-priority-cutoff 기본값보다 낮은 파드를 무시하므로, 하한을 -10 으로 정했다.

   교훈

   운영 중인 클러스터에 PriorityClass 를 설정할 때는 조심해야 한다. 모든 파드의 기본 priority 는 0 이어서 PriorityClass 설정이 의도하지 않은 선점을 일으킬 수 있다. globalDefault: true 인 PriorityClass 의 값이 0 을 넘으면 도입 전의 모든 파드가 선점 대상이 된다. 멀티 테넌시 클러스터라면 사용자가 PriorityClass 를 마음대로 배포하지 못하게 권한을 좁히고, ResourceQuota 나 OPA Gatekeeper 로 쓸 수 있는 PriorityClass 를 세밀하게 통제해야 한다.

   사례 보기
4. 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 가 정상적으로 종료됐는지 확인했다.

   사례 보기
5. IL-0038 kubelet 설정 변경을 롤링 업데이트하다 쿠버네티스 버그로 kubelet 이 올라오지 못해 한 클러스터의 노드가 NotReady 가 되고 파드 절반쯤이 축출됐다

   Oath2018

   증상

   kubelet 변경을 클러스터 전체에 롤링 업데이트하던 중 kubelet 이 다시 올라오지 못했다. 쿠버네티스 API 는 노드가 죽었다고 판단했고 노드들이 NotReady 상태로 바뀌었다.

   노드 NotReady파드 축출파드 Pending

   촉발

   kubelet 변경을 롤링 업데이트로 배포했다. kubelet 은 재시작할 때 시작 전에 임시 cgroup 파일을 정리하는데, 이 과정에서 쿠버네티스 버그로 멈췄다. 이 업데이트가 한 클러스터의 노드 전체로 퍼졌다.

   원인

   소프트웨어 결함

   구성 요소

   kubelet쿠버네티스 컨트롤러 매니저

   기여 요인

   헬스 프로브 부재과도한 영향 범위

   감지

   업데이트 중 kubelet 이 올라오지 않으면서 노드가 NotReady 로 바뀌었고, 그래프에서 eviction 큐에 들어가 축출되는 노드 수가 늘어나는 것이 보였다.

   조치

   • 해당 데이터 센터에서 다음 데이터 센터로 페일오버해 사용자를 옮겼다.

   후속 조치

   • kubelet 업데이트를 적용한 뒤 테스트 프레임워크로 kubelet 을 검증하고, 검증이 끝나야 다음 30% 묶음의 업데이트로 넘어가게 했다.

   교훈

   kubelet 을 업그레이드한 뒤에는 반드시 테스트한다. kubelet API 에 간단한 curl 명령 하나만 보내 봐도 충분하다. 노드 컨트롤러는 노드의 50% 이상이 NotReady 가 되면 축출 속도를 늦추고, 노드가 모두 내려가면 full disruption 모드로 들어가 축출을 멈춘다. 이 동작 덕분에 이번 장애에서 파드의 절반이 살아남았다. 데이터 센터와 클러스터가 여럿이면 품질이 떨어진 데이터 센터에서 다른 데이터 센터로 페일오버해 사용자를 빠르게 옮길 수 있다.

   사례 보기

원인별4