사례3건

3건 중 1~3번째

1. IL-0095 엔지니어가 kubectl 이 다른 클러스터를 가리키는 줄 모르고 prod 네임스페이스를 지워 LEAP JupyterHub 가 약 1시간 동안 멈췄다.

   2i2c2025

   증상

   새 temple 클러스터에 허브를 배포하던 엔지니어가 NFS 문제를 만나 prod 네임스페이스를 지웠는데 삭제가 멈춘 채 끝나지 않았다. 파드 목록을 보니 다른 클러스터의 사용자 파드가 잔뜩 있었다.

   리소스 삭제서비스 중단

   촉발

   2i2c 엔지니어가 새 허브의 NFS 배포 버그를 우회하던 중, kubectl 이 LEAP 클러스터를 가리키고 있는 줄 모르고 prod 네임스페이스를 지웠다.

   원인

   운영 실수

   구성 요소

   영구 볼륨과 스테이트풀셋잡과 크론잡인그레스 컨트롤러Terraform

   기여 요인

   파괴적 변경 보호 장치 부재런북 부재

   감지

   네임스페이스를 지운 엔지니어가 삭제가 멈춘 것을 보고 파드 목록을 확인하다 다른 클러스터의 사용자 파드를 발견했고, 17:00 BST 에 장애를 선언했다. 모니터링 알림보다 먼저였다. 업타임 검사 실패 알림은 17:32 에 왔고 사용자의 404 제보는 17:37 에 들어왔다.

   조치

   • prod 네임스페이스에 남아 있던 사용자 파드 하나를 지워 멈춰 있던 네임스페이스 삭제를 끝냈다.
   • 재배포를 막고 있던 nfs-share-creator 잡을 종료했다.
   • 바뀐 NFS 서버 IP 주소로 prod 허브를 다시 배포했다.
   • 배포 도중 사용자가 서버를 띄우지 못하게 prod 인그레스를 지웠다.

   후속 조치

   • 장애 보고서를 쓴다.
   • "I deleted prod, what next?" 같은 상황에서 바로 볼 수 있는 짧은 장애 대응 문서를 쓴다.
   • jupyterhub-home-nfs 를 업그레이드하고 nfs-share-creator 잡을 없앤다.
   • deployer 시스템에 kubeconfig 컨텍스트가 중첩되는 것을 막는 보호 장치를 넣었다. 기본으로는 꺼져 있고 쓰는 사람이 켜야 동작한다.
   • 해당 엔지니어의 셸 설정을 바꿔 kubeconfig 컨텍스트를 더 쉽게 구분하게 했다.

   교훈

   쿠버네티스 리소스를 잃는 경우에 대비해 영구 스토리지를 Terraform 으로 따로 프로비저닝해 둔 설계 덕분에 사용자 데이터가 살아남았다. 반면 엔지니어에게 지금 어느 클러스터를 다루고 있는지 알려 주는 단서가 없었던 것이 실수로 이어졌다. 복구 방법을 알고 있어도 데이터 손실 위험을 확인해 줄 사람이 다른 시간대에 있어 재배포가 늦어졌다. NFS 배포의 순환 의존과 nfs-share-creator 잡도 복구를 늦췄다.

   사례 보기
