▲

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

 (downdetectorsdowndetector.com)
1P by GN⁺ 15일전 | ★ favorite | 댓글 1개
  • 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⁺ 15일전  [-]
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()를 호출해 무작위 응답 시간을 만들어내는 구조임
      즉, 진짜 상태를 체크하는 게 아니라 모의 상태 데이터를 보여주는 방식임
답변달기