사례71건

71건 중 41~45번째

1. IL-0009 ArgoCD Application 이름이 겹쳐 InfluxDB Cloud 운영 환경 하나가 통째로 삭제됐다

   InfluxData2022

   증상

   PR 하나를 머지한 직후 InfluxDB Cloud 운영 환경 하나가 통째로 사라졌다. 쓰기와 읽기를 비롯한 모든 API 엔드포인트가 404 오류를 냈다.

   서비스 중단리소스 삭제오류율 상승

   촉발

   팀원 한 명이 설정 파일에 새 객체 여러 개를 더하는 PR 을 올렸다. 그중 새 ArgoCD Application 과 AppProject 의 이름이 자동화 오류로 app02-cluster01 이 아니라 기존 것과 같은 app01-cluster01 로 정해졌다. 코드 리뷰에서도 app01 과 app02 의 차이를 알아채지 못해 PR 이 그대로 머지됐다.

   원인

   설정 변경

   구성 요소

   Argo CD영구 볼륨과 스테이트풀셋설정 템플릿

   기여 요인

   리뷰 누락런북 부재파괴적 변경 보호 장치 부재모니터링 사각지대자동화 증폭

   감지

   모니터링과 경보 시스템은 이 장애를 바로 잡아내지 못했다. 그래서 팀은 계획을 세워 복구하기 전에 먼저 변경을 되돌리려 했다. 팀이 장애를 무엇으로 알게 됐는지는 글에 나오지 않는다.

   조치

   • 머지된 PR 을 되돌리기 시작했다가 곧바로 멈췄다.
   • etcd 메타데이터 클러스터를 복원했다.
   • 지워진 쿠버네티스 객체를 다시 만들어 남아 있던 PersistentVolume 을 다시 쓸 수 있게 하고, StatefulSet 을 다시 만들었다.
   • Zookeeper 볼륨을 Velero 로 매시간 받아 둔 백업에서 복원했다.
   • 헬스 체크와 readiness 체크를 끈 채 Kafka StatefulSet 을 파드 하나씩 다시 만들었다.
   • 쓰기 선행 로그 역할을 하는 Kafka 로 다시 쓰기를 받고, 쓰기를 처리하는 컴포넌트의 레플리카 수와 메모리 request 와 limit 을 늘렸다.
   • 스토리지 파드를 다시 만들었다. 파드는 오브젝트 스토리지에서 데이터를 내려받아 인덱싱한 뒤 쓰기 선행 로그에 밀려 있던 데이터를 읽어 들였다.
   • ArgoCD, 쿼리, 대시보드, 예약 작업을 다시 켜고, 레플리카 수를 원래대로 돌린 뒤 최종 QA 점검을 했다.

   후속 조치

   • 상태를 되살리는 절차를 담은 런북을 만들었다. PVC 같은 쿠버네티스 객체는 지워졌지만 디스크와 볼륨에 데이터는 남아 있을 때 할 일을 자세히 적었다.
   • 모든 환경의 모든 볼륨이 PVC 객체가 지워져도 데이터를 유지하도록 설정했다.
   • 외부에 드러나는 장애를 다루는 절차를 개선했다.
   • 생성된 YAML 을 객체 하나당 파일 하나로 저장하도록 바꿨다. 예를 들어 etcd Service 는 v1.Service-(namespace).etcd.yaml 파일이 된다. 이제 이번과 같은 PR 은 새 객체를 더하는 변경이 아니라 기존 객체를 덮어쓰는 변경으로 보인다.
   • YAML 생성 도구가 중복 객체를 찾아 리뷰를 요청하기 전에 경고하도록 고쳤다. 파일 이름만 보지 않고, apiVersion 이 networking.k8s.io/v1beta1 과 networking.k8s.io/v1 처럼 달라도 네임스페이스와 이름이 같으면 같은 객체로 판단한다.
   • 모든 상태 저장 리소스와 ArgoCD 가 관리하는 Namespace 객체에 Prune=false 어노테이션을 달아, 설정이 잘못돼도 ArgoCD 가 지우지 않게 했다.
   • ArgoCD Application 에 FailOnSharedResource=true 옵션을 넣었다. 다른 Application 이 관리하거나 관리했던 객체를 바꾸려 하면 ArgoCD 는 변경을 적용하지 않고 동기화를 실패로 멈춘다.

   교훈

   무엇보다 모니터링과 경보가 장애를 바로 잡아내지 못했다. 그 탓에 팀은 계획된 복구 대신 롤백부터 시도했다. InfluxDB Cloud 인스턴스 일부나 전체를 잃었을 때 쓸 런북도 없었다. 상태 저장 애플리케이션은 변경을 되돌린다고 원래대로 돌아오지 않고, 데이터 없는 새 인스턴스가 생길 뿐이다. 이런 PR 은 시스템이 머지를 막았어야 했다. 볼륨을 Retain 으로 둔 데다 Telegraf 처럼 쓰기를 재시도하는 클라이언트가 있어서 데이터를 하나도 잃지 않았다.

   사례 보기
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-0132 잘못된 리소스 정리 작업이 Vertex AI 예측 엔드포인트를 전역에서 삭제된 것으로 표시해 고객 모델이 내려가고 예측 요청이 4시간 넘게 실패했다.

   Google Cloud2022

   증상

   2022-06-02 10:10 US/Pacific 부터 Vertex AI Online Prediction 의 오류율이 올라갔다. 리전과 사용 패턴에 따라 요청의 30% 에서 100% 가 실패했다.

   오류율 상승리소스 삭제서비스 중단

   촉발

   잘못된 리소스 정리 작업이 Vertex 예측 엔드포인트를 전역에서 삭제된 것으로 표시했다.

   원인

   소프트웨어 결함

   구성 요소

   모델 요청 라우팅

   기여 요인

   자동화 증폭과도한 영향 범위

   감지

   Google 은 13:58 US/Pacific 에 상태 페이지에 첫 공지를 올렸고, 이 공지는 문제가 10:20 US/Pacific 에 시작됐다고 적었다. 나중에 나온 짧은 장애 보고서는 시작 시각을 10:10 으로 적었다.

   조치

   • 삭제된 것으로 표시된 Vertex 예측 엔드포인트를 복구했고, 서비스가 완전히 회복됐다.

   사례 보기
