사례39건

39건 중 38~39번째

1. IL-0258 DDoS 방어 업체에서 데이터센터로 가는 GRE 터널이 끊겨 FastMail 이 두 시간 가까이 접속되지 않았다

   Fastmail2016

   증상

   멜버른 시간 2016년 2월 7일 일요일 오전 4시 50분, UTC 로는 2월 6일 오후 6시 무렵 Level 3 와 NYI 사이의 GRE 터널이 끊겼다. FastMail 로 오는 트래픽이 FastMail 네트워크에 전혀 들어오지 못해 고객은 서비스를 쓸 수 없었다.

   서비스 중단네트워크 도달 불가

   촉발

   멜버른 시간 2016년 2월 7일 오전 4시 50분에 DDoS 방어를 맡은 Level 3 와 주 데이터센터 NYI 사이의 GRE 터널이 끊겼다.

   원인

   의존성 장애

   구성 요소

   DDoS 방어 서비스BGP 라우팅

   기여 요인

   디버그 접근 제한

   감지

   데이터센터 업체 NYI 가 장애를 금방 알아챘다.

   조치

   • NYI 가 Level 3 지원 창구에 계속 상급자 대응을 요청해, FastMail 의 공인 IP 대역이 다시 NYI 를 가리키게 했다.

   후속 조치

   • DDoS 방어를 예전 방식으로 되돌려, NYI 가 직접 통제하는 가운데 Black Lotus 가 방어를 맡는다.
   • Los Angeles 데이터센터에 보조 네트워크로 NYI 의 애플리케이션·메일 서버와 통신하는 nginx 프런트엔드를 새로 만든다. NYI 의 주 네트워크가 끊기면 DNS 로 www.fastmail.com, mail.messagingengine.com 같은 이름을 LA 프런트엔드로 돌린다.
   • Amsterdam 에 하드웨어를 늘리고, 배달 시스템이 NYI 와 덜 통신하도록 내부를 바꾼다.
   • NYI 가 네트워크 장애를 감지하고 대응하는 내부 절차를 NYI 와 함께 더 자세히 파악한다.

   교훈

   이렇게 복구가 늦어지는 것은 받아들일 수 없다. FastMail 과 NYI 가 쌓아 온 신뢰성의 큰 부분은 NYI 가 인프라를 직접 통제하는 데서 나왔다. 상시 DDoS 방어로 옮기면서 그 통제를 잃었다.

   사례 보기
