Incident Library

IL-0511 MIT Open Learning · 2023-10-30databaseaws

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

지난 6개월 사이 어느 시점에 xPro 운영 RDS 인스턴스의 기본 동작이 새 자격 증명에 MD5 대신 SCRAM 비밀번호 인증을 쓰도록 바뀌었다. xPro 는 Heroku 에서 pgbouncer 빌드팩을 쓰는데, 이 빌드팩은 SCRAM 을 지원하지 않았다. 팀은 Heroku 애플리케이션의 설정을 관리할 때 SaltStack 에서 Vault 를 불러 데이터베이스 자격 증명을 만들고 Salt Master 에 캐시한다. Vault 는 만든 자격 증명을 리스라는 내부 객체로 추적한다.

2023년 10월 30일 오후 3시 45분에 Salt 가 설정을 확인하고 적용할 때 리스가 곧 만료되고 갱신할 수 없다는 것을 보고 Vault 가 새 자격 증명을 만들었다. pgbouncer 는 MD5 비밀번호 해시를 보냈고, 데이터베이스는 이 새 자격 증명에 SCRAM 을 기대했으므로 연결을 거부했다. 애플리케이션은 데이터베이스에 연결하지 못해 시작을 끝내지 못했고 사이트가 응답하지 않았다.

오후 3시 51분에 Pingdom 알림이 왔고, 팀은 로그의 오류가 MITOpen 에서 겪은 문제와 같다는 것을 알아봤다. 그러나 xPro 의 RDS 와 관련 자원은 코드로 관리되지 않았고, AWS 가 주는 수정할 수 없는 기본 파라미터 그룹을 쓰고 있었다. 팀은 먼저 Vault 역할 정의를 고쳐 보는 다른 방법을 두 번 시도했지만 실패했다. 그 뒤 새 데이터베이스 파라미터 그룹을 만들어 운영 중인 데이터베이스에 적용하고, 캐시된 자격 증명을 지운 뒤 Salt 로 Heroku 설정을 다시 적용했다. 오후 4시 25분에 사이트와 로그인을 비롯한 데이터베이스 작업이 다시 됐다.

심각도
–
영향 범위
The xPro production site was not responding
영향 사용자
–
지역
–
감지까지
6m
복구까지
40m

증상

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

Heroku 로그의 pgbouncer 줄에는 Vault 가 발급한 사용자 v-aws-mitxpro-... 의 로그인 시도 뒤에 ERROR ... cannot do SCRAM authentication: wrong password type 오류가 나왔고, 이어서 closing because: server login failed: wrong password type (age=14s) 줄이 찍혔다. 데이터베이스 연결을 맺지 못하는 것은 애플리케이션에 치명적인 오류여서, 애플리케이션은 시작을 끝내지 못하고 요청을 받지 못했다.

팀은 이 로그가 새 MITOpen 환경을 꾸릴 때 겪은 문제와 같은 모양임을 알아보고, 그때 고친 PR 을 찾았다. 그러나 xPro 환경의 설정 코드는 Pulumi 로 관리되지 않아 같은 수정을 넣을 코드를 찾지 못했다.

팀은 데이터베이스 파라미터 그룹을 고치는 데 오래 걸릴 것으로 보고 먼저 다른 방법을 썼다. Vault 의 역할 정의를 고친 뒤 캐시된 자격 증명을 지우고 Salt 로 Heroku 설정을 다시 적용하기를 두 번 했다. Salt 가 적용한 자격 증명이 정말 새것인지도 확인했지만 사이트는 돌아오지 않았다.

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

원인

원인 설정 변경

구성 요소 데이터베이스시크릿 저장소
기여 요인 기본 설정 방치늦게 드러난 변경코드로 관리되지 않는 설정
촉발
오후 3시 45분에 Salt 로 xPro 운영 Heroku 스택에 설정 변경을 배포했다. 이때 Salt 가 본 Vault 리스가 곧 만료되고 갱신할 수 없는 상태여서 Vault 가 새 데이터베이스 자격 증명을 만들었고, 새 자격 증명은 RDS 의 새 기본값인 SCRAM 방식으로 만들어졌다.

감지

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

조치

후속 조치

교훈

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

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 데이터베이스, 시크릿 저장소. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.