사례3건

3건 중 1~3번째

1. IL-0118 쿠버네티스 네임스페이스 라벨을 전역으로 바꾸자 네트워크 계층이 메타데이터를 다시 계산하면서 가장 큰 GPU 클러스터들 가운데 세 곳의 컨트롤 플레인이 과부하에 빠졌고, ChatGPT 와 API 가 타임아웃과 503 오류를 냈다.

   OpenAI2024

   증상

   2024년 11월 25일 태평양 시각 오전 10시 15분부터 API 와 ChatGPT 트래픽의 상당 부분이 타임아웃과 503 오류로 실패했다.

   오류율 상승지연 시간 증가컨트롤 플레인 무응답

   촉발

   쿠버네티스 네임스페이스 라벨을 전역으로 바꿨고, 이 변경 때문에 네트워크 계층이 의도치 않게 메타데이터를 다시 계산했다.

   원인

   설정 변경

   구성 요소

   쿠버네티스 API 서버

   기여 요인

   과도한 영향 범위디버그 접근 제한

   조치

   • 영향받은 클러스터에서 워크로드를 손으로 빼냈다. 컨트롤 플레인이 응답하지 않아 이 작업이 더 복잡했다.
   • 클라우드 업체와 함께 컨트롤 플레인 노드 수를 늘리고 동시에 데이터 플레인 노드 수를 줄여 컨트롤 플레인을 회복시켰다.

   후속 조치

   • 같은 장애가 다시 나지 않도록 네임스페이스 변경을 잠갔다.
   • 일부 종류의 인프라 배포를 동결했다.
   • 같은 종류의 장애가 반복되지 않도록 신원을 허용 목록으로 관리한다.
   • 가능한 경우에는 트래픽이 자동으로 다른 곳으로 더 잘 옮겨 가도록 GPU 로드 밸런싱 로직을 고친다.
   • 플릿 전체에 걸친 인프라 변경을 관리하는 방식을 개선한다.

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

   사례 보기
3. IL-0466 Prow 가 테스트 작업을 서비스 클러스터에 스케줄해 작업이 뜨지 못하고 Prow 전체가 느려졌다

   Kubernetes project2019

   증상

   16:04 PST 에 Prow 의 응답이 매우 느려졌다. hook 의 응답이 5분쯤 늦었고 봇 명령이 응답하지 않았으며, /lgtm 과 담당자 지정이 오류를 냈다. 작업은 네트워크 문제로 실패하고 GCS 에 로그를 올리지 못했다.

   파드 Pending노드 CPU 고부하지연 시간 증가

   촉발

   13:20 PST 에 Prow 가 자동으로 만든 버전 올림 PR 이 머지돼 배포가 시작됐다. 새로 들어간 클라이언트 코드 리팩터링이 빌드 클러스터 시크릿에 적힌 "default" 클러스터 별칭을 무시해, Prow 가 작업을 기본 별칭인 서비스 클러스터에 스케줄하기 시작했다.

   원인

   배포 결함

   구성 요소

   CI 시스템

   기여 요인

   스테이징 불일치리소스 요청과 한도 미설정디버그 접근 제한

   감지

   16:04 PST 에 담당자가 PR 을 보다가 cat 명령이 동작하지 않는 것을 알아챘다. githubstatus.com 은 정상이었다. Slack 에서 Prow 노드가 CPU 와 메모리를 100% 넘게 쓰는 것을 찾았고, 이어서 test-pods 네임스페이스에서 시크릿을 찾지 못해 멈춘 Pending 파드 600개를 확인했다.

   조치

   • 16:40 에 Prow 를 버전 올림 이전인 v20190206-b01b288 로 롤백했고, 그사이 서비스 클러스터의 파드와 prowjob 을 모두 지웠다.
   • 직접 배포할 권한이 없어 이슈를 연 뒤, 16:50 에 되돌린 버전을 kubectl apply 로 직접 배포했다. 문제는 계속됐다.
   • 17:25 에 주어진 "default" 클라이언트를 덮어쓰지 않게 하는 수정 PR https://github.com/kubernetes/test-infra/pull/11209 을 올렸다.
   • 17:25 에 결함이 들어가기 전인 v20190125-2aca69d 로 Prow 를 다시 롤백했다.
   • 17:59 에 잘못 스케줄된 파드와 prowjob 을 모두 다시 지우고 Prow 가 정상임을 확인했다.

   후속 조치

   • 이 동작이 왜 비결정적으로 나타나는지 더 알아본다.
   • Prow 를 크게 바꾸는 변경을 배포할 때 더 조심한다. e2e 테스트를 늘리거나 실제 스테이징 Prow 를 둔다.

   교훈

   사람들이 자리에 있어 문제를 적극적으로 찾고 완화했다. 이번에도 금요일 오후에 일어났고, 동작이 비결정적이었다. 실제 스테이징 Prow 가 필요하다. 지금은 OpenShift 의 Prow 가 잘 돌면 쿠버네티스 Prow 를 올려도 안전하다고 보며 서로에게 기댄다. 그러나 빌드 클러스터를 정의하는 방식처럼 Prow 마다 구성이 다르므로, 쿠버네티스 Prow 와 매우 비슷한 스테이징 환경이 있어야 한다. 크게 바꾸는 Prow 변경은 e2e 테스트를 늘리거나 실제 스테이징 Prow 를 두어 더 조심해서 배포해야 한다.

   사례 보기

원인별3