사례6건

6건 중 5~6번째

1. IL-0446 ECS 서비스에 배포한 직후 요청의 20% 쯤이 ALB 의 5XX 를 받았고, 오류는 ap-northeast-1d 에서만 나는 것처럼 보였다

   ITANDI2020

   증상

   운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟았다. 분당 1만 건쯤 요청을 받는 서비스에서 요청의 20% 쯤이 5XX 를 받았고, 같은 때 타깃 연결 오류도 났다.

   오류율 상승

   촉발

   CircleCI 와 Terraform 으로 운영 ECS 에 배포해 ECS 태스크가 다시 만들어졌고, 그 시점에 ELB 와 백엔드 사이의 통신이 불안정해졌다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서Amazon ECS

   기여 요인

   –

   감지

   팀은 운영 ECS 에 배포한 직후 ALB 의 HTTPCode_ELB_5XX_Count 가 갑자기 치솟은 것을 보고 알았다.

   조치

   • ECS 태스크를 가장 먼저 재시작했지만 복구되지 않았다.
   • ELB 의 서브넷 가운데 1d 를 같은 1d 의 다른 서브넷으로 바꿨다. dig 로 ELB 이름을 조회해 IP 가 바뀐 것을 확인했지만 해결되지 않았다.
   • ECS 서비스 설정을 바꿔 ECS 태스크 15개 가운데 1d 에서 돌던 6개를 1a 와 1c 로 옮겼지만 해결되지 않았다.
   • 1d 에서 도는 ECS 태스크가 없어진 뒤 ELB 에서 1d 서브넷을 뺐지만 복구되지 않았다.
   • 배포로 ECS 태스크가 무거워져 ELB 와 백엔드 사이에 타임아웃이 났을 가능성을 보고 ELB 의 유휴 타임아웃 설정을 바꿨지만 복구되지 않았다.
   • ECS 태스크를 배포 전으로 되돌렸지만 복구되지 않았다.
   • VPC, 서브넷, 백엔드, SecurityGroup 이 옛 ELB 와 똑같은 새 ELB 를 만들었다.
   • ECS 서비스 하나에 ELB 여러 개를 붙일 수 있으므로 ECS 서비스에 새 ELB 를 함께 붙였다.
   • 서비스의 호스트 존에 옛 ELB 를 가리키는 레코드와 같은 레코드를 새 ELB 쪽으로 하나 더 만들었다. 두 레코드에 가중치를 줘서 트래픽의 1/10 만 새 ELB 로 보냈다.
   • 새 ELB 에서 ELB_5XX 가 하나도 나오지 않아 옛 ELB 에 문제가 있다고 보고 가중치를 새 쪽 10, 옛 쪽 0 으로 바꿨다.

   교훈

   네트워크 구성상 있을 수 없는 그래프가 보이면 AWS 쪽도 의심해 봐야 한다.

   사례 보기
2. IL-0494 DDoS 중 호스팅 사업자가 중앙 로드 밸런서 IP를 null route 해 A 레코드로 Netlify를 가리킨 사이트가 응답하지 않았다

   Netlify2016

   증상

   2016-08-22 월요일 오전 8시 PST에 Netlify 중앙 로드 밸런서가 응답하지 않는다는 알림이 왔다. 로드 밸런서의 공개 IP로 가는 트래픽은 서버에 닿기 전에 멈춘 채 응답이 없었다.

   네트워크 도달 불가

   촉발

   DDoS 트래픽이 Rackspace 시카고 데이터센터에 있던 Netlify 중앙 로드 밸런서로 몰렸고, Rackspace가 그 로드 밸런서의 IP를 null route 했다.

   원인

   클라우드 제공자 장애

   구성 요소

   클라우드 로드 밸런서

   기여 요인

   단일 장애점디버그 접근 제한

   감지

   2016-08-22 월요일 오전 8시 PST에 중앙 로드 밸런서가 응답을 멈췄다는 알림을 받았다. 이틀 전 토요일 밤에는 로드 밸런서의 트래픽 패턴에서 들어오는 전송량 급증을 먼저 알아챘다.

   조치

   • Rackspace에 문제를 올리는 동시에 Google Compute에 새 CDN 서버 클러스터를 띄우기 시작했다.
   • 새 CDN 클러스터가 준비되자 지원 채널로 연락해 온 고객에게 Google 네트워크 로드 밸런서를 가리키는 새 공개 IP를 알리고, 네이키드 도메인을 되살리도록 A 레코드를 바꾸게 안내했다.
   • 새 IP가 안정적인 해법이라고 확신한 뒤 문서 페이지를 고치고 Twitter, Gitter, 상태 페이지에 새 IP를 알렸다.

   후속 조치

   • Google 기반의 새 네트워크 IP를 계속 운영한다.
   • Netlify CDN과 밀접하게 통합된 자체 DNS 호스팅을 내놓는다. Netlify DNS를 쓰면 중간 CNAME이나 A 레코드 없이 사용자를 가장 가까운 활성 CDN 노드로 보낸다.
   • 상태 페이지 게시 과정을 고쳐 앞으로 문제가 생기면 상태 페이지가 바로 갱신되게 했다.
   • 장애 때 유료 고객 모두에게 대상을 골라 메일을 빨리 보낼 수 있는 메일 발송 도구를 만든다.

   교훈

   관리형 로드 밸런서를 쓰는 한 DDoS 대응은 Netlify가 손댈 수 없었다. Rackspace의 로드 밸런서는 DDoS 공격에 너무 약했고 DDoS 대응 절차도 함께 일하는 다른 클라우드 사업자에 못 미쳤다. 결국 도메인을 DDoS 장애에서 지키는 유일한 방법은 그 도메인에 고정 IP 주소를 아예 드러내지 않는 것이다. 단일 IP에 기대지 않고 www 도메인을 주 도메인으로 쓰는 것이 성능과 가동 시간에 중요하다. 상태 페이지 게시 체계는 가장 필요할 때 불안정했다.

   사례 보기

원인별1