사례43건

43건 중 18~22번째

1. IL-0522 ingress-nginx Helm 차트 패치 업그레이드 뒤 jenkins.io 의 Ingress 가 지워져 사이트가 HTTP/503 을 냄

   Jenkins project2021

   증상

   2021년 11월 18일 11:32 UTC, 한 사용자가 Gitter 채널 jenkinsci/jenkins 에 https://www.jenkins.io/doc/pipeline/steps/ 가 HTTP/503 오류를 낸다고 알렸다. 화면에는 Fastly 의 Varnish 가 내는 "Guru meditation" 메시지가 떴다.

   서비스 중단리소스 삭제

   촉발

   2021년 11월 18일 10:42 UTC 에 nginx Helm 차트를 패치 버전인 4.0.6 에서 4.0.8 로 올리는 배포가 성공했다. 새 버전은 `{}` 같은 Nginx 설정 블록이 든 Ingress 어노테이션을 막는 어드미션 웹훅 규칙을 새로 만들었다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   인그레스 컨트롤러어드미션 웹훅HelmCDN 과 엣지 네트워크

   기여 요인

   미검증 가정캐시로 가려진 장애모니터링 사각지대수동 조치 악화

   감지

   장애가 시작되고 25분 뒤인 11:32 UTC 에 사용자가 Gitter 채널 jenkinsci/jenkins 에 신고해 알았다. origin.jenkins.io 에는 오류를 알릴 모니터링이 없었다.

   조치

   • 13:40 UTC 에 자동화 시스템을 모두 멈춘 채 nginx Helm 차트를 이전 버전 4.0.6 으로 롤백하고, 어드미션 웹훅 구성을 손으로 지워 jenkins.io 를 되살렸다.
   • jenkins-infra/charts 에서 jenkins.io 설정의 금지된 어노테이션을 지웠다.
   • jenkins.io Helm 차트를 nginx 4.0.8 에서 제대로 동작한다고 알려진 마지막 버전으로 올렸다.
   • 필요한 수정을 모두 적용한 뒤 17:11 UTC 에 자동화 시스템이 jenkins.io Helm 차트를 다시 배포해 사이트가 돌아왔고, Fastly 에 모든 페이지의 캐시를 비우게 했다.

   후속 조치

   • 인그레스 컨트롤러를 업데이트할 때는 항상 변경 기록을 깊이 읽고, 적어도 두 사람이 실시간으로 함께 본다.
   • www.origin.jenkins.io 의 장애를 잡아내도록 Datadog 에 이 도메인의 모니터링을 더한다.
   • 이 모니터링은 Host 헤더를 www.jenkins.io 로 보내, Fastly 를 거치는 jenkins.io 로 리디렉션되지 않게 한다.
   • 첫 페이지만이 아니라 pipeline steps 페이지 같은 여러 페이지를 점검 대상에 넣는다.
   • 운영에 배포하기 전에 k3s 로 잠깐 띄웠다 지우는 엔드 투 엔드 시험 환경을 두는 방안을 다음 분기에 검토한다.

   교훈

   인그레스 컨트롤러처럼 민감한 구성 요소는 패치 버전 업그레이드라도 변경 기록을 깊이 확인해야 한다. 원본 호스트인 origin.jenkins.io 를 직접 지켜보는 모니터링이 없으면 CDN 뒤에서 난 오류를 사용자 신고로 처음 알게 된다.

   사례 보기
2. 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 를 세밀하게 통제해야 한다.

   사례 보기
3. IL-0209 웹 파드의 HPA CPU 목표값이 너무 높아 트래픽을 넘겨받는 동안 파드가 늘지 않았고, GitLab.com 웹 지연 SLO 가 약 15분 동안 깨졌다.

   GitLab2021

   증상

   2021년 8월 24일 07:30 UTC에 웹 서비스의 지연 SLO 가 깨졌다. 웹 서비스의 Apdex 가 떨어졌고, 웹 프런트엔드로 가는 요청 일부가 잠시 느려졌다. Apdex 는 응답 시간이 목표 안에 든 요청의 비율로 계산하는 만족도 점수다.

   지연 시간 증가오토스케일러 오동작

   촉발

   웹 서비스를 VM 에서 쿠버네티스로 옮기면서 트래픽을 쿠버네티스 웹 파드로 넘겼다.

   원인

   설정 변경

   구성 요소

   수평 파드 오토스케일러

   기여 요인

   미검증 가정

   감지

   07:30 UTC에 웹 지연 SLO 가 깨졌고, 10분 뒤인 07:40에 엔지니어가 Slack 에서 장애를 선언했다.

   조치

   • 웹 파드의 targetCPU 를 더 보수적인 값으로 낮추는 머지 요청 gitlab-com/gl-infra/k8s-workloads/gitlab-com!1149 를 머지했다.

   후속 조치

   • 목표 사용률을 조정하는 머지 요청 gitlab-com/gl-infra/k8s-workloads/gitlab-com!1149 를 재발 방지 조치로 올려 머지했다.

   교훈

   트래픽을 새 파드로 넘길 때 HPA 의 CPU 목표값이 너무 높으면 부하가 늘어도 파드가 제때 늘지 않는다. 팀은 목표값을 보수적으로 낮춰 이 문제를 풀었다.

   사례 보기
