사례4건

4건 중 1~4번째

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-0291 GitLab.com 의 redis-sidekiq Sentinel 이 쿼럼을 만들지 못해 Sidekiq 이 30분 동안 멈추고 500 오류가 늘었다

   GitLab2023

   증상

   #production 채널에 Redis 클라이언트 오류 알림이 먼저 오고, 이어서 여러 서비스의 Error SLO 위반 알림이 잇따랐다. Sidekiq 작업을 쓰는 모든 서비스가 30분 동안 완전히 멈췄고 Web 과 API 요청에서도 500 오류가 늘었다.

   장애 조치 실패오류율 상승

   촉발

   primary 였던 redis-sidekiq-03-db-gprd 가 GCP 호스트 오류로 실패했고, 이 VM 은 리셋되어 다른 노드로 옮겨졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   인메모리 캐시데이터베이스 장애 조치 관리자

   기여 요인

   단일 장애점모니터링 사각지대

   감지

   #production 채널에 여러 알림이 왔다. Redis 클라이언트 오류 알림부터 시작해 Webservice & API LoadBalancer 와 Puma 를 포함한 여러 서비스의 Error SLO 위반 알림으로 번졌다.

   조치

   • primary 를 뽑을 만큼 노드가 없다는 것을 확인한 뒤 실패한 노드를 재시작했다.

   후속 조치

   • Sentinel 서비스가 꺼지면 알림을 보낸다.
   • 머지 리퀘스트가 Redis Sidekiq 장애 뒤에 스스로 회복하도록 고친다.

   교훈

   꺼진 Sentinel 노드를 알림으로 잡았다면 장애 조치에 필요한 쿼럼을 만들 노드 수를 미리 확보해 이 장애를 아예 막을 수 있었다. 너무 시끄럽다는 이유로 알림을 지운 것이 꺼진 노드를 쿼럼 문제 전에 잡을 기회를 줄였을 수 있다. 복구가 몇 시간 길게 이어진 것은 머지 리퀘스트가 Redis Sidekiq 장애에서 스스로 회복하지 못했기 때문이다.

   사례 보기
