사례19건

19건 중 18~19번째

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

   교훈

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

   사례 보기
2. IL-0282 US-East 리전의 DynamoDB 스토리지 서버들이 멤버십 정보를 받지 못해 스스로 요청 처리에서 빠지면서 고객 요청의 약 55% 가 실패했다

   Amazon Web Services2015

   증상

   2:19am PDT 에 짧은 네트워크 장애가 있은 뒤 DynamoDB 고객 요청의 오류율이 치솟았다. 2:37am PDT 에는 오류율이 지난 3년 동안 겪은 어떤 수준보다 훨씬 높아졌고, 약 55% 에서 머물렀다.

   오류율 상승데이터베이스 과부하

   촉발

   2:19am PDT 의 짧은 네트워크 장애가 DynamoDB 스토리지 서버 일부에 영향을 줬고, 이 서버들이 한꺼번에 메타데이터 서비스에 멤버십 정보를 요청했다.

   원인

   용량 한계

   구성 요소

   데이터베이스

   기여 요인

   용량 계획 부재모니터링 사각지대재시도 폭주순환 의존과도한 영향 범위

   감지

   주 문제를 해결한 뒤 남은 낮은 오류율은 월요일에 고객들이 테이블이 updating 이나 deleting 단계에 멈췄다거나 오류율이 높다는 지원 케이스를 열면서 드러났다.

   조치

   • 용량 추가가 여러 번 실패한 뒤 5:06am PDT 에 메타데이터 서비스로 가는 요청을 멈췄다. 재시도가 줄어 메타데이터 서비스의 부하가 크게 덜어졌다.
   • 메타데이터 서비스가 관리 요청에 다시 응답하자 용량을 크게 늘렸다.
   • 메타데이터 서비스로 가는 요청을 다시 열고 스토리지 서버를 고객 요청 경로에 되돌렸다. 7:10am PDT 에 대부분의 고객과 AWS 서비스가 정상 운영을 이어 갈 만큼 오류율이 내려갔다.
   • 받아야 할 만큼 트래픽을 받지 못하던 메타데이터 파티션 하나를 전체 트래픽으로 되돌려 남은 오류를 월요일에 정리했다.

   후속 조치

   • 메타데이터 서비스의 용량을 이미 크게 늘렸다.
   • 멤버십 크기 같은 성능 지표를 더 엄격하게 모니터링해 상태를 파악하고 알맞은 용량을 미리 계획한다.
   • 스토리지 노드가 멤버십 정보를 요청하는 빈도를 줄인다.
   • 메타데이터 서비스가 요청을 처리하는 데 쓸 수 있는 시간을 늘린다.
   • DynamoDB 서비스를 나눠 메타데이터 서비스 인스턴스를 여럿 두고, 각 인스턴스가 스토리지 서버의 일부만 맡게 한다.
   • SQS 의 메타데이터 캐싱을 고쳐 메타데이터 테이블에 오래 접근하지 못해도 메시지 보내기와 받기가 계속되게 한다.
   • Auto Scaling 서버들에 작업을 나누는 방식을 바꿔 쌓인 스케일링 작업을 더 병렬로 처리한다.
   • 더 새로운 작업으로 대체된 오래된 스케일링 작업을 걸러 내는 장치를 넣는다.
   • 스케일링 작업을 처리하는 용량을 늘린다.
   • CloudWatch 가 DynamoDB 의 그룹 멤버십 데이터를 캐싱하는 방식을 바꿔, 갱신이 필요한 지표를 가능한 한 적게 줄인다.
   • write-through 캐싱으로 지표를 더 빨리 전달하는 기능을 개발한다. 이 캐시는 지표를 저장하기 전에 바로 보여 준다.
   • 타임아웃을 줄인 콘솔 로그인 코드를 며칠 안에 배포한다. 이 코드는 이미 테스트 과정에 들어가 있다.

   교훈

   AWS 는 멤버십 크기처럼 성능에 영향을 주는 값을 자세히 보지 않아 메타데이터 서비스에 필요한 용량을 미리 잡지 못했다. 전체 오류율이 낮아도 일부 고객에게는 오류가 몰릴 수 있다. AWS 는 이를 늦게 알아채 월요일에 상태 대시보드 게시가 늦었다. 콘솔 로그인은 성공하지 않아도 되는 API 호출에 아주 긴 타임아웃이 걸려 수십 초씩 막혔다. 이런 호출은 빨리 실패하고 로그인을 이어 가게 했어야 했다.

   사례 보기

원인별8