Incident Library

IL-0241 Stripe · 2019-07-10database

데이터베이스 shard 하나가 primary 를 뽑지 못해 Stripe API 요청 대부분이 두 차례 실패했다

Stripe 는 데이터를 종류별로 여러 데이터베이스 클러스터에, 양에 따라 여러 shard 에 나눠 두고, shard 마다 이중화한 노드를 여럿 둔다. 석 달 전 Stripe 는 데이터베이스를 새 마이너 버전으로 올렸다. 품질 보증 환경에서 시험하고 덜 중요한 클러스터부터 단계적으로 배포했으며, 석 달 동안 장애 조치도 여러 번 성공했다. 하지만 새 버전에는 멈춘 노드가 여럿 있을 때만 드러나는 장애 조치 결함이 있었다. 사고 나흘 전 노드 두 개가 아직 밝혀지지 않은 이유로 멈췄다. 두 노드는 복제 지연 지표를 내보내지 않으면서도 액티브 헬스 체크에는 정상이라고 응답했다.

2019년 7월 10일 16:35 UTC 에 이 shard 의 primary 노드가 고장 났고, shard 는 새 primary 를 뽑지 못했다. primary 가 없는 shard 는 쓰기를 받지 못했고, 여기에 쓰는 애플리케이션이 타임아웃을 내면서 API 의 컴퓨팅 자원이 바닥났다. 자동 모니터링이 1분 안에 선출 실패를 잡았고 팀은 2분 안에 대응을 시작했다. 처음 보는 장애라 원인을 진단하는 데 시간이 걸렸다. 가장 빨리 복구하는 방법은 새 primary 선출을 강제하는 것이었고, 그러려면 클러스터를 재시작해야 했다. 17:00 에 모든 노드를 재시작하자 선출이 성공했고, 시작 27분 뒤인 17:02 에 API 가 완전히 복구됐다.

20:13 에 팀은 새 마이너 버전의 선출 프로토콜에서 결함을 일으켰을 법한 코드 경로를 찾았다. 20:42 에 영향받은 클러스터의 모든 shard 를 이전의 안정된 선출 프로토콜 버전으로 되돌렸고, 배포는 4분 안에 끝났다. 그런데 되돌린 버전이 운영 shard 에 최근 넣은 설정 변경과 맞물려 21:14 부터 영향받은 shard 전부에서 CPU 가 바닥났고, 두 번째 장애가 시작됐다. 팀은 처음에 같은 문제가 다시 난 줄 알고 첫 번째 복구 절차를 따랐다. CPU 고갈을 보고 나서야 원인을 찾았고, CPU 경합 때문에 설정 변경도 느리게 적용됐다. 22:34 에 새 설정을 배포하고 노드를 재시작해 shard 를 되살렸다. 클러스터가 정상인지 확인한 뒤 사용자가 직접 보낸 API 요청에 필요한 서비스부터 트래픽을 다시 올렸고, 22:47 에 API 가 완전히 복구됐다.

심각도
–
영향 범위
Stripe API: a substantial majority of requests failed from 16:35 to 17:02 UTC and from 21:14 to 22:47 UTC
영향 사용자
Stripe users; those with five or more failed POST requests were sent an email
지역
–
감지까지
1m
복구까지
6h 12m

증상

2019년 7월 10일 16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났고, 1분 뒤 자동 모니터링이 선출 실패를 잡아 알림을 보냈다. Stripe API 요청 대부분이 실패하기 시작했다.

primary 가 없는 shard 는 쓰기를 받지 못했고, 그 shard 에 쓰는 애플리케이션들이 타임아웃을 냈다. API 를 포함해 많은 애플리케이션이 이 shard 를 쓰고 있었다. 그래서 shard 하나가 멈추자 API 의 컴퓨팅 자원이 바닥났고, API 전체의 심각한 장애로 번졌다. 16:50 에 팀은 클러스터가 primary 를 뽑지 못한다는 것을 확인했다.

이 장애의 조건은 나흘 전에 이미 만들어져 있었다. 그때 노드 두 개가 멈춰 복제 지연 지표를 내보내지 않았지만, 액티브 헬스 체크에는 계속 정상이라고 응답했다.

21:14 UTC 에 클러스터의 shard 몇 개가 사용할 수 없다는 자동 알림이 다시 울렸고, 데이터베이스 클러스터의 CPU 사용률이 높게 나타났다. 첫 장애 때 문제가 된 shard 도 그 안에 있었다.

증상이 첫 장애와 같아 보여서 팀은 같은 문제가 여러 shard 에서 다시 났다고 여기고 첫 장애 때 통했던 복구 절차를 그대로 따랐다. 실제 원인은 달랐다. 되돌린 선출 프로토콜이 최근 넣은 설정과 맞물려 영향받은 shard 전부에서 CPU 가 바닥나 있었다. CPU 경합 때문에 필요한 설정 변경을 적용하는 일도 느려졌다.

증상 오류율 상승장애 조치 실패쓰기 거부간헐적 타임아웃노드 CPU 고부하

원인

원인 소프트웨어 결함

구성 요소 데이터베이스데이터베이스 장애 조치 관리자
기여 요인 늦게 드러난 변경모니터링 사각지대과도한 영향 범위수동 조치 악화미검증 가정장애 중첩
촉발
16:35 UTC 에 데이터베이스 클러스터의 primary 노드가 고장 났다. 그 shard 에는 멈춘 노드가 여럿 있어 석 달 전 마이너 버전 업그레이드로 들어온 장애 조치 결함이 드러났다. 두 번째 장애는 선출 프로토콜을 이전 마이너 버전으로 되돌린 변경 때문에 일어났다.

감지

첫 장애는 자동 모니터링이 1분 안에 선출 실패를 잡았고, 16:36 UTC 에 팀이 알림을 받아 대응을 시작했다. 두 번째 장애는 21:14 UTC 에 클러스터의 shard 몇 개를 사용할 수 없다는 자동 알림으로 알았다.

조치

후속 조치

교훈

–

출처

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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