사례14건

14건 중 9~13번째

1. IL-0218 복제를 다시 맞추다 PostgreSQL 프라이머리의 데이터 디렉터리가 지워지고 백업이 작동하지 않아 GitLab.com 이 약 18시간 멈추고 데이터를 잃었다

   GitLab2017

   증상

   2017년 1월 31일 19:00 UTC 무렵 GitLab.com 의 데이터베이스 부하가 올랐고, 많은 사용자가 이슈와 머지 리퀘스트에 댓글을 달지 못했다. 스팸으로 의심되는 부하였고, 잡는 데 몇 시간이 걸렸다.

   데이터베이스 과부하복제 지연데이터 유실서비스 중단

   촉발

   1월 31일 23:00 UTC 무렵 데이터베이스 부하로 세컨더리의 복제가 멈췄고, 세컨더리를 다시 맞추던 엔지니어가 세컨더리가 아니라 프라이머리에서 PostgreSQL 데이터 디렉터리를 지웠다.

   원인

   운영 실수

   구성 요소

   데이터베이스데이터베이스 복제데이터베이스 백업과 스냅숏클라우드 블록 스토리지

   기여 요인

   미검증 백업단일 장애점런북 부재온콜 호출 미전달미검증 가정기본 설정 방치

   감지

   프라이머리에서 데이터 디렉터리를 지운 엔지니어가 스스로 실수를 알아채고 1~2초 만에 삭제를 멈췄다.

   조치

   • pg_basebackup 이 복제 연결이 모자라다고 알리자 max_wal_senders 를 기본값 3 에서 32 로 잠시 올렸고, PostgreSQL 이 재시작을 거부하자 max_connections 를 8000 에서 2000 으로 낮췄다.
   • 엔지니어가 프라이머리에서 데이터를 지우고 있다는 것을 알아채고 1~2초 만에 삭제 작업을 멈췄지만, 약 300 GB 가 이미 지워졌다.
   • 데이터 손실을 가장 줄일 수 있는 유일한 방법으로 장애 6시간 전에 만든 LVM 스냅샷을 쓰기로 하고, 스테이징의 PostgreSQL 데이터 디렉터리를 약 18시간 동안 운영으로 복사해 복원했다.
   • 웹훅 삭제를 거치지 않은 별도 스테이징 데이터베이스를 LVM 스냅샷으로 띄워 웹훅 테이블의 SQL 덤프를 만들고, 복원한 GitLab.com 데이터베이스에 가져왔다.
   • 장애 전에 쓰였을 수 있는 ID 를 다시 쓰지 않도록 모든 데이터베이스 시퀀스를 100,000 씩 올렸다.
   • GitLab.com 을 차례로 다시 열었다.
   • 17:20 UTC 이후에 만든 프로젝트는 NFS 클러스터에 남은 Git 저장소로 가장 기본적인 형태만 복원했고, 이슈와 머지 리퀘스트 같은 데이터는 되살리지 못했다.

   후속 조치

   • 모든 호스트의 셸 프롬프트인 PS1 을 고쳐 호스트와 환경을 더 분명히 구분한다.
   • 백업을 Prometheus 로 모니터링한다.
   • PostgreSQL 의 max_connections 를 알맞은 값으로 둔다.
   • PostgreSQL 의 시점 복구와 연속 아카이빙을 검토한다.
   • 운영 데이터베이스의 LVM 스냅샷을 매시간 뜬다.
   • 운영 데이터베이스에 Azure 디스크 스냅샷을 켠다.
   • 스테이징을 ARM 환경으로 옮긴다.
   • 운영 복제본을 되살린다.
   • PostgreSQL 백업 복원을 자동으로 시험한다.
   • PostgreSQL 복제 문서와 런북을 고친다.
   • PostgreSQL 백업에 pgbarman 을 쓸지 검토한다.
   • 데이터베이스 백업과 실시간 복제에 WAL-E 를 쓸지 검토한다.
   • 스트리밍 방식의 데이터베이스 복원을 만든다.
   • 데이터 내구성을 책임질 담당자를 정한다.
   • 세컨더리를 여러 대 두고 부하를 나누도록 pgpool-II 3.6.1 을 묶고 PostgreSQL 연결 풀링과 부하 분산을 구성한다.
   • 개발자가 데이터베이스 마이그레이션을 시험할 수 있도록 스테이징에서 Rails 마이그레이션을 실행하고 되돌리는 도구를 만든다.
   • 데이터베이스뿐 아니라 GitLab.com 인프라 전체의 복구 절차를 만들고 그 절차의 담당자를 정한다.
   • 공개 백업 모니터링 대시보드를 만들었고, 지금은 pg_dump 백업 데이터만 있지만 데이터를 더 넣는다.
   • 어뷰징 신고와 대응 시스템을 고쳐 스팸 신고로 사용자를 지울 때 데이터를 바로 영구 삭제하지 않게 한다.
   • 앞으로 공개하는 장애 문서에서는 엔지니어의 이름을 가린다.

   교훈

   GitLab 은 장애를 GitLab.com 이 약 18시간 멈춘 문제와 복원이 18시간 넘게 걸린 문제로 나눠 5 Whys 로 분석했다. 세컨더리를 다시 만드는 작업은 자동화되지도 제대로 문서화되지도 않아 손으로 해야 했다. 표준 백업은 PostgreSQL 버전이 맞지 않아 조용히 실패했고, 실패 알림 메일은 DMARC 서명이 없어 거부됐다. 다른 백업 절차를 믿고 Azure 디스크 스냅샷을 켜지 않았다. 백업 절차를 맡은 사람이 없어 아무도 정기적으로 시험하지 않았다. GitLab 은 운영 엔지니어가 특정 명령을 못 쓰게 막는 것보다 재해 복구를 고치고 지금 어느 호스트를 쓰는지 더 분명히 보이게 하는 데 집중하기로 했다. rm 을 더 안전한 별칭으로 바꾸면 실수로 지우는 것은 막지만 디스크 손상처럼 데이터를 잃는 다른 경우는 막지 못한다. 이상적인 환경은 실수해도 영향이 거의 없이 빠르게 복구할 수 있는 곳이고, 그러려면 복구 절차를 정기적으로 해 보고 변경을 쉽게 시험하고 되돌릴 수 있어야 한다.

   사례 보기
