사례4건

4건 중 1~4번째

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-0274 GitHub 코드 검색의 elasticsearch 클러스터에서 일부 노드 CPU 가 100% 에 가깝게 차고 마스터가 계속 바뀌면서 검색과 색인이 타임아웃되고 샤드 데이터가 사라졌다

   GitHub2013

   증상

   2013년 1월 24일 목요일 예외 추적·모니터링 시스템이 예외가 크게 치솟은 것을 잡았다. 예외 대부분은 코드 검색 질의의 타임아웃과, 새 push 의 데이터로 코드 검색 색인을 갱신하는 백그라운드 작업의 타임아웃이었다.

   간헐적 타임아웃노드 CPU 고부하스플릿 브레인데이터 유실

   촉발

   2013년 1월 17일 코드 검색 클러스터를 elasticsearch 0.19.9 에서 0.20.2 로 업그레이드했다. 그 뒤 코드 검색을 공개하자 클러스터에 높은 부하가 걸렸고 메모리 할당이 계속 일어났다.

   원인

   소프트웨어 결함

   구성 요소

   Elasticsearch 와 OpenSearch언어 런타임 설정

   기여 요인

   기본 설정 방치미뤄 둔 업그레이드시험하지 않은 변경초기 신호 무시수동 조치 악화

   감지

   예외 추적·모니터링 시스템이 예외가 크게 치솟은 것을 잡았다.

   조치

   • 클러스터를 완전히 멈추고, 샤드 할당과 재균형을 끄는 "maintenance mode" 로 다시 올렸다.
   • elasticsearch 를 개발하고 지원하는 회사의 엔지니어 두 명에게 도움을 청했다.
   • 두 엔지니어의 권고대로 Java 와 elasticsearch 를 곧바로 업그레이드하고 설정을 바꿨다. Puppetmaster 에 이 변경 전용 토픽 브랜치와 환경을 만들고 각 노드에서 Puppet 을 돌렸다.

   후속 조치

   • 코드 검색 클러스터의 스테이징 환경을 만들어 인프라 변경을 더 잘 시험한다.
   • elasticsearch 팀이 앞으로도 코드 검색 클러스터 설정을 다시 점검해, 쓰임새에 맞게 유지되도록 한다.

   교훈

   GitHub 는 elasticsearch 0.20.2 를 코드 검색 클러스터에 내보내기 전에 자기 인프라에서 충분히 시험하지 않았고 다른 클러스터에서도 시험하지 않았다. 코드 검색 클러스터에 제대로 된 스테이징 환경이 없던 것이 한 요인이었다. elasticsearch 팀은 큰 클러스터에 이렇게 권했다. ES_HEAP_SIZE 환경 변수로 JVM 의 최소·최대 메모리를 같게 하고 시스템 RAM 의 50% 로 둔다. recover_after_time 을 30분으로 두지 말고 복구가 바로 시작되게 한다. minimum_master_nodes 를 설정해 노드가 오래 멈출 때 노드 일부가 따로 클러스터를 이루지 않게 한다.

   사례 보기
3. IL-0263 새 애그리게이션 스위치로 옮기는 작업 뒤 데이터센터 스위치 사이 링크가 포화되어 GitHub 가 하루 종일 느렸고 18분 동안 완전히 멈췄다

   GitHub2012

   증상

   2012년 11월 30일 금요일, GitHub 는 18분 동안 완전히 접속이 안 됐고, 하루 종일 응답이 이따금 느려지고 오류가 간헐적으로 났다. 파일 서버 한 쌍이 하루 대부분 내려가 있어 일부 저장소가 영향을 받았다.

   지연 시간 증가오류율 상승서비스 중단

   촉발

   새 애그리게이션 스위치를 들이려고 액세스 스위치를 떼어 설정을 바꾸고 다시 연결하는 작업을 했다. 11월 30일 아침 A 스위치를 옮기던 중 마지막 스위치에서 브리지 루프가 생겼다.

   원인

   소프트웨어 결함

   구성 요소

   네트워크 스위치NIC·케이블·스위치 포트 링크

   기여 요인

   장애 중첩미검증 가정수동 조치 악화

   감지

   마지막 A 스위치를 연결할 때 같은 캐비닛의 B 스위치와 연결이 끊겼다. 문제를 고친 뒤에도 성능이 기대만큼 나오지 않아 들여다보다가 액세스 스위치와 애그리게이션 스위치 사이 링크가 모두 포화된 것을 봤다.

   조치

   • 마지막 A 스위치에서 난 첫 문제를 빨리 해결하고, 영향받은 B 스위치를 다시 서비스에 넣어 이전을 마쳤다.
   • 액세스 스위치에서 잘못된 설정을 지웠다. 그 뒤로는 링크를 시험해도 페일오버가 기대대로 작동했고, 애그리게이션 계층이나 액세스 계층의 스위치 하나를 빼도 서버에 영향이 없었다.
   • 몇 시간을 더 찾아도 설정 문제가 나오지 않자 네트워크 공급사에 다시 에스컬레이션했고, 공급사는 이 문제를 가장 높은 심각도 등급으로 올려 바로 함께 조사했다.
   • 태평양 시간 토요일 오전 6시에 네트워크 점검 시간을 잡고 애그리게이션 스위치의 핵심 프로세스 일부를 재시작해 MAC 주소를 다시 학습하게 했다. 이 우회책이 통해서 트래픽과 성능이 정상으로 돌아왔다.

   후속 조치

   • 공급사가 MAC 학습 문제의 근본 원인을 찾았고, 1주일쯤 안에 최종 수정이 나오면 스위치에 소프트웨어 업데이트를 배포한다.
   • 그때까지 애그리게이션 계층과 액세스 계층 사이 용량을 면밀히 지켜보고, 문제가 다시 나면 쓸 우회 절차를 둔다.
   • 라우터부터 액세스 계층 스위치까지 네트워크 스택을 똑같이 한 벌 더 갖춰 스테이징 환경으로 쓰고, 이런 변경을 미리 더 충분히 시험한다.
   • 비슷한 문제가 생기면 더 빨리 알림을 받도록 네트워크에 자동 모니터링을 더한다.
   • 앞으로 몇 달 동안 정기적인 장애 대응 훈련을 늘리고, 한 가지 가설에 매달리지 않도록 하는 시나리오를 만든다.
   • 앞으로는 네트워크에 문제 조짐이 처음 보일 때 바로 공급사 지원팀에 연락한다.

   교훈

   GitHub 는 고객에게 영향이 없도록 설계한 점검 작업이 결국 고객에게 영향을 줬다고 인정했다. 장애 대응 중에 브리지 루프라는 생각에 오래 매달려 다른 원인을 보지 못했고, 그래서 한 가지 가설에 갇히는 것을 더 경계해야 한다고 했다. GitHub 는 공급사 지원팀과 일한 경험이 좋았다며, 앞으로는 문제 조짐이 처음 보일 때 바로 지원팀에 연락하겠다고 했다.

   사례 보기
4. 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