사례52건

52건 중 31~35번째

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-0111 메인 인그레스 컨트롤러를 Traefik v2 로 바꾸자 X-Forwarded 헤더가 전달되지 않아 Okta 로그인이 깨졌고, DFDS 온라인 예약이 한 시간 넘게 멈췄다

   DFDS2021

   증상

   09:26 UTC 에 한 개발자가 HTTP 307 리다이렉트 응답이 유난히 많다고 알렸다. 특히 Okta 서비스에서 많았다. 6분 뒤인 09:32 UTC 에 온라인 예약 시스템이 다운됐다는 연락이 왔다.

   서비스 중단

   촉발

   Traefik v1 을 걷어 내는 마이그레이션 작업으로 08:22 UTC 에 AWS 로드밸런서가 새 Traefik v2 리버스 프록시로 요청을 보내도록 바뀌었다.

   원인

   설정 변경

   구성 요소

   인그레스 컨트롤러클라우드 로드 밸런서

   기여 요인

   리뷰 누락모니터링 사각지대

   감지

   09:26 UTC 에 한 개발자가 HTTP 307 리다이렉트가 많다고 보고하면서 문제가 드러났다. 특히 Okta 서비스에서 많았다. 변경 뒤 64분 만이었다. 09:32 UTC 에는 온라인 예약 시스템이 다운됐다는 연락을 받았다.

   조치

   • 조사보다 롤백을 먼저 하기로 하고 09:48 UTC 에 변경을 롤백했다.

   후속 조치

   • 중요한 공지가 더 잘 보이게 할 방법을 검토한다.
   • 시험에 쓴 ALB 를 각 팀에 알려 팀이 자기 시나리오를 직접 시험하게 했어야 하는지 검토한다. 이번에 멈춘 서비스는 ALB 앞에 CloudFront 가 있어서 그렇게 했어도 시험하기 어려웠을 수 있다.

   교훈

   Cloud Engineering 팀이 모든 시나리오를 시험할 수는 없었다. 팀은 자기 애플리케이션 몇 개로 몇 주 동안 시험했지만 Okta 로그인 흐름의 문제는 잡지 못했다. 마이그레이션 전후의 요청 헤더를 비교했다면 미리 알 수 있었을지도 모른다는 물음도 남았다.

   사례 보기
3. IL-0205 Google Cloud us-east1 의 SSD 영구 디스크 재고가 바닥나 GKE 클러스터 오토스케일러가 프로덕션 노드를 늘리지 못했고, API 디플로이먼트가 파드를 띄울 용량을 얻지 못했다.

   GitLab2021

   증상

   2021-06-21 08:05 UTC 부터 API 의 Apdex 가 나빠지고 Rails 대기열이 늘어나는 추세가 보였다. Apdex 는 목표 시간 안에 끝난 요청의 비율로 사용자 만족도를 나타내는 지표다. 08:43 에 ahmad 가 Slack 에서 장애를 선언했고, 09:01 에 API 디플로이먼트가 비정상 상태이고, 노드를 늘려 파드 용량을 더할 수도 없다는 것을 확인했다.

   노드 증설 실패지연 시간 증가파드 Pending배포 실패

   촉발

   GitLab 이 운영하는 GCP us-east1 리전에서 SSD 재고가 바닥난 상태였는데, 사용자 트래픽이 늘어 API 서비스가 노드를 늘려야 했다.

   원인

   클라우드 제공자 장애

   구성 요소

   클러스터 오토스케일러노드 풀

   기여 요인

   모니터링 사각지대디버그 접근 제한장애 중첩

   감지

   로그를 한참 뒤져서 찾았다. 클러스터 오토스케일러 오류는 일부 노드가 백오프 상태라 확장할 수 없다고만 했고, 인스턴스 그룹 수준 오류도 ZONE_RESOURCE_POOL_EXHAUSTED 뿐이어서 어떤 자원이 바닥났는지 알 수 없었다. 결국 GCP 지원팀이 SSD 재고 부족을 알려 주었다. 탐지까지 22시간이 걸렸고, 팀은 자원 가용성 알림이 있었다면 탐지와 진단을 앞당길 수 있었다고 보았다.

   조치

   • 09:55 에 pd-standard 디스크를 쓰는 노드 풀을 하나 더 만들었다.
   • 10:37 에 새 노드 풀이 늘어나지 않자 API 부담을 덜려고 이 노드 풀을 세 존 모두에서 손으로 늘렸다.
   • 13:42 에 배포가 막혀 있고 다른 워크로드도 같은 영향을 받고 있어서 pd-standard 디스크를 쓰는 새 노드 풀들을 올리기로 했다.
   • 18:16 에 canary 시험에서 클러스터 오토스케일러가 새 노드 풀과 함께 동작하지 않자 프로덕션 배포를 막는다고 공지하고, 오토스케일러 문제로 Google 에 지원 케이스를 열었다.
   • 18:26 에 남은 워크로드의 노드 풀과 nodeSelector 를 바꾸는 인프라 작업을 시작했다.
   • pd-standard 노드 풀 위주로 하루 동안 운영하며 문제가 없는 것을 확인한 뒤 SSD 노드 풀을 정리해 없앴다.

   후속 조치

   • 쿠버네티스 서비스를 pd-standard 디스크로 옮겼다.
   • 자원 고갈 오류를 지표로 수집한다.

   교훈

   장애를 수습하는 도중 다른 버그를 만나 대응 전체가 느려졌다. 팀에는 클라우드 자원 가용성을 감시할 수단도, 자원을 미리 예약해 둘 수단도 없었다. 워크로드는 pd-ssd 대신 pd-standard 디스크에서도 문제없이 도는 것으로 보였다.

   사례 보기
