사례2건

2건 중 1~2번째

1. IL-0534 US-EAST-1 의 Amazon S3 가 몇 시간 동안 요청을 처리하지 못했고 S3 에 기대는 AWS 서비스도 함께 멈췄다

   Amazon Web Services2017

   증상

   2017-02-28 오전 Northern Virginia 의 US-EAST-1 리전에서 Amazon S3 가 요청을 처리하지 못했다. GET, LIST, PUT, DELETE 요청이 모두 실패했다.

   서비스 중단

   촉발

   S3 팀원 한 명이 S3 청구 시스템이 예상보다 느린 문제를 디버깅하고 있었다. 이 팀원은 PST 오전 9:37 에 정해진 플레이북대로 청구 과정이 쓰는 하위 시스템의 서버 몇 대를 빼는 명령을 실행했다. 명령의 입력 하나가 잘못 들어가 의도보다 훨씬 많은 서버가 빠졌다.

   원인

   운영 실수

   구성 요소

   오브젝트 스토리지클라우드 블록 스토리지서버리스 함수 플랫폼

   기여 요인

   파괴적 변경 보호 장치 부재과도한 영향 범위순환 의존

   조치

   • 인덱스 하위 시스템을 먼저 재시작했다. PST 오후 12:26 에 GET, LIST, DELETE 요청을 처리할 만큼 용량이 올라왔고, 오후 1:18 에 완전히 회복했다.
   • 인덱스 하위 시스템이 동작하자 배치 하위 시스템을 회복시켰고, PST 오후 1:54 에 회복을 마쳐 S3 가 정상으로 돌아왔다.

   후속 조치

   • 용량을 빼는 도구가 용량을 더 천천히 빼도록 고쳤다.
   • 어떤 하위 시스템이든 필요한 최소 용량 밑으로 떨어지게 하는 용량 제거를 막는 안전장치를 더했다.
   • 다른 운영 도구에도 비슷한 안전 점검이 있는지 감사한다.
   • 핵심 S3 하위 시스템의 회복 시간을 줄인다. 그해 후반에 계획했던 인덱스 하위 시스템의 추가 분할 작업도 앞당겨 바로 시작한다.
   • AWS Service Health Dashboard 의 관리 콘솔이 여러 AWS 리전에서 돌도록 바꿨다.

   사례 보기
2. IL-0536 US East 의 Amazon SimpleDB 가 두 시간 동안 거의 모든 API 호출에 실패했다

   Amazon Web Services2014

   증상

   US East 리전의 SimpleDB 가 PDT 오후 9:16 부터 11:16 까지 거의 모든 API 호출에 실패했다. 최종 일관성 읽기 호출 일부만 성공했다. API 요청은 서버 쪽 오류인 http response code 500 을 받았다.

   서비스 중단오류율 상승

   촉발

   한 데이터센터에서 서버에 전원이 끊겨 SimpleDB 스토리지 노드 여러 대가 한꺼번에 내려갔다.

   원인

   소프트웨어 결함

   구성 요소

   데이터베이스코디네이션 키-값 저장소데이터센터 전력·냉각

   기여 요인

   자동화 증폭

   조치

   • 핸드셰이크 타임아웃 값을 손으로 늘렸다.
   • 메타데이터 노드 일부를 재시작해 스토리지 노드를 승인하게 했다. 스토리지 노드는 클러스터에 다시 들어가 고객 데이터 요청을 처리했다.
   • 나머지 메타데이터 노드가 안전하게 회복하도록 메타데이터 노드가 처리하는 CreateDomain 과 DeleteDomain API 호출을 PDT 오전 1:30 까지 스로틀링했다.

   후속 조치

   • 락 서비스의 핸드셰이크 타임아웃을 더 길게 잡는다. 이 수정을 모든 SimpleDB 리전에 배포한다.
   • 핸드셰이크 타임아웃을 여러 번 겪은 노드가 곧바로 클러스터에서 빠지지 않고, 기다렸다가 더 긴 타임아웃으로 핸드셰이크를 다시 시도하게 한다. 이 수정을 모든 SimpleDB 리전에 배포한다.

   교훈

   핸드셰이크 타임아웃 값을 낮게 잡은 것은 복제본 실패를 빨리 알아채기 위해서였지만, 지나고 보니 너무 낮았다. 핸드셰이크 타임아웃을 여러 번 겪은 노드가 곧바로 클러스터에서 빠지는 동작이 장애의 범위를 넓혔고 API 오류로 이어졌다. 노드는 기다렸다가 더 긴 타임아웃으로 핸드셰이크를 다시 시도했어야 했다.

   사례 보기

원인별2