2. IL-0115 OpenAI 의 운영 AKS 클러스터 세 개 중 하나가 사람의 실수로 통째로 내려가 Codex, Embeddings, 구형 GPT 모델과 파인튜닝 모델이 최대 12시간 동안 제대로 응답하지 못했다

   OpenAI2022

   증상

   2022년 6월 23일 18시 56분 PDT, UTC 로는 6월 24일 01시 56분에 여러 모델이 한꺼번에 오프라인이 됐다. 일부 파인튜닝 모델인 curie 와 davinci, 일부 Codex 베타 모델인 code-davinci-001 과 code-cushman-001, 일부 구형 GPT 모델인 curie, babbage, ada, 그리고 모든 Embeddings 모델이 응답하지 않았다.

   서비스 중단오류율 상승간헐적 타임아웃

   촉발

   사람의 실수로 운영 클러스터 하나에 파괴적인 작업이 실행돼 클러스터가 완전히 내려갔다. 안전장치에 예상하지 못한 구멍이 있었고, 그 작업이 어떤 영향을 주는지 알려 주는 정보가 미묘하게 빠져 있었다.

   원인

   운영 실수

   구성 요소

   인그레스 컨트롤러모델 허브

   기여 요인

   파괴적 변경 보호 장치 부재여유 용량 부재미뤄 둔 업그레이드장애 중첩

   조치

   • 내려간 클러스터가 맡던 모델을 남은 두 운영 클러스터에 다시 배치했다.
   • 클러스터 구성 중 AKS 연결이 끊기자 Azure 지원팀과 함께 VPN 링크를 다시 만들었다.
   • Azure Private Link 연결이 다시 끊기자 Azure 지원팀과 우회 방법을 만들었다.
   • 업그레이드한 쿠버네티스 버전이 인그레스와 호환되지 않자 클러스터를 지우고 처음부터 다시 만들었다.
   • 05시 30분부터 06시 30분 PDT 사이에 다시 만든 클러스터로 트래픽을 옮겼다.

   후속 조치

   • 이번 클러스터처럼 운영에 꼭 필요한 인프라가 실수로 바뀌지 않도록 검사와 잠금을 더한다. 기존 보호 장치는 범위가 좁아 이번 같은 클러스터 장애를 막지 못했다.
   • 실행 중인 작업이 더 잘 보이게 하고, 시스템 구성 요소의 이름이 글자만 봐도 서로 확실히 구별되도록 바꾼다.
   • AKS 네트워크 연결 문제를 Azure 와 계속 조사해 새 클러스터 작업이 다시 방해받지 않게 한다.
   • 이번에 드러난 클러스터 장애 유형을 플레이북에 넣고, 새 클러스터와 인프라를 구성하는 절차를 고친다.
   • 쿠버네티스를 체계적으로 업그레이드하고, 앞으로 버전이 뒤처지지 않도록 업그레이드할 시간을 따로 확보한다.
   • 파인튜닝 모델을 여러 클러스터에 나눠 배치하고, 클러스터 사이 복제를 더 자동으로 하는 방법을 만든다.
   • Azure Blob Storage 를 분산하고 복제해 파인튜닝 모델을 더 빠르고 안정적으로 불러올 수 있게 한다.
   • Azure Blob Storage 병목을 덜어 줄 노드 간 캐시의 배포를 마무리한다.
   • 모델 가중치를 저장하는 방식을 바꿔 더 효율적이고 빠르게 불러올 수 있게 한다.

   교훈

   클러스터 하나를 통째로 잃으면 평소의 여유 용량이 한 번에 바닥난다. GPU 처럼 몇 시간 안에 늘릴 수 없는 자원을 쓰는 서비스는 남은 클러스터만으로 완전히 되살릴 수 없다. 운영 클러스터를 지울 수 있는 작업에는 그 영향을 분명히 보여 주는 정보와 잠금이 있어야 한다. 쿠버네티스 버전이 뒤처져 있으면 급하게 하는 업그레이드가 인그레스 호환성 같은 새 문제를 만든다. AKS 는 다운그레이드가 되지 않아 되돌릴 수도 없었다. 대용량 모델을 처음부터 다시 올리는 상황에서는 스토리지 대역폭과 캐시 무효화가 복구 시간을 좌우했다.

   사례 보기
3. IL-0089 테스트 클러스터 삭제 스크립트가 운영 클러스터 live-1 을 대상으로 실행돼 인그레스 컨트롤러, 모니터링, 인증서 구성 요소가 지워지고 사용자 서비스에 접속할 수 없게 됐다.

   UK Ministry of Justice2020

   증상

   팀은 2020년 9월 21일 18:27 에 처음 장애를 알아챘다. Cloud Platform 에서 돌아가는 서비스 일부에 사용자가 접속하지 못했다.

   서비스 중단리소스 삭제모니터링 중단오래된 엔드포인트 라우팅

   촉발

   테스트 클러스터를 지우려고 삭제 스크립트를 실행했는데, kube 컨텍스트가 잘못 잡혀 있어 스크립트가 운영 클러스터 live-1 을 대상으로 돌았다.

   원인

   운영 실수

   구성 요소

   인그레스 컨트롤러파드용 자격 증명 중개자external-dns클라우드 로드 밸런서Prometheus

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   팀은 18:27 에 처음 장애를 알아챘고, 13분 뒤인 18:40 에 장애를 선언했다.

   조치

   • 기본 인그레스 컨트롤러를 먼저 되살리고, 인그레스 컨트롤러가 의존하는 external-dns 와 kiam 도 함께 되살렸다.
   • Route53 TXT 레코드의 잘못된 owner 값을 고쳐 external-dns 가 Formbuilder 레코드를 새 NLB 로 바꾸게 했다.
   • 남은 구성 요소는 대상을 지정한 apply 로 되살렸다.
   • apply 파이프라인을 돌려 환경 저장소에 있는 인증서, ServiceMonitor, Prometheus 규칙을 모두 다시 만들었다.

   사례 보기

원인별1