사례2건
2건 중 1~2번째
- 증상
2025년 9월 2일 디스크 용량을 늘리는 작업 중 11:17 UTC 에 primary 데이터베이스 서버 db-02 의 RAID 배열에서 기존 드라이브 하나가 사라졌고 모니터링 알림이 울렸다. RAID 10 이라 데이터는 잃지 않았고 배열은 degraded 모드로 계속 동작했지만, 드라이브가 하나 더 고장 나면 버티지 못할 수 있었다.
- 촉발
디스크 용량을 늘리는 정기 작업 중 primary 데이터베이스 서버 db-02 의 RAID 배열에서 드라이브가 빠져 secondary 인 db-01 로 장애 조치를 했다. 그 뒤 db-02 를 복원하던 운영자가 실패한 복원의 흔적을 지우려다 db-01 에 있던 새 primary 의 데이터 디렉터리를 지웠다.
- 원인
- 구성 요소
- 기여 요인
- 감지
11:17 UTC 에 db-02 의 RAID 배열에서 드라이브가 빠지자 모니터링 알림이 울렸고 Mythic Beasts 가 문제를 확인했다. 운영자가 db-01 의 데이터 디렉터리를 지운 것을 스스로 알아챘다. 그 뒤 백엔드 팀을 호출하고, 장애 대응을 시작하며 비상 상황을 선언했다.
- 조치
- 16:11 UTC 에 새로 만든 RAID 10 배열로 db-02 서버를 다시 올렸다.
- 16:50 UTC 에 db-01 에 있던 primary 에서 막혀 있던 WAL 의 S3 보관을 다시 돌아가게 했다. 그래서 db-01 이 쌓인 WAL 을 지울 수 있게 됐다.
- 17:30 UTC 에 S3 에서 백업을 가져오는 wal-g 로 db-02 에 데이터베이스 복원을 시작했다.
- 알 수 없는 데이터베이스 상태를 피하려고 Synapse 와 db-01 의 primary 데이터베이스를 모두 내렸다.
- 18:06 UTC 에 db-01 의 데이터 파티션을 읽기 전용으로 다시 마운트해, 나중에 살릴 경우에 대비해 데이터베이스가 더 망가지지 않게 했다.
- S3 로 보관되지 못한 WAL 을 db-01 에서 db-02 로 복사해, S3 백업 복원이 끝나면 바로 재생할 수 있게 준비했다.
- wal-g 를 같은 메이저 버전의 최신 릴리스로 올린 뒤, 전체 백업이 이미 들어 있는 비어 있지 않은 데이터 디렉터리를 받아들이도록 wal-g 를 고쳐 빌드했다. 09:23 UTC 에 이 wal-g 를 db-02 에 써서 S3 에서 다시 받지 않고 증분 백업을 복원했다.
- S3 와 db-01 에서 옮겨 온 파일 시스템 양쪽에서 WAL 을 가져오는 래퍼 스크립트로 restore_command 를 설정하고 Postgres 를 standby 모드로 띄웠다. 11:00 UTC 부터 WAL 을 재생했다.
- 16:45 UTC 에 db-02 를 primary 데이터베이스로 승격하고, Synapse 시험 worker 를 띄워 새 WAL 이 S3 에 올라오는 것을 확인한 뒤 16:54 에 Synapse 를 시작했다. 18:00 에 모든 worker 가 안정됐다.
- WAL 재생이 느렸기 때문에, 없어진 복제본 대신 primary 데이터베이스에서 백업을 받도록 다시 설정했다. 03:26 UTC 에 새 증분 백업이 끝났다.
- db-01 에 NVMe 디스크 두 개를 RAID 배열과 LVM 볼륨 그룹에 넣었다. 배열 재구성 중 재부팅해 서버가 올라오지 않자 배열을 부팅할 수 있는 상태로 고쳤고, db-02 의 basebackup 을 복사해 db-01 을 다시 복제 상태로 두었다.
- 후속 조치
- 저장 공간이 늘어난 지금 pg_repack 을 돌려 빈 공간을 되찾는다.
- 증분 백업은 WAL 재생보다 훨씬 빨리 복원되므로 증분 백업을 더 자주 받도록 이미 바꿨다.
- Synapse 가 데이터를 저장하는 방식을 고쳐 앞으로 필요한 저장 공간을 크게 줄인다.
- 데이터베이스가 클러스터에서 맡은 역할에 따라 터미널 배경색을 바꾸는 방법을 검토한다. 데이터 디렉터리에 standby.signal 파일이 있는지 보고 primary 인지 secondary 인지 판단해 배경색을 바꾸는 안이 나왔다.
- rm 의 alias 처럼 위험한 명령을 감싸는 래퍼 스크립트를 두거나, primary 에서 secondary 로 base backup 을 시작하는 일 같은 작업을 자동화하는 방법을 논의했다.
- 복구 목표 시간을 줄인다. 더 쉽고 빠르게 복구할 수 있는 무료 인프라를 얻으려고 서비스 제공자들과 이야기하고 있다.
- 재해 복구 서버뿐 아니라 모든 서버의 wal-g 를 올렸고, 올린 wal-g 로 재해 복구 시험을 한 차례 했다. 재해 복구 서버와 운영 서버를 계속 같게 유지하는 방법은 아직 찾지 않았다.
- 다음 하드웨어 교체 때 ZFS 를 검토해, 엉뚱한 데이터베이스를 지우는 사고에서도 로컬 스냅숏으로 훨씬 빨리 복구할 수 있게 한다.
- 장애 대응 절차에 status.matrix.org 를 장애 중 공식 정보원으로 갱신하는 단계를 넣고, advocacy 팀과 함께 소셜 미디어도 계속 갱신한다.
- 교훈
이번 장애가 이렇게 힘들었던 데에는 데이터베이스가 너무 크다는 점이 크게 작용했다. 엉뚱한 서버에서 파괴적인 명령을 실행한 것이 결정적인 순간이었다. 하지만 팀은 개인을 탓하지 않고, 사람이 쓰는 도구와 절차를 고쳐 같은 일이 다시 일어날 가능성을 줄여야 한다고 보았다. 세 사람이 함께 작업했지만 급박한 상황에서는 실수를 잡지 못했다. db-01 은 primary, db-02 는 secondary 처럼 읽히지만 실제 역할은 서로 바뀔 수 있으므로, 뜻이 담긴 서버 이름은 혼란을 부른다. primary 와 secondary 를 모두 잃고도 데이터를 잃지 않은 것은 정기적으로 시험한 특정 시점 복구 절차 덕분이었다. 다만 복구 목표 시간은 줄여야 한다. 재해 복구 시험에서 찾은 wal-g 수정이 운영 서버에 빠져 있었으므로, 재해 복구 서버와 운영 서버를 같게 맞춰야 한다.
- 증상
matrix.org 홈서버 사용자들이 방이 그냥 멈춘다고 보고했다. 새 메시지를 보내거나 새 멤버가 방에 들어가는 일이 이유 없이 실패했고, 오류 문구가 보일 때는 대개 "No create event in auth events" 였다.
- 촉발
matrix.org 의 PostgreSQL 테이블 state_groups_state 에서 오래전에 손상된 인덱스 영역에 Postgres 가 새 행을 채우기 시작했고, 쓰이지 않는 오래된 데이터를 지우는 백그라운드 정리 작업이 최근 그 영역을 다루기 시작했다.
- 원인
- 구성 요소
- 기여 요인
- –
- 감지
사용자의 버그 보고와 공개 Matrix 방, 다른 소셜 미디어의 비슷한 보고로 문제를 알았다. 보고가 더 쌓이자 팀이 조사를 시작했다.
- 조치
- 예방 조치로 쓰이지 않는 state group 을 지우는 정리 작업을 잠시 껐다.
- 데이터를 백업에서 되살려야 할 것으로 보고 6월 26일 데이터베이스 백업을 Amazon EC2 의 새 Postgres 인스턴스에 복원하기 시작했다.
- 아직 쓰이는 state group 의 상태를 지우려는 SQL 쿼리를 거부하는 Postgres 제약을 걸어 손상이 더 번지지 않게 했다.
- 4 TB 가 넘는 손상된 인덱스를 밤새 다시 만들었다.
- 정리 작업이 다룬 범위의 state group 을 복원한 백업에서 조회해 피해 후보를 뽑고, 운영 데이터베이스와 대조해 지워졌지만 아직 쓰이는 state group 을 찾아 운영 데이터베이스에 하나씩 다시 넣었다.
- 교훈
이 손상은 몇 달이나 몇 년 동안 아무도 모르게 있을 수 있었다. 인덱스가 힙의 빈 자리를 가리키는 동안에는 드러나지 않았고, Postgres 가 그 자리에 새 행을 채우기 시작한 뒤에야 문제가 보였다. pg_amcheck 는 이런 손상을 찾지 못했지만, 테이블의 모든 행이 인덱스에 있다는 것은 확인해 줘서 인덱스 행이 빠진 것이 아니라 남는 행이 있다는 것을 알 수 있었다. 팀은 이런 장애가 큰 규모의 서비스를 운영하면 가끔 일어나고, 미리 계획할 수 없으며, 기능 개발이나 버그 수정에 쓸 사람의 시간과 노력을 크게 잡아먹는다고 정리했다.
이 2건에서 가장 많이 나오는 구성 요소: 데이터베이스, 데이터베이스 백업과 스냅숏. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.