사례3건

3건 중 1~3번째

1. IL-0544 Wasabi 전 리전의 S3 와 사용자 서비스에 이틀에 걸쳐 세 차례 장애가 났다

   Wasabi2024

   증상

   2024년 8월 6일 10:32 UTC 부터 Wasabi 전 리전에서 S3 와 사용자 서비스에 오류가 났다. 상태 페이지에는 10:56 UTC 에 Web Console 로그인 문제와 Wasabi 리전의 오류를 조사한다는 글이 올라왔다.

   서비스 중단장애 조치 실패간헐적 타임아웃

   촉발

   2024년 8월 6일 10:32 UTC 에 큐 서비스가 가득 찬 상태가 됐다.

   원인

   용량 한계

   구성 요소

   메시지 브로커인메모리 캐시데이터베이스

   기여 요인

   –

   조치

   • 운영팀이 데이터베이스에 남은 오래된 연결을 정리하려고 주 데이터베이스를 재시작했고, 동시에 큐 서비스의 큐를 비웠다. 이 조치로는 데이터베이스가 완전히 돌아오지 않았다.
   • 보조 데이터베이스 인스턴스를 주 인스턴스로 승격했고, 11:20 UTC 에 S3 서비스가 다시 정상이 됐다.
   • 8월 6일 13:17 UTC 부터 13:23 UTC 까지 큐 서비스 라이브러리를 데이터베이스에 완전히 반영하려고 데이터베이스를 한 번 더 재시작했다.
   • 8월 7일 두 번째 사건에서 원래의 주 데이터베이스를 다시 운영에 올려 사용자 서비스의 타임아웃을 풀었다.
   • 8월 7일 세 번째 사건에서 자동화 서비스가 보지 못하던 자동화 클러스터를 다시 만들어 배포했고, S3 서비스가 완전히 돌아왔다.

   사례 보기
2. IL-0302 GitHub 의 공용 MySQL 클러스터 mysql1 이 최대 부하 시간대에 연결이 바닥나 쓰기 작업이 네 번 멈췄다

   GitHub2022

   증상

   2022년 3월 16일 14:09 UTC, 최대 부하 시간대에 mysql1 데이터베이스의 부하가 늘면서 데이터베이스 프록시가 최대 연결 수에 닿았다. GitHub 의 모든 쓰기 작업이 동작하지 않았다.

   쓰기 거부데이터베이스 과부하오류율 상승장애 조치 실패

   촉발

   최대 부하 시간대에 공용 MySQL 클러스터 mysql1 의 부하가 늘어 데이터베이스 프록시가 최대 연결 수에 닿았다.

   원인

   용량 한계

   구성 요소

   데이터베이스데이터베이스 프록시와 커넥션 풀러

   기여 요인

   비효율적인 쿼리피크 시간 변경수동 조치 악화과도한 영향 범위

   조치

   • 정상인 복제본으로 페일오버해 3월 16일 장애에서 복구했다.
   • 3월 17일 미리 한 페일오버 뒤 새 주 노드에 생긴 연결 문제를 풀려고 연결을 재설정했다.
   • 3월 17일 장애 중에 부하 패턴을 찾아 인덱스를 추가해 주된 성능 문제를 고쳤다.
   • 3월 22일 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
   • 3월 23일 같은 부하 특성으로 클라이언트 연결이 실패하자 다시 주 노드를 페일오버해 복구했다.
   • 3월 23일 부하를 줄이려고 웹훅 트래픽을 제한했다.

   후속 조치

   • 다른 대책을 더 찾는 동안 최대 부하 시간대에 웹훅 트래픽 제한을 계속 써서 같은 장애가 다시 나지 않게 한다.
   • 최대 부하 시간대의 mysql1 부하 패턴을 점검하고, 그 결과에 따라 성능 수정을 차례로 한다.
   • 부하를 줄이고 페일오버 시간을 줄이려고 mysql1 의 트래픽을 다른 데이터베이스로 옮긴다.
   • 변경 관리 절차를 검토한다. 특히 운영 환경에 부하가 높을 때의 모니터링과 변경을 살핀다.
   • 플랫폼 성장에 맞춰 데이터베이스 샤딩과 하드웨어 확장을 비롯한 인프라 확장을 이어 간다.

   사례 보기
3. IL-0320 주 MySQL 서버의 디스크가 가득 차 메일 발송, API, 웹 화면이 지연됐다

   Postmark2011

   증상

   오전 8시 15분 EDT 무렵 주 MySQL 서버의 디스크 공간이 바닥나 메일 발송, API, 웹 화면이 지연됐다. 디스크 공간 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.

   노드 디스크 가득 참쓰기 거부장애 조치 실패

   원인

   용량 한계

   구성 요소

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

   기여 요인

   –

   감지

   서버마다 디스크 공간을 감시해 알리는 시스템이 있었다. 이번에는 공간이 평소보다 훨씬 빨리 차서, 알림을 알아챘을 때 MySQL 은 이미 제대로 동작하지 못하고 있었다.

   조치

   • 로그를 지워 디스크 공간을 확보하려 했지만 쉽게 되지 않았다.
   • 약 30분 뒤 두 번째 서버로 직접 장애 조치했고, 그 뒤 서비스가 정상으로 돌아왔다.
   • 장애 조치 뒤 실패한 작업을 복구했다.
   • 데이터베이스를 쓸 수 없는 동안 각 서버가 메일을 로컬 큐에 쌓아 두었다가 복구 뒤 보냈으므로 잃어버린 메일은 없었다.

   후속 조치

   • 가용성과 성능에 초점을 맞춰 클러스터를 업그레이드한다.
   • 문제를 더 일찍 잡도록 알림을 조금 더 민감하게 바꾼다.

   교훈

   돌아보면 처음부터 바로 두 번째 서버로 장애 조치했어야 했다. 팀은 복제가 정상인지 먼저 확인하려다가 약 30분을 썼다.

   사례 보기

원인별1