2. IL-0337 US East 리전 한 가용 영역에서 네트워크 변경으로 EBS 노드가 복제본과 끊겨 EBS 볼륨이 멈췄다

   Amazon Web Services2011

   증상

   2011년 4월 21일 오전 12시 47분 PDT, US East 리전의 한 가용 영역에서 EBS 볼륨 일부가 읽기와 쓰기를 처리하지 못하게 됐고, 그 볼륨을 쓰던 EC2 인스턴스도 읽거나 쓰려다 함께 멈췄다. 리전 전체에서 EBS API 의 오류율과 지연도 높아졌다.

   스토리지 연결 끊김네트워크 도달 불가컨트롤 플레인 지연오류율 상승장애 조치 실패데이터 유실

   촉발

   US East 리전의 한 가용 영역에서 주 EBS 네트워크의 용량을 올리는 작업 중, 이중화된 라우터 하나에서 트래픽을 빼는 단계를 잘못 실행했다. 트래픽은 주 네트워크의 다른 라우터가 아니라 용량이 작은 보조 EBS 네트워크로 갔다.

   원인

   운영 실수

   구성 요소

   클라우드 블록 스토리지데이터베이스

   기여 요인

   자동화 증폭재시도 폭주여유 용량 부재과도한 영향 범위잡음에 묻힌 신호

   조치

   • 잘못된 트래픽 전환을 되돌려 네트워크 연결을 살렸다. 연결이 돌아오자 노드들이 한꺼번에 재미러링할 공간을 찾기 시작했다.
   • 4월 21일 오전 2시 40분 PDT, 영향받은 가용 영역의 새 Create Volume 요청을 모두 막는 변경을 배포했다. 2시 50분에 다른 EBS API 의 지연과 오류율이 회복했다.
   • 오전 8시 20분부터 망가진 EBS 클러스터와 EBS 컨트롤 플레인 사이의 통신을 모두 끊었다. 그 가용 영역의 EBS API 는 전부 막혔지만 리전의 나머지 EBS API 는 정상으로 돌아왔다.
   • 오전 11시 30분, 클러스터 노드 사이에 꼭 필요한 통신은 그대로 두고, 망가진 클러스터의 EBS 서버가 빈 공간도 없는 다른 서버에 헛되이 연락하지 못하게 막았다. 이 변경 뒤 클러스터는 더 나빠지지 않았다.
   • 오전 11시 30분, EBS 컨트롤 플레인을 바꿔 다른 가용 영역에서 EBS 기반 EC2 인스턴스를 새로 띄울 때의 오류와 지연을 없앴다. 정오에 거의 정상으로 돌아왔다.
   • 실패한 노드는 다시 쓰지 않고, US East 리전 곳곳의 여유 서버를 물리적으로 옮겨 망가진 EBS 클러스터에 설치했다.
   • 새로 들인 서버와는 협상이 일어나되 기존 서버에 처리하지 못할 요청이 다시 몰리지 않도록 협상 스로틀을 조심스럽게 바꿨다.
   • 리전의 다른 가용 영역에 영향이 가지 않도록 영향받은 가용 영역에만 쓰는 EBS 컨트롤 플레인을 따로 세우고 더 세밀한 스로틀을 만든 뒤, 밀린 상태 변경을 처리했다.
   • 장애 초반에 데이터 손실에 대비해 남은 2.2% 의 볼륨을 S3 백업에 스냅샷으로 떠 두었다. 그 스냅샷에서 볼륨을 복구하는 코드를 만들고 시험한 뒤 밤새 묶음으로 처리했다.
   • 기계 고장을 겪어 스냅샷도 뜨지 못한 나머지 볼륨을 포렌식으로 조사했고, 4월 24일 오후 3시부터 복구했다.
   • 자동 장애 전환을 하지 못하고 고립된 RDS multi-AZ 인스턴스의 primary 복제본은 데이터 손실 위험 때문에 사람이 직접 개입해 처리했다.

   후속 조치

   • 변경 절차를 감사하고 자동화를 늘려 이번 같은 실수가 다시 나지 않게 한다.
   • 큰 장애 복구에 필요한 안전 여유 용량을 늘 갖도록 용량 계획과 알람을 바꾼다. 용량 여유분은 이미 크게 늘렸고, 필요한 새 용량은 몇 주 안에 갖춘다.
   • EBS 서버 노드의 재시도 로직을 바꿔, 큰 중단이 나면 더 적극적으로 백오프하고 새 노드를 헛되이 찾기보다 이전 복제본과 연결을 되살리는 데 집중하게 한다.
   • EBS 노드를 죽인 경쟁 조건의 원인을 찾았고, 고친 코드를 시험해 몇 주 안에 클러스터에 배포한다.
   • RDS multi-AZ 인스턴스가 자동 장애 전환을 하지 못하게 만든 버그를 고치고 있다.
   • 한 가용 영역의 클러스터가 요청을 너무 오래 처리할 때 스레드가 고갈되지 않도록 타임아웃 로직을 바로 고친다.
   • EBS 컨트롤 플레인이 가용 영역을 더 잘 구분하고, 용량을 넘었을 때 부하를 골라서 덜어 내게 한다.
   • EBS 컨트롤 플레인의 기능을 더 많이 떼어 내, 지원하는 EBS 클러스터와 같은 가용 영역에서 도는 클러스터별 서비스로 옮긴다.
   • 로드맵을 조정해 지금은 가용 영역 하나만 쓸 수 있는 VPC 고객이 되도록 빨리 여러 가용 영역을 쓰게 한다.
   • 가용 영역 하나를 통째로 잃어도 애플리케이션 가용성이 유지되는 multi-AZ 애플리케이션을 만들 수 있도록 더 나은 도구를 고객에게 준다.
   • 클라우드 설계 모범 사례를 다루는 무료 웨비나를 5월 2일 월요일부터 열고, 모범 사례 백서와 함께 AWS 웹사이트의 새 Architecture Center 에 둔다.
   • 팀이 클러스터를 복구할 때 쓴 세밀한 제어와 스로틀을 EBS 노드 안에 바로 넣고, 여러 종류의 볼륨 복구에 쓴 방식을 자동화한다.
   • 클러스터가 나빠진 동안에도 볼륨 기능을 지키는 방법을 찾고, stuck 볼륨의 스냅샷을 뜨는 기능을 넣는 것을 검토한다.
   • 장애 도중부터 늘린 업데이트 빈도를 앞으로도 같은 수준으로 이어 간다. 또 이런 장애 때 개발자 지원 팀 인력을 더 넓게 배치하고, 짐작은 피하면서 이르고 쓸모 있는 정보를 내도록 조직하는 방법을 준비하고 있다.
   • 고객이 API 로 자기 인스턴스가 손상됐는지 볼 수 있는 도구를 만들고 있다.

   교훈

   AWS 는 이 사고를 촉발한 것은 네트워크 설정 변경이었지만, 앞으로의 일은 비슷한 실패가 나도 EBS 가 견디게 만드는 데 둔다고 했다. 여유 용량이 더 있었다면 망가진 클러스터가 재미러링 요청을 빨리 흡수해 폭주를 피했을 것이라고 봤다. 가용 영역들을 완전히 독립된 것처럼 만들려면 더 투자해야 한다는 것을 이 사고로 배웠다고 했다. 장애 중에 고객이 영향받은 자원을 다른 정상 가용 영역에서 바꾸기 어려웠던 일이 다시 일어나지 않게 하는 것을 최우선으로 꼽았다. 여러 가용 영역에 걸친 배포를 쉽게 설계하고 운영하도록 고객을 돕는 일도 더 잘해야 한다고 했다. 여러 종류의 볼륨 복구에 쓴 방식을 자동화해 두었다면 복구 시간을 크게 줄였을 것이라고 했다. 장애 중 고객 소통은 더 자주, 더 많은 정보를 담아야 한다고 봤다.

   사례 보기

원인별10