사례2건

2건 중 1~2번째

1. IL-0545 Wasabi 전 리전에서 모든 API 호출이 HTTP 5XX 오류로 실패했다

   Wasabi2024

   증상

   2024년 11월 30일 00:17 UTC 부터 Wasabi 의 모든 스토리지 리전에서 Wasabi Cloud Storage 와 Web Console 로 가는 클라이언트 연결 시도가 실패했고, 모든 API 호출이 HTTP 5XX 오류로 끝났다. 상태 페이지에는 00:20 UTC 에 전 리전의 네트워크 오류를 조사하고 있으며 Console 과 S3 서비스 접속이 오류를 낼 수 있다는 글이 올라왔다.

   서비스 중단부하 불균형

   원인

   unknown

   구성 요소

   메시지 브로커데이터베이스

   기여 요인

   –

   조치

   • 엔지니어링팀과 운영팀이 내부 서버가 여러 데이터베이스 인스턴스로 요청을 나눠 보내도록 직접 설정해 서비스를 되살렸다.
   • 서비스가 돌아온 뒤 내부 메시징 큐를 복구하고 클라이언트 요청을 제대로 처리하는 자동 작업을 다시 돌려 근본 원인을 바로잡는 작업을 했다.

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