사례2건

2건 중 1~2번째

1. IL-0335 주 SQL Server 의 bugcheck 로 Stack Exchange 네트워크가 읽기 전용이 됐다가 12분 동안 내려갔다

   Stack Exchange2017

   증상

   2017년 1월 24일 17:53 UTC 부터 Stack Exchange 네트워크가 약 5분 동안 읽기 전용으로 동작했다. 그 뒤 Stack Overflow 를 포함한 사이트 전체가 12분 동안 내려갔다.

   쓰기 거부서비스 중단장애 조치 실패데이터 유실

   촉발

   주 SQL Server 인 NY-SQL02 에서 SQL Server 프로세스가 bugcheck 를 일으켰다.

   원인

   unknown

   구성 요소

   데이터베이스

   기여 요인

   단일 장애점

   조치

   • NY-SQL02 의 SQL 서비스를 재시작해 네트워크를 읽기 전용으로 되살렸다.
   • SQL 상태를 점검한 뒤 사이트를 읽기·쓰기 모드로 되돌렸다.
   • 메모리가 384GB 라서 메모리 덤프가 끝나기를 기다리지 않고 네트워크를 먼저 살렸다.
   • NY-SQL02 를 운영에서 빼 메모리 시험을 포함한 점검에 들어갔다. 평소 부하는 모두 NY-SQL01 이 받게 했다.
   • 이 기회에 SQL 클러스터를 2016 SP1 CU1 로 올렸다.

   사례 보기
2. IL-0387 Mailgun 한 리전의 MongoDB 서버가 연결 증가로 과부하돼 트래킹, API, SMTP, 웹사이트에서 간헐적 타임아웃과 오류가 났다

   Mailgun2017

   증상

   2017년 1월 12일 14:09 UTC 에 한 운영 리전의 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터에서 알림이 울렸다. 대부분의 읽기를 맡는 MongoDB secondary 서버가 높은 부하 때문에 요청을 제때 처리하지 못했고, 트래킹 서비스의 오류도 여기서 왔다.

   데이터베이스 과부하간헐적 타임아웃오류율 상승

   촉발

   전날 낸 MongoDB 설정 변경 몇 건과 거의 같은 때부터 MongoDB secondary 서버로 들어오는 연결이 서서히 늘었다. 이 변경을 롤백하는 과정에서 사람의 실수로 API 와 SMTP 서비스가 읽기를 primary 로 보내게 됐다.

   원인

   unknown

   구성 요소

   데이터베이스

   기여 요인

   수동 조치 악화단일 장애점

   감지

   14:09 UTC 에 클릭·오픈 트래킹 서비스와 주 MongoDB 클러스터의 알림이 울려 엔지니어들이 대응을 시작했다.

   조치

   • 전날 낸 MongoDB 설정 변경을 15:15 UTC 부터 새 pull request 여러 개로 롤백했다. 이 과정에서 사람의 실수로 API 와 SMTP 서비스의 읽기를 primary 로 옮기는 변경이 함께 들어갔다.
   • 더 많은 연결을 감당하도록 MongoDB 서버 크기를 키웠다.
   • 근본 원인을 찾는 동안 서버를 안정시키려고 서버 단에 연결 한도를 넣었다. 서버 크기 조정과 함께 이 조치로 이 리전 API 가 평소 처리량의 약 75% 를 처리했다.
   • 20:28 UTC 부터 서비스가 MongoDB primary 서버에 열 수 있는 연결 수에 한도를 두는 변경을 배포했다.
   • 읽기에 secondary 서버를 우선하는 설정을 다시 배포했다. 20:35 UTC 에 이 리전 서비스가 정상으로 돌아왔다.

   후속 조치

   • 그동안 한 리전에서만 돌던 트래킹 인프라를 독립된 두 리전에서 운영한다.
   • 이 데이터베이스를 쓰는 모든 서비스에 열 수 있는 연결 수의 한도를 둬서, 서비스 하나가 다른 서비스에 주는 피해를 줄인다.
   • 주 MongoDB 클러스터 크기를 영구히 키우고, 같은 변경을 다른 데이터센터에도 적용한다.
   • 하위 서비스가 실패해도 클릭 리디렉션은 제대로 동작하도록 트래킹 서비스를 고친다.

   사례 보기

원인별1