▲

Cloudflare가 꼭 필요하지 않다면 사이트를 그 뒤에 두지 말 것

 (huijzer.xyz)
3P by GN⁺ 2일전 | ★ favorite | 댓글 11개
  • Cloudflare의 대규모 장애로 여러 웹사이트가 접속 불가 상태가 되었으며, 이는 중앙화된 서비스의 단일 장애점 문제를 보여줌
  • 많은 중소형 사이트가 Cloudflare를 사용하지만, 실제로는 DDoS 보호가 필요하지 않은 경우가 많음
  • 소규모 블로그나 개인 사이트는 공격 대상이 될 가능성이 낮아, 불필요한 의존성만 생김
  • 안정성을 원한다면 round-robin DNS를 이용해 다른 서버를 백업으로 두는 방법이 제시됨
  • 웹의 탈중앙화 원칙을 지키기 위해, Cloudflare 같은 중개 서비스에 과도하게 의존하지 않는 것이 중요함

Cloudflare 장애와 단일 장애점 문제

  • 작성 시점(UTC 11월 18일 12:43)에 Cloudflare가 여러 사이트를 중단시킨 사례가 발생
    • 작성자는 웹 탐색 중 절반가량의 사이트에서 오류를 확인했다고 언급
  • 이 사건은 중앙화된 서비스에 의존할 경우 단일 장애점(single point of failure) 이 생긴다는 점을 보여줌
  • 대형 기업조차 실수를 하거나 장애를 겪을 수 있으며, 그 영향이 광범위하게 미침

DDoS 보호에 대한 과도한 공포

  • 많은 사용자가 DDoS 공격에 대한 두려움 때문에 Cloudflare를 사용
  • 그러나 대부분의 소규모 사이트는 월 수천 명 수준의 방문자만 보유하며, 공격 대상이 될 가능성이 낮음
  • 보안 업계의 표현을 인용해, “누구도 당신을 위해 제로데이를 낭비하지 않는다”는 점을 강조
    • 즉, 소규모 블로그에는 고급 공격 수단이 사용될 이유가 없음

탈중앙화 웹과 Cloudflare 의존의 모순

  • 많은 이들이 탈중앙화 웹의 중요성을 주장하면서도, 실제로는 Cloudflare 뒤에 사이트를 두고 있음
  • 이는 자기모순적 행태로 지적됨
  • Cloudflare 장애가 발생하면, 해당 사이트들도 함께 접근 불가 상태가 됨

대안: round-robin DNS를 통한 이중화

  • 서버 안정성을 높이려면 다른 위치에 두 번째 서버를 설정하고,
    A 및 AAAA 레코드를 이용한 round-robin DNS 구성을 제안
  • 이를 통해 한 서버가 다운되더라도 다른 서버로 트래픽을 분산 가능

핵심 메시지

  • 두려움에 기반한 과도한 보호 조치보다 직접적인 운영이 중요함
  • 사이트가 일시적으로 다운될 수는 있지만, Cloudflare 장애로 인한 전체 중단은 피할 수 있음
  • 결과적으로, 자신의 서비스를 직접 인터넷에 노출하고 관리하는 것이 더 바람직한 선택임
▲
t7vonn 17시간전  [-]

전 그냥 쓸게요

답변달기
▲
wedding 15시간전  [-]

구더기 무서워서 장 못 담그는 소리네요

답변달기
▲
youknowone 17시간전  [-]

소규모 사이트들은 보통 Cloudflare 내려가는 정도의 다운타임이 사이트 운영에 큰 영향을 안끼치죠...

답변달기
▲
mstorm 17시간전  [-]

기차나 버스 위험하니 걸어다니세요. 느낌

답변달기
▲
j2sus91 13시간전  [-]

소규모 사이트라도 공격 오덥디다,..

답변달기
▲
minsuchae 15시간전  [-]

클라우드플레어의 대체제가 있으면 좋겠지만 굳이 그게 없는 상태에선 클라우드플레어를 쓰는게 좋다고 저는 생각하네요.
다른 분들도 비슷한 의견이시지만
저는 실제 장애났을 때 에러때매 정상작동하는것인가 의문을 가지긴 했지만 그래도 결국엔 DNS 프록시 끄고 DNS TTL 1분으로 셋팅에서 임시로 서비스 되도록 변경했어서...
대안이 필요한건 맞지만 아에 안쓰는건 말도 안되는 짓이라고 보입니다.

