사례2건

2건 중 1~2번째

1. IL-0385 큰 MySQL 테이블의 스키마 마이그레이션 마지막 단계에서 읽기 복제본 다수가 semaphore deadlock 에 걸려 GitHub 핵심 서비스가 2시간 50분 저하됐다

   GitHub2021

   증상

   2021년 11월 27일 20:40 UTC 부터 GitHub Actions, API 요청, Codespaces, Git 작업, Issues, GitHub Packages, GitHub Pages, Pull Requests, Webhooks 의 가용성이 떨어졌다. 큰 MySQL 테이블의 스키마 마이그레이션이 마지막 rename 단계를 실행하던 때였다.

   잠금 경합과 교착데이터베이스 과부하

   촉발

   큰 MySQL 테이블의 스키마 마이그레이션이 마지막 단계로 갱신한 테이블을 제자리로 옮기는 rename 을 실행했다. 이때 읽기 복제본 상당수가 semaphore deadlock 에 걸렸다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스스키마 마이그레이션

   기여 요인

   여유 용량 부재단계적 배포 부재

   조치

   • 정상 상태인 내부용 복제본을 모두 운영 경로로 올려 용량을 늘렸다. 이것만으로는 완전히 복구되지 않았다.
   • crash-recovery 를 되풀이하는 복제본에서 운영 트래픽을 미리 빼고, 그 복제본이 테이블 rename 을 끝까지 처리할 때까지 기다렸다.
   • 회복한 복제본을 운영에 다시 넣어 정상 운영에 필요한 용량을 되찾았다.

   후속 조치

   • 클러스터를 기능별로 나누는 작업을 계속 우선해서, 마이그레이션을 샤드 하나에서 카나리 모드로 먼저 돌릴 수 있게 한다.
   • 클러스터마다 여유 용량을 더 크게 잡도록 내부 절차를 고친다.
   • 이 문제를 막는 방법을 더 알게 될 때까지 스키마 마이그레이션을 멈춘다.
   • 이번 장애가 일어난 구체적인 조건을 계속 조사한다.
   • 마이그레이션 도구를 시험하면서 이런 상황에서 도구를 고칠 점을 가려낸다.

   사례 보기
2. IL-0303 GitHub 의 새 3노드 MySQL 클러스터에서 자동 페일오버가 잘못 일어나고 클러스터 상태가 갈라져 GitHub.com 이 두 번 멈췄다

   GitHub2012

   증상

   2012년 9월 10일 월요일, 스키마 마이그레이션이 데이터베이스에 높은 부하를 걸자 Percona Replication Manager 의 헬스 체크가 마스터에서 실패했다. Percona Replication Manager 는 'active' 역할을 다른 노드로 옮겼고, 새 노드가 느려지면서 GitHub.com 이 멈췄다.

   장애 조치 실패데이터베이스 과부하지연 시간 증가복제 지연스플릿 브레인서비스 중단

   촉발

   무중단 MySQL 스키마 마이그레이션이 이전의 같은 종류 마이그레이션보다 높은 부하를 데이터베이스에 걸었고, 그 부하로 Percona Replication Manager 의 헬스 체크가 마스터에서 실패했다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자데이터베이스 복제

   기여 요인

   자동화 증폭데워진 캐시에 기댄 구조수동 조치 악화장애 중첩

   감지

   9월 11일 아침 한 개발자가 'standby' 역할을 맡은 노드에서 잘못된 쿼리 결과가 나온다고 운영팀에 알렸다. 그 뒤 운영팀은 혼자 마스터로 뽑힌 'c' 노드가 앞서 데이터가 뒤처졌다고 판단한 노드라는 것을 알아챘다.

   조치

   • 9월 10일 Pacemaker 의 maintenance-mode 를 켜서 모든 헬스 체크와 자동 페일오버 동작을 멈췄다.
   • 9월 11일 8:26 AM 에 데이터가 뒤처진 'c' 노드의 전원을 꺼서 갈라진 클러스터 상태를 끝내고 데이터가 더 어긋나지 않게 했다.
   • 클러스터 상태를 깨끗하게 되살리려고 'a' 와 'b' 두 노드에서 Pacemaker 와 Heartbeat 프로세스를 모두 멈춘 뒤 'a' 노드에서 다시 띄웠다.
   • 'a' 노드에서 MySQL 을 띄워 'active' 역할을 맡게 했다.
   • 다른 사용자의 대시보드에 새어 나간 이벤트를 모두 지우고, 그 시간에 경로가 잘못 잡힌 저장소를 모두 점검했다.
   • 협업자가 아닌 사람에게 열려 있던 비공개 저장소 16개의 소유자에게 모두 직접 연락했다.

   후속 조치

   • Pacemaker 설정을 바꿔 'active' 데이터베이스 역할의 페일오버는 운영팀 사람이 시작할 때만 일어나게 한다.
   • 비상시나 정기 유지보수 때 페일오버를 해도 성능이 떨어지지 않도록, 복제본 데이터베이스의 InnoDB 버퍼 풀을 미리 데우는 여러 방법을 조사하고 시험한다.
   • 화요일에 segfault 를 일으킨 코드 경로를 중심으로 Pacemaker 와 Heartbeat 스택 전체를 점검한다.
   • 만일에 대비해 segfault 가 난 서버에서 강도 높은 하드웨어 시험을 한다.

   교훈

   GitHub 은 이번 장애에 세 가지가 겹쳤다고 밝혔다. 일어나지 말았어야 할 'active' 역할 페일오버가 여러 번 일어났고, 클러스터 상태가 갈라져 클러스터 관리 소프트웨어가 잘못된 동작을 했으며, 그 페일오버들이 필요 이상으로 성능과 가용성을 해쳤다. 두 장애는 모두 자동 페일오버에서 시작했는데, 그 페일오버를 해야 하느냐고 운영팀 누구에게 물었어도 하지 말아야 한다고 답했을 것이다. GitHub 은 자동 페일오버가 서비스 가용성을 지키는 좋은 방법인 경우가 많지만, 주 운영 데이터베이스는 그런 경우가 아니라고 결론 내렸다.

   사례 보기

원인별1