2. IL-0573 개발자의 실수로 MariaDB 빌링 데이터베이스의 주요 테이블 9개가 DROP되어 배달의민족 결제가 잠시 멈췄다

   Woowa Brothers2016

   증상

   2016년 12월 27일 오후 3시, 결제 시스템 모듈을 개발하던 개발자의 실수로 빌링 데이터베이스의 주요 테이블 9개가 DROP됐다. 모니터링 시스템에 빨간불이 들어오고 장애 알림이 쏟아졌으며, 배달의민족 결제가 잠시 중단됐다.

   데이터 유실서비스 중단

   촉발

   결제 시스템 모듈을 개발하던 개발자가 실수로 빌링 데이터베이스의 주요 테이블 9개를 DROP했다.

   원인

   운영 실수

   구성 요소

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

   기여 요인

   –

   감지

   모니터링 시스템에 빨간불이 들어오고 장애 알림이 쏟아져 알았다.

   조치

   • 애플리케이션이 임시 데이터베이스를 보도록 고쳐 결제 중단 시간을 줄였다.
   • 매일 새벽 6시 mysqldump로 만든 Full Backup 파일을 풀어 DB에 실행해, 빌링 시스템을 연 때부터 새벽 6시까지의 데이터를 복구했다.
   • mysqlbinlog로 binary log에서 2016-12-27 06:00:00 부터 15:00:00 까지의 이벤트를 restore.log에 뽑고, 9개 테이블만 남기도록 고친 뒤 mysql에 실행해 나머지 데이터를 복구했다.

   후속 조치

   • 빌링 데이터베이스는 장애 때 복구 과정을 단순하게 하려고 XtraBackup으로 증분 백업 없이 전체 백업을 한다.

   교훈

   장애를 관리할 지점은 많다. 데이터베이스의 서비스용 계정과 관리용 계정을 나누는 것, 쿼리를 보내기 전에 한 번 더 확인하는 것, rm -rf를 막는 것이 그 예다. 전체 백업과 binary log가 없었다면 복구할 수 없었으므로, 장애 때 전체를 복구할 지점이 있는지 점검해야 한다. 데이터가 수십에서 수백 GB에 이르면 mysqldump로는 백업과 복구에 너무 오래 걸린다.

   사례 보기
