사례13건

13건 중 6~10번째

1. 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 는 다운그레이드가 되지 않아 되돌릴 수도 없었다. 대용량 모델을 처음부터 다시 올리는 상황에서는 스토리지 대역폭과 캐시 무효화가 복구 시간을 좌우했다.

   사례 보기
2. IL-0106 잘못된 IngressRoute 매니페스트가 Traefik v2 버그를 건드려 Traefik 파드가 모두 재시작된 뒤 Kubernetes 의 모든 서비스가 404 를 냈다

   DFDS2021

   증상

   2021-09-06 08:00 UTC 에 Kubernetes 의 모든 서비스가 404 를 내기 시작했다. 30분 전인 07:30 에는 노드를 자동으로 교체하는 롤오버가 시작됐다.

   서비스 중단오류율 상승프로브 실패

   촉발

   2021-09-01 11:34 UTC 에 형식이 잘못된 IngressRoute 가 Kubernetes 에 적용됐다. 이 매니페스트는 2.5 미만 Traefik v2 의 버그를 건드렸지만, 버그는 Traefik v2 파드가 모두 재시작된 뒤에야 드러났다. 2021-09-06 07:30 에 자동 노드 롤오버가 시작됐고, 08:00 에 모든 서비스가 404 를 냈다.

   원인

   소프트웨어 결함

   구성 요소

   인그레스 컨트롤러클라우드 로드 밸런서

   기여 요인

   늦게 드러난 변경설정 테스트 부재과도한 영향 범위

   감지

   08:00 UTC 에 모든 서비스가 404 를 내기 시작했고 08:05 에 원인 조사를 시작했다. 감지까지 5분이 걸렸다.

   조치

   • ALB 헬스체크 경로를 바꿔 08:15 에 ALB 대상을 healthy 로 되돌렸지만 404 는 멈추지 않았다.
   • 08:50 에 주 인그레스 컨트롤러를 Traefik v1 으로 되돌리기로 하고, 09:00 에 손으로 롤백했다.
   • 09:10 에 잘못된 IngressRoute 를 손으로 지워 근본 원인과 Traefik v2 버그를 확인했다.
   • 09:20 에 바꾼 내용을 업스트림에도 반영했다.

   후속 조치

   • 버그가 고쳐진 Traefik v2.5 로 올리고 버그가 사라졌는지 확인한다.
   • Traefik v2 헬스체크 경로를 더 믿을 만한 경로로 바꾼다.
   • 인그레스 컨트롤러를 클러스터 바깥에서 확인하는 liveness 점검을 둔다.
   • 워크로드를 나눠 장애가 번지는 범위를 줄이는 방안을 검토한다.
   • Traefik v2 API 에서 짧은 시간에 많은 변경이 일어나는지 모니터링하는 방법을 알아본다.
   • 노드 롤오버 중과 롤오버 뒤에 스모크 테스트를 돌리는 방법을 알아본다.

   교훈

   Traefik v2 는 오류를 드러내지 않고 실패해서 조사를 ALB 쪽으로 잘못 이끌었다. 공식 API 스키마도 잘못된 매니페스트 적용을 막지 못했다. 팀은 대응 과정에서 장애 관리자를 정했다면 도움이 됐을 것으로 봤다. 그리고 워룸 회의를 녹화하고, 대응에 참여하지 않는 사람은 글로만 제안하고, 일지를 남기자고 정리했다. 대응 초반에 각자의 생각과 직감을 짧게 나누는 시간도 갖자고 했다.

   사례 보기
