사례7건

7건 중 6~7번째

1. IL-0212 캐시 적중률이 떨어지며 채널 멤버십 Vitess 키스페이스가 과부하에 빠져 많은 사용자가 Slack 에 접속하지 못했다

   Slack2022

   증상

   2022년 2월 22일 태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓과 내부 사용자의 문제 보고가 들어왔고, 여러 엔지니어링 팀에 호출과 알림이 거의 동시에 왔다. 많은 사용자가 Slack 에 접속하지 못했다. 클라이언트는 부팅 과정에서 채널 목록, 설정, 최근 대화를 서버에서 가져오는데, 부팅하지 못하면 Slack 은 오류 페이지를 보였다.

   데이터베이스 과부하오류율 상승지연 시간 증가

   촉발

   2월 22일 Consul 에이전트 업그레이드를 비율 단위로 롤아웃하는 단계에서 전체 에이전트의 25% 를 차례로 재시작했다. memcached 노드의 에이전트가 재시작될 때마다 캐시 제어 계층인 Mcrib 가 그 노드를 비어 있는 예비 노드로 바꾸거나 다시 들어온 노드를 비웠고, 하루 중 트래픽이 가장 많은 시간에 캐시 적중률이 떨어졌다.

   원인

   용량 한계

   구성 요소

   데이터베이스인메모리 캐시서비스 디스커버리

   기여 요인

   데워진 캐시에 기댄 구조비효율적인 쿼리자동화 증폭재시도 폭주피크 시간 변경

   감지

   태평양 시간 오전 6시 직후 Slack 에 접속하지 못한다는 사용자 티켓, 내부 사용자의 문제 제기, 여러 엔지니어링 팀의 호출과 알림이 거의 동시에 들어왔다.

   조치

   • 대응 초기에 장애를 촉발한 Consul 에이전트 재시작 작업을 멈췄다. 그때는 재시작이 장애와 관련 있다고 의심하지 않았다.
   • 느린 부팅 요청이 데이터베이스 자원을 바닥내 이미 부팅한 사용자의 요청까지 막자 클라이언트 부팅 요청에 엄격한 속도 제한을 걸었다.
   • 처음 제한을 너무 많이 풀어 데이터베이스 부하와 실패한 요청이 다시 늘자 부팅 속도 제한을 다시 낮췄고, 그 뒤로는 작은 폭으로 올렸다.
   • 캐시 미스마다 모든 샤드를 읽던 쿼리를 memcached 에 없는 데이터만 Vitess 에서 읽도록 바꿨다.
   • 그룹 DM 데이터는 바뀌지 않아 조금 오래된 값을 써도 되므로 쿼리가 Vitess 프라이머리뿐 아니라 복제본에서도 읽도록 바꿨다.
   • 캐시가 다시 차고 적중률이 오르자 데이터베이스 처리량을 최대로 유지하면서 클라이언트 부팅 속도 제한을 천천히 정상 트래픽 수준까지 올렸다.

   후속 조치

   • Consul 롤아웃 절차를 바꿔 업그레이드 중에 같은 장애가 다시 촉발되지 않게 했다.
   • 캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 나지 않도록 Mcrib 제어 루프의 해당 부분을 바꿔 배포한다.
   • 문제가 된 scatter query 를 채널 기준으로 샤딩한 테이블에서 읽도록 바꿨다.
   • 캐시 계층 뒤에 있는 다른 데이터베이스 쿼리를 분석해 비슷한 위험이 있는 대량 scatter query 가 있는지 찾는다.
   • 장기 프로젝트로 캐시 계층의 복원력을 높이는 다른 방법을 찾는다.

   교훈

   Slack 은 성능 병목, 연쇄 장애, 데워진 캐시에 기대는 구조, 촉발 요인이 된 변경이 장애에서 자주 보이는 패턴이라고 봤다. 이번 장애는 여러 시스템의 경계를 넘는 상호작용이었고 그중 일부 시스템은 최근에 바뀌었다. 큰 소프트웨어 시스템에서 복잡성과 변경은 피할 수 없고, 그만큼 시스템이 예측하지 못한 방식으로 움직일 위험도 커진다. Mcrib 는 틀리거나 비효율적이어서가 아니라 오히려 빠르고 효율적이어서 장애를 키웠다. 빠진 memcached 인스턴스를 더 빨리 찾아 설정을 고치면서 캐시 계층의 교체가 늘었고, 더 나은 구성 요소가 전체 시스템을 덜 안전하게 만들었다. 캐시 노드에 짧은 네트워크 단절이 생겨도 같은 연쇄 장애가 날 수 있다는 위험도 드러났다. 연쇄 장애에 빠진 시스템은 부하를 크게 줄이거나 용량을 늘리는 외부 개입 없이는 안정 상태로 돌아오지 않는다.

   사례 보기
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 은 자동 페일오버가 서비스 가용성을 지키는 좋은 방법인 경우가 많지만, 주 운영 데이터베이스는 그런 경우가 아니라고 결론 내렸다.

   사례 보기

원인별3