사례3건

3건 중 1~3번째

1. IL-0511 Vault 가 새로 발급한 데이터베이스 자격 증명이 SCRAM 으로 만들어져 pgbouncer 가 RDS 에 로그인하지 못하고 xPro 운영 사이트가 멈췄다

   MIT Open Learning2023

   증상

   설정 배포 6분 뒤 Pingdom 이 DevOps 당번 엔지니어에게 알림을 보냈고, xPro 운영 사이트는 응답하지 않았다. Heroku 로그에는 데이터베이스 로그인 실패가 찍혀 있었다.

   서비스 중단자격 증명 획득 실패

   촉발

   오후 3시 45분에 Salt 로 xPro 운영 Heroku 스택에 설정 변경을 배포했다. 이때 Salt 가 본 Vault 리스가 곧 만료되고 갱신할 수 없는 상태여서 Vault 가 새 데이터베이스 자격 증명을 만들었고, 새 자격 증명은 RDS 의 새 기본값인 SCRAM 방식으로 만들어졌다.

   원인

   설정 변경

   구성 요소

   데이터베이스시크릿 저장소

   기여 요인

   기본 설정 방치늦게 드러난 변경코드로 관리되지 않는 설정

   감지

   설정 배포 6분 뒤인 오후 3시 51분에 Pingdom 이 DevOps 당번 엔지니어에게 알림을 보냈다. 당번 엔지니어가 알림을 받고 사이트가 응답하지 않는 것을 확인했다.

   조치

   • 새 데이터베이스 파라미터 그룹을 만들어 운영 중인 데이터베이스에 적용했다. 파라미터 그룹은 xPro RDS 가 쓰던 AWS 기본 파라미터 그룹을 복제한 뒤 필요한 값을 고친 것이었다.
   • 데이터베이스가 RDS 콘솔에서 Available 로 보인 뒤 캐시된 자격 증명을 다시 지우고 Salt 로 Heroku 설정을 다시 적용했다. 그러자 사이트와 데이터베이스 로그인이 돌아왔다.

   후속 조치

   • xPro 의 자원 관리를 Pulumi 로 옮긴다. 특히 RDS 인스턴스와 그에 딸린 자원을 코드로 관리하고, AWS 가 주는 기본 파라미터 그룹을 쓰지 않는다.

   교훈

   복구를 늦춘 핵심 요인은 이 스택의 설정이 거의 코드로 관리되지 않았다는 점이었다. RDS 인스턴스가 수정할 수 없는 AWS 기본 파라미터 그룹을 쓰고 있어서, 기본 정의를 복제해 고치고 인스턴스에 새로 연결해야 했다. 이 일은 이미 연결된 파라미터 그룹의 값을 바꾸는 것보다 오래 걸렸다. 팀은 자원을 Pulumi 로 관리했다면 기본 파라미터 그룹을 쓰지 않으므로 이 지연이 없었을 것이라고 정리했다.

   사례 보기
2. IL-0514 클라우드 사업자의 노드 교체 뒤 Consul 이 리더를 뽑지 못하고 Vault 가 봉인된 채 남아 PyPI 백엔드가 7분 동안 응답하지 않았다

   Python Software Foundation2022

   증상

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 다시 올라오려면 봉인 해제가 필요하다는 첫 알림이 왔다. 살펴보니 클러스터의 Vault 컨테이너는 모두 쓸 수 없었고 Consul 컨테이너는 새 리더를 뽑지 못하고 있었다.

   서비스 중단파드 Terminating 정체

   촉발

   2022-07-28 17:24 UTC 부터 클라우드 사업자가 알 수 없는 장애를 이유로 PyPI 가 도는 쿠버네티스 클러스터의 클라우드 인스턴스 여러 대를 자동으로 교체했다.

   원인

   클라우드 제공자 장애

   구성 요소

   코디네이션 키-값 저장소시크릿 저장소

   기여 요인

   자동화 증폭

   감지

   18:23 UTC 에 PSF 인프라 팀에 Vault 컨테이너가 적어도 하나 내려가 있고 봉인 해제가 필요하다는 알림이 왔다.

   조치

   • Terminating 상태에 멈춘 Consul 파드를 강제로 지우고 다시 만들어지게 했다. 그 뒤 Consul 회복이 시작됐다.
   • Consul 을 되살린 뒤 새 Vault 컨테이너의 봉인을 풀었다.

   사례 보기
3. 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 검증 때문에 몇 분 걸리는 이 단계는 건너뛸 수 있었다.

   사례 보기

원인별3