Incident Library

IL-0321 GitLab · 2021-01-16databasegcp

GitLab.com 의 Patroni 주 데이터베이스 노드가 멈춰 장애 조치가 일어났고 쓰기 요청에서 5xx 오류가 튀었다

2021-01-16 GitLab 인프라 팀은 production#2648 변경을 진행하면서, 관련 파일시스템 변경에 앞선 안전 조치로 23:36 UTC 에 모든 Patroni 데이터베이스 노드에서 GCP 디스크 스냅샷을 동시에 시작했다. 팀은 스냅샷이 GCP API 로 뒤에서 처리돼 실행 중인 노드에 영향을 주지 않는다고 잘못 알고 있었다.

Postgres 데이터 볼륨의 스냅샷은 IO 지연을 크게 끌어올렸다. 팀은 스냅샷이 네트워크로 연결된 영구 디스크에 쓸 수 있는 네트워크 대역폭을 다 써 버렸기 때문으로 추정했다. 영구 디스크는 VM 인스턴스에 할당된 네트워크 대역폭을 나눠 쓴다. 변경을 계획한 엔지니어는 이 구조를 몰랐고, 그 때문에 하트비트와 헬스 체크를 놓칠 수 있다는 점도 몰랐다. 주 노드의 디스크 접근이 멈췄고, 같은 때 그 노드는 consul 과의 네트워크 연결도 잃었다. 둘 중 하나 또는 둘 다가 장애 조치를 일으켰다. 23:40 에 Patroni 가 patroni-06 의 락을 무효로 하고 장애 조치를 시작했고 23:41 에 patroni-03 이 새 주 노드가 됐다.

23:38 부터 23:42 사이에 데이터베이스 쓰기가 필요한 요청 일부가 5xx 오류를 받았고, 23:42 에 오류율이 내려갔다. 팀은 예상보다 심한 성능 저하를 보고 세 존 가운데 두 존의 스냅샷을 취소했다. 장애 조치가 일어난 것은 나중에 변경 계획의 다음 단계를 진행하면서 알았다. 23:56 에 Slack 에서 장애를 선언했다. 전에도 스냅샷 때문에 Patroni 장애 조치가 난 비슷한 일이 있었다.

심각도
–
영향 범위
Some GitLab.com requests that needed database writes returned 5xx errors for about 4-5 minutes: about 0.133% of Rails requests and about 2.86% of Workhorse requests
영향 사용자
All active users during the incident
지역
–
감지까지
1m
복구까지
4m

증상

2021-01-16 23:38 UTC 부터 GitLab.com 의 오류가 급증했고 23:39 에 서비스 중단 알림이 여러 개 들어왔다. 데이터베이스 쓰기가 필요한 요청 일부가 5xx 오류를 받았다.

오류는 약 4~5분 이어졌다. Rails 에서는 23:38:30 과 23:42:00 사이에 약 2,000건의 5xx 오류가 났고, 기록된 요청 1,521,180건에 견주면 약 0.133% 였다. Workhorse 에서는 481,335건 가운데 13,757건으로 약 2.86% 였다. 장애 중에 확인 삼아 새로 고친 페이지는 정상으로 떴다.

23:40 에 Patroni 가 patroni-06 의 락을 무효로 하고 장애 조치를 시작했고, 23:41 에 patroni-03 이 새 주 노드가 됐다. 23:42 에 오류율이 내려갔다.

팀은 마지막으로 한 작업인 스냅샷이 원인이라는 것을 곧바로 알았다. 예상보다 심한 성능 저하를 보고 세 존 가운데 두 존의 스냅샷을 취소했다. 하지만 장애 조치까지 일어났다는 것은 장애 중에 알아채지 못했고, 변경 계획의 다음 단계를 진행하면서 나중에 알았다.

증상 오류율 상승

원인

원인 용량 한계

구성 요소 데이터베이스데이터베이스 장애 조치 관리자클라우드 블록 스토리지
기여 요인 미검증 가정단계적 배포 부재
촉발
production#2648 변경을 진행하던 엔지니어가 23:36 UTC 에 모든 Patroni 노드에서 GCP 디스크 스냅샷을 동시에 시작했다. 이 스냅샷은 관련 파일시스템 변경에 앞선 안전 조치였다. 엔지니어는 스냅샷이 GCP API 로 뒤에서 처리돼 실행 중인 노드에 영향을 주지 않는다고 잘못 알고 있었다.

감지

다운스트림 서비스의 영향을 알리는 알림이 한꺼번에 쏟아지면서 알아챘다. 23:38 UTC 에 오류 급증이 보였고 23:39 에 서비스 중단 알림이 여러 개 들어왔다. 감지까지 1~2분이 걸렸다.

조치

후속 조치

교훈

실행 중인 PG 리더 노드에서 GCP 스냅샷을 뜨지 않는다. 변경 요청 이슈 본문이 바뀌거나 내용이 더해지면, 기술 검토자는 관리자나 디렉터가 승인하기 전에 그 내용을 하나하나 검토한다. Datastores 팀은 운영 데이터베이스의 백업과 스냅샷이 어떻게 동작하는지 자세히 공유한다. 변경과 관련된 작업은 일정 초대에 잡힌 변경 시작 시각이 된 뒤에 시작한다.

출처

참고 문서

관련 사례

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

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

kubegap 열기

AI 도구와 스크립트용

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