다운디텍터를 위한 다운 감시 서비스

• DownDetector 사이트의 가동 상태를 여러 지역에서 실시간으로 점검하는 웹 서비스
• 런던, 오클랜드, 뉴욕 등 3개 지역 서버에서 HTTP 응답 코드와 지연 시간(latency) 을 측정
• 모든 지역에서 HTTP 코드 200(정상 응답) 을 반환하며, 사이트가 정상 작동 중임
• 지역별 평균 지연 시간은 478~586ms 범위로 표시
• 주요 장애 감시 플랫폼의 신뢰성 검증 도구로 활용 가능성

---

지역별 점검 결과

• London, UK 지역에서 상태는 Up, HTTP 코드 200, 지연 시간 547ms
• Auckland, NZ 지역에서 상태는 Up, HTTP 코드 200, 지연 시간 478ms
• New York, US 지역에서 상태는 Up, HTTP 코드 200, 지연 시간 586ms
• 모든 지역에서 동일한 결과가 반복되어, DownDetector 서비스가 정상 운영 중임을 확인

서비스 개요

• 이 사이트는 DownDetector의 상태를 감시하는 전용 모니터링 페이지
• 각 지역별로 HTTP 응답 코드와 지연 시간을 주기적으로 측정해 표시
• 장애 감시 플랫폼 자체의 가용성 검증을 위한 참고 지표 제공
• 원문에 추가 정보 없음

[GN⁺]

Hacker News 의견

• 유럽 기반의 1인 개발자로서 올해 초부터 모든 인프라를 유럽 서비스로 전환했음
  Cloudflare 대신 Bunny.net, AWS 대신 Hetzner, 비즈니스 이메일은 Infomaniak으로 바꿨음
  지금까지 단 한 번의 다운타임도 없었고, 미국 서비스에서 완전히 분리된 느낌이 정말 좋음

  • 이 서비스들은 규모는 작지만, 작기 때문에 신뢰성 확보에 훨씬 더 진심임
    대기업 환경에서는 “AWS 썼으면 이런 일 없었을 텐데”라는 말이 흔함. 예전 IBM처럼 말임
    Hetzner는 AWS보다 훨씬 단순한 서비스 세트를 제공해서 복잡성이 적음
    다만 브랜드 인지도나 ‘프로페셔널해 보이는가’라는 문화적 요인도 여전히 큼
  • AWS나 Cloudflare가 실제로 더 자주 다운되는 건 아님. 단지 사용자 수가 많아서 이슈가 더 크게 보도될 뿐임
    인프라 선택은 자유지만, 가용성에 대한 인식이 실제와 다를 수 있음
  • 올해 초 내가 관리하던 Hetzner 서버가 이유 없이 리부팅된 적이 있었음
    유지보수 공지가 있었지만 해당 서버는 영향 목록에 없었음
    Hetzner가 나쁘다는 건 아니고, 유럽에서도 이런 사소한 사고는 일어남
  • Bunny.net의 팬이지만, Cloudflare는 AI 스크래퍼나 악성 트래픽 필터링 같은 ‘스마트 방어’ 기능이 강함
    Bunny.net이 그 역할까지 대체할 수 있는지는 의문임
  • Infomaniak과 Proton을 비교해보고 싶음. Infomaniak은 오피스 생산성 도구가 더 많아 보이는데, 메일과 드라이브 품질은 어떤지 궁금함

• 어제 Cloudflare 장애 때 Downdetector까지 같이 다운돼서 다들 웃었음. 타이밍이 절묘했음

  • 예전에 내가 일하던 CDN 회사도 상태 페이지 제공업체가 우리 고객이 되면서 상태 페이지를 바꿔야 했던 일화가 있었음

• “세 개의 Down Detector가 바에 들어왔다”는 농담이 있었음
  첫 번째가 “모르겠음”, 두 번째도 “모르겠음”, 세 번째가 “예”라고 답함

  • 아마 ‘눈먼 다운 디텍터들’ 이었을 거라는 반응이 있었음
  • 너무 웃겨서 이 농담은 꼭 훔쳐 써야겠음

• “이건 진짜 금이야(GOLD)”라며, “그럼 다운 디텍터를 감시하는 다운 디텍터를 감시하는 다운 디텍터는 누가 감시하냐”는 메타 농담이 이어졌음

  • 실제로 isitdownrightnow.com의 다운디텍터 감시 페이지가 공유됨
  • “지금 그 사이트에 접속해 있는 게 바로 너야!”라는 반응도 있었음
  • 진지하게는, 서로 다른 가용 영역과 코드베이스를 가진 다운 디텍터들이 서로를 감시하면 꽤 실용적인 접근임
  • “분산 다운 디텍터” 아이디어로 발전시켜서 HN에 프로젝트로 올릴 수도 있겠다는 의견도 있었음
  • “세 개 중 어떤 게 다운됐는지 감시하는 메타 다운 디텍터”를 만들자는 제안도 나왔음

• 사실 Downdetector 자체가 완전히 다운된 건 아니고, Cloudflare의 인간 인증 모듈이 문제였음
  그래서 기술적으로는 “정상”이었지만 실제로는 사용할 수 없었음

• “너의 다운 디텍터가 살아 있는지 감시할 또 다른 다운 디텍터가 필요함”이라는 농담이 있었음
  “Downdetectorsdown이 끝없이 이어지는 구조”라는 말도 나왔음

  • downdetectorsdowndetectorsdowndetector.com 링크가 공유됨
  • 여러 개를 두면 일부는 항상 다운될 테니, 그 비율을 추적하는 사이트가 있으면 좋겠다는 아이디어도 나왔음
  • 이건 결국 중앙화 vs 분산화 vs 분산 시스템의 문제임
    다운 디텍터들이 서로 하트비트를 주고받으며 감시하면, 일부가 죽어도 전체는 살아남는 구조가 가능함
    자가 치유 구조를 갖추면 훨씬 탄력적인 네트워크가 됨
  • “다운 디텍터가 끝없이 이어진다”는 말도 반복됐고
  • “N번째 다운 디텍터”로 표현되는 연결 리스트 구조로 만들자는 농담도 있었음

• “Sup dawg, I heard you like down detectors”라는 밈식 댓글도 있었음

• Downdetector의 상태 페이지가 직접 공유되었음

• “Cloudflare 장애로 Downdetector가 다운되고, 그로 인해 CloudFront까지 부하를 받은 상황”이라며
  그 부하까지 견딜 수 있는 새로운 CDN을 만들어보라는 도전이 제시됨

  • 하지만 “이미지 없는 정적 HTML이라면 CDN이 꼭 필요할까?”라는 현실적인 반응도 있었음

• “Downdetector는 어떻게 ‘정상 상태’를 감지하나?”라는 질문이 있었음
  Cloudflare 장애 당시 인덱스 페이지는 200을 반환했을 수도 있음
  헤드리스 브라우저로 스크린샷을 찍어 확인하려 하면 Cloudflare에 의해 차단될 듯함

  • 실제로는 가짜 데이터를 생성함
    script.js의 fetchStatus()가 generateMockStatus()를 호출해 무작위 응답 시간을 만들어내는 구조임
    즉, 진짜 상태를 체크하는 게 아니라 모의 상태 데이터를 보여주는 방식임