사례12건

12건 중 10~12번째

1. 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 규칙을 모두 다시 만들었다.

   사례 보기
2. IL-0190 쿠버네티스 업그레이드로 etcd 리더가 있던 노드가 갑자기 종료된 뒤, Cortex distributor 두 개가 옛 리더와 맺은 TCP 연결이 멈춘 채 그 연결을 계속 써서 런던 리전 Hosted Prometheus 쓰기가 12분 동안 일부 실패했다.

   Grafana Labs2020

   증상

   2020년 3월 16일 11:31 UTC에 SLO 기반 알림이 당직 엔지니어를 호출했다. 런던 리전 Hosted Prometheus 로 들어오는 쓰기의 약 20%가 실패하고 있었다. 문제는 이미 11분 전에 시작된 상태였다.

   오류율 상승간헐적 타임아웃

   촉발

   예약된 쿠버네티스 버전 업그레이드가 etcd 리더가 돌던 노드를 정상 종료 절차 없이 갑자기 종료했다.

   원인

   소프트웨어 결함

   구성 요소

   etcd노드 풀

   기여 요인

   기본 설정 방치파괴적 변경 보호 장치 부재

   감지

   SLO 기반 알림이 11:31 UTC에 당직 엔지니어를 호출했다. 장애가 시작되고 11분이 지난 시점이었다. 오류율이 20% 수준이었기 때문에 이대로 두었다면 월간 SLA 를 넘기기까지 약 18시간이 걸렸을 것이다.

   조치

   • 11:32 UTC에 영향받은 distributor 를 재시작했고, 오류가 멈췄다.

   후속 조치

   • Cortex 의 etcd 클라이언트 설정에 gRPC keepalive 프로브를 켠다. DialKeepAliveTime 은 10초, DialKeepAliveTimeout 은 DialTimeout 의 두 배로 두고 PermitWithoutStream 을 true 로 한다.
   • 쿠버네티스 업그레이드 절차를 고쳐, etcd operator 가 관리하는 etcd 파드까지 포함해 파드와 머신을 정상 종료 절차로 내리게 한다.

   교훈

   노드가 죽으면 TCP 연결이 정상적으로 닫히지 않고 멈춘 채 남을 수 있다. etcd 클라이언트에 keepalive 를 설정하지 않으면 새 리더가 뽑힌 뒤에도 클라이언트는 죽은 연결을 계속 쓴다. 노드를 내리는 업그레이드 스크립트는 operator 가 관리하는 파드까지 정상 종료할 수 있어야 한다. 장애 대응과 복구, 사후 분석 동안 Grafana Loki 로 로그를 빠르게 뒤질 수 있어서 복구 시간이 줄었다.

   사례 보기
3. IL-0061 Terraform 상태 파일이 리뷰 빌드에서 바뀐 데다 권한 차이까지 겹쳐 Terraform 이 운영 GKE 클러스터 세 개 중 두 개를 삭제했다

   Spotify2019

   증상

   Terraform 이 아시아 운영 GKE 클러스터를 지웠다. 사내 서비스 디스커버리가 사라진 클러스터에 닿지 못하자 클러스터 운영 팀이 호출을 받았다.

   리소스 삭제

   촉발

   클러스터 운영 팀이 아시아 클러스터를 Terraform 상태 파일로 가져오는 PR 을 올렸고, 그 리뷰 빌드가 운영에 쓰이는 전역 상태 파일을 바꿨다. 그런데 이 PR 보다 클러스터 사용자의 PR 이 먼저 머지됐고, 그 PR 에는 아시아 클러스터 정의가 없었다. Terraform 은 정의에 없는 아시아 클러스터를 삭제했다.

   원인

   설정 변경

   구성 요소

   TerraformCI 시스템GKE 컨트롤 플레인

   기여 요인

   파괴적 변경 보호 장치 부재리뷰 누락미검증 가정

   감지

   사내 서비스 디스커버리가 사라진 클러스터에 닿지 못하자 클러스터 운영 팀이 호출을 받았다.

   조치

   • 서비스 디스커버리 설정에서 사라진 클러스터를 빼고 사내 서비스 디스커버리를 재시작해 파드 IP 를 백엔드 목록에서 지웠고, 트래픽을 쿠버네티스 밖 인스턴스로 넘겼다.
   • 쿠버네티스와 VM 에 반씩 나눠 돌던 한 팀이 부하를 받으려고 쿠버네티스 밖 VM 을 더 만들었다.
   • 미리 복원을 시험해 둔 클러스터 백업으로 삭제된 클러스터를 다시 만들었다.
   • 옛 클러스터 마스터 IP 를 하드코딩한 곳을 찾아 모두 새 값으로 고쳤다.

   후속 조치

   • 드라이런 결과를 PR 댓글로 달아 무엇이 바뀔지 바로 보이게 했다.
   • 머지 전에 브랜치가 최신 master 를 반영해야 하는 필수 상태 검사를 켜서, 드라이런이 실제로 일어날 일을 보여 주게 했다.
   • PR 머지에 승인 리뷰를 필수로 했다.
   • destroy 같은 키워드가 보이면 리뷰를 바로 실패시키고, 클러스터 삭제는 이 저장소 밖에서 손으로 하게 했다.
   • 클러스터 설정을 린터와 검증기로 검사하게 했다.
   • 일정을 미리 잡아 널리 알린 뒤, 클러스터가 사라지는 경우와 그보다 작은 실패를 다루는 재해 복구 훈련을 했다.

   교훈

   Terraform 은 상태 파일을 보고 할 일을 정한다. 리뷰 빌드가 운영 상태 파일을 바꾸게 두면 머지 순서 하나로 운영 리소스가 지워질 수 있다. 같은 리소스도 API 를 호출하는 권한에 따라 다른 속성으로 보이므로, 가져올 때와 관리할 때 권한이 다르면 Terraform 이 그 차이를 변경으로 읽는다. 처음부터 실패에 대비하고, 큰 인프라를 서서히 옮기고, 되돌릴 방법을 남겨 둔 덕분에 운영 클러스터 두 개가 사라져도 최종 사용자 영향이 없었다. 복원을 시험해 보지 않은 백업은 백업이 아니다. 실수를 누가 했는지보다 무엇을 배웠고 같은 종류의 실수를 어떻게 막을지가 중요하다.

   사례 보기

원인별4