코드 저장소 '기트랩' 중단에 개발자들 초긴장…왜

휴먼에러의 치명성과 백업의 중요성 시사

컴퓨팅입력 :2017/02/06 14:44

소스코드 호스팅 서비스인 기트랩이 지난달 31일 심각한 장애로 서비스 중단됐다가 6시간 만에 복구됐다. 시스템 관리자 실수로 프로덕션 데이터베이스를 삭제해 벌어진 사건으로, 일부 사용자의 데이터가 완전 유실됐다.

최근 외신에 따르면, 지난달 31일 기트랩의 데이터베이스 중 하나가 문제를 일으켜 서비스 중단 사태가 발생해 6시간 분량의 데이터베이스가 유실됐다. 기트랩은 긴급복구를 통해 유실된 데이터 복구에 나섰지만, 일부 사용자의 데이터는 끝내 복구하지 못했다.[기트랩 블로그 바로가기]

기트랩은 2014년 설립된 회사로 소스코드 깃을 호스팅하는 기트랩닷컴 서비스를 제공한다. 세계의 개인 및 기업 소속 개발자가 소스코드를 저장하고 있다.

기트랩은 1일 서비스를 정상작동시킨 후 6시간 동안의 데이터베이스 백업을 복구했다.

지난달 31일 기트랩닷컴의 중단을 알리는 트위터 공지

이 회사에 의하면, 31일 오후 6시(UTC 기준, 한국시간 오전 9시) 불량사용자가 스니펫(사용자코드) 대량입력으로 데이터베이스를 불안정하게 만드는 것을 감지해, 해결 조치를 시작했다.

3시간 뒤 데이터베이스 쓰기 기능이 마비되고 다운타임이 발생했다. 이에 따라 기트랩은 IP 주소에 기반해 불량 사용자 접근을 제한하고, 4만7천개 IP를 동일 ID로 접근하는 사용자를 제거하고, 스니펫을 대량생산하는 불량사용자의 접근을 제한했다.

오후 10시 DB 복제가 심각하게 지연되면서 다방면에서 장애가 발생했다. 오후 11시 담당자 중 한명이 백업 DB 인스턴스를 삭제하려다 실수로 프로덕션 DB 인스턴스에 시스템삭제 명령어인 ‘rm -rf’를 입력하고 말았다. 긴급히 실수를 인지하고 취소하려 했지만, 저체 300GB 중 4.5GB 데이터만 유지됐다. 결국 기트랩닷컴 서비스를 완전히 중단시켜야 했다.

가까스로 6시간 전의 DB 데이터로 원상복구했지만, 유실된 데이터를 되찾는 작업이 문제였다. 다행스럽게 스테이징 서버에 데이터 백업이 남아있었던 게 발견돼 대부분의 데이터를 복구했다고 한다.

이 사건으로 ‘projects’ ‘issues’ ‘merge requests’ ‘users’ ‘comments’ ‘snippets’ ‘etc’ 등의 데이터가 손실됐다. 사용자의 깃 데이터와 기트랩의 셀프 호스트 인스턴스는 영향을 받지 않았다.

협정세계시(UTC) 기준 오후 5시20분~오후 1시 25분 사이의 모든 데이터가 기트랩닷컴에서 삭제됐다. 6시간 동안 4천613개의 일반 프로젝트와 74개 포크, 350개 임포트 등이 유실됐다. 약 4천979건의 코멘트도 사라졌다고 한다.

기트랩 측은 전체 사용자의 1% 미만만 영향을 받았으며, 707 사용자의 데이터를 완전히 유실했다고 밝혔다.

기트랩은 자사의 데이터베이스 복구 작업을 유튜브 실시간 스트리밍을 통해 생중계했다.

전세계 개발자들이 발칵 뒤집혔다. 개발중이거나 운영중인 소프트웨어의 소스코드를 잃을까봐 노심초사한 개발자가 뜬눈으로 기트랩의 복구작업을 지켜봤다. 동시시청자가 5천명을 훌쩍 넘겼다는 후문이다.

기트랩에 대한 스니펫 생성 공격은 지금도 계속 이어지고 있다. 특히 공격 대부분이 한글로 이뤄지고 있다.

이 사건은 시스템 관리에서 휴먼에러의 위험성을 보여준다. 명령어를 잘못 입력한 담당자는 여러 터미널을 한 화면에 띄워놓고 장시간 극도의 스트레스를 받으며 작업하다 실수를 하고 말았다. 기트랩은 5종의 백업 및 복구 기술을 운영해 걷잡을 수 없는 사태를 겨우 방지했다.

관련기사

이용자들은 심각한 상황 속에서도 상세한 장애 복구 관련 정보를 외부에 제공한 기트랩의 조치를 긍정적으로 평가했다. 자칫 서비스 신뢰도가 완전히 무너질 지 모르는 최악의 장애도 운영 투명성을 유지했다는 반응이다.

반면, 비판도 거세다. 유사한 사건이 재발하면 안 된다는 비판도 많았다. 무엇보다 기트랩이 백업 기술을 여러개 도입하고도 사전에 충분히 테스트하지 않았다는 비판이 주를 이뤘다.