사례3건

3건 중 1~3번째

1. IL-0116 CNI 설정 변경이 스테이징에 없던 하드웨어 종류와 호환되지 않아 GPU 클러스터 하나의 워크로드가 네트워크 연결을 잃었고, text-davinci-003 모델이 완전히 멈췄다.

   OpenAI2023

   증상

   2023년 1월 25일 태평양 시각 오후 4시 53분, GPU 클러스터 하나에 큰 장애가 나서 text-davinci-003 모델이 완전히 멈췄다.

   서비스 중단처리량 저하

   촉발

   컨테이너에 네트워크 연결을 제공하는 CNI 플러그인의 설정을 바꿨고, 이 변경이 운영에만 있는 하드웨어 종류를 쓰는 클러스터에 배포됐다.

   원인

   설정 변경

   구성 요소

   CNI 플러그인

   기여 요인

   스테이징 불일치모니터링 사각지대

   감지

   엔지니어들은 네트워크 연결 문제임을 곧바로 알아봤지만, CNI 가 원인임을 밝히는 데 거의 한 시간이 걸렸다.

   조치

   • CNI 를 원인으로 찾은 뒤 수정을 적용해 트래픽의 80% 를 바로 되살렸다.
   • 이후 약 3시간에 걸쳐 모델을 GPU 에 다시 올려 용량을 완전히 안정시켰다.

   후속 조치

   • 스테이징 환경에 가능한 모든 하드웨어 구성을 갖춰 운영 환경과 더 가깝게 만든다.
   • CNI 시스템 자체의 상태를 직접 모니터링하고 알림을 걸어 장애가 더 잘 보이게 한다.
   • 모델 복제본을 빠르게 대량으로 배포하지 못하게 막는 네트워크와 스토리지 인프라의 병목을 고친다.

   교훈

   변경을 스테이징에서 충분히 시험해도, 운영에만 있는 하드웨어 종류가 스테이징에 없으면 문제를 잡지 못한다. 다른 클러스터에 24시간 동안 배포돼 안전하다고 본 변경도, 하드웨어가 다른 클러스터에서는 깨졌다.

   사례 보기
2. IL-0032 mutating admission controller 의 JSON 패치 버그로 일주일 동안 새 코드가 배포되지 않았고, 운영 서비스 하나는 파드가 두 개만 남아 오류율이 치솟았다

   Airbnb2020

   증상

   운영 서비스 하나에서 오류율이 높아졌고 그 서비스는 배포도 되지 않았다. 배포할 때 인덱스 5에 접근할 수 없다는 뜻의 unable to access invalid index 오류가 났는데, 처음에는 무슨 뜻인지 알기 어려웠다.

   오류율 상승처리량 저하배포 실패

   촉발

   지난 한 달 사이에 도입한 mutating admission controller 에 변경이 들어갔고, 그 뒤로 컨트롤러가 배열에서 항목 두 개를 지우는 JSON 패치를 잘못된 순서로 만들었다. 이 변경은 장애가 드러나기 7일 전에 적용되어 있었다.

   원인

   소프트웨어 결함

   구성 요소

   어드미션 웹훅수평 파드 오토스케일러

   기여 요인

   늦게 드러난 변경모니터링 사각지대초기 신호 무시

   감지

   운영 서비스의 오류율이 높아지고 배포가 실패하면서 드러났다. 지표는 이미 있었지만 그 지표에 걸린 알림이 없어, 7일 동안 배포가 실패하는 것을 아무도 알아채지 못했다.

   조치

   • 해당 클러스터에서 mutating admission controller 를 지워 파드가 다시 정상적으로 뜨게 했다.

   후속 조치

   • 이 문제를 더 일찍 잡을 수 있었던 기존 지표에 알림을 건다.

   교훈

   클러스터에 mutating admission controller 가 있다는 사실을 늘 염두에 둔다. 최근에 도입한 것이라 장애가 났을 때 팀원 대부분이 이를 먼저 떠올리지 못했다. 막히면 도움을 청한다. 동료를 호출한 뒤에야 조사가 진척됐다. 오류 문구를 검색한다. 처음 보고된 오류 문구를 바로 검색했다면 이미 알려진 문제라는 것을 훨씬 일찍 알았을 것이다. 알림을 만든다. 문제를 일찍 잡을 수 있는 지표가 있었지만 알림이 없었다.

   사례 보기
3. IL-0401 Kubernetes 프로젝트의 Prow 빌드 클러스터 노드가 GCP 디스크 IOPS 스로틀링에 걸려 테스트가 이상하게 실패하고 PR 머지가 몇 시간 멈췄다

   Kubernetes project2019

   증상

   2019년 5월 30일 13:26 PDT 에 Slack 으로 Prow 가 이상하다는 신고가 들어왔다. GitHub 에는 잡이 실패했다고 올라왔는데 Deck 에서는 같은 잡이 아직 실행 중으로 보였다. 많은 테스트가 뜻밖의 방식으로 실패하거나 실행 도중 뚜렷한 이유 없이 중단됐다.

   노드 NotReady노드 커널 패닉파드 Terminating 정체처리량 저하

   촉발

   Kubernetes 1.15 code freeze 를 앞두고 테스트 사용량이 치솟아, k8s-prow-build 클러스터 노드의 디스크 I/O 가 GCP 의 스로틀링 한도에 걸렸다.

   원인

   용량 한계

   구성 요소

   클라우드 블록 스토리지노드 루트 디스크kubeletCI 시스템

   기여 요인

   모니터링 사각지대초기 신호 무시

   감지

   여러 사용자가 GitHub 에는 실패로 올라왔지만 잡 상태로는 아직 실행 중인 잡이 있다고 신고했다. 첫 신고는 13:26 에 Slack 으로 들어왔다. 이런 장애를 잡는 알림은 없거나 동작하지 않았다.

   조치

   • 디스크 quota 를 더 요청해 15:14 에 받았다.
   • 17:10 에 500 GB 디스크 노드 55개를 띄웠다.
   • 23:55 에 새 노드 풀로 옮기는 일을 마쳐 모든 노드가 500 GB 디스크를 쓰게 됐다.

   후속 조치

   • tide 가 일을 멈추면 온콜 담당자가 호출을 받도록 모니터링을 만들거나 고친다. 이 일은 이슈 #12829 에서 다룬다.
   • 온콜 순번에 새 사람을 넣는 절차와 지침을 만들어, 새 사람이 준비나 추가 지원 없이 혼자 맡겨지지 않게 한다.

   교훈

   사고 전에 Prow 지표가 기록되지 않아 무슨 일인지 파악하기 어려웠다. 이런 장애를 잡는 알림은 없거나 동작하지 않았다. 원인을 찾고 해결책을 정한 뒤에도 두 시간 동안 아무것도 하지 않았다. 사고로 1.15 code freeze 가 밀렸다. IOPS 가 문제라는 것을 알아본 사람이 마침 자리에 있었던 것은 운이었다.

   사례 보기

원인별3