사례6건

6건 중 5~6번째

1. IL-0491 CDN 원본 서버군의 정상 노드가 안전 수준 아래로 줄어 Squarespace 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다

   Squarespace2019

   증상

   2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. static.squarespace.com과 static1.squarespace.com 도메인이 영향을 받아 일부 사이트가 이미지, 스크립트, 스타일시트를 불러오지 못했다.

   오류율 상승

   촉발

   2019-02-11 오후 10시 30분 ET에 한 엔지니어가 Squarespace CDN 원본 서버군 전체에 유지보수 작업을 시작했다. 엔지니어는 작업을 멈췄다고 생각했지만 작업은 백그라운드에서 계속 돌았고, 2019-02-12 오전 12시 10분에 CDN 원본 서비스 장애를 일으켰다.

   원인

   운영 실수

   구성 요소

   CDN 과 엣지 네트워크

   기여 요인

   과도한 영향 범위모니터링 사각지대

   감지

   2019-02-12 오전 12시 10분 ET에 모니터링 시스템이 CDN 원본 서버군의 정상 노드 수가 안전한 수준 아래로 떨어졌다고 당번 엔지니어에게 알렸다. 알림은 서버군이 핵심 가용성 기준 아래로 떨어진 뒤에야 왔고, 고객 영향이 크다는 것은 나중에야 분명해졌다.

   조치

   • 오전 2시 15분 ET까지 추가 복구 조치로 CDN 원본 서버군 일부를 되살렸고, 2시 20분에 서비스가 정상으로 돌아왔다.

   후속 조치

   • 장애 대응 플레이북을 고쳐 이 서버군에 영향을 주는 문제 대부분을 빨리 해결할 점검과 조치를 넣는다. 첫 점검에서 고객 영향을 판단하고 인시던트 커맨더를 바로 부르게 한다.
   • CDN 협력사와 원본 서비스의 문제가 고객에게 주는 영향을 더 빨리 판단할 수 있도록 외부 모니터링을 개선한다.
   • 엔지니어가 유지보수 명령을 내리는 방식의 운영 정책을 고치고 안전장치를 더한다. 그런 명령이 작업할 수 있는 서버군의 범위를 제한한다.
   • 사람이 직접 하는 유지보수 작업이 필요한 경우를 줄인다.
   • 독립된 장애 도메인을 만들고, 상태가 나쁜 부분을 피해 요청을 자동으로 보내도록 해 인프라의 복원력을 높인다.

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

   사례 보기

원인별5