4. IL-0105 VPC CNI 교체로 ALB 에서 타깃 그룹이 떨어져 나가 쿠버네티스 클러스터의 모든 서비스가 503 을 냈다

   DFDS2021

   증상

   2021-06-22 08:29 UTC 에 알림이 울렸다. 쿠버네티스 클러스터로 들어오는 트래픽이 모두 실패했고, 모든 서비스가 503 을 냈다.

   서비스 중단오류율 상승

   촉발

   EKS 애드온을 kubectl 대신 Terraform 으로 관리하려는 리팩터링과 정리 작업 중에 파이프라인이 VPC CNI 를 교체했다.

   원인

   설정 변경

   구성 요소

   AWS VPC CNI클라우드 로드 밸런서Terraform

   기여 요인

   미검증 가정설정 테스트 부재

   감지

   08:29 UTC 에 알림으로 감지했다. 파이프라인이 VPC CNI 를 교체한 지 8분 뒤였다. 08:32 에는 고객도 문제를 알려 왔다.

   조치

   • infrastructure-modules 참조를 되돌리는 수정을 커밋했다.
   • AWS API 타임아웃으로 멈춘 파이프라인을 다시 돌렸다.
   • 파이프라인이 타깃 그룹을 ALB 에 다시 붙였다.

   후속 조치

   • ALB 의 등록 해제 지연을 기본값 300초로 되돌린다.
   • 노드 교체 스크립트가 교체 전에 ALB 등록 해제 지연을 잠시 0 으로 낮추도록 고친다.
   • Ingress 테스트 스위트를 만든다.

   교훈

   팀은 등록 해제 지연을 주로 성능 측면에서만 보고 바꿨다. 중요한 파이프라인 실행은 끝날 때까지 지켜봐야 한다. 알림은 모든 사람이 받고 대응해야 한다. 뜻이 분명하지 않은 알림 문구는 고쳐 써야 한다.

   사례 보기
5. IL-0197 Elasticsearch StatefulSet 을 새 퍼시스턴트 볼륨으로 옮기던 중 빈 볼륨으로 다시 뜬 elasticsearch-0 이 혼자 새 클러스터를 만들어 스플릿 브레인이 났다.

   Palark2021

   증상

   옛 노드 세 개를 하나씩 새 StorageClass 의 볼륨으로 바꾸다가 마지막으로 elasticsearch-0 파드를 지우고 다시 띄웠다. elasticsearch-0 안에서 `_cat/nodes` 를 조회하자 자기 자신 하나만 마스터로 나왔다.

   스플릿 브레인

   촉발

   옛 PVC 와 파드를 지운 뒤 elasticsearch-0 이 새 StorageClass 의 빈 볼륨을 받아 다시 시작했다.

   원인

   운영 실수

   구성 요소

   Elasticsearch 와 OpenSearch영구 볼륨과 스테이트풀셋Helm

   기여 요인

   미검증 가정

   감지

   마지막으로 0번 파드를 교체한 뒤 엔지니어가 elasticsearch-0 과 elasticsearch-1 안에서 각각 `_cat/nodes` 를 조회했다. 두 결과가 서로 다른 노드 목록과 다른 마스터를 보여 스플릿 브레인을 알아챘다.

   조치

   • 데이터를 실시간으로 쓰는 워커의 디플로이먼트 세 개를 0으로 줄여 새 데이터가 갈라진 클러스터로 들어가지 않게 했다.
   • ConfigMap 의 initial_master_nodes 를 elasticsearch-0, elasticsearch-1, elasticsearch-2 로 바꾸고 StatefulSet 에서 cluster.initial_master_nodes 환경 변수를 지웠다.
   • 롤링 업데이트가 도는 동안 디스커버리용 elasticsearch Service 를 YAML 로 저장한 뒤 지우고, 0번 파드의 PVC 도 지웠다.
   • ConfigMap 의 initial_master_nodes 를 elasticsearch-3, elasticsearch-4, elasticsearch-5 로 바꾸고, 0번 파드의 빈 PVC 를 만든 뒤 파드 6개를 모두 지워 다시 띄웠다.
   • 저장해 둔 YAML 로 Service 를 다시 만들었다. 노드 6개가 한 클러스터로 모였고 green 이 아닌 인덱스는 0개였다.

   후속 조치

   • ConfigMap 의 initial_master_nodes 를 원래 값으로 되돌리고 모든 파드를 한 번 더 재시작한다.
   • 모든 샤드를 0, 1, 2번 노드로 옮기고 클러스터를 노드 6개에서 3개로 줄인다.
   • 손으로 바꾼 내용을 모두 저장소에 커밋한다.

   교훈

   운영 데이터를 옮길 때는 설정 오류, 데이터센터 장애, 네트워크 단절처럼 무언가 잘못될 수 있다는 전제로 준비해야 한다. 이번에 쓴 다운타임 없는 절차는 예상하지 못한 문제에 약했다. 팀은 ConfigMap 을 꼼꼼히 확인했지만 Helm 차트 템플릿이 StatefulSet 에 넣는 환경 변수는 보지 않았다. cluster.initial_master_nodes 가 파드 하나로 고정된 상태에서 그 파드가 빈 볼륨으로 다시 뜨면 기존 클러스터에 합류하지 않고 새 클러스터를 만든다.

   사례 보기

원인별10