사례2건

2건 중 1~2번째

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-0039 CentOS 저장소 재구성으로 kops nodeup 에 하드코딩된 container-selinux 패키지 주소가 깨져 새 워커 노드가 클러스터에 합류하지 못했다

   FREE NOW2019

   증상

   Prelive 클러스터에 배포하던 개발자들이 #ask-platform 슬랙 채널에 배포가 실패한다고 알렸다. 16:00 에 첫 제보가 왔고 16:06 에 두 번째 제보가 왔다.

   파드 Pending노드 증설 실패

   촉발

   CentOS 저장소가 재구성되면서 container-selinux 패키지의 고정 다운로드 주소를 더는 쓸 수 없게 됐다. kops 는 nodeup 에 이 주소를 하드코딩해 두었고, docker-ce 를 실행하려면 이 패키지가 필요했다.

   원인

   의존성 장애

   구성 요소

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

   기여 요인

   모니터링 사각지대

   감지

   팀은 개발자들이 배포가 실패한다며 #ask-platform 슬랙 채널에 도움을 요청하면서 장애를 알게 됐다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다.

   조치

   • Prelive 노드에서 패키지를 손으로 내려받아 부트스트랩을 끝내고 노드를 클러스터에 합류시켰다.
   • 클러스터 AMI 를 Amazon Linux 2 에서 Debian 으로 바꿔 Prelive 에서 확인한 뒤 모든 클러스터에 적용했다.

   후속 조치

   • 노드가 클러스터에 합류하지 못하는 상황을 알려 주는 알림을 만든다. cluster-autoscaler 가 이 정보를 갖고 있을 수 있다.
   • 노드 시작에 필요한 외부 의존성을 문서로 정리하고 줄일 방법을 찾는다.
   • kops 가 이 문제를 고치면 AMI 를 Amazon Linux 2 Minimal 로 되돌린다.
   • 클러스터 노드 문제 해결 문서를 보강해, 부트스트랩 중에 무슨 일이 일어나고 로그가 어디에 남는지 적는다.

   교훈

   kops 와 Jenkins 로 클러스터 변경을 적용하는 흐름은 잘 동작했다. 조사를 시작하자 배포 실패의 원인이 클러스터 용량 부족이라는 것이 빠르게 드러났다. 일부 오토스케일링 그룹의 워커 인스턴스 수와 쿠버네티스에 등록된 워커 노드 수가 오랫동안 달랐는데도 아무도 알아채지 못한 것은 잘못이었다. 문제가 이어지는 동안 운영 환경의 스팟 인스턴스가 대량으로 종료되지 않은 것과 업무 시간에 발견한 것은 운이 좋았다.

   사례 보기

원인별2