3. IL-0388 Redis 고가용 클러스터의 primary 노드가 내려간 뒤 Discord API 가 느려지고 길드 일부가 오프라인으로 보이며 접속이 실패했다

   Discord2017

   증상

   2017년 10월 13일 14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. API 서비스가 쓰는 Redis 고가용 클러스터에서 primary 노드가 완전히 사라졌다. 클러스터는 secondary 노드로 제대로 failover 했지만, 일부 API 인스턴스가 failover 를 제대로 처리하지 못했다.

   장애 조치 실패지연 시간 증가서비스 중단

   촉발

   14:01 PDT 쯤 Google Cloud Platform 이 API 서비스용 Redis 고가용 클러스터의 primary 인스턴스를 자동으로 마이그레이션했다. 이 마이그레이션으로 노드가 잘못 오프라인이 되면서 클러스터가 재조정됐고, API 인스턴스의 Redis failover 처리에 있던 알려진 문제가 드러났다.

   원인

   소프트웨어 결함

   구성 요소

   인메모리 캐시데이터베이스CDN 과 엣지 네트워크

   기여 요인

   미패치 알려진 버그장애 중첩모니터링 사각지대

   감지

   14:01 PDT 에 실시간 지표와 모니터링이 이상을 알렸다. 15:41 에 모니터링에서 다시 이상이 보였고, 15:42 에 서버 일부가 오프라인으로 보인다는 사용자 신고가 엔지니어링 팀에 들어왔다.

   조치

   • Redis 연결 문제를 풀려고 14:11 PDT 에 모든 API 인스턴스를 롤링 재시작했다. 재시작은 14:15 에 끝났지만 API 지연은 계속 높았다.
   • 비용이 큰 API 경로에 잘못 걸린 엣지 캐시 규칙을 고쳤다.
   • 엔드포인트를 쓸 수 없는 동안에는 응답을 캐시할 수 없어서, 문제를 일으킨 API 엔드포인트를 상위 엣지 네트워크에서 막았다.
   • 부하로 쓰러진 Cassandra 클러스터를 되살려 정상 서비스로 돌렸다.
   • Cassandra 클러스터 문제로 생긴 지연을 풀려고 모든 API 인스턴스를 다시 롤링 재시작했다. 14:57 에 API 가 정상으로 돌아왔다.
   • 15:50 PDT 에 이상하게 동작하는 "guilds" 노드를 서비스 해시링에서 강제로 빼서, 그 서버가 스스로 제대로 내려가기를 기대했다.
   • 15:52 PDT 에 그 guilds 노드를 강제로 재시작했고, 재시작은 성공했다.
   • 16:07 PDT 에 전체 서비스를 재시작하기로 하고, 모든 사용자를 다시 접속시켜 여러 서비스의 잘못된 상태를 초기화했다.
   • "push" 구성 요소의 부하를 줄이려고 이 구성 요소에 기대는 트래픽 여러 갈래를 차단 목록에 넣었다.
   • 사용자가 빠르고 안전하게 다시 접속하게 해 주는 API 설정이 사람의 실수로 잘못 들어가 있던 것을 고쳤다. 16:33 부터 서비스가 천천히 회복했다.

   후속 조치

   • Redis failover 의 알려진 문제를 고치는 일의 우선순위를 올려, 앞으로 몇 주 안에 끝내려 한다. 노드 하나의 장애로 문제가 더 생기지 않게 하려는 것이다.
   • 캐시가 잘못 걸렸던 경로의 동작을 바꿔, 앞으로 이런 오류가 나도 다른 서비스를 망가뜨리지 않고 제대로 처리하게 했다.
   • 연쇄 장애를 미리 알려 줄 수 있었던 신호 일부에 모니터링을 더했다. 엔지니어가 조사하고 대비할 시간을 벌려는 것이다.
   • 이번 장애에 영향을 받은 서비스들의 전반적인 신뢰성과 장애 처리를 개선할 계획을 이어 간다.
   • 문제가 된 서비스가 쓰는 라이브러리에서 결함으로 보이는 것을 찾았고, 이를 고칠 것으로 보는 업데이트를 배포하고 있다.

   사례 보기
4. IL-0278 주간 소프트웨어 업데이트 뒤 GCP 의 Redis Cloud 클러스터 노드 대부분이 동시에 응답하지 않아 그 클러스터의 데이터베이스가 내려갔다

   Redis2016

   증상

   2016년 2월 8일 17:45 UTC 에 Google Cloud Platform 의 Redis Cloud 클러스터 us-central1-1-1.gce.garantiadata.com 에서 큰 장애가 났다. 데이터베이스 엔드포인트가 us-central1-1-1.gce.garantiadata.com 으로 끝나는 사용자들이 데이터베이스를 쓰지 못했다.

   서비스 중단장애 조치 실패

   촉발

   2016년 2월 8일 17:30 UTC 에 서비스 소프트웨어의 주간 업그레이드가 GCP 클러스터 us-central1-1-1.gce.garantiadata.com 에 처음 배포됐다.

   원인

   배포 결함

   구성 요소

   인메모리 캐시데이터베이스 장애 조치 관리자DNS 서버와 레코드

   기여 요인

   장애 중첩

   조치

   • 클러스터의 모든 노드를 내리고 종료했다.
   • 클러스터의 모든 엔드포인트를 클러스터의 DNS 영역에서 지웠다. DNS 제공자가 삭제 요청을 스로틀링해 남은 항목은 손으로 지웠다.
   • 주간 업데이트를 뺀 새 클러스터 노드를 처음부터 만들었다.
   • 원래 노드가 쓰던 저장소를 새 노드에 다시 붙여, 영속성이 있는 데이터베이스를 복구할 수 있게 했다.
   • 데이터베이스를 모두 띄웠고, 영속성이 있는 데이터베이스는 저장소에서 복구했다.

   후속 조치

   • 이번 같은 장애를 막는 절차를 갖출 때까지 자동 주간 업그레이드를 모두 멈춘다.
   • DevOps 코드 배포의 QA 절차를 다시 검증한다.
   • DNS 요청이 스로틀링될 때 도구가 이를 처리하도록 개선한다.

   사례 보기

원인별4