3. IL-0434 ElasticSearch 0.19 클러스터 전체 재시작 뒤 샤드 12개가 unassigned 로 남아 데이터 일부를 읽을 수 없었다

   CyberAgent2016

   증상

   OpenStack 호스트 서버가 다운되어 ElasticSearch 노드 하나가 내려간 뒤, API 서버 쪽 ElasticSearch 헬스 체크가 false 를 반환했다. Head 플러그인으로 본 클러스터 상태는 그린이었다.

   지연 시간 증가데이터 유실

   촉발

   OpenStack 호스트 서버가 다운되어 30대짜리 ElasticSearch 클러스터의 노드 하나가 내려갔다.

   원인

   운영 실수

   구성 요소

   Elasticsearch 와 OpenSearch

   기여 요인

   미검증 가정자동화 증폭

   감지

   API 서버가 ElasticSearch 에 하는 헬스 체크가 false 를 반환했다. 클러스터 상태는 Head 플러그인에서 그린으로 보였다.

   조치

   • 호스트가 언제 다시 다운될지 몰라, 복구된 ElasticSearch 노드 서버를 다른 호스트 서버로 마이그레이션했다.
   • 마이그레이션 뒤 ElasticSearch 프로세스를 띄워 노드를 클러스터에 다시 넣었다.
   • 헬스 체크를 되살리려고 1번 노드부터 로그를 보며 차례로 전체 재시작했지만, 스무 번째 노드까지 재시작했을 즈음 API 서버 지연이 생겨 멈췄다.
   • 다시 1번 노드부터 차례로 전체 재시작해 API 서버 지연과 헬스 체크를 되살렸다.
   • _cluster/reroute 의 allocate 명령으로 unassigned 샤드를 옮기려 했지만 오류가 나서 실패했다.
   • A 인덱스의 53번 샤드는 22번 노드에만 파일이 남아 있었다. 그래서 프로세스를 멈추고 그 파일을 디렉터리만 남은 3번 노드와 10번 노드로 복사한 뒤, 22번 노드의 상태 파일만 "primary" 를 true 로 바꿨다.
   • B 인덱스의 51번 샤드는 lucene-core 검사로 27번 노드 쪽이 망가진 것을 확인했다. 27번 노드의 파일을 지운 뒤 28번 노드의 파일을 27번 노드와 다른 노드로 복사하고, 28번 노드만 "primary" 를 true 로 바꿨다.
   • C 인덱스의 2번 샤드는 27번 노드에만, 4번 샤드는 25번 노드에만 파일이 남아 있었다. 그래서 각 파일을 다른 두 노드로 복사하고, 복사한 쪽의 상태 파일은 "primary" 를 false 로 바꿨다.

   후속 조치

   • 오래된 ElasticSearch 버전을 그만 쓰고 버전을 올린다.

   교훈

   재시작할 때는 자동 재배치를 끄고 작업해야 했다. 노드 하나를 재시작한 뒤에는 로그만 볼 것이 아니라 재배치가 완전히 끝나는 것을 보고 나서 다음 노드를 재시작해야 했다.

   사례 보기
