2/1/17 GitLab.com Database Incident(한글번역)

출처 : Gitlab.com
Gitlab의 허락을 받고 번역하였습니다.
피드백은 자유롭게 부탁드립니다.

17년 1월 31일  Gitlab의 데이터베이스 중 하나가 문제가 발생했습니다. 그 결과 Gitlab.com의 6시간 분량의 데이터베이스 데이터(issues, merge, requests, users, comments, snippets, etc.)를 잃었습니다. Git/wiki 리포지토리 및 self-hosted-installations는 영향을 받지 않았습니다. Production 데이터를 잃는 것은 심각한 사건이기에, 빠른 시일 내 이와 같은 사태가 벌어진 5가지 이유와 조치 사항을 포스팅 하겠습니다.

업데이트 2월 1일 18:14 UTC: GitLab.com  – 온라인 (정상 작동 )

업데이트 포스팅을 하는 동시에, 6시간 전 데이터베이스 백업을 복구하고 있습니다. 즉, Gitlab.com이 정상 작동 시, 17:20 UTC 와 23:25 UTC 사이의 데이터 중 (projects, issues, merge requests, users, comments, snippets, etc.) 는 손실됩니다.

Git 데이터 (리포지토리 와 wikis), self-hosted instances of GitLab은 영향을 받지 않았습니다.

아래는 이번 사건을 간략하게 정리한 내용입니다. 조금 더 자세한 내용은  gitlab 즉각 조치사항(영문) 에서 확인 하실 수 있습니다.

최초 사건

2017/01/31 18:00 UTC에, 우리는 불량 사용자들이 Snippets(사용자 코드)을 대량으로 입력하여 데이터베이스를 불안정하게 만드는 것을 감지했습니다. 이후 문제점 파악 및 해결을 위해 조치를 시작했습니다.

2017/01/31 21:00 UTC에, 이 사건으로 인해 데이터베이스의 쓰기 기능이 일시적으로 마비되었으며, downtime을 초래했습니다.

조치 사항

  • IP address기반으로 불량 사용자 접근 제한
  • 리포지토리를 CDN으로 사용하여 47,000개 IP를 동일 아이디로 접근하는 User를 제거
  • Snippets를 대량 생산하는 불량 사용자 접근 제한

두번째 사건

2017/01/31 22:00 UTC에 – DB Replication의 지연이 심각해지면서 우리는 호출을 받았습니다. 이는 write 급상승으로 보조 DB가 제 때 처리 되지 않았기 때문에 발생했습니다.

조치 사항

  • db2 고장 조치 시도(약 4 GB 지연)
  • db2.cluster 가 replicate 거부하여 /var/opt/gitlab/postgresql/data 삭제(clean replication)
  • db2.cluster 가 max_wal_senders의 수치가 낮음을  이유로  db1연결을 거부함, 이 설정은  WAL (= replication) 제한을 위해 사용했음
  • 팀원-1db1의 max_wal_senders 을 32 로 변경 후  PostgreSQL 재시작
  • PostgreSQL – 에러 (많은 semaphores 가 열려있어 start 거부)
  • 팀원-1max_connections 을 2000 에서 8000으로 조정, PostgreSQL 시작 성공 (8000having been used for almost a year)
  • db2.cluster 여전히 repliacte 거부, 에러는 없어졌지만 아무 동작도 하지 않음
  • 여기서부터 좌절감이 들어오기 시작함. 팀원-1 이 퇴근 예정이었지만 갑자기 많은 문제들이 발생하면서 퇴근 지연

세번째 사건

2017/01/31 23:00경 팀원-1 은 pg_basebackup 이 작동하지 않는 이유로, PostgreSQL 의 데이터 디렉토리가 비었음에도 불구하고 존재한다고 생각하여, 삭제를 결정. 삭제 몇 초 후  db2.cluster.gitlab.com 가 아닌, db1.cluster.gitlab.com에서 삭제한 것을 인지함.
2017/01/31 23:27 팀원-1 이 삭제를 취소했지만,  300 GB 데이터 중 약 4.5 GB 만 유지 됨.

