Incident Library
적용된 필터 원인클라우드 제공자 장애기여 요인디버그 접근 제한조직Netlify모두 풀기검색어 없이 필터만 적용한 목록입니다. 최근 사례부터입니다.
추천 필터 검색하면 검색어에서 찾은 분류 값이 여기에 나옵니다.

그래프

  • 원인
  • 구성 요소
  • 증상
  • 기여 요인
  • 사례

사례1건

1건 중 1~1번째

  1. 증상

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

내 클러스터에도 있는지 확인하기

이 사례에서 가장 많이 나오는 구성 요소: 클라우드 로드 밸런서. kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이런 틈을 점검합니다. 점검 항목의 근거는 이 라이브러리와 같은 공개 보고서입니다.

원인별1