3. IL-0111 메인 인그레스 컨트롤러를 Traefik v2 로 바꾸자 X-Forwarded 헤더가 전달되지 않아 Okta 로그인이 깨졌고, DFDS 온라인 예약이 한 시간 넘게 멈췄다

   DFDS2021

   증상

   09:26 UTC 에 한 개발자가 HTTP 307 리다이렉트 응답이 유난히 많다고 알렸다. 특히 Okta 서비스에서 많았다. 6분 뒤인 09:32 UTC 에 온라인 예약 시스템이 다운됐다는 연락이 왔다.

   서비스 중단

   촉발

   Traefik v1 을 걷어 내는 마이그레이션 작업으로 08:22 UTC 에 AWS 로드밸런서가 새 Traefik v2 리버스 프록시로 요청을 보내도록 바뀌었다.

   원인

   설정 변경

   구성 요소

   인그레스 컨트롤러클라우드 로드 밸런서

   기여 요인

   리뷰 누락모니터링 사각지대

   감지

   09:26 UTC 에 한 개발자가 HTTP 307 리다이렉트가 많다고 보고하면서 문제가 드러났다. 특히 Okta 서비스에서 많았다. 변경 뒤 64분 만이었다. 09:32 UTC 에는 온라인 예약 시스템이 다운됐다는 연락을 받았다.

   조치

   • 조사보다 롤백을 먼저 하기로 하고 09:48 UTC 에 변경을 롤백했다.

   후속 조치

   • 중요한 공지가 더 잘 보이게 할 방법을 검토한다.
   • 시험에 쓴 ALB 를 각 팀에 알려 팀이 자기 시나리오를 직접 시험하게 했어야 하는지 검토한다. 이번에 멈춘 서비스는 ALB 앞에 CloudFront 가 있어서 그렇게 했어도 시험하기 어려웠을 수 있다.

   교훈

   Cloud Engineering 팀이 모든 시나리오를 시험할 수는 없었다. 팀은 자기 애플리케이션 몇 개로 몇 주 동안 시험했지만 Okta 로그인 흐름의 문제는 잡지 못했다. 마이그레이션 전후의 요청 헤더를 비교했다면 미리 알 수 있었을지도 모른다는 물음도 남았다.

   사례 보기
4. IL-0086 테스트 Kubernetes 클러스터용 배포가 운영 클러스터의 Traefik 과 Calico 리소스까지 지워 CircleCI UI 와 runner.circleci.com 이 1시간 54분 동안 내려갔다.

   CircleCI2021

   증상

   2021년 3월 11일 15:35 EST 에 CircleCI UI 에 접속할 수 없게 됐다. API 는 별도 인그레스로 들어오기 때문에 계속 응답했고 빌드도 계속 돌았다.

   서비스 중단리소스 삭제

   촉발

   테스트 Kubernetes 클러스터를 대상으로 한 배포가 테스트 클러스터와 운영 클러스터 양쪽에서 Traefik 과 Calico 리소스를 지웠다.

   원인

   배포 결함

   구성 요소

   인그레스 컨트롤러Calico

   기여 요인

   과도한 영향 범위런북 부재모니터링 사각지대

   감지

   알림을 받은 엔지니어들이 조사를 시작했다. 상태 페이지에는 20:45 UTC 에 첫 공지가 올라왔다.

   조치

   • 지워진 Traefik 을 복구했다.
   • Calico 를 복구해 운영 클러스터의 파드가 다시 고객 요청을 처리하게 했다.

   후속 조치

   • Kubernetes 네트워크의 여러 계층을 모두 다루도록 네트워크 수준 문서와 런북을 보강한다.
   • 네트워크 인프라 쪽 모니터링과 알림을 개선했다.
   • 운영 클러스터와 스테이징 클러스터가 서로 간섭하지 않도록 둘을 더 확실히 떼어 놓는 안전장치를 추가한다.

   교훈

   테스트 클러스터용 배포가 운영 클러스터의 리소스를 건드릴 수 있으면 스테이징 작업이 곧 운영 장애가 된다. 스테이징 배포가 운영에 영향을 줬다는 사실이 바로 보이지 않아 조사가 DNS 와 AWS 에서 시작됐다. Traefik 만 되살려서는 복구되지 않았고 Calico 와 Traefik 의 관계까지 알아야 했다. CircleCI 는 Kubernetes 네트워크의 모든 계층을 담은 문서와 런북이 필요하다고 정리했다.

   사례 보기
5. 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 규칙을 모두 다시 만들었다.

   사례 보기

원인별7