GitLab.com 을 중지할 수 밖에 없었으며,  Twitter에 공지함:

We are performing emergency database maintenance, http://GitLab.com  will be taken offline

Photo published for Code, test, and deploy together with GitLab open source git repo management software

발생했던 문제

  • LVM snapshots 이 매 24시간마다 찍힘. 팀원-1 이 사건 발생 6시간 전 DB 로드 밸런싱을 위해 수동으로  snapshot을 저장하였음.
  • Regular backups 또한 매 24시간마다 찍히지만, 팀원-1 은 그것이 어디에 저장되어 있는지 몰랐으며, 팀원-2 에 의하면 Regular backups은 제대로 작동하지 않았고, 몇 바이트만 저장됨.
  • 팀원-3: 제가 생각하기에 pg_dump 이 실행 되지 않은 이유로, PostgreSQL가 9.6 binaries버전이 아닌, 9.2 binaries 에서 실행되고 있었기 때문입니다. 이것은 data/PG_VERSION이 9.6으로 설정되었을 때, omnibus가 Pg 9.6만을 지원하기 때문입니다. 하지만 9.6파일이 존재하지 않았기에 9.2버전 파일에 접근하여 실행이 되지 않았습니다. 그 결과 SQL dumps는 만들어 지지 않았고, Fog gem은 과거 백업들을 삭제했을 것입니다.
  • Azure에 있는 NFS server를 대상으로 Disk snapshots가 실행되고  있었지만, DB servers에는 snapshots가 실행되고 있지 않음.
  • 동기화 프로세스에서 데이터 동기화 후 staging단계 도달 시, webhooks를 제거. 24간 전 Regular Backup에서 Pull을 하지 않으면 없어짐
  • Replication 프로세스가 너무 취약함, 에러에 민감, 랜덤한 shell scripts에 의지하고 있고 문서화가 안되어 있음
  • backups to S3 가 작동하지 않고 있음. (Bucket이 비어있음)
  • 즉, 5 backup/replication 기술이 deploy되었지만 그 중 하나도 제대로 작동하지 않고 있음. 결국 6 시간 전 백업을 사용해서 복구.
  • pg_basebackup 은 master가 replication프로세스를 시작하기 기다릴것, 다른 Prod 엔지니어에 의하면 10분 정도 소요됨.어떤이들은 이것을 멈춤 상태로 인지할 수 있음. 프로세스 진행 시 “strace” 상태로 무엇이 진행되는지 알 수 없음.

복구 작업

현재 우리는 staging DB에 있는 DB 백업을 통해 복구 중입니다.

We accidentally deleted production data and might have to restore from backup. Google Doc with live notes https://docs.google.com/document/d/1GCK53YDcBWQveod9kfzW-VCxIABGiryG7_z_6jHdVik/pub 

  • 2017/02/01 00:36 –  db1.staging.gitlab.com 데이터 백업
  • 2017/02/01 00:55 – Mount db1.staging.gitlab.com on db1.cluster.gitlab.com
  • StagingDB에 있는 /var/opt/gitlab/postgresql/data/ 를 productionDB /var/opt/gitlab/postgresql/data/ 에 복사
  • 2017/02/01 01:05 – nfs-share01 를 임시저장소로 사용 (/var/opt/gitlab/db-meltdown)
  • 2017/02/01 01:18 – 남은 production data 복사 ( pg_xlog 를 압축한 20170131-db-meltodwn-backup.tar.gz 포함)

아래 그래프는 데이터 삭제 시간 및 이후 데이터 복사 시간을 보여줍니다.

2/1/17 GitLab.com Database Incident(한글번역)”에 대한 2개의 생각

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

Google+ photo

Google+의 계정을 사용하여 댓글을 남깁니다. 로그아웃 / 변경 )

%s에 연결하는 중