사례45건

45건 중 31~35번째

1. 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 디스크에서도 문제없이 도는 것으로 보였다.

   사례 보기
2. 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 를 쓰는 방안을 검토한다.

   사례 보기
3. IL-0449 EKS 관리형 노드 그룹으로 옮긴 며칠 뒤 파드가 재시작을 되풀이하거나 Terminating 상태에 멈추고 노드를 쓸 수 없게 됐다

   Enigmo2020

   증상

   EKS 클러스터의 파드를 새로 만든 관리형 노드 그룹으로 옮기고 2~3일 지나자, 파드가 갑자기 재시작을 되풀이하거나 제대로 종료되지 못하고 Terminating 상태로 계속 남았다. 노드의 CPU 와 메모리 부하가 높아져 클러스터에서 노드를 쓸 수 없게 됐다.

   파드 Terminating 정체노드 CPU 고부하메모리 압박노드 NotReady업그레이드 정체

   촉발

   EKS 1.16 업그레이드를 앞두고 파드를 버그가 있는 AMI 로 만든 새 관리형 노드 그룹으로 옮기고 옛 노드 그룹을 지웠다.

   원인

   업그레이드로 깨진 호환성

   구성 요소

   노드 운영체제 이미지노드 풀

   기여 요인

   롤백 무효늦게 드러난 변경

   조치

   • 수정된 AMI 가 나오자 관리형 노드 그룹의 AMI 버전을 바꿨다.
   • CloudFormation 으로 관리형 노드 그룹 업데이트를 실행했다.
   • 업데이트가 도는 동안 kubectl get pods --all-namespaces 로 파드 상태를 지켜봤다.
   • Terminating 상태로 한동안 변화가 없는 파드를 찾을 때마다 kubectl delete pods <pod name> --grace-period=0 --force 로 강제로 지웠다.

   후속 조치

   • 분기나 달마다 각종 모듈의 최신 릴리스를 확인하고 정기적으로 업그레이드해, 서비스 영향을 가장 작게 하는 운영 방법을 찾는다.

   교훈

   Amazon EKS 나 쿠버네티스를 쓰는 한 클러스터 본체와 Ingress Controller 같은 모듈의 업그레이드를 늘 신경 써야 한다. 안정적으로 돈다고 한동안 손대지 않고 두면, 그사이 호환성을 깨는 변경이 담긴 릴리스가 갑자기 발표되는 일이 드물지 않다. 쿠버네티스 마이너 버전은 3개월쯤마다 나오므로 1년에 적어도 한 번은 업그레이드해야 한다.

   사례 보기
4. IL-0094 JupyterHub 클러스터에서 학생 파드가 노드의 CPU 와 메모리를 다 써서 자원 보장이 부족했던 코어 파드가 자원을 얻지 못했고, 허브 전체가 멈췄다.

   2i2c2020

   증상

   WER 허브의 학생들이 페이지가 멈춘다고 알려 왔다. 아무것도 쓸 수 없는 완전한 장애였다. 08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   서비스 중단노드 CPU 고부하

   촉발

   WER 학생들의 사용량이 늘어 사용자 파드와 코어 파드가 함께 도는 노드의 CPU 와 메모리를 다 썼다.

   원인

   용량 한계

   구성 요소

   노드 풀컨테이너 메모리 한도

   기여 요인

   리소스 요청과 한도 미설정미검증 가정과도한 영향 범위

   감지

   08:52 PM IST 에 많은 학생이 허브에 접속하지 못하고 허브가 멈췄다는 보고가 들어왔다.

   조치

   • 09:23 PM 에 WER 학생 파드의 메모리 오버커밋을 없앴다. 학생들이 메모리 한도의 상당 부분을 쓰고 있었고, 새 노드가 하나 더 떠서 기존 노드의 부담을 덜 것으로 보았다.
   • 09:24 PM 에 모든 코어 파드의 자원 보장을 올려 노드가 가득 차도 코어 파드가 동작할 자원을 갖게 했다. 코어 파드가 재시작되며 일부가 새 노드로 옮겨졌다.

   후속 조치

   • 사용자 파드를 별도 노드 풀로 옮겨 코어 파드에 부담을 주지 않게 한다.
   • prometheus, grafana, ingress 같은 지원 인프라에도 한도를 건다.
   • 메모리 오버커밋 비율을 검토하고 문서로 남긴다.
   • 자원 사용량을 감시할 Grafana 대시보드를 더 낫게 만든다.
   • 다른 사람도 문제를 살펴볼 수 있게 클러스터의 kubectl 접근 권한을 얻는 방법을 문서로 남긴다.

   교훈

   코어 파드와 사용자 파드가 같은 노드에 섞여 있으면 사용자 사용량이 몰릴 때 코어 파드까지 자원을 얻지 못한다. 코어 파드에는 노드가 가득 차도 동작할 만큼의 자원 보장이 있어야 한다. 메모리 오버커밋 비율은 관례대로 정하지 말고 실제 사용량에 맞춰야 한다. WER 학생들은 한도의 상당 부분을 실제로 쓰고 있어서 4배 오버커밋은 지나쳤다.

   사례 보기
5. IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.

   Grafana Labs2020

   증상

   2020년 3월 16일 11:31 UTC에 SLO 기반 알림이 당직 엔지니어를 호출했다. 런던 리전 Hosted Prometheus 로 들어오는 쓰기의 약 20%가 실패하고 있었다. 문제는 이미 11분 전에 시작된 상태였다.

   오류율 상승간헐적 타임아웃

   촉발

   예약된 쿠버네티스 버전 업그레이드가 etcd 리더가 돌던 노드를 정상 종료 절차 없이 갑자기 종료했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd노드 풀

   기여 요인

   기본 설정 방치파괴적 변경 보호 장치 부재

   감지

   SLO 기반 알림이 11:31 UTC에 당직 엔지니어를 호출했다. 장애가 시작되고 11분이 지난 시점이었다. 오류율이 20% 수준이었기 때문에 이대로 두었다면 월간 SLA 를 넘기기까지 약 18시간이 걸렸을 것이다.

   조치

   • 11:32 UTC에 영향받은 distributor 를 재시작했고, 오류가 멈췄다.

   후속 조치

   • Cortex 의 etcd 클라이언트 설정에 gRPC keepalive 프로브를 켠다. DialKeepAliveTime 은 10초, DialKeepAliveTimeout 은 DialTimeout 의 두 배로 두고 PermitWithoutStream 을 true 로 한다.
   • 쿠버네티스 업그레이드 절차를 고쳐, etcd operator 가 관리하는 etcd 파드까지 포함해 파드와 머신을 정상 종료 절차로 내리게 한다.

   교훈

   노드가 죽으면 TCP 연결이 정상적으로 닫히지 않고 멈춘 채 남을 수 있다. etcd 클라이언트에 keepalive 를 설정하지 않으면 새 리더가 뽑힌 뒤에도 클라이언트는 죽은 연결을 계속 쓴다. 노드를 내리는 업그레이드 스크립트는 operator 가 관리하는 파드까지 정상 종료할 수 있어야 한다. 장애 대응과 복구, 사후 분석 동안 Grafana Loki 로 로그를 빠르게 뒤질 수 있어서 복구 시간이 줄었다.

   사례 보기

원인별10