사례18건

18건 중 11~15번째

1. IL-0443 Aurora MySQL reader 가 이유 없이 재시작한 뒤 writer 의 insert latency 가 7배쯤 오르고 replication lag 가 하루 넘게 이어졌다

   Repro2019

   증상

   Aurora MySQL 의 reader 가 이유를 알 수 없이 재시작했다. 그 직후부터 writer 의 insert latency 가 7배쯤 오르는 등 writer 성능이 크게 떨어진 상태가 오래 이어졌다. 같은 일이 2019년 11월 두 주 사이에 두 번 일어났다.

   지연 시간 증가복제 지연처리량 저하

   촉발

   reader 에서 오래 도는 쿼리 때문에 롤백 세그먼트가 계속 커진 끝에 reader 가 재시작했다. 글쓴이는 그 쿼리가 Redash 에서 reader 로 보낸 것이었다고 기억한다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   모니터링 사각지대

   조치

   • 팀은 writer 성능이 원래대로 돌아올 때까지 지켜보기만 했다.

   후속 조치

   • 롤백 세그먼트 길이를 Datadog 의 mysql.innodb.history_list_length 로 감시하는 모니터를 더했다.
   • reader 가 재시작할 만큼 오래 도는 쿼리를 찾으면 바로 kill 하게 했다.
   • 모니터 알림이 거의 매주 울리게 되자 사내에 알린 뒤 max_execution_time 을 설정해, 일정 시간이 지난 쿼리를 강제로 끝내게 했다.

   교훈

   롤백 세그먼트가 커지지 않도록 트랜잭션을 작게 해야 한다. 롤백 세그먼트는 클러스터 전체가 함께 쓰므로, 한번 커지면 인스턴스를 바꿔도 해제가 끝나기를 기다리는 수밖에 없다. 롤백 세그먼트 길이는 show engine innodb status 의 "History list length" 값으로 볼 수 있다.

   사례 보기
2. IL-0323 s3 주 데이터베이스 마스터 db1075 가 완전히 멈춰 s3 위키 전체가 읽기 전용이 됐다

   Wikimedia Foundation2019

   증상

   s3 의 주 데이터베이스 마스터 db1075 가 응답하지 않아 s3 의 모든 위키가 쓰기를 받지 못하고 읽기 전용이 됐다. 레플리카는 모두 살아 있어 읽기는 정상이었다. Icinga 가 IRC 에 HOST DOWN 을 알렸고 사용자들이 #wikimedia-operations 에 문제를 알렸다.

   쓰기 거부복제 지연지연 시간 증가

   촉발

   db1075 의 RAID 백업 배터리인 BBU 가 고장 나면서 호스트가 완전히 멈췄다.

   원인

   하드웨어 고장

   구성 요소

   데이터베이스데이터베이스 복제

   기여 요인

   온콜 호출 미전달수동 조치 악화

   감지

   db1075 의 HOST DOWN 이 보고되면서 문제가 분명해졌다. 하지만 HOST DOWN 알림은 IRC 로만 가고 호출을 보내지 않았다. 알림은 IRC 와 호출로 보내졌고, 첫 SMS 호출은 18:56 UTC 에 나갔다. 사용자들도 #wikimedia-operations 에 문제를 알렸고, 자원봉사자와 직원은 알림보다 먼저 장애를 알아챘다.

   조치

   • BBU 문제이고 호스트가 응답하지 않는 것을 확인한 뒤 19:02 UTC 에 idrac 으로 호스트를 재부팅했다.
   • MySQL 이 19:03 에 InnoDB 복구를 시작해 19:06 에 마쳤다.
   • 19:07 에 db1075 의 read_only=ON 을 직접 풀었다.
   • 19:16 에 puppet 을 다시 직접 돌려 성공했고, pt-heartbeat 가 시작되면서 장애가 끝났다.

   후속 조치

   • 마스터를 쓸 수 없을 때 레플리카를 옮기는 스크립트를 만들거나 고친다. 이번에는 필요하지 않았지만 앞으로의 장애에서는 필요할 수 있다.
   • MediaWiki 의 heartbeat 방식을 고친다. pt-heartbeat 가 슈퍼유저를 쓰지 않게 하고, 단일 장애점을 없애고, puppet 없이 실제 마스터로 자동 전환되게 한다.
   • 이미 BBU 문제를 겪은 같은 배치의 호스트들을 어떻게 할지 정한다.
   • db1075 에 쓸 새 BBU 를 산다.
   • db1075 를 마스터에서 뺀다.
   • 읽기 전용이거나 마스터를 쓸 수 없는 동안 MediaWiki 가 쏟아내는 스팸을 해결한다.
   • 주 데이터베이스 마스터가 HOST DOWN 일 때 호출이 가게 한다.
   • Netbox 에서 하드웨어 오류를 더 잘 추적한다.

   교훈

   BBU 고장이 호스트 전체를 멈추게 해서는 안 됐지만 HP 호스트에서는 전에도 그런 일이 있었다. puppet 으로 띄우는 pt-heartbeat 와 아직 다 뜨지 않은 MySQL 사이의 경합으로 수동 puppet 실행이 실패했는데 아무도 알아채지 못했다. 그 때문에 모든 것이 올라온 뒤에도 복제 지연이 보고돼 장애가 8분 더 길어졌다. 알림은 잘 동작했고 idrac 으로 재부팅한 것도 통했다. 호스트가 깨끗하게 돌아오지 않았다면 새 레플리카를 마스터로 올리는 장애 조치를 손으로 해야 했다.

   사례 보기