4. IL-0113 한 번도 교체되지 않은 GKE API 서버 인증서 때문에 메인 클러스터의 컨트롤 플레인이 망가져 EU 리전의 백엔드 API, 프런트엔드, 터널이 모두 멈췄다

   Webhook Relay2022

   증상

   2022년 5월 10일 낮 12시 EST 에 헬스체크 시스템이 경보를 울렸다. EU 리전의 백엔드 API, 프런트엔드, 터널이 모두 내려가 있었다. 처음에는 클라이언트 쪽에서 요청이 끊겼거나, 메모리나 CPU 사용량 때문에 축출된 서버에 요청이 닿은 일시적 오류라고 생각했다. 메인 대시보드가 내려간 것을 보고 바로 대응을 시작했다.

   서비스 중단컨트롤 플레인 지연컨트롤 플레인 무응답API 조회 결과 불일치자격 증명 획득 실패

   원인

   인증서·자격 증명 만료

   구성 요소

   GKE 컨트롤 플레인쿠버네티스 API 서버노드 풀RBAC 와 서비스 어카운트

   기여 요인

   디버그 접근 제한단일 장애점

   감지

   헬스체크 시스템이 서비스가 내려갔다는 첫 알림을 보냈다. 팀은 처음에 일시적 오류로 보고 자동 복구를 기대했지만, 메인 대시보드가 내려간 것을 확인하고 바로 대응을 시작했다.

   조치

   • 인증서 교체가 노드를 다시 만들지 않아 13시 20분 노드 풀을 손으로 다시 만들었다.
   • 14시 30분에는 이미 메인 클러스터의 서비스를 새로 만든 GKE 클러스터에 복제하고 있었다.
   • 16시 50분 기존 클러스터에서 쿠버네티스 Service 레코드를 지워 로드 밸런서를 새 클러스터에 붙일 수 있게 했다.
   • 17시 30분 StatefulSet 을 기존 클러스터에서 떼어 내고 모든 쓰기를 메인 디스크로 돌렸다.
   • 18시 30분 임시 ClickHouse 인스턴스의 데이터를 내보내 메인 인스턴스에 다시 넣었다.

   후속 조치

   • 디스크 데이터를 복잡하게 옮기지 않고도 클러스터 사이를 빠르게 바꿀 수 있도록 배포 매니페스트를 고쳤다.

   교훈

   기존 인프라를 살리는 작업에는 시간 상한을 정해야 한다. 장애 내내 서비스가 곧 살아날 것처럼 보였지만, 기존 클러스터를 훨씬 일찍 포기하고 새 클러스터에서 다시 시작했어야 했다. 이미 들인 노력이 아까워 살리기를 멈추지 못한 것이 판단을 늦췄다. 오래된 GKE 클러스터라면 클러스터 CA 인증서의 유효기간을 `gcloud container clusters describe <cluster name> --zone europe-north1-a --format "value(masterAuth.clusterCaCertificate)" | base64 --decode | openssl x509 -text | grep Validity -A 2` 로 확인할 수 있다.

   사례 보기
5. 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 스키마도 잘못된 매니페스트 적용을 막지 못했다. 팀은 대응 과정에서 장애 관리자를 정했다면 도움이 됐을 것으로 봤다. 그리고 워룸 회의를 녹화하고, 대응에 참여하지 않는 사람은 글로만 제안하고, 일지를 남기자고 정리했다. 대응 초반에 각자의 생각과 직감을 짧게 나누는 시간도 갖자고 했다.

   사례 보기

원인별11