사례2건

2건 중 1~2번째

1. IL-0493 Google Cloud TCP 로드 밸런서의 백엔드 노드가 상태 검사에 모두 실패해 Netlify 전체 트래픽의 약 5%가 처리되지 않았다

   Netlify2021

   증상

   2021-03-25 14:39 UTC에 모니터가 로드 밸런서 상태 검사 실패를 알렸다. 고정 IP로 A 레코드를 거는 고객이 쓰는 Google Cloud TCP 로드 밸런서에서 전체 트래픽의 약 5%가 처리되지 않았고, 18:46 UTC까지 이어졌다.

   프로브 실패오류율 상승

   촉발

   OS의 자동 업데이트가 백엔드 노드의 systemd-networkd 유닛을 재시작해 로컬 라우팅 테이블에 넣어 둔 로드 밸런서 IP 항목을 지웠다. google-guest-agent는 systemd-networkd 재시작을 감시하지 않아 그 IP를 다시 넣지 않았다.

   원인

   소프트웨어 결함

   구성 요소

   클라우드 로드 밸런서systemd-networkd

   기여 요인

   모니터링 사각지대장애 중첩

   감지

   14:39 UTC에 모니터가 로드 밸런서 상태 검사 실패를 알렸다. 백엔드에 직접 붙는 노드 단위 상태 검사는 장애 내내 정상이라고 했고, 로드 밸런서의 백엔드 상태 검사는 알림에 들어 있지 않아 노드가 하나씩 빠지던 몇 시간 동안 알림이 없었다.

   조치

   • 15:30 UTC까지 엔터프라이즈 네트워크 트래픽을 받을 IP 대역을 따로 마련하고, 영향을 받은 고객에게 연락하기 시작했다.
   • 15:55 UTC에 Global Accelerator를 앞에 둔 AWS 네트워크 로드 밸런서를 프로비저닝하기 시작했고, 16:46 UTC에 이 엔드포인트의 새 IP를 상태 페이지와 지원 페이지에 올렸다.
   • 18:46 UTC에 영향을 받은 모든 노드에서 GCP 네트워킹 데몬을 재시작해 Google 로드 밸런서로 가는 트래픽을 되살렸다.

   후속 조치

   • 모든 GCP CDN 노드의 guest-agent systemd 설정을 손으로 고쳐 systemd-networkd 재시작을 감지하게 했다.
   • 이 버그를 Google에 알리고 google-guest agent 저장소에 이슈를 열었다. 글을 쓸 때 공식 수정 PR이 열려 있었다.
   • 로드 밸런서의 백엔드 상태 검사를 알림에 넣어 로드 밸런서 모니터링을 넓힌다.
   • 업데이트 시험을 개선하고 며칠 동안 문제를 지켜볼 수 있도록 백엔드에 카나리 노드를 더한다.
   • 트래픽 등급을 나누고 여러 리전으로 옮겨, 등급마다 따로 규모를 늘리고 리전 장애에 더 잘 견디게 했다.
   • 고객이 apex 도메인을 Netlify 사이트로 보내는 방법을 넓힌다. 많은 DNS 사업자가 apex 도메인에 지원하는 ALIAS와 ANAME 레코드로 가용성을 높이는 방법을 찾는다.
   • 엔터프라이즈 트래픽 라우팅을 전용 IP로 나눠, 엔터프라이즈 고객과 나머지 고객의 용량과 설정 변경을 따로 다룬다.

   교훈

   Netlify는 자사 같은 서비스를 쓸 때 IP 기반 A 레코드에 기대지 말라고 권하지만, 많은 DNS 사업자에서는 A 레코드가 유일한 방법이다. 노드 단위 상태 검사는 백엔드의 자체 IP로 붙었기 때문에 로드 밸런서 IP가 빠진 것을 잡지 못했고, 로드 밸런서의 백엔드 상태 검사를 알림으로 받았다면 장애 전에 진단할 시간을 더 벌었을 것이다.

   사례 보기
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 도메인을 주 도메인으로 쓰는 것이 성능과 가동 시간에 중요하다. 상태 페이지 게시 체계는 가장 필요할 때 불안정했다.

   사례 보기

원인별2