4. IL-0319 mysql2 를 다시 적재하려고 데이터베이스를 지우는 동안 mysql1 의 데이터베이스도 함께 지워졌다

   Oregon State University Open Source Lab2015

   증상

   복제 오류를 고치려고 mysql2 의 데이터베이스를 하나씩 지우던 중, 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지고 있는 것을 알아챘다. 지워진 데이터베이스들은 복원될 때까지 쓸 수 없었다.

   데이터 유실서비스 중단복제 지연

   촉발

   7월 30일 오후 4시 PDT 에 팀은 복제 오류를 고치려고 mysql2 를 다시 적재하기로 했다. 슬레이브 복제를 멈춘 뒤 mysql2 의 데이터베이스를 하나 지울 때마다 잠깐씩 쉬면서 지웠다.

   원인

   운영 실수

   구성 요소

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

   기여 요인

   미검증 가정미검증 백업

   감지

   데이터베이스를 지우는 스크립트가 하나를 지울 때마다 짧게 쉬었기 때문에, 시작하고 몇 분 뒤 mysql1 에서도 데이터베이스가 지워지고 있는 것을 알아챘다.

   조치

   • mysql1 에서도 데이터베이스가 지워지는 것을 보고 스크립트를 멈췄다.
   • 곧바로 지워진 데이터베이스의 복원을 시작했다.
   • 인덱스와 외래 키 문제로 복원이 실패한 데이터베이스는 약 200GB 백업 파일에서 따로 꺼내 복원했고, 아직 복원하지 못한 나머지 데이터베이스도 다시 꺼내 복원했다.
   • 백업은 mysql1 보다 뒤처진 mysql2 에서 뜬 것이어서, 17일부터 30일까지의 바이너리 로그로 대부분의 데이터를 되살렸다. 15일과 17일 사이의 데이터 일부는 되살리지 못했다.

   후속 조치

   • 처음 문제였던 복제 오류를 줄이려고 행 기반 복제를 포함해 더 나은 복제 방식을 검토한다.
   • 바이너리 로그를 별도 서버에 백업으로 보관한다.
   • 전체 복원이 훨씬 빨라지도록 Percona XtraBackup 으로 백업한다.
   • 논리 백업 속도를 높이려고 mysql-zrm 대신 mydumper 를 쓴다.
   • 복잡한 시스템의 문서와 교육을 손본다.
   • 백업 절차의 하나로 예비 서버에서 전체 복원을 정기적으로 시험한다.
   • 복원에 걸리는 예상 시간을 더 정확하게 잡는다.
   • 호스팅하는 데이터베이스를 정기적으로 점검한다. 시험용 데이터베이스와 100GB 넘게 불어난 데이터베이스 여러 개가 이번 복원을 크게 늦췄다.
   • 더 크고 성능이 좋은 MySQL 클러스터로 옮긴다. 이 이전은 장애 전부터 계획돼 있었다.
   • 장애와 유지보수, 자원 사용량과 경고 신호를 대시보드로 커뮤니티에 더 잘 알리는 정책과 수단을 만든다.
   • 핵심 서비스의 용량 한계를 정하고 감시한다.
   • 핵심 서비스에 이중화와 복원 절차를 갖추고 직원 훈련을 한다.
   • 핵심 서비스를 더 많이 Chef 로 옮긴다.
   • 문서, 정책, 성능 지표를 주기적으로 검토한다.
   • 커뮤니티의 전문 지식으로 연구소의 역량을 보완할 더 나은 방법을 찾는다.
   • 가장 낡은 인프라를 교체하고 가장 심한 기술 부채를 해소할 기금을 모은다.

   교훈

   Open Source Lab 은 이번 장애에서 MySQL 클러스터를 운영하는 방식과 연구소 전체가 자원을 계획하고 관리하는 방식 모두에서 교훈을 얻었다고 적었다. 디스크 공간을 아끼려고 백업을 강하게 압축한 선택은 전체 복원이 드물었던 그동안에는 괜찮았지만 이번 복원을 크게 늦췄다. 더 많은 프로젝트를 받으려고 자원을 빠듯하게 나눠 써 왔고, 그 대가로 백업을 압축하고 바라던 것보다 이중화를 덜 갖췄다. 장애가 길었던 것과 진행 상황을 알리지 못한 것은 받아들일 수 없는 일이었다고 밝혔다.

   사례 보기
5. IL-0538 사쿠라 클라우드 스토리지의 일괄 삭제 작업이 고객이 쓰던 디스크 53개를 지웠고 되살리지 못했다

   Sakura Internet2012

   증상

   2012년 1월 5일 긴급 점검에서 스토리지의 불필요한 파일 시스템을 한꺼번에 지운 뒤, 고객이 사용 중이던 사쿠라 클라우드 디스크 53개가 함께 지워졌다. 이 디스크들은 백업에서도 되살릴 수 없었다.

   데이터 유실

   촉발

   스토리지 부하가 너무 높아 통상 절차로는 삭제가 실행되지 않자, 이 점검만을 위해 배치 명령을 새로 만들어 불필요한 파일 시스템을 한꺼번에 지웠다. 리뷰와 테스트를 충분히 거치지 않은 이 명령이 예비로 미리 만들어 둔 파일 시스템을 생성에 실패한 디스크로 잘못 분류했다.

   원인

   운영 실수

   구성 요소

   클라우드 블록 스토리지데이터베이스 백업과 스냅숏

   기여 요인

   리뷰 누락미검증 백업

   후속 조치

   • 불필요한 파일 시스템을 지우는 절차를 단순하게 바꾼다.
   • 리뷰와 테스트를 충분히 거치지 않은 스크립트는 실행하지 않는다는 원칙을 철저히 지킨다.

   사례 보기

원인별1