주 서버 실패. 보조 서버 삭제. 기업의 자가 파괴 기록.

이 문서는 2025년 9월 2일, 오픈 소스 통신 프로토콜인 매트릭스(Matrix) 의 최대 홈 서버인 matrix.org에서 발생한 치명적인 데이터 삭제 사고와 그 복구 과정을 상세히 기록하고 있습니다. 하드웨어 결함으로 시작하여 운영자의 실수로 주 데이터베이스가 통째로 삭제되는 일련의 재난적 상황과 이를 해결하며 얻은 교훈을 담고 있습니다.

배경: 엘리먼트 크리에이션즈와 매트릭스 프로토콜

• 엘리먼트 크리에이션즈(Element Creations Limited) : 런던에 본사를 둔 기업으로, 예술적인 게임이나 장신구를 만드는 곳처럼 들리지만 실제로는 애플리케이션 계층 통신 프로토콜인 매트릭스를 개발하고 운영합니다.
• 프로토콜의 정의: 데이터가 클라이언트와 서버 사이에서 어떻게 흐르는지(메시지 형식, 암호화 방식 등)에 대한 약속된 규칙입니다.
• 매트릭스의 특징:
  • 탈중앙화: 왓츠앱(WhatsApp)이나 슬랙(Slack) 같은 중앙 집중형 플랫폼과 달리, 누구나 자신의 서버(홈 서버)를 구축하여 통신할 수 있습니다. 이메일과 유사한 구조이지만 실시간 채팅, 채팅방, 타이핑 표시, 읽음 확인 등의 기능을 제공합니다.
  • 주요 사용자: 미질라(Mozilla), 독일군 등이 자체 홈 서버를 운영하고 있습니다.
• matrix.org 홈 서버: 매트릭스 생태계에서 가장 오래되고 큰 공개 서버로, 엘리먼트 크리에이션즈가 관리하며 대다수의 사용자가 기본적으로 가입하는 중앙화된 진입점 역할을 합니다.

시스템 구조 및 사고의 시작

• 데이터베이스 구성:
  • 시냅스(Synapse) : 엘리먼트가 제작한 매트릭스 홈 서버 소프트웨어입니다.
  • 포스트그레스(PostgreSQL) : 거의 모든 데이터(방 상태, 이벤트, 메시지, 계정)를 저장하는 데이터베이스 관리 시스템입니다.
  • 이중화 구조: 주 데이터베이스인 DB2(Primary) 와 장애 대비용 보조 데이터베이스인 DB1(Secondary) 으로 구성되어 있었습니다.
  • 백업 방식: 트랜잭션 기록인 Write Ahead Log(WAL) 를 생성하여 보조 데이터베이스로 복제하고, 이를 아마존 S3(Amazon Simple Storage Service)에 아카이빙합니다.
• 초기 하드웨어 장애 (11:03 AM - 12:11 PM) :
  • 데이터베이스 서버 용량이 90%(51TB)에 도달하자 디스크 업그레이드를 결정했습니다.
  • 호스팅 업체인 미틱 비스트(Mythic Beasts)가 새로운 NVMe 드라이브를 추가하는 과정에서 DB2의 RAID 배열 내 기존 드라이브 하나가 오프라인이 되었습니다.
  • DB2는 RAID 10 구조를 사용하고 있어 드라이브 하나가 고장 나도 작동은 가능했지만, 추가 고장이 발생하면 데이터 손실이 일어날 수 있는 위험한 상태였습니다.

치명적 실수: "잘못된 터미널에서의 실행"

• 트래픽 전환 (12:57 PM - 1:27 PM) : 유지보수를 위해 고객 트래픽을 보조 서버인 DB1으로 전환했습니다. 이제 DB1이 주 서버가 되었습니다.
• 백업 공백: 당시 DB1에는 아카이빙 스크립트 버그가 있어 S3로 백업이 전송되지 않고 있었습니다. 즉, DB1에 하드웨어 장애가 발생하면 데이터가 영구 유실될 위기였습니다.
• DB2의 붕괴 (2:00 PM) : RAID 복구를 위해 DB2를 재부팅했으나, 두 번째 드라이브마저 사라지면서 RAID 배열 구성에 실패하고 복구 모드로 진입했습니다. DB2의 모든 데이터가 사실상 소실되었습니다.
• 사상 최악의 실수 (5:25 PM - 6:00 PM) :
  • 엔지니어들은 S3 백업을 통해 DB2를 복구하기로 했습니다.
  • Wall-g라는 도구를 사용하여 백업을 가져오려 했으나, 대상 디렉터리가 비어 있지 않다는 오류가 발생했습니다. (실행 중 생성된 로그 파일 때문이었습니다.)
  • 디렉터리를 비우기 위해 강제 삭제 명령(rm -rf)을 실행하려던 엔지니어는 혼란스러운 서버 명칭(과거의 Primary와 현재의 Primary) 때문에 현재 트래픽을 처리 중이던 DB1의 데이터 디렉터리를 삭제해 버렸습니다.
  • 이로 인해 matrix.org 서비스 전체가 오프라인이 되었습니다.

복구 과정의 난관 (7:21 AM 익일 - 6:00 PM 익일)

• 대용량 데이터의 압박: 51TB에 달하는 데이터를 S3에서 내려받아 복구하는 데 막대한 시간이 소요되었습니다.
• 소프트웨어 버그: 복구 도중 Wall-g의 특정 버그로 인해 증분 백업 복원이 실패했습니다.
  • 엘리먼트는 이미 테스트 서버에서 이 버그를 발견하고 수정했으나, 정작 운영 서버의 도구는 업데이트하지 않은 상태였습니다.
  • 전체 데이터를 다시 받지 않기 위해 엔지니어들이 현장에서 Wall-g 소스코드를 직접 수정(패치)하여 복구를 이어갔습니다.
• 복구 완료: 하드웨어 장애 발생 후 31시간, 서비스 전면 중단 후 24시간 만인 9월 3일 오후 6시에 matrix.org가 정상화되었습니다.

결론 및 교훈: 더 강력한 복구 시스템 구축

• 운영 환경의 개선:
  • 명령어의 대상 경로를 상대 경로가 아닌 절대 경로로 지정하여 실수를 방지해야 합니다.
  • 터미널 배경색 변경 등을 통해 서버 구분을 명확히 하는 것도 도움이 되지만, 극심한 압박 상황에서는 이마저도 놓칠 수 있습니다.
• 복구 속도의 중요성:
  • 사람이든 인공지능이든 실수는 언제나 발생할 수 있습니다. 핵심은 백업 복구 속도를 얼마나 높이느냐에 있습니다.
  • 엘리먼트는 증분 백업 주기를 단축하여 트랜잭션 로그를 재생하는 시간을 줄이기로 했습니다.
• 로컬 스냅샷 활용 (ZFS 등) :
  • 클라우드 백업 외에도 ZFS와 같은 파일 시스템의 스냅샷 기능을 추천합니다.
  • 스냅샷은 데이터를 물리적으로 복사하지 않고 메타데이터만 관리(Copy-on-write 방식)하므로, 실수로 데이터를 지웠을 때 네트워크 다운로드 없이 즉각적인 복구가 가능합니다.
• 마지막 경고: 로컬 스냅샷이 있더라도 서버 전체 고장에 대비한 외부 백업은 반드시 병행되어야 합니다.