사례11건

11건 중 6~10번째

1. IL-0009 ArgoCD Application 이름이 겹쳐 InfluxDB Cloud 운영 환경 하나가 통째로 삭제됐다

   InfluxData2022

   증상

   PR 하나를 머지한 직후 InfluxDB Cloud 운영 환경 하나가 통째로 사라졌다. 쓰기와 읽기를 비롯한 모든 API 엔드포인트가 404 오류를 냈다.

   서비스 중단리소스 삭제오류율 상승

   촉발

   팀원 한 명이 설정 파일에 새 객체 여러 개를 더하는 PR 을 올렸다. 그중 새 ArgoCD Application 과 AppProject 의 이름이 자동화 오류로 app02-cluster01 이 아니라 기존 것과 같은 app01-cluster01 로 정해졌다. 코드 리뷰에서도 app01 과 app02 의 차이를 알아채지 못해 PR 이 그대로 머지됐다.

   원인

   설정 변경

   구성 요소

   Argo CD영구 볼륨과 스테이트풀셋설정 템플릿

   기여 요인

   리뷰 누락런북 부재파괴적 변경 보호 장치 부재모니터링 사각지대자동화 증폭

   감지

   모니터링과 경보 시스템은 이 장애를 바로 잡아내지 못했다. 그래서 팀은 계획을 세워 복구하기 전에 먼저 변경을 되돌리려 했다. 팀이 장애를 무엇으로 알게 됐는지는 글에 나오지 않는다.

   조치

   • 머지된 PR 을 되돌리기 시작했다가 곧바로 멈췄다.
   • etcd 메타데이터 클러스터를 복원했다.
   • 지워진 쿠버네티스 객체를 다시 만들어 남아 있던 PersistentVolume 을 다시 쓸 수 있게 하고, StatefulSet 을 다시 만들었다.
   • Zookeeper 볼륨을 Velero 로 매시간 받아 둔 백업에서 복원했다.
   • 헬스 체크와 readiness 체크를 끈 채 Kafka StatefulSet 을 파드 하나씩 다시 만들었다.
   • 쓰기 선행 로그 역할을 하는 Kafka 로 다시 쓰기를 받고, 쓰기를 처리하는 컴포넌트의 레플리카 수와 메모리 request 와 limit 을 늘렸다.
   • 스토리지 파드를 다시 만들었다. 파드는 오브젝트 스토리지에서 데이터를 내려받아 인덱싱한 뒤 쓰기 선행 로그에 밀려 있던 데이터를 읽어 들였다.
   • ArgoCD, 쿼리, 대시보드, 예약 작업을 다시 켜고, 레플리카 수를 원래대로 돌린 뒤 최종 QA 점검을 했다.

   후속 조치

   • 상태를 되살리는 절차를 담은 런북을 만들었다. PVC 같은 쿠버네티스 객체는 지워졌지만 디스크와 볼륨에 데이터는 남아 있을 때 할 일을 자세히 적었다.
   • 모든 환경의 모든 볼륨이 PVC 객체가 지워져도 데이터를 유지하도록 설정했다.
   • 외부에 드러나는 장애를 다루는 절차를 개선했다.
   • 생성된 YAML 을 객체 하나당 파일 하나로 저장하도록 바꿨다. 예를 들어 etcd Service 는 v1.Service-(namespace).etcd.yaml 파일이 된다. 이제 이번과 같은 PR 은 새 객체를 더하는 변경이 아니라 기존 객체를 덮어쓰는 변경으로 보인다.
   • YAML 생성 도구가 중복 객체를 찾아 리뷰를 요청하기 전에 경고하도록 고쳤다. 파일 이름만 보지 않고, apiVersion 이 networking.k8s.io/v1beta1 과 networking.k8s.io/v1 처럼 달라도 네임스페이스와 이름이 같으면 같은 객체로 판단한다.
   • 모든 상태 저장 리소스와 ArgoCD 가 관리하는 Namespace 객체에 Prune=false 어노테이션을 달아, 설정이 잘못돼도 ArgoCD 가 지우지 않게 했다.
   • ArgoCD Application 에 FailOnSharedResource=true 옵션을 넣었다. 다른 Application 이 관리하거나 관리했던 객체를 바꾸려 하면 ArgoCD 는 변경을 적용하지 않고 동기화를 실패로 멈춘다.

   교훈

   무엇보다 모니터링과 경보가 장애를 바로 잡아내지 못했다. 그 탓에 팀은 계획된 복구 대신 롤백부터 시도했다. InfluxDB Cloud 인스턴스 일부나 전체를 잃었을 때 쓸 런북도 없었다. 상태 저장 애플리케이션은 변경을 되돌린다고 원래대로 돌아오지 않고, 데이터 없는 새 인스턴스가 생길 뿐이다. 이런 PR 은 시스템이 머지를 막았어야 했다. 볼륨을 Retain 으로 둔 데다 Telegraf 처럼 쓰기를 재시도하는 클라이언트가 있어서 데이터를 하나도 잃지 않았다.

   사례 보기
2. IL-0132 잘못된 리소스 정리 작업이 Vertex AI 예측 엔드포인트를 전역에서 삭제된 것으로 표시해 고객 모델이 내려가고 예측 요청이 4시간 넘게 실패했다.

   Google Cloud2022

   증상

   2022-06-02 10:10 US/Pacific 부터 Vertex AI Online Prediction 의 오류율이 올라갔다. 리전과 사용 패턴에 따라 요청의 30% 에서 100% 가 실패했다.

   오류율 상승리소스 삭제서비스 중단

   촉발

   잘못된 리소스 정리 작업이 Vertex 예측 엔드포인트를 전역에서 삭제된 것으로 표시했다.

   원인

   소프트웨어 결함

   구성 요소

   모델 요청 라우팅

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   Google 은 13:58 US/Pacific 에 상태 페이지에 첫 공지를 올렸고, 이 공지는 문제가 10:20 US/Pacific 에 시작됐다고 적었다. 나중에 나온 짧은 장애 보고서는 시작 시각을 10:10 으로 적었다.

   조치

   • 삭제된 것으로 표시된 Vertex 예측 엔드포인트를 복구했고, 서비스가 완전히 회복됐다.

   사례 보기
