사례1건

1건 중 1~1번째

1. IL-0273 주 데이터센터의 전원이 잠깐 끊긴 뒤 Redis 클러스터가 돌아오지 않아 GitHub 가 2시간 6분 동안 HTTP 503 을 냈다

   GitHub2016

   증상

   2016년 1월 28일 00:23am UTC 에 여러 온콜 엔지니어에게 알림이 갔고, GitHub 가 HTTP 503 응답과 함께 유니콘 그림이 있는 오류 페이지를 내기 시작했다. 로드 밸런서와 프런트엔드 애플리케이션 서버 다수는 멀쩡했지만, 그 서버들이 요청을 처리하는 데 의존하는 시스템들에 닿을 수 없었다.

   서비스 중단

   촉발

   2016년 1월 28일 00:23am UTC 에 주 데이터센터에서 서버와 장비에 전원을 대는 시스템이 잠깐 끊겼고, 전체 서버의 25% 를 조금 넘는 서버와 여러 네트워크 장비가 재부팅됐다.

   원인

   의존성 장애

   구성 요소

   인메모리 캐시데이터센터 전력·냉각

   기여 요인

   미패치 알려진 버그단일 장애점자동 테스트 공백순환 의존

   감지

   서버에 닿을 수 없다는 알림과 Redis 연결 예외 급증 알림이 여러 온콜 엔지니어에게 갔다.

   조치

   • 현장 기술자와 함께 flea power 를 빼 완전히 꺼진 상태에서 서버를 다시 켜, 디스크가 다시 보이게 했다.
   • 영향받은 Redis 클러스터를 다른 하드웨어에 다시 만들기 시작했다.
   • Redis 클러스터 데이터를 대기 장비에 복원하고 Redis 서버 프로세스를 다시 올렸다.
   • 사이트 동작을 확인한 뒤 점검 페이지를 내리고 상태를 노란색으로 바꿨다.

   후속 조치

   • 전원이 다시 들어온 뒤 서버가 자기 드라이브를 보지 못하게 한 알려진 펌웨어 문제를 전체 서버에서 업데이트한다.
   • 새 펌웨어 업데이트가 나오면 도구가 팀에 이슈를 자동으로 열어, 변경 내역을 GitHub 환경과 대조해 검토하게 한다.
   • 애플리케이션 테스트에서 일부 외부 시스템이 없어도 애플리케이션 프로세스가 시작하는지 명시적으로 확인한다.
   • 백엔드 서비스가 꺼졌을 때 기능을 단계적으로 줄일 수 있도록 서킷 브레이커를 개선한다.
   • 새 서버 준비처럼 중요한 운영 작업을 맡는 내부 시스템의 가용성 요건을 사용자용 시스템과 같은 수준으로 다시 검토한다.
   • 팀 사이의 소통을 강화한다.
   • 모든 인원이 대응에 나서야 하는 상황의 에스컬레이션 방식을 미리 정해, 사고 조정자가 문서를 찾는 대신 복구를 관리하는 데 시간을 쓰게 한다.
   • 장애 동안 사용자에게 보내는 안내를 개선해, 무슨 일이 일어나는지와 다음 안내가 언제 올지 알 수 있게 한다.

   교훈

   복잡한 시스템은 구성 요소마다 의존을 이해해도 그 의존을 엄격하게 시험하지 않으면 새로운 방식으로 실패할 수 있다. 인프라의 큰 부분이 전원을 잃는 일을 완전히 막을 수는 없지만, 복구를 빠르고 믿을 만하게 하고 사용자 피해를 줄일 수는 있다. 예상하지 못한 장애에서 복구하는 데 필요한 내부 시스템은 복구 대상 시스템만큼 믿을 만해야 한다.

   사례 보기

원인별1