3. IL-0210 43초 네트워크 단절 뒤 MySQL 프라이머리가 미국 서부로 넘어가 GitHub.com 이 24시간 11분 동안 느려지고 오래된 데이터를 보여 줬다

   GitHub2018

   증상

   2018년 10월 21일 22:54 UTC 에 내부 모니터링 시스템이 여러 시스템에서 장애가 났다는 알림을 쏟아내기 시작했다. 23:02 UTC 에 첫 대응 팀은 여러 데이터베이스 클러스터의 토폴로지가 예상하지 못한 상태라는 것을 확인했다.

   스플릿 브레인장애 조치 실패복제 지연지연 시간 증가

   촉발

   10월 21일 22:52 UTC 에 고장 난 100G 광 장비를 교체하는 정기 유지보수 작업 중 미국 동부 네트워크 허브와 동부 주 데이터센터 사이의 연결이 끊겼다. 연결은 43초 만에 돌아왔다.

   원인

   DNS·네트워크 장애

   구성 요소

   데이터베이스데이터베이스 장애 조치 관리자데이터베이스 복제데이터베이스 백업과 스냅숏NIC·케이블·스위치 포트 링크

   기여 요인

   자동화 증폭미검증 가정

   감지

   22:54 UTC 에 내부 모니터링 시스템이 알림을 내기 시작해 여러 엔지니어가 알림을 분류했다. 23:02 UTC 에 첫 대응 팀이 Orchestrator API 를 조회해 복제 토폴로지에 서부 데이터센터 서버만 남은 것을 확인했다.

   조치

   • 23:07 UTC 에 내부 배포 도구를 수동으로 잠가 더는 변경이 들어오지 않게 했다.
   • 푸시 같은 메타데이터를 쓰는 작업을 멈추려고 웹훅 전송과 GitHub Pages 빌드를 일시 중지했다.
   • 10월 22일 06:51 UTC 까지 여러 클러스터를 미국 동부 데이터센터에서 백업으로 복원했고, 복원된 서버는 서부에서 새 데이터를 복제받기 시작했다.
   • 외부 저장소에서 내려받는 처리량 한계를 피하려고 서부 데이터센터에서 직접 복원하는 방법을 찾았다.
   • 11:12 UTC 에 모든 데이터베이스 프라이머리를 다시 미국 동부에 세웠다.
   • 미국 동부 퍼블릭 클라우드에 MySQL 읽기 복제본을 추가로 띄워 읽기 요청을 더 많은 서버로 나눴고, 복제본 전체의 사용률이 내려가 복제가 따라잡았다.
   • 복제본이 맞춰진 뒤 16:24 UTC 에 원래 토폴로지로 페일오버했다.
   • 밀린 웹훅 이벤트와 Pages 빌드를 처리했다. 웹훅 페이로드 약 200,000건이 내부 TTL 을 넘겨 버려진 것을 발견하자 처리를 멈추고 TTL 을 당분간 늘리는 변경을 배포했다.

   후속 조치

   • 각 클러스터에서 서부로 복제되지 않은 쓰기를 담은 MySQL 바이너리 로그를 분석해, 자동으로 맞출 수 있는 쓰기와 사용자에게 연락해야 하는 쓰기를 가린다.
   • GitHub Pages 빌드가 멈춘 상황에서도 공지 글을 낼 수 있게 한다.
   • 장애 중 복구 예상 시간을 더 정확하게 알린다.
   • Orchestrator 설정을 고쳐 데이터베이스 프라이머리가 리전 경계를 넘어 승격되지 않게 한다.
   • 녹색, 노란색, 빨간색 세 단계만 있던 상태 표시를 새 상태 보고 방식으로 옮겨 플랫폼 구성 요소마다 상태를 보여 준다.
   • 여러 데이터센터에서 트래픽을 받는 active/active/active 구성으로 옮기는 일을 앞당겨, 시설 단위 N+1 이중화로 데이터센터 하나가 통째로 망가져도 사용자에게 영향이 없게 한다.
   • 시스템이 기대는 가정을 더 적극적으로 시험한다.
   • 장애 시나리오를 사용자에게 닿기 전에 검증하는 관행을 들이고, 장애 주입과 카오스 엔지니어링 도구에 투자한다.

   교훈

   GitHub 은 Orchestrator 가 설정대로 움직였지만 애플리케이션 계층은 그 토폴로지 변경을 견디지 못했다고 봤다. 리전 안의 리더 선출은 대체로 안전하지만, 갑자기 생긴 대륙 간 지연이 이번 장애를 키운 큰 요인이었다. 자동 페일오버 설정은 애플리케이션이 기대하는 것과 맞춰야 한다. GitHub 은 이만큼 복잡한 서비스 체계에서는 운영 통제를 조이거나 대응을 빠르게 하는 것만으로는 안정성을 지킬 수 없다고 판단했다. 그래서 가정을 더 적극적으로 시험하고, 장애 시나리오를 사용자에게 닿기 전에 검증하기로 했다. 복구 예상 시간은 모든 변수를 고려하지 못해 틀렸다.

   사례 보기