4. IL-0521 AKS 클러스터의 Azure 서비스 주체 자격 증명이 만료돼 파드가 볼륨을 마운트하지 못함

   Jenkins project2021

   증상

   2021년 6월 2일 18:02 UTC 부터 Jenkins 인프라의 AKS 클러스터에서 파드가 볼륨을 마운트하지 못한다는 오류와, 스케일 업으로 늘어난 노드가 CNI 에서 네트워크 가상 인터페이스를 받지 못한다는 오류가 나타나기 시작했다.

   자격 증명 획득 실패파드 ContainerCreating 정체

   촉발

   2021년 6월 2일 17:53 UTC 에 AKS 노드가 Azure API 인증에 쓰는 Azure 서비스 주체 자격 증명이 만료됐다.

   원인

   인증서·자격 증명 만료

   구성 요소

   클러스터의 클라우드 자격 증명영구 볼륨과 스테이트풀셋CNI 플러그인노드 풀

   기여 요인

   모니터링 사각지대

   감지

   LTS 2.289.1 릴리스 문제의 근본 원인을 조사하던 엔지니어가 AKS 콘솔 화면에서 오류를 확인했다.

   조치

   • 인프라 팀이 서비스 주체 자격 증명을 갱신했다. 그러자 AKS 가 모든 노드를 재시작하는 작업을 자동으로 시작했고, 이 작업은 멈출 수 없었다.

   후속 조치

   • 인증서 만료 점검처럼, 서비스 주체 만료 일주일 전에 PagerDuty 알림을 울리는 자동 점검을 더한다.
   • 자격 증명 재설정 같은 수동 작업 일정을 적어 둘 팀 공용 캘린더를 마련한다.
   • 서비스 주체 대신 자동으로 갱신되는 Azure managed identity 를 쓰는 방안을 검토한다.

   사례 보기
5. IL-0086 테스트 Kubernetes 클러스터용 배포가 운영 클러스터의 Traefik 과 Calico 리소스까지 지워 CircleCI UI 와 runner.circleci.com 이 1시간 54분 동안 내려갔다.

   CircleCI2021

   증상

   2021년 3월 11일 15:35 EST 에 CircleCI UI 에 접속할 수 없게 됐다. API 는 별도 인그레스로 들어오기 때문에 계속 응답했고 빌드도 계속 돌았다.

   서비스 중단리소스 삭제

   촉발

   테스트 Kubernetes 클러스터를 대상으로 한 배포가 테스트 클러스터와 운영 클러스터 양쪽에서 Traefik 과 Calico 리소스를 지웠다.

   원인

   배포 결함

   구성 요소

   인그레스 컨트롤러Calico

   기여 요인

   과도한 영향 범위런북 부재모니터링 사각지대

   감지

   알림을 받은 엔지니어들이 조사를 시작했다. 상태 페이지에는 20:45 UTC 에 첫 공지가 올라왔다.

   조치

   • 지워진 Traefik 을 복구했다.
   • Calico 를 복구해 운영 클러스터의 파드가 다시 고객 요청을 처리하게 했다.

   후속 조치

   • Kubernetes 네트워크의 여러 계층을 모두 다루도록 네트워크 수준 문서와 런북을 보강한다.
   • 네트워크 인프라 쪽 모니터링과 알림을 개선했다.
   • 운영 클러스터와 스테이징 클러스터가 서로 간섭하지 않도록 둘을 더 확실히 떼어 놓는 안전장치를 추가한다.

   교훈

   테스트 클러스터용 배포가 운영 클러스터의 리소스를 건드릴 수 있으면 스테이징 작업이 곧 운영 장애가 된다. 스테이징 배포가 운영에 영향을 줬다는 사실이 바로 보이지 않아 조사가 DNS 와 AWS 에서 시작됐다. Traefik 만 되살려서는 복구되지 않았고 Calico 와 Traefik 의 관계까지 알아야 했다. CircleCI 는 Kubernetes 네트워크의 모든 계층을 담은 문서와 런북이 필요하다고 정리했다.

   사례 보기

원인별9