답변달기
▲
colus001 16시간전  [-]

차라리 경쟁자의 출현을 기대하는게 더 현실적일 것 같음..

답변달기
▲
qpolsa95 17시간전  [-]

ddos보단 서버 리얼ip 숨기려고 쓰는 경우는 어떨까요?

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 월 100명 방문자 정도의 작은 블로그라도 DDoS 공격을 받을 수 있음
    공격자가 마음만 먹으면 몇 달러로 DDoS 서비스를 살 수 있고, 호스팅 업체는 서버를 내릴 것임
    이런 이유로 나는 익명 계정으로 글을 쓰고 있음. “작은 사이트라 괜찮다”는 건 보안 전략이 아님

    • DDoS로 인한 다운타임과 CDN이나 외부 서비스 장애로 인한 다운타임을 합치면 어느 쪽이 더 클지 궁금함
      개인 사이트가 잠시 다운돼도 큰 문제는 없다고 생각함
    • 개인 블로그라면 복잡성 제거와 비용 절감이 더 중요하다고 봄
      Cloudflare를 미리 켜두는 건 과한 조기 최적화처럼 느껴짐
    • 블로그가 몇 시간 오프라인 되는 비용은 거의 없음
      누군가 DDoS에 몇 달러 쓰는 것보다 훨씬 작음
    • CDN 뒤에 있지 않으면 서버 IP가 노출되고, 공격자가 똑똑하지 않거나 IP를 바꾸지 않는 이상 방어가 거의 불가능함
    • 예전에 정치적 의견을 말했다가 컨설팅 사이트가 DDoS 공격을 받았던 경험이 있음
      그래서 지금은 가명으로 활동함. 사람들은 생각보다 악의적임

  • 정적 자산을 CDN에 올리면 단일 장애점(SPOF) 에서 벗어나는 셈임
    차라리 내 사이트가 다운될 때 수천 명의 엔지니어가 있는 대기업도 같이 다운되는 게 낫다고 생각함

    • 예전에 Cloudflare 장애가 있었을 때 CEO가 “대응하라”고 했지만, 작은 팀이 수개월 리소스를 쓸 일은 아니었음
      규모에 따라 Cloudflare가 필요 없는 경우도 있지만, 리스크 대비 가치를 따져야 함
    • 기술적 SPOF는 줄지만, 운영 조직의 문화나 정책이 전체 시스템에 영향을 줄 수 있음
      Cloudflare를 쓰면 대부분에게는 합리적이지만, 그만큼 의존성이 생김
    • “Oracle을 선택해도 아무도 해고되지 않는다”는 말처럼, Cloudflare 선택도 비슷한 느낌임
      다만 요즘은 마치 사이버 날씨처럼 장애를 받아들이는 게 이상하게 느껴짐
    • 문제를 남에게 넘기는 것도 일종의 해결책이라는 농담 같은 현실임
    • Cloudflare를 잠시 꺼뒀는데, 오히려 Cloudflare가 다운될 때 내 사이트는 멀쩡했음
      작은 사이트는 캐시 효과도 거의 없어서 성능 이점이 크지 않음

  • 트래픽이 거의 없는 PHP 사이트를 운영 중인데, 봇 트래픽이 너무 많음
    CDN 없이 로컬 캐시만으로는 사이트가 버티지 못함
    예전에 Fastly를 통해 대형 언론사에 소개됐을 때도 CDN 덕분에 문제없이 대응했음

    • Cloudflare 같은 서비스를 벗어나려면 스크래퍼와 봇 통제가 필수임
      하지만 현실적으로 불가능에 가까움. 규제가 생겨도 오히려 더 해로울 수 있음

  • 우리처럼 작은 사이트도 Cloudflare 없이는 악성 요청이 너무 많음
    필터링 없이는 데이터 분석이 엉망이 되고, 비즈니스 파트너와의 협업에도 문제 생김
    Cloudflare 장애 시에도 DNS만 바꾸면 1분 내로 복구 가능했음
    비용이 아깝긴 하지만, 부하분산기 앞단 필터링으로 꽤 만족스러움

    • 다만 원본 IP가 노출되면 직접 공격이 늘어날 수 있음
      방화벽으로 막더라도 CPU 리소스는 여전히 소모됨

  • Cloudflare는 무료이고 설정도 매우 간단함
    사용하지 않을 이유를 모르겠음. 글쓴이는 Cloudflare의 역할을 잘 이해하지 못한 듯함

    • 하지만 모두가 Cloudflare를 쓰면 결국 인터넷의 중앙집중화가 심해짐
      Cloudflare가 인터넷 접근의 심판자가 되는 셈임
    • 이런 중앙화는 걱정스럽지만, 대부분의 사용자에게는 편의성이 더 중요함
    • 개인적으로는 분산화를 선호하지만, 학습용으로 Cloudflare를 써보는 건 좋은 경험임
    • “3년에 한 번, 3시간 다운된다”는 식의 과장된 불만은 의미 없음
    • 독일에서는 저녁 시간대에 Cloudflare 사이트가 절반 이상 접속 불가한 경우도 있음

  • 내 서버는 Facebook, Azure, OpenAI 같은 대형 트래픽에 자주 시달림
    Cloudflare 규칙으로 막고 있지만, 때로는 중국·러시아발 DDoS도 있음
    Cloudflare 말고 이런 복잡한 규칙을 대체할 방법이 있을지 고민임

    • 2000년대 초 내 사이트가 Slashdot에 올라 “slashdotted” 됐지만, 성능 저하는 없었음
      요즘 서버가 너무 약한 것 아닐까 싶음
    • OpenAI의 gptbot 요청이 끊임없이 들어옴
    • 다른 CDN은 공격 표면이 작지만, 그만큼 타깃이 덜 됨
    • 시장이 이미 결론을 냈다는 냉소적인 반응도 있음

  • Cloudflare를 써도 되지만, DNS 등록기관은 Cloudflare에 두지 말아야 함
    우리도 등록기관이 Cloudflare에 있어 잠시 잠금 상태가 되어 복구가 어려웠음
    DNS, 도메인, 인프라 제공자를 분리하는 게 좋음

    • 하지만 요즘은 등록기관과 DNS 제공자도 Cloudflare를 보호용으로 쓰는 경우가 많음
    • DNS 제공자 장애도 위험 요소임. 자가 호스팅은 또 다른 비용과 문제를 낳음

  • Cloudflare 관련 지역 장애는 종종 BGP 문제 때문이었음
    관련 내용은 Cloudflare 블로그와 HN 토론에 있음
    대부분의 사이트는 Cloudflare를 쓰는 게 낫지만, 예측 불가능한 DDoS를 고려하면 완전한 답은 없음

    • “대부분의 사이트가 Cloudflare를 쓰는 게 낫다”는 주장엔 근거 부족이 있음
      어떤 기준으로 “대부분”이라 하는지 궁금함
    • 한 번의 DDoS로 망하지 않음. 필요할 때 Cloudflare를 나중에 켜도 됨
    • Cloudflare는 중앙화와 프라이버시 침해를 초래함
      2017년 데이터 유출 사건을 기억해야 함

  • 나는 집 서버에서 여러 프로젝트를 Cloudflare tunnel로 노출함
    ISP가 고정 IP를 제공하지 않아 동적 DNS를 피할 수 있고, 포트도 열 필요 없음
    캐싱, 속도 제한, 봇 차단을 거의 설정 없이 처리해줘서 편리함

  • 이제 Cloudflare는 “진짜 인터넷”이 아니라 거대한 사설 인트라넷처럼 느껴짐

    • Cloudflare가 어떤 규제를 받는지, 프라이버시 보호는 되는지 의문임
      SSL을 맡기면 패킷을 볼 수 있는지, 정부 기관과 협력하는지도 걱정됨
      인터넷의 분산 모델이 Cloudflare나 SNS로 중앙화된 현실이 안타까움
      연합(federation) 논의가 희망적이지만, 지금은 자율성과 프라이버시를 지키기 어려운 시기임
답변달기