사례1건

1건 중 1~1번째

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가 빠진 것을 잡지 못했고, 로드 밸런서의 백엔드 상태 검사를 알림으로 받았다면 장애 전에 진단할 시간을 더 벌었을 것이다.

   사례 보기

원인별1