사례3건

3건 중 1~3번째

1. IL-0242 primary 와 secondary PostgreSQL 데이터베이스를 모두 잃어 matrix.org homeserver 가 약 24시간 동안 멈췄다

   Matrix.org Foundation2025

   증상

   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 수정이 운영 서버에 빠져 있었으므로, 재해 복구 서버와 운영 서버를 같게 맞춰야 한다.

   사례 보기
2. IL-0325 주 데이터베이스가 지워져 DigitalOcean 제어판과 API 가 4시간 56분 동안 멈췄다

   DigitalOcean2017

   증상

   2017-04-05 10:24 EDT 에 공개 서비스가 동작하지 않는다는 알림이 들어왔다. 제어판과 API 를 쓸 수 없었다. 돌고 있던 Droplet 은 계속 동작했지만, 새 Droplet 이나 다른 자원을 만들거나 관리할 수는 없었다.

   서비스 중단

   촉발

   자동 테스트를 돌리는 프로세스가 운영 환경 자격 증명을 쓰도록 잘못 설정돼 있었고, 그 결과 주 데이터베이스가 지워졌다.

   원인

   설정 변경

   구성 요소

   데이터베이스데이터베이스 복제데이터베이스 백업과 스냅숏

   기여 요인

   파괴적 변경 보호 장치 부재

   감지

   10:24 EDT 에 공개 서비스가 동작하지 않는다는 알림이 들어왔고, 3분 뒤 마스터의 운영 데이터베이스가 지워진 것을 확인했다.

   조치

   • 10:34 EDT 에 시간 지연 레플리카에서 복구를 시작했다.
   • 11:53 에 시간 지연 레플리카의 백업을 마쳤다.
   • 12:34 에 백업을 마스터로 복사하고 복원을 시작했다.
   • 13:31 에 마스터 복구를 마쳤고 레플리카로 백업을 복사하는 일을 이어 갔다. 15:20 에 모든 시스템이 복원됐다.

   후속 조치

   • 같은 일이 다시 없도록 특정 작업에서 주 시스템에 접근할 수 있는 권한을 크게 줄인다.
   • 데이터베이스 서버 사이의 네트워크 연결을 업그레이드한다.
   • 복구 속도를 높이도록 하드웨어를 바꾼다.
   • 개발자 실수를 막는 안전장치를 더 검토한다.
   • 데이터 복구 절차를 개선한다.
   • 고객에게 영향을 주는 장애가 날 때 실시간 정보를 더 잘 전할 방법을 찾는다.

   사례 보기
3. IL-0485 계획된 OS 업그레이드 작업이 운영 중인 데이터베이스 서버를 재설치해 Dropbox 서비스가 멈췄다

   Dropbox2014

   증상

   2014-01-10 금요일 오후 5시 30분 PT에 시작한 계획된 유지보수 중에 Dropbox 서비스가 내려갔다. 약 3시간 뒤 서비스는 다시 올라왔지만, 핵심 서비스가 완전히 돌아온 것은 일요일 오후 4시 40분 PT였다.

   서비스 중단

   촉발

   일부 서버의 OS를 올리는 계획된 유지보수에서 업그레이드 스크립트의 잘 드러나지 않는 버그 때문에 사용 중인 데이터가 있는 서버 몇 대에 재설치 명령이 내려졌다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 백업과 스냅숏

   기여 요인

   파괴적 변경 보호 장치 부재

   조치

   • 서비스를 빨리 되살리려고 영향을 받은 데이터베이스를 백업에서 복원했다.

   후속 조치

   • 서버가 들어온 명령을 실행하기 전에 자기 상태를 로컬에서 확인하는 검사 단계를 더했다. 중요한 프로세스를 돌리고 있다고 스스로 확인한 서버는 파괴적일 수 있는 작업을 거부한다.
   • 바이너리 로그 재생을 병렬로 처리하는 도구를 만들어 큰 MySQL 백업에서 더 빨리 복원한다.
   • 이 바이너리 로그 병렬 재생 도구를 오픈 소스로 공개할 계획이다.

   교훈

   서버 상태를 원격 스크립트로만 확인하면 스크립트의 버그 하나로 운영 서버에 파괴적인 작업이 실행될 수 있으므로, 서버 스스로도 자기 상태를 확인해야 한다. 복제본을 여러 대 두어도 복제본까지 잃으면 백업에서 복원하는 길뿐이다. 큰 데이터에서는 MySQL 표준 복원 도구가 느리므로 복구를 빠르게 할 수단이 필요하다.

   사례 보기

원인별3