복제본의 지연—그리고 프로덕션 서버의 타격
2017년 1월, GitLab.com은 복원력을 위해 PostgreSQL 프라이머리 서버인 db1.cluster.gitlab.com과 라이브 복제본인 db2.cluster.gitlab.com에 의존하고 있었습니다. 고가용성 설정을 위한 일반적인 이 아키텍처는 장애 조치를 위해 db2를 동기화 상태로 유지하는 것을 목표로 했지만, 이는 중요하면서도 종종 취약한 방어 수단이었습니다.
그날 저녁, 부하 급증으로 인해 db2가 너무 뒤처져 복제가 중단되었습니다. 표준 해결책은 db2의 데이터 폴더를 삭제하고 db1에서 모든 것을 복사하여 재초기화하는 것이었습니다. 이론적으로는 간단한 절차였습니다.
그러나 재초기화 과정에서 한 엔지니어가 실수로 db2가 아닌 프로덕션 프라이머리인 db1에서 rm -rf 명령어를 실행했습니다. 명령어는 1~2초 만에 중단되었지만, 이미 피해는 발생했습니다. 약 300GB의 데이터가 삭제된 것입니다. 이는 서서히 진행된 손상이 아니라 라이브 프로덕션 데이터의 갑작스럽고 치명적인 삭제였습니다. 이 잘못된 명령어 하나가 초래한 결과는 곧 드러났고, 훨씬 더 깊은 문제를 보여주었습니다.
모든 백업은 실제보다 안전해 보였다
GitLab의 재난은 단 하나의 실수뿐만 아니라 검증되지 않은 가정 위에 쌓아 올린 모래성 같은 구조에서 비롯되었습니다. 조직은 강력한 백업 전략을 갖추고 있다고 믿었지만, 모든 계층이 치명적인 결함을 안고 있었으며, 이는 테스트되지 않은 백업은 보호 수단이 아니라 단순한 가설에 불과하다는 것을 증명했습니다.
Amazon S3로 매일 수행되는 pg_dump 내보내기에 대한 신뢰는 잘못된 것이었습니다. PostgreSQL 9.6 데이터베이스를 보호하기 위한 이 작업은 이상하게도 훨씬 구버전인 PostgreSQL 9.2의 pg_dump 도구를 사용하고 있었습니다. 이러한 불일치로 인해 내보내기 작업은 오류 메시지 없이 실패했고, S3 버킷은 비어 있었습니다.
결정적으로, 아무도 이 시스템적 실패를 알아차리지 못했습니다. 백업 작업 실패를 알리기 위한 알림 이메일은 인증 문제로 인해 메일 서버에서 즉시 거부되었습니다. 설상가상으로 복원력의 기본 계층인 프로덕션 데이터베이스 스냅샷은 활성화조차 되어 있지 않았습니다. LVM 스냅샷은 스테이징 환경에만 존재했고, Azure Cloud 스냅샷은 OS 디스크만 다룰 뿐 중요한 데이터베이스 볼륨은 포함하지 않았습니다.
프라이머리 데이터베이스가 손상되고 복구 시도 중 복제본마저 삭제되면서, GitLab은 실행 가능한 최근 백업이 없다는 끔찍한 현실에 직면했습니다. 유일한 복구 방법은 엔지니어가 관련 없는 부하 테스트를 위해 수동으로 생성했던 약 6시간 전의 스냅샷뿐이었습니다. 엔지니어링된 솔루션이 아닌 이 행운은 그들의 전체 백업 철학이 얼마나 위태로웠는지를 강조했습니다. 느린 디스크에서 이 스냅샷을 복사하는 데 약 18시간이 소요되었으며, 이는 전체 서비스 중단 시간과 일치했고 데이터 복구 준비 소홀이 초래한 진정한 비용을 보여주었습니다.
5,000명의 시청자 앞에서 진행된 복구 과정
GitLab의 위기 대응은 급진적 투명성의 모범 사례였습니다. 엔지니어들은 Google Doc, 소셜 미디어, YouTube 라이브 스트리밍을 통해 실시간 업데이트와 문제 해결 과정을 공개했습니다. 이 결정은 치명적인 기술적 실패를 신뢰에 대한 고도의 가시적 시험대로 바꾸어 놓았고, 최대 5,000명 이상이 이를 지켜보았습니다.
매우 느리게 진행된 복구 작업은 느린 스토리지 디스크에 저장된 6시간 전의 수동 스냅샷에 의존했습니다. 이 스냅샷을 복원하는 데 약 18시간이 소요되었으며, 이는 전체 서비스 중단 시간과 같았습니다. 이러한 느린 복구로 인해 GitLab.com은 상당 기간 동안 중단되었습니다.
결과적으로 GitLab은 약 6시간 분량의 데이터베이스 레코드를 손실했습니다. 여기에는 대략 다음이 포함됩니다:
- 5,000개의 프로젝트
- 5,000개의 댓글
- 700개의 사용자 계정
다행히도 리포지토리 데이터는 별도의 스토리지에 온전히 보존되었습니다. 결과는 고통스러웠지만, 회복 탄력성과 정직함을 공개적으로 보여준 모습은 큰 존경을 받았습니다. 자세한 내용은 Postmortem of database outage of January 31 - GitLab을 참조하십시오. 이 사건은 업계의 많은 이들이 사고 대응과 급진적 투명성(radical transparency)을 바라보는 관점을 근본적으로 변화시켰습니다.
이 글이 마음에 드셨나요? 매일 아침 이런 글을 메일로 받아보세요.
하루 한 통 · 두 번의 클릭으로 구독 취소 · 제3자 추적 없음
교훈은 비난이 아닌 책임의 소재였다
GitLab의 사후 분석은 희생양을 찾는 것이 아니라 소유권(ownership)의 체계적 실패를 진단하는 것이었습니다. 핵심 문제는 엔지니어의 실수가 아니라 백업 신뢰성과 정기적인 복구 검증을 담당할 전담 역할이 부재했다는 점이었습니다. 아무도 책임을 지지 않았기에 중요한 안전장치들이 약화되었습니다.
이 사건은 내부적인 대대적 개혁을 촉발했습니다. GitLab은 자동화된 복구 테스트를 도입하여 백업이 단순히 존재하는 것뿐만 아니라 실제로 작동함을 보장했습니다. 또한 프로덕션 액세스 가드레일을 강화하여 파괴적인 작업이 실수로 발생하지 않도록 했으며, database reliability에 대한 명확한 책임을 전담 팀에 부여했습니다.
모든 엔지니어링 조직에게 주는 교훈은 명확합니다. 백업 무결성을 담당할 구체적인 담당자를 지정하십시오. 백업 실패 시 확인 가능한 알림 채널을 구축하고, 확인되지 않은 이메일에 의존하지 마십시오. 무엇보다 중요한 것은 복구 전략을 검증하기 위해 정기적으로 복구 테스트를 수행하고, 우발적인 데이터 손실을 방지하기 위한 강력한 안전장치를 구현하는 것입니다. 백업은 마지막으로 검증된 복구만큼만 신뢰할 수 있습니다.
자주 묻는 질문(FAQ)
2017년 GitLab 데이터베이스 중단 사고의 원인은 무엇인가요?
뒤처진 복제본을 수정하던 중, 엔지니어가 실수로 복제본이 아닌 프로덕션 데이터베이스의 데이터를 삭제했습니다.
GitLab은 왜 백업에서 복구할 수 없었나요?
일일 내보내기 작업이 호환되지 않는 Postgres 도구 버전으로 인해 실패했고, 실패 알림 이메일도 거부되었습니다. 프로덕션 스냅샷 또한 사용할 수 없는 상태였습니다.
GitLab의 서비스 중단 시간은 얼마나 되었나요?
복구에는 약 18시간이 소요되었는데, 이는 주로 느린 스토리지에서 수동으로 생성된 스냅샷을 복구하는 데 시간이 걸렸기 때문입니다.
GitLab은 어느 정도의 데이터를 손실했나요?
GitLab은 약 6시간 분량의 데이터베이스 데이터를 손실했으며, 여기에는 약 5,000개의 프로젝트, 5,000개의 댓글, 700개의 사용자 계정이 포함되었습니다.
이 사건의 가장 큰 교훈은 무엇인가요?
백업은 팀이 정기적으로 복구 가능 여부를 테스트하고, 그 과정에 대해 누군가 책임을 질 때만 신뢰할 수 있습니다.