사례8건

8건 중 7~8번째

1. IL-0338 Google Cloud 의 HTTP(S) 로드 밸런서와 TCP/SSL Proxy 로드 밸런서가 32분 동안 요청의 33~87% 에 502 나 연결 재설정을 냈다

   Google Cloud2018

   증상

   2018년 7월 17일 12시 17분 PDT 부터 Google Cloud App Engine, HTTP(S) 로드 밸런서, TCP/SSL Proxy 로드 밸런서를 쓰는 고객의 요청이 502 응답 코드나 연결 재설정으로 실패했다. 오류 비율은 32분 동안 33% 에서 87% 사이를 오갔다.

   오류율 상승연결 리셋지연 시간 증가

   촉발

   두 번째 계층 GFE 코드에는 아직 쓰지 않던 새 기능이 들어가 있었고, 이 기능에 버그가 있었다. 운영 환경의 설정 변경이 이 버그를 간헐적으로 건드렸고, 버그는 GFE 를 재시작시켰다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서CDN 과 엣지 네트워크

   기여 요인

   자동 테스트 공백과도한 영향 범위

   감지

   12시 19분에 자동 모니터링이 Google 엔지니어링 팀에 알림을 보냈다. 엔지니어는 장애가 시작되고 3분 안에 알림을 받고 바로 조사를 시작했다.

   조치

   • 12시 44분 PDT 에 원인을 찾고 문제의 설정 변경을 곧바로 되돌렸다. 영향받은 GFE 들이 재시작을 멈추고 모두 서비스에 돌아오자 트래픽이 평소 수준과 동작을 되찾았다.

   후속 조치

   • 아직 쓰지 않는 기능을 꺼 두는 안전장치를 더한다.
   • 작업을 재시작시킬 수 있는 잠재 버그가 운영 바이너리에 남을 위험을 줄이도록 GFE 테스트 스택을 더 단단하게 만든다.
   • 장애가 미치는 범위를 줄이도록 GFE 풀의 샤드끼리 더 격리한다.
   • 진단을 빠르게 하도록 GFE 풀의 모든 설정 변경을 한곳에 모은 대시보드를 만들어, 엔지니어가 문제를 일으킨 변경을 쉽게 보고 대조해 찾아내게 한다.

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