3. IL-0208 GitLab Helm 차트 업그레이드가 Service 와 Deployment 의 포트 이름을 바꿔 GCP 로드 밸런서가 다시 구성되는 동안 GitLab.com 요청이 느려지고 50x 오류가 났다

   GitLab2022

   증상

   2022-03-31 07:53 UTC 에 GitLab.com 웹 서비스의 50x 오류가 늘기 시작했고, 1분 뒤 당직 엔지니어가 오류율 증가 페이지를 받았다. 사용자에게는 GitLab.com 이 느려졌고 간헐적으로 500 오류 페이지가 떴다.

   오류율 상승지연 시간 증가간헐적 타임아웃

   촉발

   gitlab-com/gl-infra/k8s-workloads/gitlab-com!1643 머지 요청을 배포하는 파이프라인이 07:49 UTC 에 gprd-cny 로 배포를 시작했다. 이 변경에는 GitLab 차트 버전 업그레이드가 들어 있었고, 새 차트는 Prometheus ServiceMonitor, PodMonitor 설정과 관련된 변경으로 Kubernetes Service 와 Deployment 의 포트 이름을 바꿨다.

   원인

   설정 변경

   구성 요소

   Helm클라우드 로드 밸런서HAProxy

   기여 요인

   자동화 증폭

   감지

   07:53 UTC 에 50x 오류가 늘기 시작했고 07:54 에 PagerDuty 알림이 당직 엔지니어를 호출했다. 변경을 배포하던 엔지니어가 오류를 보고 그 변경과 연결해 원인을 짚었다.

   조치

   • 08:05 UTC 에 당직 엔지니어가 카나리 환경을 트래픽에서 뺐다가 08:25 에 다시 넣었다.
   • 08:15 에 cluster c 와 cluster d 배포 작업을 시작 전에 취소했다.
   • 08:51 에 HAProxy 에서 gprd-us-east1-d 클러스터를 뺐다가 08:56 에 다시 넣었다.
   • 09:31 에 최소 레플리카 수를 100 넘게 올리는 변경 !1650 을 머지했다.
   • 09:53 에 HAProxy 에서 gprd-us-east1-c 클러스터를 빼고, 09:57 에 이 클러스터에 !1643 을 배포한 뒤 10:07 에 다시 넣었다.
   • 10:19 에 최소 레플리카 상향을 되돌리는 변경 !1652 를 머지했다.

   후속 조치

   • 리전 클러스터 하나에서 트래픽을 통째로 안전하게 빼는 graceful drain 기능을 만든다.
   • PagerDuty 를 유지보수 모드로 바꾸는 ChatOps 명령을 만든다.

   교훈

   알림은 정확하게 울렸다. 원인이 바로 직전에 배포한 변경이라는 것을 알았기 때문에, 그 변경을 배포하던 파이프라인을 멈추는 것이 자연스러운 첫 대응이었다.

   사례 보기
4. IL-0049 CoreDNS 파드가 줄어든 뒤 kube-proxy 가 conntrack 항목을 지우지 못해 일부 서비스의 DNS 요청이 없어진 파드로 가면서 5xx 가 쏟아졌다

   Preply2020

   증상

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 당직자를 호출했다. 당직 엔지니어들은 22시 18분부터 VictorOps 호출을 받기 시작했다. Kibana 에서도 5xx 비율이 올라간 것이 보였다.

   DNS 조회 실패오류율 상승오래된 엔드포인트 라우팅

   촉발

   클러스터 안의 부하가 낮아지자 CoreDNS-autoscaler 가 CoreDNS 파드를 3개에서 2개로 줄였다.

   원인

   DNS·네트워크 장애

   구성 요소

   CoreDNSkube-proxyconntrack 테이블

   기여 요인

   자동화 증폭초기 신호 무시캐시 부재

   감지

   Prometheus 모니터링이 서비스 A, B, C 에서 5xx 비율이 높아진 것을 잡아 VictorOps 로 당직자를 호출했다. 포스트모템이 적은 감지 시간은 4분이다.

   조치

   • 22시 39분에 당직 엔지니어들이 해당 서비스의 최신 릴리스를 되돌렸다.
   • 정기 배포로 새 노드가 생기자 CoreDNS-autoscaler 가 CoreDNS 파드를 다시 늘렸고, conntrack 테이블이 자동으로 새로 쓰였다.

   후속 조치

   • CoreDNS 의 오토스케일러를 끈다.
   • 운영 환경에 DNS 캐시 서버를 둔다.
   • conntrack 사용량을 모니터링한다.

   교훈

   모니터링은 장애를 빨리 잡았고 대응도 빠르고 체계적이었다. 노드는 어떤 한도에도 닿지 않았다. 진짜 근본 원인은 아직 모른다. conntrack 의 특정 버그로 보인다. 팀이 정한 후속 조치는 모두 장애가 낳는 결과를 막는 것이지 근본 원인을 고치는 것이 아니다. 팀은 DNS 에서 문제가 날 수 있다는 것을 알고 있었지만 이 일을 우선해서 다루지 않았다.

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

   사례 보기

원인별6