4. IL-0431 AWS 로 옮기는 점검 중 PostgreSQL 이 의도하지 않게 장애 조치되어 한 시간 동안 갱신된 데이터가 사라졌다

   Hatena2017

   증상

   Mackerel 을 온프레미스 데이터 센터에서 AWS 로 옮긴 뒤 애플리케이션 동작을 확인하다가, 특정 시간대의 데이터가 사라진 것을 발견했다. 2017년 8월 7일 14시 30분부터 15시 30분 사이에 PostgreSQL 서버에서 갱신된 데이터가 없었다.

   데이터 유실복제 지연네트워크 도달 불가

   촉발

   새 마스터인 db001 로 접속을 바꾸고 한 시간 뒤 db001 과 네트워크 통신이 끊겼고, 복제가 멈춰 있던 스탠바이 서버 db002 로 의도하지 않은 장애 조치가 일어났다.

   원인

   운영 실수

   구성 요소

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

   기여 요인

   장애 중첩기본 설정 방치스테이징 불일치자동화 증폭

   감지

   마이그레이션 작업 뒤 애플리케이션 동작을 확인하던 중 특정 시간대의 데이터가 사라진 것을 발견했다.

   조치

   • db001 에 남은 테이블 데이터로 손으로 복구할 수 있는지 검토했지만, 이미 많은 데이터가 갱신되어 테이블 사이 정합성을 지키며 db002 에 반영하기 어렵다고 보고 포기했다.
   • 점검 전 베이스 백업, db001 에 남은 WAL, 백업 서버로 보내 둔 WAL 아카이브로 PostgreSQL 의 PITR 복구를 시도했지만, 갈라진 두 타임라인을 이어서 복구할 수 없어 포기했다.
   • 장애 조치 직후 db002 를 마스터로 하고 새 슬레이브 서버 db003 을 만들어 db002 와 db003 으로 이중화했다.
   • 장애가 난 db001 은 조사용으로 점검 상태에 남겨 두었다.
   • db002 에서 db001 과 같은 문제가 나지 않는지 일정 시간 지켜본 뒤 마이그레이션 점검을 마쳤다.

   후속 조치

   • PostgreSQL 레플리카 생성 스크립트가 recovery.conf 에 recovery_target_timeline = 'latest' 를 기본으로 넣도록 바꾼다.
   • Serverspec 같은 서버 구성 관리 테스트 도구에 recovery.conf 안에 recovery_target_timeline = 'latest' 문자열이 있는지 확인하는 항목을 더한다.

   교훈

   Hatena 는 이 문제가 평소 운영에서는 일어나지 않지만, PostgreSQL 버전을 올리거나 다른 리전으로 옮길 때 같은 구성을 다시 쓸 수 있다고 보았다. recovery_target_timeline = 'latest' 는 평소 스탠바이 서버에 두어도 문제가 없으므로, 사람이 빠뜨릴 여지를 없애려고 슬레이브를 만들 때 기본으로 넣도록 운영을 바꿨다. 이 설정을 쓰려는 사람은 자기 구성에서 문제가 없는지 먼저 확인하라고 덧붙였다.

   사례 보기
5. 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 을 더 안전한 별칭으로 바꾸면 실수로 지우는 것은 막지만 디스크 손상처럼 데이터를 잃는 다른 경우는 막지 못한다. 이상적인 환경은 실수해도 영향이 거의 없이 빠르게 복구할 수 있는 곳이고, 그러려면 복구 절차를 정기적으로 해 보고 변경을 쉽게 시험하고 되돌릴 수 있어야 한다.

   사례 보기

원인별9