사례6건

6건 중 5~6번째

1. IL-0459 쿠버네티스 위 MediaWiki 가 TLS 종료에 엉뚱한 인증서를 써서 약 30분 동안 트래픽 1% 가 오류를 받았다

   Wikimedia Foundation2023

   증상

   MediaWiki 설정 변경을 배포한 11:41 부터 쿠버네티스로 가는 MediaWiki 트래픽이 오류를 받기 시작했다. 11:47 에 mw-api-ext 와 mw-api-int 서비스의 프로브 실패 알림이 온콜 담당자를 호출했다. 전체 트래픽의 1%, 초당 120건의 요청이 약 30분 동안 오류를 받았다.

   오류율 상승TLS 인증서 오류컨트롤 플레인 지연

   촉발

   09:37 에 쿠버네티스 전역 기본값을 바꾸는 변경이 머지됐다. 이 변경으로 이 기본값을 따르는 차트가 cert-manager 인증서를 쓰게 됐다. 11:41 에 MediaWiki 설정 변경을 배포하면서 쿠버네티스 위 MediaWiki 배포가 이 기본값을 받아 TLS 종료에 엉뚱한 인증서를 쓰게 됐다.

   원인

   설정 변경

   구성 요소

   cert-managerHelm

   기여 요인

   늦게 드러난 변경설정 테스트 부재

   감지

   11:47 에 "(ProbeDown) firing: (6) Service mw-api-ext:4447 has failed probes (http_mw-api-ext_ip4)" 와 "(ProbeDown) firing: Service mw-api-int:4446 has failed probes (http_mw-api-int_ip4)" 알림이 온콜 담당자를 호출해 알아챘다. 두 사람이 호출을 받았다.

   조치

   • 11:58 에 원인을 찾고 패치 https://gerrit.wikimedia.org/r/947331 을 준비했다.
   • 12:08 에 MediaWiki 디플로이먼트를 모두 다시 배포하기 시작했고, 12:16 에 장애가 끝났다.

   후속 조치

   • 배포 절차와 테스트를 더 강화해야 하는지 검토한다. 다음 배포에 뜻밖의 변경이 함께 실리는 문제와 쿠버네티스 카나리 배포도 검토 대상이다.
   • 배포 중에 일부 지표를 볼 수 없거나 비정상이 되는 문제를 지표 쪽에서 고칠지, 배포의 영향을 줄일지 검토한다.

   교훈

   문제를 일으킨 변경을 낸 사람이 대응자 가운데 있어 원인을 빨리 찾았다. 근본 원인은 CI 에서 보였어야 했다. 그러나 변경은 hieradata 저장소에서 했고 원인은 deployment-charts 저장소 쪽에 있어, 변경한 저장소의 CI 에서는 보이지 않았다. 당시에는 트래픽의 1% 만 쿠버네티스로 가서 피해가 작았다. 오류의 양이 적어 문제를 쿠버네티스 쪽으로 좁히는 데 시간이 걸렸다. 보고서는 쿠버네티스를 서비스 풀에서 더 일찍 뺐어야 했는지를 묻는다.

   사례 보기
2. IL-0460 Vault 가 만료된 TLS 인증서를 계속 써서 Vault 에 기대는 서비스 파드가 연쇄로 죽고 GoCardless 서비스 전체가 22분간 멈췄다

   GoCardless2020

   증상

   07:32 에 자동 모니터링이 장애를 잡아 온콜 엔지니어를 호출했다. 07:31 부터 GoCardless API 로 가는 요청이 전부 실패했고, 대시보드, 결제 페이지, 파트너 연동을 거치는 작업도 쓸 수 없었다. 07:32 부터 07:54 GMT 까지 22분 동안 서비스 전체가 멈췄다.

   서비스 중단컨테이너 재시작 반복TLS 인증서 오류자격 증명 획득 실패

   촉발

   cert-manager 가 Vault 의 TLS 인증서를 갱신했지만 Vault 는 새 인증서를 다시 읽지 않고 옛 인증서를 계속 썼다. 07:22 에 그 옛 인증서가 만료됐다.

   원인

   인증서·자격 증명 만료

   구성 요소

   cert-manager시크릿 저장소

   기여 요인

   단일 장애점모니터링 사각지대미검증 가정수동 조치 악화

   감지

   07:32 에 자동 모니터링이 장애를 잡아 온콜 엔지니어를 호출했다.

   조치

   • 07:42 에 인증서가 만료됐다고 보고 cert-manager 가 인증서를 다시 만들도록 손으로 강제했다. 실제로 인증서는 이미 갱신돼 있어 이 단계는 필요 없었다.
   • 07:48 에 새 인증서가 만들어지자 Vault 가 그 인증서를 읽도록 Vault 클러스터를 손으로 재시작했다.
   • 중요한 워크로드의 파드 몇 개를 직접 삭제해 5분까지 늘어난 지수 백오프를 건너뛰었고, 서비스가 몇 분 일찍 완전히 돌아왔다.

   후속 조치

   • L7 로드 밸런서에만 있던 TLS 인증서 만료 모니터링을 Vault 가 쓰는 단순 TCP 로드 밸런서까지 넓히고, Blackbox exporter 로 그 인증서도 주기적으로 검사한다.
   • Vault 서버가 바뀐 인증서를 스스로 다시 읽는 기능이 없으므로, Reloader 컨트롤러를 배포해 인증서 데이터가 바뀌면 Vault 를 롤링 업데이트한다.
   • Vault 로 가는 네트워크 분할 같은 다른 장애가 실행 중인 서비스에 번지지 않도록, theatre-envconsul 을 바꿔 envconsul 이 자식 프로세스를 관리하지 않게 하고 컨테이너 시작 때 비밀 환경 변수를 넣는 일만 하게 한다.

   교훈

   Vault 를 쓸 수 없게 된 것보다 Vault 에 기대는 모든 애플리케이션이 거의 곧바로 실패한 것이 훨씬 나빴다. 이런 장애 상황을 충분히 시험하지 않았고, 단일 장애점과 피해 범위를 줄여야 한다는 것을 장애를 겪고서야 다시 확인했다. 대응 중에는 인증서 자체가 만료됐다고 여겨 인증서를 다시 만들게 했다. 실제로는 인증서가 이미 갱신돼 있었고 Vault 가 다시 읽지 않았을 뿐이었다. 그래서 DNS 검증 때문에 몇 분 걸리는 이 단계는 건너뛸 수 있었다.

   사례 보기

원인별4